RE : [lwip-devel] [bug #1902] Timeouts and semaphores/mailboxes aretootightly integrated

[Frédéric BERNON]

>If you measure using lwip sys_timeout(), aren't the meassured results 
>inaccurate?

I already do some measures in my real application (using the same dsp to 
compress datas), and in a simple application where the processor is not 
stressed. I always give to tcpip_thread the higher priority.

So, in stressed environment, tcpip_thread is accurate for snmp (I moved 
snmp_timer inside tcpip_thread), even if sometimes, +/- 1ms is observed. But 
"application" timeout (with a 10ms period) get +/- 5ms (50%).

In a "cool" environment, I don't have any problems with timeouts (but, 
application do nothing, just send/recv datas).


>OK, but what does it help if an application timeout is triggered while in an 
>api_lib.c function? You can't do anything about the function call anyway,
>it will go on waiting after the timeout callback has been called. AND you must 
>not call lwip functions in that state or you will REALLY have to know
>what you're doing (and that's what I call hacking, not programming...)

>I think if you need timeouts in applications using multithreading lwip, you 
>have to do it using OS functions directly, not lwip sys-functions.
>This way, we could guarantee lwip function calls are consistent. 

Agree with you. In my case, I directly use my OS for timers and others. It's 
safer and faster. But I don't think that all users share the same point of 
view...

>That we have already taken care of by initializing those timers in 
>tcpip_thread().
Yes, I known, all my "sys_timeouts" are already in tcpip_thread (even the 
igmp_tmr, I will commit it soon).

  
====================================
Frédéric BERNON 
HYMATOM SA 
Chef de projet informatique 
Microsoft Certified Professional 
Tél. : +33 (0)4-67-87-61-10 
Fax. : +33 (0)4-67-70-85-44 
Email : address@hidden 
Web Site : http://www.hymatom.fr 
====================================
P Avant d'imprimer, penser à l'environnement
 


-----Message d'origine-----
De : address@hidden [mailto:address@hidden De la part de Goldschmidt Simon
Envoyé : vendredi 9 mars 2007 10:41
À : lwip-devel
Objet : RE: [lwip-devel] [bug #1902] Timeouts and semaphores/mailboxes 
aretootightly integrated


> Follow-up Comment #3, bug #1902 (project lwip):
> 
> Hi, agree with you.
> 
> More informations, based on "problems" I cause to Dmity and
> others with SO_RCVTIMEO (sorry :( ):
> 
> I do lot of tests and measures to evaluate Dimtry's solution
> (sys_mbox_fetch_timeout based based on 
> sys_mbox_fetch+sys_timeout, like sys_sem_wait_timeout is 
> based on sys_sem_wait+sys_timeout), and in fact, there is not 
> sensible performance difference between his solution and mine 
> (I try on recv and/or write scenarios, with 4Mbps, and with a 
> sys_timeout(10ms) in application to check all the code).

If you measure using lwip sys_timeout(), aren't the meassured results 
inaccurate?

> But, you can increase performance when you replace in
> api_lib.c all sys_mbox_fetch per directly sys_arch_mbox_fetch 
> !! And the code is simpler.

That's true...

> In my case, it's work fine and faster (note, I don't have
> test "select()"), but, if like Dmitry, you have to use 
> internal sys_timeout features in your application level, it's 
> a real problem. But, it's is really good to use lwip 

OK, but what does it help if an application timeout is triggered while in an 
api_lib.c function? You can't do anything about the function call anyway, it 
will go on waiting after the timeout callback has been called. AND you must not 
call lwip functions in that state or you will REALLY have to know what you're 
doing (and that's what I call hacking, not programming...)

I think if you need timeouts in applications using multithreading lwip, you 
have to do it using OS functions directly, not lwip sys-functions. This way, we 
could guarantee lwip function calls are consistent.

> internals features? Perhaps it will prevent to do some futur
> improvements inside lwip core? I don't know. We can talk about that...
> 
> I also think that current timeouts implementation in sys.c -
> even if they help to reduce footprint - are not really 
> efficent (if any internal process take too "long" time, timer 
> would not be accurate), and some timers (arp, dhcp, etc...) 
> would have to be used only in tcpip_thread (the real core 
> stack context when you are in multithread) to be safe-thread.

That we have already taken care of by initializing those timers in 
tcpip_thread().



Simon


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

Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf