Re: [9fans] syscall 53

[ron minnich <rminnich@gmail.com>]

On Mon, May 19, 2014 at 2:30 PM, Charles Forsyth
<charles.forsyth@gmail.com> wrote:

> 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.

I did not want to make this too long, but, sure, everything you say is
quite correct. It's why we considered taking the implementation even
further on NxM, but we stopped that project before we got to that
point. There are way more opportunities for the introduction of jitter
with the old system as opposed to the new, because there are far more
places that you might get to where scheduling can occur. In other
words, again, you're right as rain in what you're saying.

What can I say? We measured it on NxM, were disappointed with the
results from the old way, and happy(er) with the new way.

And, again, I was not inclined to act on any of this until the
discussion on the golang-dev list, which boiled down to:
"if you can do it with a single system call, you should" with a
response of "we put in a patch, was not accepted yet.". I just renewed
the request to reexamine the patch.

ron