Re: Fix FRTO+NewReno problem (Was: Re: This has a work around)

["Damon L. Chesser" <damon@damtek.com>]

[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]

Ilpo Järvinen wrote:
> On Mon, 12 May 2008, Damon L. Chesser wrote:
>
>> I applied the patches in order, no errors on that.  I compiled a stock
>> 2.4.24-1 kernel with the patches, I saw no errors there.
>>
>> booted into new kernel, printed with tcp_frto=0.  set tcp_frto =2, 
>> restarted
>> the network (is this required, or is this a dynamic setting?), 
>> printed from OO
>> document.  No joy.  tcpdump log attached (almost 15 min. worth of data)
>>
>> If you want, I can re-compile and double check for any compilation 
>> errors,
>> however, if there were any, it was not sever enough to stop the 
>> compilation.
>
> On the bright side, the FRTO problem that was occuring previously is 
> now fixed but there seems to be very few ways to communicate with that 
> device sanely because it assumes in-order arrival and keeps 
> discarding, as it seems, _all_ other segments... If you could try with 
> this additional work-around attached (keep the fixes there as well). 
> Turn tcp_frto_inorder_workaround sysctl to 1 before testing with FRTO.
>
> ...Can you please send a dump about working case too, this seems 
> rather nasty device to work with (tcp_frto = 0 is enough to attain it, 
> no need to have another kernel booted for that) and I'm interested to 
> see what are the loss rates without FRTO...
>
>
New patch added in with the first two, tcp_frto_inorder_workaround =1 
test printed 5 pages:  This worked.  Attached is the output of tcpdump.  
Need anything else?

-- 
Damon L. Chesser
damon@damtek.com
http://www.linkedin.com/in/dchesser


[-- Attachment #2: frtoprob6.txt.gz --]
[-- Type: application/x-gzip, Size: 235644 bytes --]