[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [lwip-users] Out Of Order Sequence (Segments?)
From: |
Bill Auerbach |
Subject: |
RE: [lwip-users] Out Of Order Sequence (Segments?) |
Date: |
Tue, 8 Apr 2008 13:21:28 -0400 |
Thanks Jonathan for the detailed reply! I couldn't find anything online
that explained what really is going on.
> Most likely packet loss, and your remote end (the sender) has not
> retransmitted the missing packet yet. It could mean that your receive
> window size is too large for the pbuf space you have available. In other
> words, you are telling the remote end that it can send more data without
> acknowledgement than you actually have room for.
What is hard to determine is what number of pbufs is good? I don't want to
be on the edge, but I don't want to allocate 100 or more that I need.
> That sounds like a port or driver problem (or a bug I haven't
> encountered).
Or a PowerPC problem. There is some kind of problem using a DMA channel to
copy memory from the TSEC BD pointer to data to my data buffer. I know it's
hard to believe, but I don't have problems with a limited number of pbufs if
I use a software copy, or if I use DMA and have about 100 extra pbufs. This
is the reason for the processor freezing with limited pbufs, *not* the OOS
list consuming pbufs.
> > Should there be a #define and a test and for the amount of ooseq's to be
> > allowed to be buffered? If not, what is a practical limit?
>
> Your receive window (TCP_WND in lwipopts.h).
With 65535, that isn't easy to accommodate. Is that number divided by the
MTU a reasonable estimate? If there are so many out of order sequences, I
think I'll have bigger problems (like bandwidth).
> Nothing special should be required by the driver. The bigger problem is
> why it doesn't get to that point.
One thing I didn't do (but wasn't the reason for the lockup) was to release
the BD before returning NULL. I eventually would run out of BDs, but the
processor wouldn't have hung - the DMA memory copying was the cause.
Thanks again!
Bill