Jeff Dike wrote: > [EMAIL PROTECTED] said: >> Something somewhere is buffering a few packets, and dropping the >> rest. When the transfer rate goes high enough and there's no >> physical interface to create delay, the buffer gets full and the >> majority of packets are discarded. However, no dropped counters >> rise on any of the interfaces, nor are any kernel messages printed >> from uml or the host. >> >> Or, there's a locking bug somewhere that stalls the transfer for a >> while every now and then. > > If either of these it true, you should be able to track it down by > tcpdumping both inside and outside the UML and looking at timestamps > for a given packet or seeing which interface is dropping packets.
The problem with the dumping is that since the problems only occur at high transfer speeds, and there's three places to dump from (both virtual machines and host) - all my attempts to get a complete trace of what is happening has been daunted by kernel dropping packets to be tcpdumped since the tcpdump processes have not been able to read them fast enough. I will try again though, with a bit more preparation. -- Naked ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
