On Thu, 7 Feb 2002, Alan Cox wrote:
> Wrong. man ping. ping -f doesn't do what you apparently think it does.
strace ping, you'll see it doing a
setsockopt(7, SOL_SOCKET, SO_SNDTIMEO, [1], 8) = 0
on its socket.
That's about the only way (aside from using a TBF queue, and other non
FIFO queues) you can lose data from a socket's queue.
Getting back to the NFS/UDP example: yes, NFS has its own flow control,
but that's not the point. The reason NFS/UDP works so well with large NFS
packets over a fully-switched *local* subnet is precisely because NFS's
flow control is almost never exercised in that case. Data simply doesn't
get lost -- never in the UDP socket's queue, and very rarely on the wire.
But you don't need to believe me. Just run the ttcp -uts test and explain
how come all the data makes it to the other end (again, over a
fully-switched local subnet) if:
1. ttcp has no clue about the wire speed (which it obviously doesn't) so
it can't do rate limiting
2. the UDP socket simply discards data when some internal queue fills up,
without blocking sendto() and without returning an error.
Moreover: please strace -T that ttcp -uts test, and notice how the time
for the system call goes up by 2 orders of magnitude (i.e. it blocks) as
soon as the socket queue fill up.
Ion
--
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Feb 07 2002 - 21:00:57 EST