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/
This archive was generated by hypermail 2b29 : Tue Jul 23 2002 - 22:00:40 EST