[time-nuts] Cheap jitter measurements
kb8tq at n1k.org
Tue Apr 10 17:40:34 EDT 2018
> On Apr 10, 2018, at 5:05 PM, Dan Kemppainen <dan at irtelemetrics.com> wrote:
> Hi Bob,
> The performance counter does not use the system time calls, NTP, etc. It's an independent counter clocked from raw CPU clock. So you have a ~300pS Timestamping counter in the processor. Why not use that hardware to do the measurement? Does the signal have to exit the PC to measure it?
> Yes, getting ~300pS out of the code calls is probably unrealistic for various reasons, however 300nS should be easily achievable.
One point might that there is a *long* way between 300 ps and 300 ns. Another point would be that the CPU clock architecture is very
different from one brand CPU to the next. If I’m on a 32 bit ARM, I have very different “this and that” than I do on a modern Intel CPU.
I will not dispute the 300 ns number, it’s probably a good guess. The *hope* is that with some sort of software magic, the same sort of
thing can be done here as with GPS modules. You accept that positioning the pulse to 300 ns is “as good as it gets”. You then do this
and that to estimate and report how far off it was.
> If you use the actual NTP PPS capture code with a few extra lines of code added, you should be able to timestamp PPS and NTP values against the performance counter.
The desire would be to get as far away from NTP evaluating it’s self as possible. Yes, this is a bit of a philosophical
sort of thing. If NTP tells us when the pulse was, it’s still very much involved. With a pulse out, one can at least begin to evaluate
what is going on independent of the clock architecture on the CPU and the various things the kernel is (or isn’t) doing.
Why bother? Well, we might learn something about timing …. We might also get a way to produce much more accurate
time pulses out of a system.
If I want to do this same sort of thing with 1588, there are cards out there that will do the job. I plug this one in here
and that one in another system. I grab the PPS outputs from the cards and start testing things. Net result is that I
*can* directly evaluate how well 1588 is doing. Right now with NTP …. not so much.
> Correct me if I'm wrong, but the issue with the GetSystemTime calls is they don't use the performance counters. They are system time related calls and affected by UTC/NTP or other system time adjustments.
> The bigger questions is how does NTP query the serial port? Is it in an actual interrupt routine, or is the data captured via software driven event? (I'm betting on a OS driven event).
> Maybe the Dave Hart patches improve the PPS capture???
> The bottom line is it all depends on now the PPS Capture event is handled, and if that's even predictable enough or stable enough to prove useful. The performance counter is, but getting the PPS code to read the counter is still a software problem.
> If you guys want to take this offline and chat about it further, I'd be happy to discuss this without using up bandwidth here.
> On 4/10/2018 4:01 PM, time-nuts-request at febo.com wrote:
>> Take a look at Dave Hart's patches to the Microsoft serial port driver, that
>> does something similar. The source may be in the NTP distribution, or
>> Meinberg may have a copy. At one time using the QueryPerfomanceCounter call
>> was an option (look for "QPC"). With Windows-8 and later there is a much
>> more precise GetSystemTime call which NTP uses.
>> I played a little with those calls (in a non-serious way) and wrote some
>> based on:
>> and just messing around! Perhaps it's of interest or use?
>> -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-taylor at blueyonder.co.uk Twitter: @gm8arv
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
More information about the time-nuts