[lkml]   [2002]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: want opinions on possible glitch in 2.4 network error reporting
On Fri, 8 Feb 2002, Pavel Machek wrote:

> Hi!
> > > > 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.
> >
> > Read the ping manual page. Then when you understand what ping -f does
> > come back and have a useful conversation.
> But I guess it *would* be usefull to have -F option saying "feed data
> as fast as possible", right? And it would be nice if this option did
> not eat 100% cpu when possible, right?
> So what he is asking for is pretty usefull behaviour.

I'm not asking for it. I'm saying this is what we already have. Too bad
people won't listen -- and yes I know ping -f was a bad example. A
blocking sendto() *will* block (surprise surprise), even though it *might*
throw the data away later on.

Indeed, as Davem stated, a UDP socket will lose data under memory
pressure. In real life this hardly ever happens, however, even with large
message sizes: I just tested with sizes up to 52000, which is just about
as large as you'll ever see in real environments.

Also: I'm just dying to be enlightened about how a dumb program like
ttcp -u, doing a totally dumb "while (1) sendto();", can manage to score
sending rates identical to the raw wire speed, if indeed sendto() never
blocks and simply throws away the data:

apollo:/# ttcp -utsl 53000 zeus
ttcp-t: buflen=53000, nbuf=2048, align=16384/0, port=5001 udp -> sybase2
ttcp-t: socket
ttcp-t: 108544000 bytes in 9.02 real seconds = 11745.26 KB/sec +++
ttcp-t: 2054 I/O calls, msec/call = 4.50, calls/sec = 227.59
ttcp-t: 0.0user 0.2sys 0:09real 2% 0i+0d 0maxrss 0+13pf 0+0csw
zeus:/var/lib/pgsql# ttcp -ursl 53000
ttcp-r: buflen=53000, nbuf=2048, align=16384/0, port=5001 udp
ttcp-r: socket
ttcp-r: 108544000 bytes in 9.03 real seconds = 11741.76 KB/sec +++
ttcp-r: 2050 I/O calls, msec/call = 4.51, calls/sec = 227.08
ttcp-r: 0.0user 0.1sys 0:09real 1% 0i+0d 0maxrss 0+12pf 0+0csw

11745KB/sec sounds suspiciously close to the 100Mb/sec wire speed.

and, for reference, just to make sure ttcp wasn't lying to me:

zeus:/var/lib/pgsql# iptables -L -n -v
Chain INPUT (policy ACCEPT 7217K packets, 3137M bytes)
pkts bytes target prot opt in out source destination
2051 108M udp -- * * udp dpt:5001

But no, it's so much easier to incompletely quote a message and then claim
the other person has no idea about what he's talking about. Yes, Alan,
that's precisely what you did.


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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:24    [W:0.065 / U:5.824 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site