[En-Nut-Discussion] wrong ack on tcp message.

[Harald Kipp]

Grayson,

In general Ethernut seems not to be able to catch
up with the first burst sent by the server. MP3
streaming servers typically keep a few hundred
kilobytes buffer, which is sent immediately after
the connection has been established. This is why
we added extra RAM to Ethernut 2 to be able to buffer
this initial burst.

Are you using Ethernut 2 with banked RAM for MP3
data? If not, you have to stick with lower bitrates.
128 bps will not work with Ethernut 1 boards.


>>Hello Herald.
>>
>>I use version 3.9.2. But saw that there is already a 3.9.3 version.
>>Have a ethereal log file, you can download it at 
>>http://home.wanadoo.nl/gpenzo/nutdump.eth       (142KB)
>>
>>But i discovery other things and made a mistake.
>>
>>1. "ack are sent for packages that do not exist"  Is saw the log and made 
>>a mistake, the server sents dup ack for packages that do not exist yet, 
>>but the nut sends correct ack, see packet nr 290.
>>Do you kow what this could be, are packages routed some where else and 
>>they take along time to arrive??? Still debuging but no clue

In itself, packet 290 looks OK. The server sends
relative ACK of 127, which means, that it expects
relative sequence 127 next. However, empty segments
with ACKs previously sent are considered duplicate
ACKs and used to force the partner to resend a previously
lost segment. This works up to a certain point in the
log you provided. However, when Ethernut tries to get
sequence 42045 again, the server never provides it.
To me it looks like a wrong behavior on the server side,
which is probably caused by Ethernut being far too slow.



>>2. Ack are sent for old packages continuesly.  After packet nr 20 the nut 
>>ack packet nr 19 till packet nr 35,
>>at packet nr 50 the problem is bigger. Is it possible that the stack has 
>>a dead lock or something.

The late ACK doesn't work properly on Ethernut. In fact
it often sends too many ACKs, but that isn't really
harmful.



>>I just look shortly at the code but could not see anything wrong. I willl 
>>run the code today with only what is needed.
>>
>>Grayson Penzo

You may also try to increase the MSS to get better
throughput. As far as I can see, there is no real
trouble with Ethernut's small receive window, but you
may also try to increase this one.

Use NutTcpSetSockOpt() with TCP_MAXSEG and SO_RCVBUF
to adjust these values.

Harald