Re: [ntp:questions] Performance estimation
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) Also, does the Pi really use the full rate processor clock for real time measurement, and is there a slower synchronous logic clock associated with the interface used to receive the external time source? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
On 17/06/2020 00:03, William Unruh wrote: 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. [] Bill, this is a 10 cm ribbon cable at 3.3V TTL levels. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
On 2020-06-16, David Taylor 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=64_id=84 > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
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! https://store.uputronics.com/index.php?route=product/product=64_id=84 -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
Quoting David Taylor: The clock on a Raspberry Pi ranges from 700 to 1500 MHz, so clock resolution is in the nanosecond range. There is mention of 250 MHz as well, which would be 4 nanoseconds. It would be nice to see numbers which distinguish a little better than earlier RPi is "3" and more recent ones are "1"! The system's time (kernel "clocksource") on the RPI is actually not running at the same speed as the CPU clock. From dmesg: arch_timer: cp15 timer(s) running at 19.20MHz (phys). This gives you around 52ns of resolution. I believe it's the same on all the rpi models. I would also like to see whether the characteristics of the GPS and its location make a measurable difference to the RPi's timekeeping. For example: is it better to have a GPS with 3 service capability at a location where the signal is poor, or is it masked by the RPi's performance? All this with kernel-mode PPS. What I've used for this is a percentile of offsets. Looking at the 1% and 99% values on a histogram is an estimate of the system's stability. For instance (not an rpi): https://dan.drown.org/cheese/run3/offset-histogram.png So from that graph, I can say that 98% of the time, the system clock is within +/-80ns of the PPS. I believe you're using ntpd, and my code to generate that graph from ntpd logs is here: https://github.com/ddrown/chrony-graph/tree/ntpd Quoting William Unruh: 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) On different ARM hardware (beaglebone black), I've measured interrupt latency: https://blog.dan.drown.org/content/images/2014/Dec/interrupt-latency.png I'd expect the rpi to have a similar magnitude. Somewhere around +10us delay and 1us jitter. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
On 2020-06-16, David Taylor wrote: > On 15/06/2020 19:00, David Woolley wrote: > [] >> What is the clock resolution? If you try and measure jitters that >> aren't several times the resolution, they are not going to be >> particularly valid. >> >> If the hardware clock is almost dead on, and the peak to peak dither is >> just less than the resolution, there will be long periods in which it >> will read as as zero, even though it is actually close to one resolution >> unit. You could also get cases where dither was very low but read as >> one resolution unit for long periods. In fact, if it was possible to >> find tune the actual clock oscillator, during an ideal lock you would >> have peak to peak dither, as measured, of one or two resolution units, >> even though the actual phase noise was much less. >> >> (Arguably, a jitter that is less than the clock resolution will result >> in worse time accuracy than one that a few times it, as the clock >> resolution will not be dithered out. >> >> That makes the, normally unrealistic, assumption that the systematic >> error is less than the clock resolution.) > > The clock on a Raspberry Pi ranges from 700 to 1500 MHz, so clock > resolution is in the nanosecond range. There is mention of 250 MHz as > well, which would be 4 nanoseconds. It would be nice to see numbers > which distinguish a little better than earlier RPi is "3" and more > recent ones are "1"! > > I would also like to see whether the characteristics of the GPS and its > location make a measurable difference to the RPi's timekeeping. For > example: is it better to have a GPS with 3 service capability at a > location where the signal is poor, or is it masked by the RPi's > performance? All this with kernel-mode PPS. 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) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
Forgot the link: RasPi-1: https://www.satsignal.eu/mrtg/performance_raspi-1.php -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
On 16/06/2020 14:04, Miroslav Lichvar wrote: On 2020-06-16, David Taylor wrote: The clock on a Raspberry Pi ranges from 700 to 1500 MHz, so clock resolution is in the nanosecond range. For best timekeeping performance, you would want to set the CPU frequency to a fixed value. I would also like to see whether the characteristics of the GPS and its location make a measurable difference to the RPi's timekeeping. For example: is it better to have a GPS with 3 service capability at a location where the signal is poor, or is it masked by the RPi's performance? All this with kernel-mode PPS. The interrupt latency of the PPS timestamping is probably much larger than any errors related to GPS, so I'd say it doesn't matter. Oh, sorry, that's the CPU performance range between the models, from earliest to latest. Having said that, some of the [later?] models do operate a varying CPU frequency. Perhaps that's why the offset varies so little on my very earliest RPi: https://www.satsignal.eu/mrtg/performance_raspi-1.php I'm inclined to agree with you about interrupt latency, not to mention the Ethernet being over USB in the earlier models! Still nice to make measurements to see what can be achieved, and the principles are more widely applicable. Good lockdown learning! -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
On 2020-06-16, David Taylor wrote: > The clock on a Raspberry Pi ranges from 700 to 1500 MHz, so clock > resolution is in the nanosecond range. For best timekeeping performance, you would want to set the CPU frequency to a fixed value. > I would also like to see whether the characteristics of the GPS and its > location make a measurable difference to the RPi's timekeeping. For > example: is it better to have a GPS with 3 service capability at a > location where the signal is poor, or is it masked by the RPi's > performance? All this with kernel-mode PPS. The interrupt latency of the PPS timestamping is probably much larger than any errors related to GPS, so I'd say it doesn't matter. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
On 15/06/2020 19:00, David Woolley wrote: [] What is the clock resolution? If you try and measure jitters that aren't several times the resolution, they are not going to be particularly valid. If the hardware clock is almost dead on, and the peak to peak dither is just less than the resolution, there will be long periods in which it will read as as zero, even though it is actually close to one resolution unit. You could also get cases where dither was very low but read as one resolution unit for long periods. In fact, if it was possible to find tune the actual clock oscillator, during an ideal lock you would have peak to peak dither, as measured, of one or two resolution units, even though the actual phase noise was much less. (Arguably, a jitter that is less than the clock resolution will result in worse time accuracy than one that a few times it, as the clock resolution will not be dithered out. That makes the, normally unrealistic, assumption that the systematic error is less than the clock resolution.) The clock on a Raspberry Pi ranges from 700 to 1500 MHz, so clock resolution is in the nanosecond range. There is mention of 250 MHz as well, which would be 4 nanoseconds. It would be nice to see numbers which distinguish a little better than earlier RPi is "3" and more recent ones are "1"! I would also like to see whether the characteristics of the GPS and its location make a measurable difference to the RPi's timekeeping. For example: is it better to have a GPS with 3 service capability at a location where the signal is poor, or is it masked by the RPi's performance? All this with kernel-mode PPS. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
On 15/06/2020 19:58, William Unruh wrote: [] Why would it be useful? What are you trying to do. It is always better to first present the problem rather than trying to get people to improve your solution to an unknown problem. It's not a problem, simply trying to get a better understanding of what the variables are and whether they are useful to measure. If you want to call it a problem, call it the "Performance Estimation" problem. I've been measuring offset for some time, and Gary Miller suggested that jitter might also be a useful measure. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
On 2020-06-15, David Woolley wrote: > On 15/06/2020 15:38, David Taylor wrote: >>> >>> https://www.eecis.udel.edu/~mills/ntp/html/cluster.html > > What is the clock resolution? If you try and measure jitters that > aren't several times the resolution, they are not going to be > particularly valid. > > If the hardware clock is almost dead on, and the peak to peak dither is > just less than the resolution, there will be long periods in which it > will read as as zero, even though it is actually close to one resolution > unit. You could also get cases where dither was very low but read as > one resolution unit for long periods. In fact, if it was possible to > find tune the actual clock oscillator, during an ideal lock you would > have peak to peak dither, as measured, of one or two resolution units, > even though the actual phase noise was much less. >From his graphs this sure seems to be what is going on. The changes in the clock seem to all have 1/2 us resolution, while the clock seems to have 1us resolution. > > (Arguably, a jitter that is less than the clock resolution will result > in worse time accuracy than one that a few times it, as the clock > resolution will not be dithered out. > > That makes the, normally unrealistic, assumption that the systematic > error is less than the clock resolution.) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
On 2020-06-15, David Taylor wrote: > On 15/06/2020 08:33, Miroslav Lichvar wrote: >> On 2020-06-14, David Taylor wrote: >>> When using the ntpq -crv command, which is the better measure of system >>> performance - clk_jitter or sys_jitter? I've look for the definitions >>> and I'm thinking sys_jitter but perhaps someone could please remind me >>> of the difference? >> >> clk_jitter seems to be the jitter of the system clock as it is being >> updated with offsets, and sys_jitter seems to be the jitter of the >> selected peer, or the combined peers after clustering. >> >> https://www.eecis.udel.edu/~mills/ntp/html/cluster.html > >== > > [Been trying to send through e-mail to ntp-questions, but anything I > send gets rejected!] > > Thanks, Miroslav. Right! I'm not sure which I should be measuring so I > plotted both: > >https://www.satsignal.eu/mrtg/performance_ntp_jitter.php > > Blue is system jitter, green is clock jitter. > > The lightly-loaded Raspberry Pi cards are all showing low numbers of > jitter, and it would be really useful to get that in more than three > decimal places of milliseconds. Why would it be useful? What are you trying to do. It is always better to first present the problem rather than trying to get people to improve your solution to an unknown problem. > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
On 15/06/2020 15:38, David Taylor wrote: https://www.eecis.udel.edu/~mills/ntp/html/cluster.html What is the clock resolution? If you try and measure jitters that aren't several times the resolution, they are not going to be particularly valid. If the hardware clock is almost dead on, and the peak to peak dither is just less than the resolution, there will be long periods in which it will read as as zero, even though it is actually close to one resolution unit. You could also get cases where dither was very low but read as one resolution unit for long periods. In fact, if it was possible to find tune the actual clock oscillator, during an ideal lock you would have peak to peak dither, as measured, of one or two resolution units, even though the actual phase noise was much less. (Arguably, a jitter that is less than the clock resolution will result in worse time accuracy than one that a few times it, as the clock resolution will not be dithered out. That makes the, normally unrealistic, assumption that the systematic error is less than the clock resolution.) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
On 15/06/2020 16:10, Miroslav Lichvar wrote: On 2020-06-15, David Taylor wrote: [] The lightly-loaded Raspberry Pi cards are all showing low numbers of jitter, and it would be really useful to get that in more than three decimal places of milliseconds. You would probably need to patch ntpd to report the values in a better precision. Thanks! I recall talking about this some time back and wondered whether anything had actually been done. There was talk of a "wide" version but while that parameter is accepted it doesn't affect the output from "-crv", or "-pn". -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
On 2020-06-15, David Taylor wrote: > [Been trying to send through e-mail to ntp-questions, but anything I > send gets rejected!] The news<->mail gateway has been broken for a very long time, e.g. responses to the mailing list are not getting back to the original posters in the ntp group, so maybe it would be better to turn it off and ask people to subscribe to both if interested. > The lightly-loaded Raspberry Pi cards are all showing low numbers of > jitter, and it would be really useful to get that in more than three > decimal places of milliseconds. You would probably need to patch ntpd to report the values in a better precision. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
On 15/06/2020 08:33, Miroslav Lichvar wrote: On 2020-06-14, David Taylor wrote: When using the ntpq -crv command, which is the better measure of system performance - clk_jitter or sys_jitter? I've look for the definitions and I'm thinking sys_jitter but perhaps someone could please remind me of the difference? clk_jitter seems to be the jitter of the system clock as it is being updated with offsets, and sys_jitter seems to be the jitter of the selected peer, or the combined peers after clustering. https://www.eecis.udel.edu/~mills/ntp/html/cluster.html == [Been trying to send through e-mail to ntp-questions, but anything I send gets rejected!] Thanks, Miroslav. Right! I'm not sure which I should be measuring so I plotted both: https://www.satsignal.eu/mrtg/performance_ntp_jitter.php Blue is system jitter, green is clock jitter. The lightly-loaded Raspberry Pi cards are all showing low numbers of jitter, and it would be really useful to get that in more than three decimal places of milliseconds. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Performance estimation
On 2020-06-14, David Taylor wrote: > When using the ntpq -crv command, which is the better measure of system > performance - clk_jitter or sys_jitter? I've look for the definitions > and I'm thinking sys_jitter but perhaps someone could please remind me > of the difference? clk_jitter seems to be the jitter of the system clock as it is being updated with offsets, and sys_jitter seems to be the jitter of the selected peer, or the combined peers after clustering. https://www.eecis.udel.edu/~mills/ntp/html/cluster.html -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Performance estimation
When using the ntpq -crv command, which is the better measure of system performance - clk_jitter or sys_jitter? I've look for the definitions and I'm thinking sys_jitter but perhaps someone could please remind me of the difference? Are the units for sys/clk_jitter in milliseconds. For my application, more than three decimal digitals would be helpful, i.e. down to nanoseconds. Is there a way to get that from a command-line query? [Similar questions posted to questions@... haven't appeared - yet.] -- Thanks, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
