[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] ERR MEM & TCP_OUT_ORDER

From: Cellule Numerique
Subject: Re: [lwip-users] ERR MEM & TCP_OUT_ORDER
Date: Wed, 30 Nov 2011 22:14:08 +0100


I tested your solution ( if(!(....)) but i m already probleme.
So i try use the fonction Api bool for look the sndbuf when my server no send.
And i have change the Time when tcptmr() is call. The new Time is: 10uS.

My application is more stable ( 5h on run), but the flow isnt stable ( Start at 
23 mbits/s end finish at 21 mbits/s).


Le 29 nov. 2011 à 21:25, Kieran Mansley <address@hidden> a écrit :

> On 28 Nov 2011, at 21:57, Cellule Num wrote:
>> I have a lot of error message with "ERR4N -1" so a ERR MEM but i have 
>> verified the snd_buf.
> You're accessing state that is not part of the API.  You should use 
> tcp_sndbuf() rather than conn->snd_buf directly.  However, I don't think 
> there is a way to get at the sndqueuelen field through the API so I can see 
> why you've done it that way, and it doesn't explain why you get the ERR_MEM 
> from tcp_write().  I think the logic you are looking for is:
> if( ! ( (1440 > tcp_sndbuf(serveur1.tcp_socket)) || 
> (snd_queuelen >=TCP_SND_QUEUELEN) ||
> (snd_queuelen > TCP_SNDQUEUELEN_OVERFLOW) ) )
> which is functionally nearly the same as you have, but I think you've made an 
> error when negating the clause to avoid the runtime-not (which will probably 
> work out to be compile time anyway).
> Try that.  If it still fails with ERR_MEM despite passing the above then let 
> us know.
> The other problem you have is you don't handle err=-4 or err > -9.  Rather 
> than coding checks against integers like that, why not use the ERR_IS_FATAL 
> macro?
> The client acknowledging every other frame is normal.  This is the delayed 
> ack algorithm working, and reducing the number of acknowledgments (and their 
> associated overhead).
> None of this explains why there is such a degradation in performance. Please 
> send the packet capture.  And make it clear which end of the connection (i.e. 
> IP address) is the lwIP device, and which end is not.  If you have a capture 
> that shows the good performance and one that shows the bad performance, that 
> would be great.
> Kieran
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users

reply via email to

[Prev in Thread] Current Thread [Next in Thread]