[net-perf] bad performance w/o jumbo frames over large BDPs

[Michael Sinatra]

Jeff W. Boote wrote:
> Michael Van Norman wrote:
>>> boote at nms1-chin:~[465]$ uname -a
>>> Linux nms1-chin.abilene.ucaid.edu 2.4.25-2.3.6smp #1 SMP Tue Mar 23 
>>> 12:41:02
>>> CST 2004 i686 i686 i386 GNU/Linux
>>>
>>> Not so current... ;)
>>
>> And that may be why it works! :)
>>
>> I don't think we had these problems when we were running a 2.4 kernel and
>> alpha web100 code.  Have you guys tried using the current web100 kernel
>> releases?  Put another way: is there a reason the test nodes are still
>> running code that's over two years old?
> 
> Laziness? If it ain't broke...
> 
> Actually, we are in the process of testing:
> 
> boote at nms-blmt-rtrh2:~[11]$ uname -a
> Linux nms-blmt-rtrh2 2.6.9-42.0.2.ELsmp #1 SMP Thu Aug 17 18:00:32 EDT 
> 2006 i686 i686 i386 GNU/Linux
> 
> This is what we are most likely going to deploy on the new network for 
> our measurement hosts. It has worked fine in the lab, but we have not 
> been able to test any high BW*Delay paths yet. I will be setting one up 
> in Tampa next week for SC. I hope to test from Tampa to current abilene 
> POPs as well as to other new test systems at IU.

If you need high BDP testers, there's a bunch of us out here. :)

Re, the question of whether it makes sense to use such an old kernel: If 
we're mainly interested in testing the *network* with the Abilene nms 
infrastructure, then it doesn't really matter what the test nodes use as 
their kernel/OS, as long as it can push line-rate.  OTOH, what most of 
us are doing is testing both the network and the end hosts (particularly 
tuning of the end hosts), and for that it might make sense to have a 
host in the infrastructure that is likely to be similar to what would be 
on the other end that we are trying to talk to.  It may be possible 
(although unlikely) that there are differences in optimal tuning based 
on what the other host is doing.  The reason I think that may be 
unlikely is that tuning the congestion control algorithm is basically a 
sender-side issue and tuning the window is basically a receiver-side 
issue.  But who knows?

In other words, if we're just interested in making sure there's no 
packet loss on the abilene backbone, then it doesn't matter what the 
nodes use, as long as they do RFC-compliant TCP, so that they're 
approximating the type of production traffic that we would be sending. 
But, if you wanted to provide an infrastructure that helps end sites 
optimally tune their machines, then it *might* be good to use something 
similar to what end-sites are using.

michael