On Thu, 7 Aug 2008, Denys Fedoryshchenko wrote: > On Thursday 07 August 2008, Ilpo Järvinen wrote: > > On Wed, 6 Aug 2008, Dâniel Fraga wrote: > > > On Thu, 31 Jul 2008 15:47:55 +0200 > > > > > > Thomas Jarosch <thomas.jarosch@xxxxxxxxxxxxx> wrote: > > > > If your problem is really FRTO related (that what the patch is for), > > > > you could try to disable FRTO temporarily: > > > > > > Hi, the patch helped, but what's the conclusion? Is the problem > > > "solved"? Will this patch be merged in the next kernel? This thread > > > seems to be forgotten. > > > > I was yesterday preparing the patch description by adding some more > > thoughts to it (as if there weren't enough already) but didn't yet send it > > with new cover (to sort of notify davem). > > > > I give no guarantees about the _next_ kernel but some 2.6.26.y and 2.6.27 > > is more likely bet. > > By the way, i had also problem with frto with local connections, and it was > trivial to reproduce. But because of proprioetary(but i have sources) > userspace application and specific way of using it - i didn't report to > maillist. I could have still looked to it :-), I can mostly decide anything TCP congestion control related based on solely a tcpdump, and I can even read tcpdump -n -r logfile output if you want to fully hide any payloads (as long as the lines are not split to a mess in an email :-)) though then plotting them is not as easy for me (I could hack my tool someday though to handle that as well). But if there is pre-2.6.25.7/2.6.26 kernel involved, then it's obsolete one and requires upgrade or the relevant fixes from 2.6.25.7. > But after patch is ready, add me please in cc, i will test it with > me too. I already sent it, though vger was in some sort of distress, so it might take some time to arrive... > For me disabling frto helps to solve problem. With frto i have > connections "stalling", if there is trasferred large chunks of data over > loopback. It is complicated way how it works all - but i can try to explain > how everything works, if required. Could you just tcpdump over (at least) one stall? ...That would be useful even if you find the patch I sent working because it's always possible that something has been overlooked in FRTO spec or so and I would like to understand the problem rather than just use a workaround which was intented to fix (possibly) other problem... If there's something I cannot figure out from the dump, I'll then consult you about the userspace details. -- i.
