Messages in this thread | | | Subject | Re: 2.2 to 2.4... serious TCP send slowdowns | From | Mika Liljeberg <> | Date | 22 Jul 2002 23:32:55 +0300 |
| |
On Mon, 2002-07-22 at 23:09, Hayden Myers wrote: > Is it possible the window scaling mechanism is slowing us down. Since the > connections are so short the window never scales upwards.
I'm pretty sure the window DOES scale upwards. As I said, you didn't dump the other direction of the connection, which would actually SHOW the advertised window.
The 6432 you're seeing is the server telling the client how much the client is allowed send. Only, the client isn't sending anything. You need to look at what the client is advertising to the server.
> Do you think > I'd benefit by starting off with a larger window?
I don't think so. The transfer is unlikely to be limited by the advertised window. Short TCP connections are constrained by the congestion window, not the advertised window.
> My tests have shown > that the 2.2 can handle more traffic with our application than the 2.4's > I've used so far. I would expect the 2.4 to be faster. I imagine it's a > tuning issue somewhere or an inefficient code issue. I changed the code > for sending files from the disk across the wire from using read and writen > to sendfile and set the tcp cork option with setsockopt but contrary to > everyones messages about it being faster, it slowed things down, more > noticeably in 2.2.
Not sure why you're seeing a difference here and it's hard to say without a complete TCP dump. As far as I can see, the halfdump doesn't exhibit any abnormalities.
This could easily be something completely unrelated to the networking stack, however. You could be limited by file I/O, for instance. Have you tried measuring pure TCP throughput without file access?
MikaL
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |