[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : [lwip-devel] [bug #1902] Timeouts and semaphores/mailboxes aretooti
From: |
Frédéric BERNON |
Subject: |
RE : [lwip-devel] [bug #1902] Timeouts and semaphores/mailboxes aretootightly integrated |
Date: |
Fri, 9 Mar 2007 11:01:22 +0100 |
>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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- RE : [lwip-devel] [bug #1902] Timeouts and semaphores/mailboxes aretootightly integrated,
Frédéric BERNON <=