On Mon, May 19, 2014 at 2:30 PM, Charles Forsyth <charles.fors...@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
