[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: address@hidden
Subject: Re: [lwip-users] TCP bandwidth limited by rate of ACKs
Date: Mon, 17 Oct 2011 18:47:49 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1

Mason wrote:
The STB can now process 2.4 million packets in 5 minutes, which
corresponds to 97.8 Mbps.

Good news! Although (as I said before), some things might not work, yet, with PBUF_REF used for RX packets.

I'm trying to optimize this a bit further, first by attacking
the memcpy for rxapp.

Up to this point, I'd been using the BSD socket API in rxapp
with the following code (error-handling removed).

Interesting that RxTask still uses more CPU time than rxapp although it should be rxapp that copies (RxTask should now be zero copy, right?). Maybe the reason is that RxTask sends the ACK packets, too.

I tried using the Netconn API because I thought it didn't
force a memcpy (is that correct?), but I can't get it to work.
Yes, that's correct. From your example, I guess you're running out of netbufs: if netconn_recv returns success, it passes you a netbuf (the RX data) and it's up to your application to free the buffer when you're done with it.
   struct netconn *conn = netconn_new( NETCONN_TCP );
   netconn_bind(conn, IP_ADDR_ANY, 44044);
   while ( 1 )
     struct netconn *foo;
     while ( 1 )
       struct netbuf *buf;
       err = netconn_recv(foo,&buf);
       if (err) { printf("recv=%d\n", err); break; }

--> Add netbuf_free(buf); here



reply via email to

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