[...]
> I took a look at your dumps, but can't say it's a linux version problem,
> just that one packet gets dropped somewhere in the first connection.
I forgot to post the results of running the tests the other way. As
in, running the client under 2.0.36 and the server on 2.2. It doesn't
look like dropped packets in this case, but things are much much
slower.
Just using one thread at a time, the system call times are
interesting:
FD connect read read read close
5: <1.40198> 1.052 322.509 0.0209961 <0.448975>
5: <0.98999> 1.03601 326.91 0.0209961 <0.405029>
5: <0.964966> 0.977051 327.226 0.019043 <0.403931>
5: <0.974121> 0.985962 327.208 0.0198975 <0.402954>
5: <0.968018> 0.979004 327.182 0.026001 <0.411011>
5: <1.00208> 0.95105 327.094 0.0189209 <0.401978>
The second read take over 300 ms, always. Packets do not seem to be
getting lost in this case, at least not according to these tcpdumps:
Client - http://www.ranney.com/~mjr/lisa_tcpdump2.txt
Server - http://www.ranney.com/~mjr/pornucopia_tcpdump2.txt
The 3 second pause due to dropped packets does occur in this
configuration if you use more than one thread.
-- 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/