> The TCP_TMR_INTERVAL is the time the stack should wait for an ACK from my master, right?
Yes, before it re-transmits. > What is akward to me is that after the retransmission of LWIP which happends in 30-40ms after the first response, the ACK for the response arrives 1ms after the retransmission. That may not be wrong. If the master saw the first transmission, but was delaying it's ACK, then it sees another packet, it may immediately send an ACK. > Could it be that the sys_timeout function is not working properly of my OS which is ecos? It's not that sys_timeout function is incorrect, but that your system seems to think that about 150 microseconds is really 1 millisecond. So your ecos timer *configuration* is probably incorrect, and this looks like the right place to look for an issue. Do NOT raise TCP_TMR_INTERVAL to a large number. The 250ms is good, since many systems use ACK delays of about 200ms. So if lwIP does not see the ACK in 250, it should retransmit. And once ecos is configured correctly, that may work well for you, depending on the delay from your master. However to test the theory that the ecos timer is an issue and to see if the Delayed ACK from the master is arriving after maybe 200ms or 500ms, you could temporarily set TCP_TMR_INTERVAL to higher numbers, and your cycle time to greater than 500ms. Then based on how long the Master delays, you may choose to raise TCP_TMR_INTERVAL to something maybe 50ms above that delay time (and, of course, get the ecos timer configuration fixed). Marty _______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
