Re: [lwip-users] Timing issue with fast interfaces

[Jim Gibbons]

Perhaps your sys_arch_mbox_fetch could maintain a higher resolution, but still meet the needs of its caller.

For example, if sys_arch_mbox fetch held its wait time in microseconds, it could return the milliseconds to sys_mbox_fetch, but continue to accumulate the remaining microseconds.  That is, add the remainder to the microseconds spent waiting for the next message before computing the millisecond value to return.

This should keep pretty reasonable time without requiring an interface change.

Bob Grice wrote:

I've been chasing a problem in LWIP (based on 1.1.0) which while not strictly a bug was causing me issues. The problem is related to the interface between sys_mbox_fetch( ) and sys_arch_mbox_fetch( ).

 

sys_arch_mbox_fetch is required to return the time in milliseconds that it waited for a message, the returned value is then used to reduce the sys_timeout on the next call.

 

With a fast interface (100 MHz), the stack was getting messages for received IP frames faster than one per millisecond. My implimentation in sys_arch_mbox_fetch was returning zero (i.e less than 1 ms) on a large number of the calls, and hence the timeout value was not getting decremented and timeout activity was not occurring.

 

The simplistic fix was to return a minimum value of one in sys_arch_mailbox_fetch, however this then has the side effect of reducing the timeouts.

 

A better solution would be to increase the returned resolution,  but this would then require a change to the sys_timeout structure to add a member for the parts of a millisec, or go through the entire code base changing all the timeout values to the higher resolution. 

_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users

--

Jim Gibbons	address@hidden
Gibbons and Associates, Inc.	TEL: (408) 984-1441
900 Lafayette, Suite 704, Santa Clara, CA	FAX: (408) 247-6395