[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-users] Re: [lwip] lwip-cvs-20011210 problems
From: |
Adam Dunkels |
Subject: |
[lwip-users] Re: [lwip] lwip-cvs-20011210 problems |
Date: |
Wed, 08 Jan 2003 22:20:20 -0000 |
Hi!
On Monday 10 December 2001 13:19, you wrote:
> 1. the timer are running very fast
> tcp_slowtmr(void) should be 500 ms - but in my system it's about 300 ms.
> I havn't a real good idea for that. The only things I found are in the
> new sys_arch_mbox_fetch() and sys_arch_sem_wait() functions:
> These functions must return at least "1", even if they return immediately
> because of waiting messages/semaphores; this may result in a wrong time
> delay - or I am wrong?
You are right that the "1" return value will cause a certain drift, but
hardly not enough to explain the 200 ms error that you see (it would require
that the semaphore was signalled or a message was posted to the mailbox 200
times in 500 ms). Have you been using the unix/sys_arch.c from the earlier
CVS version? I fixed a bug which caused weird timers in the unix sys_arch
just yesterday.
> 2. repeatedly call of sys_sem_signal()
> After setting up my tcp-echo application and getting an incoming call,
> sys_sem_signal() will be called repeatedly from within tcp_slowtmr(),
> ->poll() without subsequent sys_arch_sem_wait() calls!?
This particular problem was because I hand't written all the code that wa
really needed. The problem is because netconn_write() blocks in
sys_sem_wait() if there wasn't enough memory to send the data. The ->poll()
(poll_tcp() in api_msg.c) signals the semaphore at regular intervals, which
causes netconn_write() to try again.
> The application works with the sequential api! All tcp data is received
> and transmitted very well. After disconnection (from remote side) the
> PCB stays in CLOSE_WAIT forever.
It might be a stupid question, but do you close the connection at the lwIP
side? The CLOSE-WAIT state is entered when the remote side has closed the
connection, but the local application hasn't.
If you have closed the connection, the problem most likely is that there
wasn't enough memory to fulfill the close() request, and for some reason
netconn_close() didn't try again as it should.
> Adam: is your sequential api supported in the futere in lwip 0.5 and up?
Yes.
--
Adam Dunkels <address@hidden>
http://www.sics.se/~adam
[This message was sent through the lwip discussion list.]
- [lwip-users] Re: [lwip] lwip-cvs-20011210 problems,
Adam Dunkels <=