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,
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
>>
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
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
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
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 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
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
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
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
On 15/06/2020 19:53, William Unruh wrote:
[]
And why would you think that posting it to the newsgroup would get the
people in charge of the email list?
Do you mean one of the mailing lists listed on
https://lists.ntp.org/listinfo? Which one?
There it says
If you are having trouble using the
11 matches
Mail list logo