On 24/07/2019 08:07, William Unruh wrote:
On 2019-07-24, Jakob Bohm wrote:
On 21/07/2019 16:02, Terje Mathisen wrote:
William Unruh wrote:
...
No. The mechanism is clear. While one is answering its interrupt the
other gets to wait. So, it is the earliest one that is closest to
"right" Ie,
On 21/07/2019 16:02, Terje Mathisen wrote:
William Unruh wrote:
On 2019-07-19, Chris wrote:
On 07/18/19 11:13, William Unruh wrote:
Sure, but I do not have faith in the "averaging" If one is always 30us
after the other, then the average will always be out by 15us.
One would expect a
William Unruh wrote:
On 2019-07-24, Jakob Bohm wrote:
On 24/07/2019 08:07, William Unruh wrote:
On 2019-07-24, Jakob Bohm wrote:
...
A good timing-optimized gps unit, like the original Oncore, have a sw
mechanism to offset the PPS event away from the actual top of the
second, as well as a
> Le 24 juil. 2019 à 11:19, William Unruh a écrit :
>>
>> The hardware under consideration can time the pulse arrivals more
>> precisely than the interrupt delivery time, thanks to special hardware.
That tickled a grey cell. There was/is a timing product family bc635/637 time
and frequency
On 2019-07-24, Jakob Bohm wrote:
> On 24/07/2019 08:07, William Unruh wrote:
>> On 2019-07-24, Jakob Bohm wrote:
...
A good timing-optimized gps unit, like the original Oncore, have a sw
mechanism to offset the PPS event away from the actual top of the
second, as well as a way for
On 2019-07-24, Jakob Bohm wrote:
> On 21/07/2019 16:02, Terje Mathisen wrote:
>> William Unruh wrote:
>>> On 2019-07-19, Chris wrote:
On 07/18/19 11:13, William Unruh wrote:
>
> Sure, but I do not have faith in the "averaging" If one is always 30us
> after the other, then
On 07/21/19 15:02, Terje Mathisen wrote:
William Unruh wrote:
On 2019-07-19, Chris wrote:
On 07/18/19 11:13, William Unruh wrote:
Sure, but I do not have faith in the "averaging" If one is always 30us
after the other, then the average will always be out by 15us.
One would expect a
William Unruh wrote:
On 2019-07-19, Chris wrote:
On 07/18/19 11:13, William Unruh wrote:
Sure, but I do not have faith in the "averaging" If one is always 30us
after the other, then the average will always be out by 15us.
One would expect a difference, but how can you tell which one is
On 2019-07-20, Chris wrote:
> On 07/19/19 21:47, William Unruh wrote:
>
>> No. The mechanism is clear. While one is answering its interrupt the
>> other gets to wait. So, it is the earliest one that is closest to
>> "right" Ie, do not try to use more than one interrupt on the same
>> computer. It
On 07/19/19 21:47, William Unruh wrote:
No. The mechanism is clear. While one is answering its interrupt the
other gets to wait. So, it is the earliest one that is closest to
"right" Ie, do not try to use more than one interrupt on the same
computer. It does not work
I think we are at cross
On Sat, Jul 20, 2019 at 2:26 AM Gabs Ricalde wrote:
>
> On Wed, Jul 17, 2019 at 7:59 PM William Unruh wrote:
> > I suspect it will be a bad outcome. The rpoblem is that you get
> > interrupt contention, and the two interrups will put in time delays into
> > the second one processed.
> >
>
> That
On 2019-07-19, Chris wrote:
> On 07/18/19 11:13, William Unruh wrote:
>
>>
>> Sure, but I do not have faith in the "averaging" If one is always 30us
>> after the other, then the average will always be out by 15us.
>
> One would expect a difference, but how can you tell which one is right
> using
On 07/18/19 11:13, William Unruh wrote:
Sure, but I do not have faith in the "averaging" If one is always 30us
after the other, then the average will always be out by 15us.
One would expect a difference, but how can you tell which one is right
using just 2 pps ?. With three, you could choose
On Wed, Jul 17, 2019 at 7:59 PM William Unruh wrote:
> I suspect it will be a bad outcome. The rpoblem is that you get
> interrupt contention, and the two interrups will put in time delays into
> the second one processed.
>
That was my observation when I did some tests years ago with a single
On 2019-07-17, Chris wrote:
> On 07/17/19 12:59, William Unruh wrote:
>
> > I had some indication that the parallel port was faster.
>
> That would make sense, since the rs232 devices tend to be slew
> rate limited for noise rejection. Found some DS8921 driver / receiver
> devices, originally
On 07/13/19 16:38, Chris wrote:
On 06/20/19 23:39, Chris wrote:
Have a couple of surplus gps based ntp servers that have been
used for time sync in the lab for few years. They are on a UPS
with several hours backup and seems like a good idea to use
them to contribute to the ntp global network.
On 07/17/19 12:59, William Unruh wrote:
> I had some indication that the parallel port was faster.
That would make sense, since the rs232 devices tend to be slew
rate limited for noise rejection. Found some DS8921 driver / receiver
devices, originally designed for hard drive data path use.
On 2019-07-17, Chris wrote:
>
> Next thing to try is the parallel port ack line pps and would be
I had some indication that the parallel port was faster.
> interesting to add a second pps signal to see how that affects the
> result. Interesting project for the summer anyway...
I suspect it
On 06/20/19 23:39, Chris wrote:
Have a couple of surplus gps based ntp servers that have been
used for time sync in the lab for few years. They are on a UPS
with several hours backup and seems like a good idea to use
them to contribute to the ntp global network.
Don't want to expose them
On 06/25/19 19:35, William Unruh wrote:
On 2019-06-25, Chris wrote:
...
Thanks again for the replies. Did a bit of digging this morning and
find that the 1pps sync stuff has been done before. Well, many
years ago in fact and more or less how I had visualised it - ntp
data augmented by the 1
On 06/21/19 15:48, Jakob Bohm wrote:
On 21/06/2019 15:14, Thomas Laus wrote:
On 2019-06-21, David Woolley wrote:
On 21/06/2019 12:26, Thomas Laus wrote:
Will either isolation solution have direct access to the computer
CPU? The GPS clock will need the ability to directly adjust the
frequency
On 06/25/19 10:52, David Taylor wrote:
On 25/06/2019 01:33, Chris wrote:
[]
Thanks for all the replies. I guess the next thing to do is to build
a working system, then evaluate to see how it can be improved. All
the kit is in the same rack and with dedicated hardware interfaces,
network latency
On 06/25/19 11:34, William Unruh wrote:
On 2019-06-25, Chris wrote:
On 06/21/19 15:48, Jakob Bohm wrote:
On 21/06/2019 15:14, Thomas Laus wrote:
On 2019-06-21, David Woolley wrote:
On 21/06/2019 12:26, Thomas Laus wrote:
Will either isolation solution have direct access to the computer
On 21/06/2019 15:14, Thomas Laus wrote:
On 2019-06-21, David Woolley wrote:
On 21/06/2019 12:26, Thomas Laus wrote:
Will either isolation solution have direct access to the computer
CPU? The GPS clock will need the ability to directly adjust the
frequency of the CPU to achieve expected
On 2019-06-21, David Woolley wrote:
> On 21/06/2019 12:26, Thomas Laus wrote:
>> Will either isolation solution have direct access to the computer
>> CPU? The GPS clock will need the ability to directly adjust the
>> frequency of the CPU to achieve expected results for a Stratum 1
>> serve
>
>
On 2019-06-20, Chris wrote:
> Have a couple of surplus gps based ntp servers that have been
> used for time sync in the lab for few years. They are on a UPS
> with several hours backup and seems like a good idea to use
> them to contribute to the ntp global network.
>
> Don't want to expose them
Have a couple of surplus gps based ntp servers that have been
used for time sync in the lab for few years. They are on a UPS
with several hours backup and seems like a good idea to use
them to contribute to the ntp global network.
Don't want to expose them directly to the net, so plan to
On 2019-06-25, Chris wrote:
> On 06/25/19 19:35, William Unruh wrote:
>> On 2019-06-25, Chris wrote:
>> ...
>>>
>>> Thanks again for the replies. Did a bit of digging this morning and
>>> find that the 1pps sync stuff has been done before. Well, many
>>> years ago in fact and more or less how I
On 2019-06-25, Chris wrote:
...
>
> Thanks again for the replies. Did a bit of digging this morning and
> find that the 1pps sync stuff has been done before. Well, many
> years ago in fact and more or less how I had visualised it - ntp
> data augmented by the 1 pps signal. Several pointers to the
On 2019-06-25, Chris wrote:
> On 06/21/19 15:48, Jakob Bohm wrote:
>> On 21/06/2019 15:14, Thomas Laus wrote:
>>> On 2019-06-21, David Woolley wrote:
On 21/06/2019 12:26, Thomas Laus wrote:
> Will either isolation solution have direct access to the computer
> CPU? The GPS clock will
On 25/06/2019 01:33, Chris wrote:
[]
Thanks for all the replies. I guess the next thing to do is to build
a working system, then evaluate to see how it can be improved. All
the kit is in the same rack and with dedicated hardware interfaces,
network latency shouldn't be a problem. This is
On 21/06/2019 12:26, Thomas Laus wrote:
Will either isolation solution have direct access to the computer
CPU? The GPS clock will need the ability to directly adjust the
frequency of the CPU to achieve expected results for a Stratum 1
serve
I'm not aware of anything in ntpd that directly
32 matches
Mail list logo
