lkml.org 
[lkml]   [2002]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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 -- * * 10.2.10.216 0.0.0.0/0 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.

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/

\
 
 \ /
  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