On 14/08/2013 21:20, Rob wrote:
[]
The raspberry pi already does that. It regularly (and on shutdown)
saves the date/time in a file and loads that on boot.
No need to handle this in ntpd. it is done in the /etc/init.d scripts.
Thanks, Rib, I didn't know that. Do you happen to know which
On 14/08/2013 22:07, Harlan Stenn wrote:
David Malone writes:
Indeed - you need to have a timestamp within about ten years of
correct before you start up, otherwise the problem will be worse. Ntp
has the same problem in figuring out the ntp epoch, though we've yet
to see an ntp timestamp wrap
On 14/08/2013 17:44, Rob wrote:
[]
How does a good receiver know the correct time? Does it rely on
local (backed-up) storage, or is there some way of receiving it via
the almanac? Or are good receivers hardwired as well, only with
a different valid span?
I would not be surprised when good
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 14/08/2013 17:44, Rob wrote:
[]
How does a good receiver know the correct time? Does it rely on
local (backed-up) storage, or is there some way of receiving it via
the almanac? Or are good receivers hardwired as well, only with
a
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 14/08/2013 21:20, Rob wrote:
[]
The raspberry pi already does that. It regularly (and on shutdown)
saves the date/time in a file and loads that on boot.
No need to handle this in ntpd. it is done in the /etc/init.d scripts.
On 15/08/2013 08:27, Rob wrote:
The file is /etc/fake-hwclock.data
It is set by the command fake-hwclock save which is in
/etc/cron.hourly/fake-hwclock and in /etc/init.d/fake-hwclock which
is called in the startup and shutdown sequence.
Thanks, Rob, and my apologies for a finger slip
On 15/08/2013 08:34, Rob wrote:
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 14/08/2013 17:44, Rob wrote:
[]
How does a good receiver know the correct time? Does it rely on
local (backed-up) storage, or is there some way of receiving it via
the almanac? Or are good receivers
I am trying to get this right,
remote refid st t when poll reach delay offset jitter
==
oPPS(0) .PPS.0 l4 16 3770.000 -0.003 0.005
*GPS_PALISADE(0) .GPS.
On 2013-08-15, unruh un...@invalid.ca wrote:
On 2013-08-14, Steve Kostecke koste...@ntp.org wrote:
The time server specified in each of those lines is the one which is
currently selected as the sys_peer.
But as I understand it, it is simply one of the systems which is
not a false ticker,
On 2013-08-15, Steve Kostecke koste...@ntp.org wrote:
On 2013-08-15, unruh un...@invalid.ca wrote:
On 2013-08-14, Steve Kostecke koste...@ntp.org wrote:
The time server specified in each of those lines is the one which is
currently selected as the sys_peer.
But as I understand it, it is
On 08/15/2013 07:55 AM, David Taylor wrote:
On 14/08/2013 22:07, Harlan Stenn wrote:
David Malone writes:
Indeed - you need to have a timestamp within about ten years of
correct before you start up, otherwise the problem will be worse. Ntp
has the same problem in figuring out the ntp epoch,
On 08/15/2013 10:22 AM, David Taylor wrote:
On 15/08/2013 08:34, Rob wrote:
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 14/08/2013 17:44, Rob wrote:
[]
How does a good receiver know the correct time? Does it rely on
local (backed-up) storage, or is there some way of
Mark C. Stephens wrote:
remote refid st t when poll reach delay offset jitter
oPPS(0) .PPS. 0 l4 16 377 0.000 -0.003 0.005
*GPS_PALISADE(0) .GPS. 0 l4 16 377 0.0000.014
On 2013-08-15, Magnus Danielson mag...@rubidium.dyndns.org wrote:
On 08/15/2013 10:22 AM, David Taylor wrote:
On 15/08/2013 08:34, Rob wrote:
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
On 14/08/2013 17:44, Rob wrote:
[]
How does a good receiver know the correct time? Does it
On 14/08/13 16:03, Nils Brubaker wrote:
all of whose error intervals overlap and uses the average of those times
as the time to send on the the ntp engine. The others are false
tickers. It estimates the error by looking at the round trip time and
the other machine's estimate of its own max
On 2013-08-15, unruh un...@invalid.ca wrote:
On 2013-08-15, Steve Kostecke koste...@ntp.org wrote:
[---=| Quote block shrinked by t-prot: 42 lines snipped |=---]
The mitigation algorithm proceeds in three steps in turn.
1. If there are no survivors, the modem driver becomes the only
If I have palisade prefer PPS comes up fine within a minute or so.
When I tried making pps prefer it got an x beside the PPS.
I waited for an hour or 2 but it was still marked bad.
Not sure what's going on there..
this is the relevant part of the config:
# PPS
server 127.127.22.0 minpoll 4
On 15/08/2013 20:18, Magnus Danielson wrote:
[]
I do not mention a 500 week period. I mention a 1024 week period with
various phases, 500, 512 and obviously 729 (wrapped this Sunday as we
went into week 1753).
OK, swap period with phase.
Judging by some reports here, people may be using NTP
Mark C. Stephens wrote:
If I have palisade prefer PPS comes up fine within a minute or so.
When I tried making pps prefer it got an x beside the PPS.
I waited for an hour or 2 but it was still marked bad.
Not sure what's going on there..
this is the relevant part of the config:
# PPS
On 15/08/2013 21:33, Magnus Danielson wrote:
[]
They completely avoid it by not numbering it that way. They have their
own numbering scheme that fit's the system, and the conversion over to
UTC is an added feature. It's all in ICD-GPS-200 for the current set of
details, and in the ION red book
20 matches
Mail list logo
