I've got some early SPECWeb [*] results with 2.5.33 and TSO on e1000. I get 2906 simultaneous connections, 99.2% conforming (i.e. faster than the 320 kbps cutoff), at 0% idle with TSO on. For compari
A 10% bump is good. Thanks for running the numbers. Sorry, I should have made a CONFIG switch. Just hack the driver for now to turn it off: -- linux-2.5/drivers/net/e1000/e1000_main.c Fri Aug 30 19:2
Hey, thanks for crossposting to netdev So if i understood correctly (looking at the intel site) the main value add of this feature is probably in having the CPU avoid reassembling and retransmitting.
Quoting David S. Miller: I'll gather netstat -s after runs with and without TSO enabled. Anything else you'd like to see? Yes. My webserver is Apache 2.0.36, which uses sendfile for anything over 8k
Quoting Troy Wilson <tcw@xxxxxxxxxxxxxxxxxxxx>: Troy, this is pointing out the obvious, but make sure you have the before stats as well :)... thanks, Nivedita
Quoting jamal <hadi@xxxxxxxxxx>: Er, even just assembling and transmitting? I'm thinking of the reduction in things like separate memory allocation calls and looking up the route, etc..?? Why do say
Nivedita Singhvi wrote: SpecWeb99 doesnt execute the path that might benefit the most from this patch - sendmsg() of large files - large writes going down.. For those of you who don't know Specweb we
I am not sure; if he gets a busy system in a congested network, i can see the offloading savings i.e i am not sure if the amortization of the calls away from the CPU is sufficient enough savings if i
Quoting jamal <hadi@xxxxxxxxxx>: do you mean sack data being sent as a tcp option? dont know, lots of other questions arise (like timestamp on all the segments would be the same?). most recent (dont
It's the DMA bandwidth saved, most of the specweb runs on x86 hardware is limited by the DMA throughput of the PCI host controller. In particular some controllers are limited to smaller DMA bursts to
From: jamal <hadi@xxxxxxxxxx> Date: Thu, 5 Sep 2002 21:47:35 -0400 (EDT) I am not sure; if he gets a busy system in a congested network, i can see the offloading savings i.e i am not sure if the amor
most recent (dont know how far back) versions of netstat display /proc/net/snmp and /proc/net/netstat (with the Linux TCP MIB), so netstat -s should show you most of whats interesting. Or were you re
Quoting "David S. Miller" <davem@xxxxxxxxxx>: Sure :). The motivation for seeing the stats though would be to get an idea of how much retransmission/SACK etc activity _is_ occurring during Troy's Spe
From: Nivedita Singhvi <niv@xxxxxxxxxx> Date: Thu, 5 Sep 2002 21:20:47 -0700 Sure :). The motivation for seeing the stats though would be to get an idea of how much retransmission/SACK etc activity _
Author: "Martin J. Bligh" <Martin.Bligh@xxxxxxxxxx>
Date: Thu, 05 Sep 2002 23:48:42 -0700
I'm not sure that's entirely true in this case - the Netfinity 8500R is slightly unusual in that it has 3 or 4 PCI buses, and there's 4 - 8 gigabit ethernet cards in this beast spread around differe
From: "Martin J. Bligh" <Martin.Bligh@xxxxxxxxxx> Date: Thu, 05 Sep 2002 23:48:42 -0700 Just to throw another firework into the fire whilst people are awake, NAPI does not seem to scale to this sort
Mala did some testing on this a couple of weeks back. It appears that NAPI damaged performance significantly. http://www-124.ibm.com/developerworks/opensource/linuxperf/netperf/results/july_02/netper
Mala did some testing on this a couple of weeks back. It appears that NAPI damaged performance significantly. http://www-124.ibm.com/developerworks/opensource/linuxperf/netperf/results/july_02/netpe
I looked at those graphs, but the lack of information makes them useless. For example there are too many variables to the tests -- what is the effect the message size? and then look at the socket buf
Hopefully yes... I see other numbers so we have to sort out the differences. Andrew Morton pinged me about this test last week. So I've had a chance to run some tests. Some comments: Scale to CPU can