[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 |
Hi
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).
Pierre
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