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

["Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi>]

On Thu, 8 May 2008, Damon L. Chesser wrote:

> Ilpo Järvinen wrote:
> > SNIP
>
> >
> > Could you next try with tcp_frto set to 1, if my theory proves to be
> > correct, it too should be "enough" to fix the problem (in this particular
> > case). Of course you can verify the patch below too if you want to, the
> > patch should allow cups<->printer to work with tcp_frto = 2 too. In case you
> > have problem to apply the patch to the particular version you're want to try
> > with, just send a note about the version number to me so I can adapt the
> > patch for you (space etc. formatting issues may show up because I recently
> > run a code style cleanup on the tcp code).
>
> reran the print job with the correct kernel (for control reasons) and received
> the same results:  tcp_frto=1 no print.  tcp_frto=0 I can print.  Attached is
> the output of tcpdump
>
> uname -r = 2.6.24-1-amd64

Well, that was a surprise, there must be something else too I didn't yet
notice. I don't think it's that necessary for you to test that patch I
sent earlier (basically the code paths it would have fixed were already in
use with tcp_frto=1). And that patch was "obviously correct" anyway though
it wasn't enough to fix this issue.

...I too can probably reproduce this locally with small amount of work
because the receiver pattern is dead obvious from the logs.

--
i.