Timing issue with fast interfaces

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Timing issue with fast interfaces

Bob Grice
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
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Timing issue with fast interfaces

Christiaan Simons

lwip-users-bounces+christiaan.simons=[hidden email] wrote on 23-11-2005
11:31:30:

> 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.

Well the amount of affected code is probably rather small since
this is only used by the sequential API.

It wouldn't affect the 'lwip/core'
but it might break some userland/contrib code.

I'll note this as a change request.
Is there somebody looking after (maintaining) the sequential API nowadays?

BTW:
I'm not so fond of the sequential API since it's a lousy approximation
of the BSD sockets interface.

Bye,

Christiaan Simons

Hardware / Software Engineer
Axon Digital Design

+31 (0)13 511 66 66
+31 (0)13 511 41 51

http://www.axon.tv


This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named.  If you are not the named addressee you should not
disseminate, distribute or copy this e-mail.



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Timing issue with fast interfaces

Jim Gibbons
In reply to this post by Bob Grice
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 [hidden email] http://lists.nongnu.org/mailman/listinfo/lwip-users

--
E-mail signature
Jim Gibbons
[hidden email]
Gibbons and Associates, Inc.
TEL: (408) 984-1441
900 Lafayette, Suite 704, Santa Clara, CA
FAX: (408) 247-6395



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Timing issue with fast interfaces

Mitani Hiroshi
In reply to this post by Bob Grice
Bob Grice wrote:
> A better solution would be to increase the returned resolution,

Another solution is separating timeout process from mbox/semaphore.
If you use some rtos, it will not be difficult.
--
mitani



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users