[...]
> The client, lisa, gets the first segment from the server, then sits on
> it for 300 ms hoping there'll be another. I'm not too familiar with the
> old 2.0 network code, but this looks like tcp_delack_estimator() is just
> setting ato to 333 ms, and not doing the "quickack" stuff of 2.2.
Interesting that it does this with a 2.2 server and not with a 2.0
server.
> Would you mind summarizing any unexplained behavior? I'm trying to see
> if there's really a problem in the v2.2.2 TCP code, or if you've just
> uncovered some odd interactions among various stacks.
Sure.
2.0.36 client to 2.0.36 server:
Works well. Able to make hundreds of concurrent connections and
move 80Mb/s with larger requests.
2.0.36 client to 2.2.2 server:
300 ms delays on all connections, and frequent packet loss when
making concurrent connections.
2.2.2 client to 2.0.36 server:
Works OK. Performance almost that of 2.0.36<->2.0.36.
Frequent packet loss under load.
2.2.2 client to 2.2.2 server:
Performance almost that of 2.0.36<->2.0.36. Frequent packet loss
under load.
-- Matt Ranney - mjr@ranney.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/