KK, On Fri, 2007-08-06 at 10:36 +0530, Krishna Kumar2 wrote: > I will try that. Also on the receiver, I am using unmodified 2.6.21 bits.
That should be fine as long as the sender is running the patched 2.6.22-rc4 > My earlier experiments showed that even small buffers were filling the > E1000 > slots and resulting in stop queue very often. In any case, I will also > add 1 or 2 larger packet sizes (1K, 16K in addition to the 4K already > there). Thats interesting - it is possible there is transient burstiness which fills up the ring. My observation of your results (hence my comments): for example the buffer size = 8B, TCP 1 process you achieve less than 70M. That is less than 100Kpps on average being sent out. Very very tiny - so it is interesting that it is causing a shutdown. Also note something else strange that it is kind of strange that something like UDP which doesnt backoff will send out less packets/second ;-> I could put a little hack in the e1000 driver to find exact number number of times per run it was shutdown. BTW, another interesting things to do is ensure that several netperfs are running on different CPUs. > I was planning to submit my changes on top of this patch, and since it > includes > a configuration option per device, it will be easy to test with and without > this API. fantastic. > When I ran after setting this config option to 0, the results > were almost identical to the original code. I will try to post that today for > your review/comments. no problem. > > Sorry, been many moons since i last played with netperf; what does > "service > > demand" mean? > > It gives an indication of the amount of CPU cycles to send out a particular > amount of data. Netperf provides it as us/KB. I don't know the internals of > netperf enough to say how this is calculated. I am hoping Rick would comment. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
