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

Submitted by:  Simon Goldschmidt <goldsimon>
Submitted on:  Sun 17 Jan 2010 06:30:29 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: Change RequestStatus: Wont Fix
Privacy: PublicAssigned to: Simon Goldschmidt <goldsimon>
Open/Closed: ClosedPlanned 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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project Administrator
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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 26 Mar 2010 04:43:51 PM UTCgoldsimonStatusNeed Info=>Wont Fix
      Open/ClosedOpen=>Closed
    Tue 09 Feb 2010 08:32:20 PM UTCgoldsimonStatusNone=>Need Info
      Assigned toNone=>goldsimon

    Back to the top


    Powered by Savane 3.1-cleanup1