TCP issue

[Martin Kocian]

Hi,

I actually had Nagle disabled but I think it should not really matter in 
this case because Nagle only applies to buffers that are small enough to
send in one packet:

                 if ((idle || tp->t_flags & TF_NODELAY) &&
                     (tp->t_flags & TF_NOPUSH) == 0 &&
                     len + off >= so->so_snd.sb_cc)
                         goto send;

I was trying to send a large buffer so len + off >= so->so_snd.sb_cc
was false in any case.

Thanks,

Martin


On Tue, 13 Sep 2011, Wesley Eddy wrote:

> It doesn't sound like a bug; it sounds like Nagle is working the way it's 
> supposed to.  You can disable Nagle if it bothers your application.
>
>
> On 9/13/2011 9:16 PM, Joel Sherrill wrote:
>> Martin,
>> 
>> Is the code similar or different in recent FreeBSD? This sounds like a bug 
>> that should have been fixed there. You may be able to go through the BSD 
>> history of that file and see the fix.  It has happened before and we can 
>> hope it happens this time.
>> 
>> --joel
>> 
>> Martin Kocian<kocian at slac.stanford.edu>  wrote:
>> 
>>> 
>>> Hi,
>>> 
>>> I discovered an issue with TCP where RTEMS hangs when after an idle
>>> period it tries to send a small message followed by a large message.
>>> Looking at tcp_output.c I think I understand what's going on:
>>> When TCP is idle for awhile the congestion window gets reset to t_maxseg.
>>> Then the first message I send is smaller than t_maxseg so it is sent out
>>> in a single packet. The receiver (Linux) only sends an ACK on every other
>>> packet so no ACK comes back which means the RTEMS congestion window stays
>>> at t_maxseg.
>>> Now we send a message that is larger than t_maxseg. Len (the number of
>>> bytes to be sent) gets set to congestion window size (t_maxseg) minus
>>> the length of the first (unacknowledged) message.
>>> The conditions in the code to actually send the next packet are:
>>> - len = t_maxseg
>>> - This is the last part in a send and idle or NODELAY set
>>> - Time-out
>>> - We have more then 1/2 the maximum send window's worth of data
>>> - Retransmitting
>>> 
>>> All of the conditions are false so the send hangs until the Linux side
>>> times out and sends the ACK.
>>> This looks like a bug to me but I'm no TCP expert so any confirmation or
>>> suggestion on how to fix this would be greatly appreciated.
>>> 
>>> Thank you,
>>> 
>>> Martin
>>> 
>>> 
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
>> 
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>> 
>> 
>
>
> -- 
> Wes Eddy
> MTI Systems
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>

| Martin Kocian                                       |
| kocian at slac.stanford.edu                            |
| Stanford Linear Accelerator Center                  |
| M.S. 95, P.O. Box 20450                             |
| Stanford, CA 94309                                  |
| Tel. (650)926-2887  Fax (650)926-2923               |