From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <92606a17ce255a2e74049e4090d948b3@proxima.alt.za> <36c5eca0f06e9acbe2fac19067f457d8@ladd.quanstro.net> <20140519195016.B21E6B827@mail.bitblocks.com> <3a6dcbf0845989d60e627ad4e5df4313@ladd.quanstro.net> Date: Mon, 19 May 2014 22:30:35 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=089e0149402448754804f9c779e5 Subject: Re: [9fans] syscall 53 Topicbox-Message-UUID: e8e15c8e-ead8-11e9-9d60-3106f5b1d025 --089e0149402448754804f9c779e5 Content-Type: text/plain; charset=UTF-8 On 19 May 2014 21:54, ron minnich wrote: > jitter-free time Jitter says something about (in)consistency of time periods or intervals. It will be a function of scheduling decisions, not the overhead of a single call. In Nix, on an AP core, sure, because there isn't any scheduling. When there is scheduling of any sort, it's the scheduling that results in the jitter, not either of these two time implementations, surely. You could clearly say "faster", but I'm not convinced about "jitter-free". For instance, you can still be pre-empted for variable time between the invocation of "nsec", its arrival in the kernel, and on return from the kernel before and after return from "nsec". Preventing that is a scheduling matter, with both implementations. --089e0149402448754804f9c779e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 19 May 2014 21:54, ron minnich <rminnich@gmail.com> wrot= e:
jitter-free time

Jitter says something about (in)cons= istency of time periods or intervals. It will be a function of scheduling d= ecisions, not the overhead of a single call.
In Nix, on an AP core, sure, because there isn't any scheduling. When t= here is scheduling of any sort,
it's th= e scheduling that results in the jitter, not either of these two time imple= mentations, surely.
You could clearly say "faster", but I&= #39;m not convinced about "jitter-free". For instance, you can st= ill be pre-empted for variable
time between= the invocation of "nsec", its arrival in the kernel, and on retu= rn from the kernel before and after return from "nsec".
Preventing that is a scheduling matter, with bot= h implementations.
--089e0149402448754804f9c779e5--