Probably -o proto=tcp, or rsize=1024,wsize=1024. I've seen this often enough, and it usually (always, I think, in my experience) means that the UDP packets involved get fragmented and, for whatever reason, at least one of the resulting back-to-back fragments consistently gets dropped. Using TCP instead lets TCP deal with that issue; using rsize=1024,wsize=1024 means that no single request carries enough data to get fragmented in the first place. The reason for the drop varies. I once saw it occurring because the packets were generated at 100Mb, the receiving host was 10Mb, and the dual-speed element in the switch network between them didn't buffer enough. I've also seen it occurring when the receiving Ethernet simply can't handle back-to-back packets. There was even one memorable case where it would strike onjly sometimes; it turned out that the receiving host couldn't handle sufficiently small packets. The sending host padded according to the spec but the receiving host needed slightly more padding than that. (Non-fragmented packets had enough headers to always push them past the limit.) It occurs to me that using a network layer that supports jumbograms end-to-end would probably work, too, but that's unlikely for most of the machines likely to be discussed here. It probably wouldn't. Inter-host X is always done over TCP (well, almost always; I've seen it done over DECnet, and in theory it can be done over any bidirectional flow-controlled reliable-delivery protocol, but these days that pretty much means TCP). A few applications might have performance issues without TCP_NODELAY, but they are rare and the issues are performance, not correctness. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B