LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)
-   -   Ethernet packets vs kernel speed (https://www.linuxquestions.org/questions/linux-networking-3/ethernet-packets-vs-kernel-speed-260997/)

alaios 11-30-2004 01:46 PM

Ethernet packets vs kernel speed
 
Hi.... Today a really strange problem appeared in my mind...

Lets take the following example..
We have ethernet packets of 1250 bytes/packet...
(i use the 1250 number because i make the calculation simpler)

We have 1250*8bits=10.000 bits..
My pc has an 100Mbit ethernet card this means 100.000.000 bits per second... So our ethernet card must transmit data in 100.000.000/10.000= 10.000 packets per second...

I am trying to figure out how a kernel can tolerate with so much traffic... I think/suppose that a packet needs some ms for being handled (i wiil check it later).. If this is true how a kernel can send so much packets when there is not enough time? 1000ms == 1 sec.

PS: I know that the 100Mbit is only a theory based speed and you can not achieve such a number... But stil l my question has not been answered...
Thx a lot...
I hope that your answers will satisfy eveyone :)
Have a nice day

bastard23 11-30-2004 03:26 PM

I think/suppose that a packet needs some ms for being handled (i wiil check it later)..

I think you are referring to the RTT (round trip time) here. There is no reason why you can't send a packet in less than a millisecond. The RTT is device -> wire -> device -> wire -> original device. The 100,000,000 bits/second is the wire speed. If you send UDP (UDP does not require an acknowledge from the recieving device, and neither does ethernet) packets you should be able to get close to wire speed. TCP requires an ACK (acknowledge). So, to get closer to wire speed, TCP sends more than one packet and periodically waits for the ACK. (the TCP window, see http://www.faqs.org/rfcs/rfc1323.html for an indepth look at how TCP handles thourghput.)

Does this answer your question? If not, fire away :)

alaios 12-01-2004 07:49 AM

Fire!
 
Sending packets whatever protocol is needs some cpu-times.... I want to know how big this time is (ms-ns-s e.t.c)
Every packet needs a header a reclculation of some fields as CRC perhaps a lookup to the routing table .... reassembly and packet fragmentation that nees lot of cycles...... So can u think how can handle so many packages?

bastard23 12-02-2004 02:10 AM

So you want to know how much time the kernel takes to build and send a packet right? 36 microseconds on my computer with a mtu of 1000 using the loopback device.

Let's remove the wire from our equations and try it over the loopback device.

# Sending end
$ dd if=/dev/zero bs=100k count=10000|time netcat localhost 1234 -q0
10000+0 records in
10000+0 records out
1024000000 bytes transferred in 23.658508 seconds (43282527 bytes/sec)
0.46user 12.00system 0:23.67elapsed 52%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+176minor)pagefaults 0swaps

# Receiving end
$ /usr/bin/time netcat -l -p 1234 localhost >/dev/null
0.49user 8.35system 0:26.70elapsed 33%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+174minor)pagefaults 0swaps

$ ifconfig lo
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:889854 errors:0 dropped:0 overruns:0 frame:0
TX packets:889854 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4154749315 (3.8 GiB) TX bytes:4154749315 (3.8 GiB)

So we've transfer just under a GB in 23 and some odd seconds on the wall clock. But if we look at the system portion, we see how much time the kernel took. 12 seconds.

1024000000/16436/12 is about 5191 packets a second

Now I've lowered the mtu on my lookback device to 1000:
1024000000 bytes transferred in 71.608342 seconds (14300010 bytes/sec)
0.45user 36.28system 1:11.60elapsed 51%CPU (0avgtext+0avgdata 0maxresident)k

We've increased the amount of time it took to transfer. This is because we have a lot more overhead by sending 16x packets. But our p/s has gone up:

1024000000/1000/37 is about 27675 packets/second.

So, assuming we don't have to wait on a device, the kernel can generate 27kps (tcp, udp is about twice as fast) easily on my lowly PIII. So 1/27675 = .0000361 or about 36 microseconds. You could lower the mtu to 1 byte over the loopback+ip+tcp overhead and try that.

Caveats:
I don't know what the difference between a loopback packet and an ethernet packet is (Or how much is done on the card).
This does not take into account the queuing strategies for keeping the card at "wire" speeds (The card needs to have multiple packets ready to send, or the latency between it and the host cpu will kill the speed.)
Fragmentation and reassembly are checked? They definately aren't happening over the loopback. This is a seperate problem to measure than the above.
Not sure if the loopback device gets to skip the routing table. But my routing table is small, so it doesn't matter.
Others I'm not thinking of. It's late here.

Does this help your thought experiment?


All times are GMT -5. The time now is 09:15 AM.