Date: Tue, 27 Jan 2004 11:41:01 +0000 (GMT) From: Jan Grant <Jan.Grant@bristol.ac.uk> To: Steve Watt <steve@Watt.COM> Cc: julian@elischer.org Subject: Re: send(2) does not block, send(2) man page wrong? Message-ID: <Pine.GSO.4.58.0401271137500.15107@mail.ilrt.bris.ac.uk> In-Reply-To: <200401262059.i0QKxdIi038551@wattres.Watt.COM> References: <E1Al8xj-0002aR-00@roo> <200401262059.i0QKxdIi038551@wattres.Watt.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 26 Jan 2004, Steve Watt wrote: > julian@elischer.org wrote: > >do what ping does (ping -f) > >when you get an ENOBUFS do a usleep for 1 mSec. > >and then send it again. > > So how, exactly, do you actually sleep for 1mSec? I recently did some > experiments using nanosleep(), and it seems that the minimum sleep time > is 2 / HZ. I.e. ask for 100nS, get 20mS (on a 10mS-ticking system). > > Mind you, that behavior is precisely aligned with what POSIX says should > happen, since nanosleep() is not allowed to return success before the > specified amount of time has expired, and you might be calling it 5nS > before the clock tick. But it does make doing correct Tx pacing a bit > more challenging. For what it's worth, when I tried this I wound up using gettimeofday (IIRC) as a "macroscopic" clock and calculating nanosecond sleeps between transmits; drift due to HZ was correctable because I knew the average throughput I was after. -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/ That which does not kill us goes straight to our thighs.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.58.0401271137500.15107>