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 app
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 t
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
o
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 mayb
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 t
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
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_j
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 val
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 wh
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 resoluti
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 t
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 l
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
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 th
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
re
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
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
>> ro
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, et
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 usi
19 matches
Mail list logo
