[ntp:questions] Performance estimation

William Unruh unruh at invalid.ca
Tue Jun 16 23:03:53 UTC 2020


On 2020-06-16, David Taylor <david-taylor at blueyonder.co.uk.invalid> wrote:
> On 16/06/2020 17:11, William Unruh wrote:
> []
>> The question then is how rapidly the system can respond to an
>> interrupt,. This at least used to be of the order of a microsecond.
>> Also, how logd does it take to read the clock with the kernel gettime
>> routines. They all limit the accuracy of your clock using gps refclock > (and also how long the wire is between the gps unit and the computer)
>
> I quick it more a question of variance rather than the absolute time, 
> but I agree with your comment.  Again, with only microsecond reporting 
> and today's processors it's difficult to measure.
>
> To the latter, cable length, well under 5 nanoseconds!

Unless the cables are properly terminated at boththe gps receiver and
the computer, this is probably not true. (the velocity of light may be
under 5ns (ie less than 5 feet between the receiver and the computer)
but the capacitive charging of the cable, etc if not properly terminated
would produce a pulse with a rise time of much longer than that.
Note that it is NOT the antenna that I am refering to, but the cable
connecting the gps pps to the computer and the capacitance in the
receiver in the computer and transmitter in the gps. 
. 

Note that the interrupt latency can be very variable, depending on what
else is happening in the computer. I do not know if on the RPi the
interrupt is processed via interrupt, or via some busy loop to find the
edge of the signal. Since one hardly wants to make the RPI spend all of
its processing reading the input, this will also introduce a grainyness
to the received time. 


>
>  
> https://store.uputronics.com/index.php?route=product/product&path=64&product_id=84
>



More information about the questions mailing list