[En-Nut-Discussion] Suggested modification to nut\net\tcpsm.c again

[ennut at thezachariasgroup.com]

   I have heartache casting the 32 bit result from NutGetMillis() to uint16_t.
   Doesn't it make more sense to define so_retran_time as u_long 
rather than u_short in sock_var.h ?

I didn't look at the code but I would check to see if the u_long 
result from NutGetMillis() is
stored in so_time_wait. If so I would change it to u_long.

   Thoughts?

    Zack



At 04:54 AM 11/12/2009, you wrote:
>Some time ago Zack suggested a modification of the TCP state machine:
>
>http://lists.egnite.de/pipermail/en-nut-discussion/2007-May/008089.html
>
>I assume, that this one fixed the problem at that time. However, recent
>tests showed, that the problem is back again.
>
>I do not have a proof, just a strong feeling that somehow the way
>changed, the GNU compiler does calculations. Wasn't there similar fix
>required during the last months? I'm currently using GCC 4.4.2.
>
>Unfortunately the problem now appears more often after
>
>http://ethernut.svn.sourceforge.net/viewvc/ethernut/trunk/nut/net/tcpout.c?r1=1751&r2=2082
>
>because so_retran_time may be 1 ms ahead.
>
>As a result, Ethernut sends duplicate segments quite often.
>
>Anyone else observed something similar with GCC calculation routines?
>
>The following change seems to fix it.
>
>/*
>  * Process retransmit timer.
>  */
>if (sock->so_tx_nbq && sock->so_retran_time) {
>   uint16_t millis = (uint16_t)NutGetMillis();
>   uint16_t diff = millis > sock->so_retran_time ? millis -
>sock->so_retran_time : sock->so_retran_time - millis;
>   if (diff >= sock->so_rtto) {
>     NutTcpStateRetranTimeout(sock);
>   }
>}
>
>I'm afraid, that there are other parts of the OS/Net code failing with
>the latest GCC.
>
>Harald
>
>
>_______________________________________________
>http://lists.egnite.de/mailman/listinfo/en-nut-discussion