lwip-users
[Top][All Lists]
Advanced

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

RE: [lwip-users] Losing packets


From: Pettinato, Jim
Subject: RE: [lwip-users] Losing packets
Date: Fri, 3 Sep 2004 14:24:51 -0400

Hi Chris,

A comment, and a possible hack/workaround:

I agree. It seems like a major weakness for lwIP to fall back on the
relatively slow recovery times of TCP when we know darn well the hardware
isn't ready to send another packet yet. The stack should be able to handle
the error condition as returned from the low-level driver, and simply retain
the current state and attempt to queue the same packet next time around. It
is one thing to expect that a packet will make it to the receiving end if
you know it was transmitted properly, it is quite definitely another to make
that assumption when you know it wasn't transmitted!

This issue is very much a factor with the SMSC91C111 part, which only has a
4-packet FIFO for both transmitted and received packets.

One thing that might help, if you can afford the effect on the overall
system: In low_level_output(), execute a short delay loop before giving up
on the buffer allocation. I've found that a very brief decrement loop (60 to
0) reduces the incidence of ERR_IF condition having to be returned to nearly
0%.
        .
        .
        .
        // attempt to allocate memory for the TX packet
        len = ((p->tot_len & ~1) + (6 - 1)) >> 8;
        saved_bank = SMSC_BANK;
        SMSC_SELECT_BANK(2);
        SMSC_MMU_CMD_LO = SMSC_MMU_TX_ALLOC | len;
        i = 60;
        // wait briefly for MMU
        do
        {
                if (--i == 0)
                        break;
        } while (!(SMSC_INT_STATUS & SMSC_ALLOC_INT));
        // since we can't hold up the stack, if we've filled the TX FIFO
        // just drop the packet, let the upper layer resend it
        if (!i)
        {
                SMSC_SELECT_BANK(saved_bank);
                lwip_stats.link.drop++;
                return ERR_BUF;
        }
        .
        .
        .

The overall effect is throttling the transmit side of the stack to match the
maximum transmission rate of the hardware, within reason. On a 100Mbps link,
this really works well, especially if the individual packets are
significantly smaller.

- Jim

--

James M. Pettinato, Jr.
Software Engineer
FMC Measurement Solutions/Smith Meter, Inc.
address@hidden
 


-----Original Message-----
On Behalf Of Chris WIlliams
Sent: Friday, September 03, 2004 1:42 PM
To: address@hidden
Subject: [lwip-users] Losing packets


I am losing packets when transmitting:

I am sending packets to my ethernet interface using the
low_level_output() routine in ethenetif.c. I am sending the data very
quickly, and at some point I fill up the buffer in the ethernet chip and I
can't store any more data. I therefore drop the packet, and return ERR_IF.

I assumed that at this point the TCP/IP would stop, and retry again in the
future. However, the returned value from low_level_output() is never
examined and the packet is lost. The next packet is transmitted OK, and then
it takes time for the system to recover.

Does anybody have an comments or a fix for this?

Thanks for your help.

Chris.
-- 
---------------------------------------------------------------------------
| Chris Williams    EMail address@hidden                      |
|                   Tel/Fax  01686 688065                                 |
| Chrysalis Design. Electronics, Computers, Hardware, Software.           |
|                   Design and development to meet all your needs.        |
---------------------------------------------------------------------------


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




reply via email to

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