From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 28 Nov 2012 08:30:49 -0500 To: 9fans@9fans.net Message-ID: <0cf8de222eb5fa81721e8bcf4dd4e875@brasstown.quanstro.net> In-Reply-To: References: <0263c93c2d57900638e664f1b538a76d@brasstown.quanstro.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] sleep(2) historical question Topicbox-Message-UUID: eb277b96-ead7-11e9-9d60-3106f5b1d025 On Wed Nov 28 08:11:43 EST 2012, charles.forsyth@gmail.com wrote: > No, really, I'm quite serious. A grep of /sys/src/cmd/ suggests that > most sleeps are relatively large, and arbitrary. > None of the applications look likely to need microsecond let alone > nanosecond resolution, and that seems reasonable to me. > One exception is sleep(0), but that's yield() you haven't explained how one can emulate a sub-ms sleep with the edf scheduler. i've got a legit problem. and i don't see why the common case has anything to do with this. if you would look at some of the stuff we're doing at coraid (which has actually been written this decade), i think you'll find a number of short sleeps. i've mentioned before that doing realistic timeouts for aoe in userspace would require about a 50-100=C2=B5s sleep, as rtt on 10gbe is in the neighborhood of 10-40=C2=B5s. under the covers, sleep multiplies ms * 1000000 to get ns, and sets a timer. it is a trivial thing that doesn't harm any part of the system to allow one to specifiy ns directly. this is a 100% artificial limit to resolution. also, resolution !=3D precision. and clearly with the type of hardware we've got, 1=C2=B5s is going to be about the limit, and 10=C2=B5s is going to be the practical limit. =20 in 1990 with 20Mhz processors, one couldn't sleep for 1ms, probablly not even 10ms. why do extra zeros on the right bother you? i don't mind them since the resolution of the interface is an absolute limit on how short a sleep i can have. we could if you want specify sleep in 10=C2=B5s units, which would accurately reflect todays hardware. but i'd rather err on the side of too many zeros on the right than the left. - erik