[...]
> If this isn't a known bug, I'd be happy to get some tcpdumps or
> whatever else is required to track it down.
Since this is pretty much stopping me cold, I looked into it some
more. Running with only a single thread at a time causes no "hanging"
behavior, but each individual connection takes noticeably longer than
it does with a 2.0.36 machine. Furthermore, having 2 threads running
is enough to trigger the sucking. I wrapped the connect(), read(),
and close() calls in timers to see where the time was being spent, and
sure enough, there are several ~3 second pauses at various points. Is
3 seconds a magic retry interval perhaps?
Here's a sample output for 6 connections with 2 threads. Lines are
printed when sockets are closed, and times are in milliseconds.
FD connect read read close
6: <1.65308> 1.16003 0.0209961 <0.771973>
6: <0.67395> 1.99194 0.0209961 <0.403931>
6: <0.970093> 1.82898 0.0219727 <0.401978>
6: <1.02795> 1.49609 0.0219727 <0.722046>
6: <0.668091> 1.823 0.0220947 <0.406006>
5: <0.856079> 2994.89 0.0229492 <0.406006>
So as not to burden people that don't care, tcpdumps of this session
can be found here:
Client - http://www.ranney.com/~mjr/pornucopia_tcpdump.txt
Server - http://www.ranney.com/~mjr/lisa_tcpdump.txt
The client is called pornucopia, running 2.2.1. The server is called
lisa, running 2.0.36. Both machines have 512MB of RAM and eepro100's
in FD mode.
-- 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/