[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] gpsd for time sync on Ubuntu remix too hard for normals -
From: |
Greg Troxel |
Subject: |
Re: [gpsd-dev] gpsd for time sync on Ubuntu remix too hard for normals - how to improve? |
Date: |
Mon, 06 May 2019 07:27:24 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (berkeley-unix) |
Hal Murray <address@hidden> writes:
> address@hidden said:
>> Time quality as you think about it does not matter here. If we could sync to
>> within 50 ms, that is completely good enough. We are talking about lining up
>> a ~13s transmission window and a 2s guard time with other stations. People
>> who set their computers manually to WWV can succeed.
>
> I assume the time accuracy determines how far the receiver has to search.
> Does that take a significant amount of CPU time? Or do you just have to stay
> within the guard band?
No significant CPU time issues.
It is not about having to search. This is a mode where people transmit
and receive in alternate 15s chunks. In order for someone else to hear
you, you have to transmit within the window where they are listening
> If your target is 50 ms, I see two problems.
It is not really. That's just a "if we achieve 50 ms, everything is
totally wonderful".
I think 500 ms is good enough. 1s probably, 2s very iffy, 5s not ok.
> The first is that some old but popular receivers have 100 ms error band after
> you correct the offset. Sample here:
> http://users.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif
> My model is that they have a 100 ms clock internally that drives the
> scheduler, or something like that.
I am seeing well within 10 ms with a cheap recent USB dongle, after
calibrating the offset.
> The other is that the offset correction probably depends on the brand/model
> of
> GPS unit you are using. More likely on the chip set behind the label.
Sure.
> At any rate, you setup recipe may need a setup section for each type of GPS
> unit and/or you may want a list of known-good units.
Agreed.
> Things may get a lot easier of you can relax your goals to 100 ms.
There's goal, and there's good enough to work. But a fair point that
the odds of achieving 100ms are much higher than 50, and I probably
should use the 100 ms figure in discussions.
[gpsd-dev] Best way to avoid systemd woes for NTP?, Greg Troxel, 2019/05/05