On Tue, Dec 06, 2005 at 06:08:35PM -0500, jamal wrote: > a 2Ghz dual Xeon hyperthreading (shows up as 4 processors);
Would it be a burden to make for one run with e1000-2.6.15 and hyperthreading turned off? I'm leery of hyperthreading since really messes with cache in a totally different way. I'm not suggesting the results with hyperthreading are invalid. Just observing the huge impace it has on the thing we are trying to measure: effect of cache prefetching. > 512 KB L2 Cache and 1Gig Ram. Two ethernet e1000 82546EB > > tests: > ------ > > Forwarding tests with a single flow into eth0 and another into eth1. > A switch connects the two ports since this is an embedded device. > All load goes onto CPU#0. I didnt try to tune or balance anything > so the numbers could be better than those noted here ok - that's fair. I suspect the hyperthreading case is one where binding the IRQs to particule "CPUs" is necessary to reproduce the results. > All tests send exactly 10M packets burst at wire rate (1.488 MPps) on > each interface. > 4 runs are made; pick the last 3 of 4. > > Results: > -------- > > kernel 2.6.11.7: 446Kpps > kernel 2.6.14: 452kpps > kernel 2.6.14 with e1000-6.2.15: 470Kpps > Kernel 2.6.14 with e1000-6.2.15 but rx copybreak commented out: 460Kpps > > conclusion: > ----------- > > One could draw the conclusion that copybreak is good or prefetch is bad. Like Robert, I conclude that both helped in this case. thanks, grant > There are two other important tests i need to get conclusive results: > > 1) remove prefetch + copybreak > 2) keep copybreak but remove prefetch > > And lastly to just play with different prefetch on/off as Robert did. > > Robert, I did notice some odd behavior with the latest driver - it comes > turned on for some reason with 802 tx and receive flow control. The > switch i have in the middle obeys flow control and so i was getting some > _very_ incosistent results until i turned it off. Example one of the > ethernets would be starved while the other got full traffic etc. > Could you verify if this was affecting your results? > > Also - to the intel folks, any reason this behavior was made default? > > 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
