On Tue, Oct 7, 2008 at 1:24 PM, bill <address@hidden>
wrote:
> Kieran Mansley wrote:
> >> Thank you for any feedback on this.
> >>
> >
> > I don't know of any timers that have that periodicity in lwIP.
> None.
> > It might
> > be useful to get a packet capture from just before the poor
performance
> > that we could look at in ethereal - that might give a clue about why the
> > performance is poor.
> >
> The first thing I would do is to check whether this is a real delay in
> your device or a simple TCP retransmission delay (i.e. the first
> response has a bad checksum or something like that and the PC has to
> wait for the device to retransmit).
> I strongly suspect the latter.
Thanks to both of you. I wanted to add to lwIP_stats
when retransmissions
occur so I know if something was missed or there are errors. I had
trouble
finding where all of the error recovery retransmissions occur.
Is putting debug traces in tcp_rexmit_rto sufficient to catch when they
occur?
One point is truly interesting. I can send 10MB/S (1MB every 100mS) for
~9.5 minutes, or sit for 9 minutes while sending the 836 byte "I'm
here"
packet once per second and then start the 1MB/100mS transfers and at ~9:30
it fails. There have been a few times that I've seen a program crash or
memory corruption but most often the drop in bandwidth is what starts things
off, and it is repeatable (from 9:25 to 9:40). The time seems to start
then
the connection is made. It doesn't matter how long the firmware is
running
before the connection takes place. The connection can be terminated from
the PC and reconnected and it still times out at 9:30 or so from the first
connection. It makes it seem like an uninitialized variable in the
connection management.
Thank you. If I learn anything, I'll let you know. I must resolve
this.
:-)
Bill