buglwIP - A Lightweight TCP/IP stack - Bugs: bug #28652, sockets/netconn: speed up rx by...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #28652: sockets/netconn: speed up rx by calling do_recv asynchronously

Submitter:  Simon Goldschmidt <goldsimon>
Submitted:  Sun 17 Jan 2010 06:30:29 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  Change Request Status:  Wont Fix
Privacy:  Public Assigned to:  goldsimon
Open/Closed:  Closed Planned Release:  None
lwIP version:  CVS Head

Fri 26 Mar 2010 04:43:51 PM UTC, comment #4: 

OK, this doesn't work like I thought and with the solution that can be done (not waiting for recved to return), an embedded OS would only benefit if the netconn/socket thread has a higher priority than the tcpip_thread, which most often is not a good idea anyway...

Closing as won't do.

Simon Goldschmidt <goldsimon>
Group administrator
Fri 12 Feb 2010 03:48:48 PM UTC, comment #3: 

Hmm, that's true for some connections, however, if you know (like for my protocol) that it doesn't hurt, then the current implementation involves thread changes we wouldn't need.

For example, I know that a request received will lead to a response being sent and that there will be no additional data received in between.

Also, I noticed in some traces that wireshark marks "window update" packets red, so it seems to me like packets simply containing window updates should somehow be prevented??

Any other idea how to solve this performance problem? Many times there's not even a packet sent out (due to our new window-update algorithm) but still the thread change is done.

Simon Goldschmidt <goldsimon>
Group administrator
Thu 11 Feb 2010 12:28:01 PM UTC, comment #2: 

Window updates are crucial to getting good performance, and having them only sent as often as the TCP fast timer runs would in some cases really hurt throughput.

Kieran Mansley <kieranm>
Group Member
Tue 09 Feb 2010 08:32:20 PM UTC, comment #1: 

Simply not pending on op_completed while do_recv is running might not do the trick for an embedded OS with static priorities.

The solution favoured by me to implement this is to add a counter of received data to struct netconn or tcp_pcb and increase this counter instead of directly calling do_recv and then somehow letting the tcp-fasttimer handle the window updates.

However, that would leave us either with threading problems (SYS_ARCH_PROTECT etc.) in the tcp-fasttimer or with yet another timer to handle window updates on netconn-level.

Any other ideas? This additional task-switch while receiving socket data is so ugly and slow!

Simon Goldschmidt <goldsimon>
Group administrator
Sun 17 Jan 2010 06:30:29 PM UTC, original submission:  

Currently, during netconn_recv(), do_recv() is called synchronously into the tcpip_thread to update the RX window. This could be done without waiting for the result, which might save one thread-change.

Simon Goldschmidt <goldsimon>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by kieranm (Posted a comment)
  • -email is unavailable- added by goldsimon (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-03-26 goldsimon StatusNeed Info Wont Fix
        Open/ClosedOpen Closed
    2010-02-09 goldsimon StatusNone Need Info
        Assigned toNone goldsimon

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code