Hi Jim, I don't remember the details enough to know if this is normal or not, but trace number 362 is the ACK for seq 172. It has First Packet:145 and Prev Packet: 172. Then the server resends seq 145, and the next ACK has First Packet: 145, Prev Packet: 145. The slowdown starts when this "backup" in the Prev Packet value occurs in the ACK packets.
That may be something to look at? K.C. > Those of you who have been testing the OpenBSD client, please grab the cvs > head, rebuild, and test again. I just fixed a major bug that was preventing > me from even logging in. > > By the way, if any of you rx experts want to look at a tcpdump and tell me > what's wrong, it would be a big help. The client gets stuck in a fetchdata > at about seq no 145. The server retransmits, but then never resumes sending > data where it left off, at seq 173. It pings the client a couple times then > gives up. I don't think the server is at fault. > > tcpdump file is here: > > http://www.citi.umich.edu/u/rees/rx.bin > _______________________________________________ > OpenAFS-devel mailing list > [EMAIL PROTECTED] > https://lists.openafs.org/mailman/listinfo/openafs-devel > _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
