RE: [lwip-users] Re: curious large packets and transmit stuck

[Taranowski, Thomas \(SWCOE\)]

I didn't see any details on what driver/hardware/os you're using, so I'm
making an educated guess...

The problem you describe could potentially be a problem within the
driver.  I could see a scenario where the driver fails to send/transmit
any data because, say, there are no transmit buffers available.  In this
case the driver would fail to send, but be unable to notify that data
was sent, depending on the implementation of the low level driver/stack
interface.  In this case, the stack could be caught in some undefined
state.  The receipt of the ping triggers a transmit, and an interrupt,
and perhaps some other events, depending on the implementation, that
could cause operation to resume, but you'd probably see that some
packets were lost.  

I'd make sure that the driver send call never returns an error
condition.  As a simple test, try increasing the size of the transmit
queue, or whatever you use, for the driver.

You could also increase the size of the PBUF_POOL_BUFSIZE option, so
that the depth of the buffer chain sent to the driver is shorter.  This
could result in fewer transmit buffers being used, depending on your
implementation of course.

-Thomas

-----Original Message-----
From: address@hidden
[mailto:address@hidden
On Behalf Of Andre Puschmann
Sent: Sunday, February 04, 2007 12:06 PM
To: address@hidden
Subject: [lwip-users] Re: curious large packets and transmit stuck

hey guys,
another thing that maybe brings a bit more light is the following. once
the stack is as slow i can burst the things up for another ~300 packets
with a single ping.
after that burst transmission is slow again. but i can do this "trick"
again and again.
i already checked the timer function but they are called frequently.
what can a single ping packet activate in the stack (or its helper
functions)??
any hints??


best regards,

andre


Andre Puschmann wrote:
> hi kieran,
> here are my lwip opts.h and one trace using the netconn-api and
another
> one using the raw api ..
> if you have a look at the first trace (netconn) you can see that the
> packets slowly dropping out/in .. it seems that lwip "forgets" acks
the
> other end send. you can't see the large packets directly, i mean there
> is one large and another small one, but before the stuck all packets
> were 1000bytes long. so it seems that it has something to do with
that.
> if i use the raw api there are no "large" packets .. since as long as
> lwip has something to send it sends packet with max size (1456byte).
but
> nevertheless, after a while the whole system shows the same behavior.
> 
> do you think it has something to do with my timer/semaphore/mbox
> implementation?
> 
> 
> many thanks
> 
> andre
> 
> 
> 
> 1: http://www.puschmann.net/public/dropping_packets_rawapi.cap
> 2: http://www.puschmann.net/public/large_and_small_packet.cap
> 3: http://www.puschmann.net/public/opt.h
> 
> 
> Kieran Mansley wrote:
>> On Tue, 2007-01-30 at 21:56 +0100, Andre Puschmann wrote:
>>> i am aware of this fact. the curious thing IMO is the correlation
>>> between the occurrences of this "larger packets" and the stuck of
the
>>> whole stack.
>> Sounds like you may either have a locking problem (the usual cause of
>> deadlock) or possibly a resource allocation issue.  Is lwIP sending
or
>> receiving the large packet?  Could you get a packet trace using
>> something like ethereal?  Your lwipopts.h configuration might throw
some
>> light on the problem too.
>>
>> Kieran



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