lwIP - A Lightweight TCP/IP stack - Bugs: bug #20506, Initial congestion window is very...
You are not allowed to post comments on this tracker with your current authentication level.
bug #20506: Initial congestion window is very small
Submitter: | Vipin <vipin_dce> | ||
Submitted: | Tue 17 Jul 2007 10:43:15 AM UTC | ||
Category: | TCP | Severity: | 3 - Normal |
Item Group: | Feature Request | Status: | Fixed |
Privacy: | Public | Assigned to: | goldsimon |
Open/Closed: | Closed | Planned Release: | None |
lwIP version: | git head |
Jump to the original submission
Fri 16 Jan 2015 04:49:25 PM UTC, comment #47: |
Simon Goldschmidt <goldsimon> |
Fri 16 Jan 2015 04:31:15 PM UTC, comment #46: I'm reopening this because the fix does not follow RFC 3390, which says:
|
Simon Goldschmidt <goldsimon> |
Thu 23 Aug 2007 07:07:14 AM UTC, comment #45: Dear Simon,
|
Vipin <vipin_dce> |
Wed 22 Aug 2007 08:06:17 PM UTC, comment #44:
|
Simon Goldschmidt <goldsimon> |
Tue 31 Jul 2007 08:55:42 AM UTC, comment #43: I have checked the patch and its working fine at my end. May be it can be closed.
|
Vipin <vipin_dce> |
Wed 25 Jul 2007 07:32:15 AM UTC, comment #42: OK, I've checked in the patch. I'll leave this open for a while (as 'Ready For Test'), but I'd regard it as fixed. |
Simon Goldschmidt <goldsimon> |
Tue 24 Jul 2007 12:37:30 PM UTC, comment #41: Yes (it's the same test than comment #20, and capture files are attached) |
Frédéric Bernon <fbernon> |
Tue 24 Jul 2007 10:42:02 AM UTC, comment #40: What do you mean with 'hack'? Splitting the packets so that 2 packets are transmitted with total amount of data < mss? |
Simon Goldschmidt <goldsimon> |
Tue 24 Jul 2007 09:42:44 AM UTC, comment #39: Ok, for passive open (the case of the http server), it seems to be good. With or without the hack, result is the same (~4ms), with an advantage to "without hack" solution, since the number of packets is smaller.
|
Frédéric Bernon <fbernon> |
Tue 24 Jul 2007 07:54:45 AM UTC, comment #38:
|
Frédéric Bernon <fbernon> |
Tue 24 Jul 2007 07:49:48 AM UTC, comment #37: Sorry I didn't post a patch yet. It's a bit different to your patch (see the attached patch file): It should be 2*mss or 1*mss for both, not 2*mss or cwnd.
|
Simon Goldschmidt <goldsimon> |
Tue 24 Jul 2007 07:35:44 AM UTC, comment #36: Can you confirm the patch I attach is what you want we test? |
Frédéric Bernon <fbernon> |
Tue 24 Jul 2007 06:18:50 AM UTC, comment #35: Yes. Thanks for testing it.
|
Simon Goldschmidt <goldsimon> |
Tue 24 Jul 2007 06:12:37 AM UTC, comment #34: May be the issue can be closed with the solution suggested by Simon & Kieran (if this is what all need to be done).
|
Vipin <vipin_dce> |
Fri 20 Jul 2007 03:01:54 PM UTC, comment #33: The point to change it is line 567 for passive open: ACK (probably including data) received after SYN - SYNACK in state SYN_RCVD.
|
Simon Goldschmidt <goldsimon> |
Fri 20 Jul 2007 09:36:38 AM UTC, comment #32: I'll try that, but it can take a while until I find the time. |
Simon Goldschmidt <goldsimon> |
Fri 20 Jul 2007 09:23:44 AM UTC, comment #31: Yes, set initial cwnd to 2 mss.
|
Kieran Mansley <kieranm> |
Fri 20 Jul 2007 09:20:51 AM UTC, comment #30: To conclude: The speed will be improved if i increase the Congestion window size to 'pcb->cwnd = pcb->mss*2'.
|
Vipin <vipin_dce> |
Fri 20 Jul 2007 09:00:07 AM UTC, comment #29: That's a good link, indeed. It describes our problem very accurate:
|
Simon Goldschmidt <goldsimon> |
Fri 20 Jul 2007 08:34:18 AM UTC, comment #28: This looks rather useful:
|
Kieran Mansley <kieranm> |
Fri 20 Jul 2007 08:27:31 AM UTC, comment #27:
|
Simon Goldschmidt <goldsimon> |
Fri 20 Jul 2007 07:39:14 AM UTC, comment #26: That's a partial solution as there are other places in the stack where it will get set back to 1 mss, e.g. after a packet loss. However, if we could find something (i.e. an RFC) to justify this new minimum value it would certainly be an easy fix. |
Kieran Mansley <kieranm> |
Thu 19 Jul 2007 08:24:53 PM UTC, comment #25:
|
Simon Goldschmidt <goldsimon> |
Thu 19 Jul 2007 08:19:22 PM UTC, comment #24: Another limitation of the example webserver is that it lacks sending the 'Content-Length'. We should include that (actually, it must be included when generating the 'file system')!
|
Simon Goldschmidt <goldsimon> |
Thu 19 Jul 2007 06:18:48 PM UTC, comment #23: Haha, I just discovered tcp_output() is called: it's called from tcp_input() after calling http_recv() (where tcp_write() is called).
|
Simon Goldschmidt <goldsimon> |
Thu 19 Jul 2007 02:38:01 PM UTC, comment #22: Just to give my lwipopts.h values for this test:
|
Frédéric Bernon <fbernon> |
Thu 19 Jul 2007 02:29:22 PM UTC, comment #21: Hmm, that is odd; the size of the application's sends shouldn't make a difference, although I agree that from the traces there it is!
|
Kieran Mansley <kieranm> |
Thu 19 Jul 2007 02:01:39 PM UTC, comment #20:
|
Frédéric Bernon <fbernon> |
Thu 19 Jul 2007 12:45:10 PM UTC, comment #19:
|
Simon Goldschmidt <goldsimon> |
Thu 19 Jul 2007 12:40:14 PM UTC, comment #18: Splitting into two is a dirty hack and shouldn't even be tried. It won't work with many stacks (who count bytes rather than packets for the delayed ack algorithm) so at best is just making your end less efficient.
|
Kieran Mansley <kieranm> |
Thu 19 Jul 2007 12:37:03 PM UTC, comment #17:
|
Simon Goldschmidt <goldsimon> |
Thu 19 Jul 2007 12:29:47 PM UTC, comment #16:
|
Frédéric Bernon <fbernon> |
Thu 19 Jul 2007 12:26:51 PM UTC, comment #15: Sounds like normal behaviour for me. Working out why the small initial window would be interesting, but even a larger one might not make any difference as at the beginning of a connection you'll be in TCP's slow-start phase, and more likely congestion window limited rather than receive window limited.
|
Kieran Mansley <kieranm> |
Thu 19 Jul 2007 12:16:17 PM UTC, comment #14: This really is a problem. But it's not the internet explorer that
|
Simon Goldschmidt <goldsimon> |
Thu 19 Jul 2007 11:53:27 AM UTC, comment #13: Hello all,
|
Vipin <vipin_dce> |
Thu 19 Jul 2007 08:14:18 AM UTC, comment #12: I conducted tests with these changes(ethereal traces are attached):
|
Vipin <vipin_dce> |
Wed 18 Jul 2007 12:50:46 PM UTC, comment #11:
|
Jim Pettinato <jim_pettinato> |
Wed 18 Jul 2007 12:37:22 PM UTC, comment #10:
|
Simon Goldschmidt <goldsimon> |
Wed 18 Jul 2007 12:18:35 PM UTC, comment #9:
|
Frédéric Bernon <fbernon> |
Wed 18 Jul 2007 11:16:28 AM UTC, comment #8:
|
Simon Goldschmidt <goldsimon> |
Wed 18 Jul 2007 11:10:02 AM UTC, comment #7: I think the httpd.c is not the same as lwpi contrib (/contrib/apps/httpserver), but it was in a "obsolete" port I think...
|
Frédéric Bernon <fbernon> |
Wed 18 Jul 2007 11:02:41 AM UTC, comment #6: If I understand you capture (not it will be better to attach the .cap/.acp file), the problem is the delay between the first packet of the HTTP reply and the second :
*/
|
Frédéric Bernon <fbernon> |
Wed 18 Jul 2007 10:57:26 AM UTC, comment #5: Oh, and I'm changing the subject to better reflect the source of the problem. |
Simon Goldschmidt <goldsimon> |
Wed 18 Jul 2007 10:56:07 AM UTC, comment #4: BTW: Attaching an ethereal/wireshark capture file is worth much more than only seeing the image you attached. E.g. we can see the MAC/IP/TCP headers, maybe there are problems there?
|
Simon Goldschmidt <goldsimon> |
Wed 18 Jul 2007 10:09:41 AM UTC, comment #3:
|
Vipin <vipin_dce> |
Tue 17 Jul 2007 12:25:31 PM UTC, comment #2: Can you also provide us your Ethereal capture, and tell us which lwIP release you use (CVS HEAD, 1.2.0...) and the API layer yyou use (socket, netconn, "raw"...)?
|
Frédéric Bernon <fbernon> |
Tue 17 Jul 2007 11:11:41 AM UTC, comment #1: Could you provide us with a little more details about your hardware and the port you are using? Do you have any comparison measurements that would show us how fast your hardware platform could be?
|
Simon Goldschmidt <goldsimon> |
Tue 17 Jul 2007 10:43:15 AM UTC, original submission:
Hello all,
|
Vipin <vipin_dce> |
Depends on the following items: None found
Items that depend on this one: None found
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 25 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2015-01-16 | goldsimon | Status | In Progress | Fixed | |
Open/Closed | Open | Closed | |||
2015-01-16 | goldsimon | Status | Fixed | In Progress | |
Open/Closed | Closed | Open | |||
2007-08-22 | goldsimon | Status | Ready For Test | Fixed | |
Open/Closed | Open | Closed | |||
2007-07-25 | goldsimon | Status | In Progress | Ready For Test | |
2007-07-24 | goldsimon | Attached File | - | Added tcp_in.c.patch, #13448 | |
2007-07-24 | fbernon | Attached File | - | Added tcp_in.patch, #13447 | |
2007-07-24 | goldsimon | Status | None | In Progress | |
Assigned to | None | goldsimon | |||
Summary | HTTP server doesn\'t call tcp_output | Initial congestion window is very small | |||
2007-07-19 | goldsimon | Status | Confirmed | None | |
2007-07-19 | fbernon | Attached File | - | Added with_hack.acp, #13397 | |
Attached File | - | Added without_hack.pcap, #13398 | |||
2007-07-19 | vipin_dce | Attached File | - | Added initial, #13391 | |
Attached File | - | Added TCP_TMR_In100, #13392 | |||
Attached File | - | Added tcp_output_http, #13393 | |||
Attached File | - | Added tcpout_Buffer, #13394 | |||
2007-07-18 | goldsimon | Status | None | Confirmed | |
Summary | LWIP: TCP Layer Performance | HTTP server doesn't call tcp_output | |||
2007-07-18 | fbernon | Category | Contrib | TCP | |
Item Group | Faulty Behaviour | Feature Request | |||
Status | Confirmed | None | |||
Summary | HTTP server doesn\'t call tcp_output | LWIP: TCP Layer Performance |
Powered by Savane 3.13-02a9.
Corresponding source code
Fixed by implementing the formula from RFC3390.