[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] TCP bandwidth limited by rate of ACKs
From: |
Mason |
Subject: |
Re: [lwip-users] TCP bandwidth limited by rate of ACKs |
Date: |
Tue, 11 Oct 2011 16:50:13 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1 |
Simon Goldschmidt wrote:
> Mason wrote:
>
>> I send 58,400,000 bytes from the PC to the STB.
>> This takes 14.25 seconds, i.e. an average of 33 Mbit/s
>>
>> I was expecting to reach 80+ Mbit/s, so I captured the conversation
>> with Wireshark, and I noticed that the sender is being throttled
>> because the receiver (the STB running lwip) is not sending ACKs
>> fast enough.
>
> From reading the wireshark capture, it seems that the receiver simply
> is not fast enough. It correctly sends an ACK for every 2nd data
> packet - no retransmissions involved mean no data dropped. And no
> data dropped normally means no configuration error in lwIP. It's just
> processing 2 data packets while in the same time the sender sends
> three packets.
>
> Where does your expectation of 80+ Mbit/s come from?
I tested with UDP traffic.
I have the PC blasting 40,000 UDP frames at line speed, and the STB
is supposed to reply to each datagram with a bogus "ACK" frame. The
STB does indeed manage to send 40,000 replies.
cf. STB_UDP_RX.pcap at http://dl.free.fr/cZYXFg1Yf
40,000 frames x 1514 bytes in 4.9 seconds
= 8163 packets per second
= 98.9 Mbit/s
(= 100 Mbit/s if we take into account preamble, SoF, and IFG)
So the hardware + driver is indeed able to handle the load.
I must be doing something wrong in my driver when I pass
data to lwip.
> If the hardware
> is really fast enough, you seem to have a bottleneck somewhere in
> your code, supposedly either somewhere around your netif driver or in
> your OS threading? If your netif driver uses PBUF_POOL for rx
> packets, you might want to check that PBUF_POOL_BUFSIZE is large
> enough to hold a complete frame.
In the RX part, I copy the incoming frame :
packet_descriptor *desc = wait_for_next_packet( );
/*** PROCESS THE PACKET ***/
struct pbuf *pbuf = pbuf_alloc(PBUF_RAW, desc->length, PBUF_RAM);
memcpy(pbuf->payload, desc->buffer, desc->length);
mynetif->input(pbuf, mynetif);
I've disabled TCPIP checksum verification with
#define CHECKSUM_CHECK_TCP 0
In the TX part, I copy the outgoing pbuf :
packet_descriptor *desc = get_packet_descriptor( );
assert(p->next == NULL);
memcpy(desc->buffer, p->payload, p->len);
desc->length = p->len;
// add desc to list of frames to send
Do you spot any glaring error?
--
Regards.
- [lwip-users] TCP bandwidth limited by rate of ACKs, Mason, 2011/10/10
- Re: [lwip-users] TCP bandwidth limited by rate of ACKs, Simon Goldschmidt, 2011/10/10
- Re: [lwip-users] TCP bandwidth limited by rate of ACKs,
Mason <=
- Re: [lwip-users] TCP bandwidth limited by rate of ACKs, Kieran Mansley, 2011/10/11
- Re: [lwip-users] TCP bandwidth limited by rate of ACKs, Mason, 2011/10/11
- Re: [lwip-users] TCP bandwidth limited by rate of ACKs, Kieran Mansley, 2011/10/11
- Re: [lwip-users] TCP bandwidth limited by rate of ACKs, Mason, 2011/10/12
- Re: [lwip-users] TCP bandwidth limited by rate of ACKs, Bill Auerbach, 2011/10/12
- Re: [lwip-users] TCP bandwidth limited by rate of ACKs, Mason, 2011/10/12
- Re: [lwip-users] TCP bandwidth limited by rate of ACKs, address@hidden, 2011/10/12
- Re: [lwip-users] TCP bandwidth limited by rate of ACKs, Mason, 2011/10/13
- Re: [lwip-users] TCP bandwidth limited by rate of ACKs, address@hidden, 2011/10/13
- Re: [lwip-users] TCP bandwidth limited by rate of ACKs, Mason, 2011/10/17