On 12/9/2011 1:27 PM, omall...@msu.edu wrote: > > I also just remembered, There is something about windows xp's network > stack isn't as robust (nt was worse) and does have a tendency to drop > packets off the queue (oldest first), versus unix which does just the > opposite. If you make a request from a windows client to your unix > server, then the windows network stack gets overloaded with network > requests or the unix server is overloaded busy already, then windows > times out the oldest request, and then the unix server tries to respond > to the old request, which windows disregards as irrelevent because it is > already off its queue, this could be causing spikes in the AFS > processes. (I can't remember if this just affects tcp or it affects udp > also.)
I'm not sure what the above has to do with this thread. The problems with idle dead are strictly limited to Rx and the service that runs atop it. The Windows AFS client unlike the Unix AFS client is "rx hot threaded" just as the AFS file server is and is less likely to drop incoming packets because it has more than one listener thread to read and process them. The order that packets are dropped on a socket on the Windows platform is determined by the application with the SIO_ENABLE_CIRCULAR_QUEUEING ioctl(). The size of the packet buffers are also set by the application. The rx stack on Windows configures both of these values. Rx connections are reliable. The retries are performed within Rx and not by the underlying UDP/IP layer which is a connectionless. An Rx sender does not drop packets from its transmit queue until the peer has issued both a soft ack (packet received) and a hard ack (packet processed). Regardless of Microsoft's IP packet buffer processing, it does not have an impact on AFS in the way that you describe. Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
