kocian at slac.stanford.edu
Wed Sep 14 02:24:59 UTC 2011
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)
I was trying to send a large buffer so len + off >= so->so_snd.sb_cc
was false in any case.
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:
>> 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.
>> Martin Kocian<kocian at slac.stanford.edu> wrote:
>>> 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,
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>> rtems-users mailing list
>> rtems-users at rtems.org
> Wes Eddy
> MTI Systems
> rtems-users mailing list
> rtems-users at rtems.org
| 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 |
More information about the users