NTPD is at its best from about 2300 local time to 0700 local time. The
net quiets down and NTP packets travel with minimal and highly
predictable delays.
Except at 3 AM when the cron jobs go off and warm up the system.
--
These are my opinions, not necessarily my employer's. I hate spam.
Or one could get a plug computer like http://www.tonidoplug.com and
use a GPS over USB, which works quite well as David proved. I myself
am tempted at one such plug computer just for the geek factor! :-)
Thanks. $99 makes it interesting.
I poked around a bit but did't find what I'm looking
Thanks, Hal. Perhaps I should have been a little more patient! G I
wonder what version of the firmware your unit had?
$PGRMT,GPS 18x-LVC software ver. 2.50*68
It was an early one.
It also seems to have a bug/glitch. After you turn on the PGRMT
stuff, it echos many copies of the
My GPS18x LVC stopped working a couple of days ago. There appears to +5V
going into the unit, and the serial output is stuck around -5V with no
signs of data on the 'scope. Garmin have accepted the unit back for
checking, but I wondered whether anyone else had seen a failure?
I had one do
I never scoped mine but it did give a very poor ntp output by one
of usb-serial I tried (nowhere near that without pps using serial
port on server and much worse than you reported for yours using
usb and Windows) and I had no output at all with other usb-serial
I tried (that works ok connected to
I have a SiRF star III based USB dongle (US GlobalSat BU-353)/plug
that I got a location off of in a basement room about 6 feet from the
window. currently it's attached to box whos' ntpd crashes every time
I
mention it. I think it's talking in the binary mode and the kernel
device
is tuck at the
IF the latency is known to be symmetric ( which it is
on an interplanetary system) then large latency is no
problem.
I don't see how they are likely to have symmetric latency.
e.g.
The earths orbital velocity is something like 67k mph?
mars orbital velocity is something like 54k mph?
So... I'm about to try a couple of Windows solutions
(opportunities) One the Tardis program, that would appear
to be able to take PPS based GPS signals, and act as a server.
Tardis?
Please see:
http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse
In particular, I'd call Dave Plonka's
One thing you could try would be to put your clock in a thermostatically
controlled oven. I'm not talking about something you could bake a pizza
in, but rather something that will keep 140 degrees F +/- half a degree.
140 is pretty warm. That will reduce the lifetime of most
electronics
In article jo03m.17805$xw4.4...@bignews7.bellsouth.net,
Phil p...@x.xxx writes:
Has anyone setup an ntp server using the HP/Symmetricom 58534a ?
I understand it is nmea-0183 with a 1pps output.
Pros, cons ?
I haven't used one. If it's NMEA, the NMEA driver (20) should
work.
Basically,
I'm not sure whether the NMEA driver attempts to send anything /to/ the
GPS device. If not, three lines might to (ground, TX from GPS, PPS),
otherwise four lines are required. If you want to take USB power from the
server (as I now do), it's five lines minimum.
The driver expects the data
In article zu2dnetyfmcp4atxnz2dnuvz_hodn...@giganews.com,
Richard B. Gilbert rgilber...@comcast.net writes:
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
Rob wrote:
Richard B. Gilbert rgilber...@comcast.net wrote:
I
If you need extreme accuracy, you can install a GPS timing receiver,
spend about a month doing a site survey to determine your location to
within plus/minus a foot or two and be certain of the time within a
nanosecond or two.
Radio astronomers, for example, really care about nanosecond
In article a8a58913-1ed4-482d-b54f-2b234905b...@z9g2000yqi.googlegroups.com,
vhfme...@t-online.de writes:
On 25 Mai, 17:37, David J Taylor david-tay...@blueyonder.not-this-
part.nor-this.co.uk.invalid wrote:
1165 hours - 2^32 milliseconds.
Sounds like something rolled over.
Supposedly
In article 4a15e001$0$18238$da0fe...@news.zen.co.uk,
Andy Yates andyy1...@gmail.com writes:
Does anybody have any figures that shows the effect on accuracy of an
NTP v3 client using a stratum 1 server rather than a stratum 2 or 3
server? It's all in a GE LAN based scenario, commercial stratum 1
In article 4a173189$0$18246$da0fe...@news.zen.co.uk,
Andy Yates andyy1...@gmail.com writes:
Hi Hal
Its up to us to specify what we think the SLA should be - the guide is
as accurate as possible!
I think there is an implied at reasonable cost in there.
I've never run a data center nor had to
If you assume a client-server model, from the client's view
there are 4 time stamps:
when the request leaves the client
when the request arrives at the server
when the response leaves the server
when the response arrives at the client
This model makes complete sense. What I'm
...and I'm curious about the timestamps. I don't quite understand the
values presented. I've been pouring through the NTPv4 specification,
but it doesn't provide a great deal of explanation.
If you assume a client-server model, from the client's view
there are 4 time stamps:
when the request
Bug 1183 is resolved in 4.2.5p175, which removes the long-deprecated
typeunit array that meant unit numbers had to be less than 4. In
theory ntpd on Windows should support COM1: through COM255:, and David
Taylor verified COM4: now works.
Thanks.
--
These are my opinions, not necessarily my
In article 3uftl.5045$lc7.2...@text.news.virginmedia.com,
David J Taylor david-tay...@blueyonder.neither-this-bit.nor-this.co.uk
writes:
I don't know if anyone has written a driver which will suit your USB-based
BU353.
The BU-353 uses one of the common serial-USB chips and
speaks the NMEA
In article 8001da0b-3037-491a-a4a4-7a441cff9...@13g2000yql.googlegroups.com,
jack j.jack.w...@gmail.com writes:
Thanks again for your suggestion. It seems Garmin 18X USB can be
tailored to only output certain messages as you said. Hopefully this
will improve the performance. I am going to give
In article c4odnqpbdb1stirunz2dnuvz_thin...@giganews.com,
Richard B. Gilbert rgilber...@comcast.net writes:
ISTR that there have been previous references in this newsgroup.
Specifically, EIDE disk drivers can mask or disable interrupts for a
period long enough to cause a lost tick. I
In article b1inl.26624$oo7.7...@text.news.virginmedia.com,
David J Taylor
david-tay...@blueyonder.not-this-part.nor-this.co.uk.invalid writes:
Hal Murray wrote:
I know it's off-topic, but how far apart in time does two singers, or
choir, have to be before you notice? (No, I'm not suggesting
In article 2mdml.25650$oo7.18...@text.news.virginmedia.com,
David J Taylor
david-tay...@blueyonder.not-this-part.nor-this.co.uk.invalid writes:
I've recent been suggesting the Windows port of NTP as a program suitable
for an application where the timekeeping needed to be within a second or
An greater than 500 PPM suggests seriously broken hardware!
Or software.
--
These are my opinions, not necessarily my employer's. I hate spam.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
In article d25045f8-a596-439c-883b-2a98bd35d...@g31g2000pra.googlegroups.com,
Kat schwar3...@gmail.com writes:
I would like to hack refclock_atom.c to introduce a drift factor in
ppm for a PPS source that I am experimenting with.
I can't figure out how to make fudgetime2 available to this
In article 485551ee-a847-45b6-a040-624dc80ce...@s38g2000prg.googlegroups.com,
cjc yhef...@gmail.com writes:
We have some time servers with GPS clocks. One of their uses is in
operations centers where satellites are being flown. The satellites
use
GPS (as opposed to UTC) internally, so we want the
In article c5391c04-b342-4922-b520-ff862fa38...@v1g2000prd.googlegroups.com,
Kat schwar3...@gmail.com writes:
To try and maintain better accuracy on the ntp server that feeds my
small network and increase the maxtime for server polling, I thought
that I would dig into my scrap box and build a
The programmers think it's obvious. It's not! I can see that the code
swaps the positions of the two bytes in a sixteen bit word. If you
don't include a comment explaining *why* you are swapping the bytes it
makes the code extremely difficult to understand. It may be obvious to
you that
As mentioned in my other posting from today, my final goal is to run NTP
with hardware timestamp support to have a fair comparison to IEEE 1588
for my PhD. (I guess, there won't be much difference, concerning
accuracy) Unfortunately, I couldn't find any implementations (maybe
there is a good
ISTR that PHK has been running NTPD on Soekris single board computers
with the program and O/S (if any) in PROM. When you don't have a file
system or much in the way of hardware and you run a single application,
you don't NEED much of an O/S.
Several OS-es (and/or distributions) can be
It's his privilege to play by his own rules. If he is willing to spend
several months slewing the clock. . . .
I would be tempted to slew the clock at a rate far beyond 500 PPM if I
could figure out how.
Patch the kernel, recompile, install, reboot.1/2 :)
I's suggesting deliberately
Actually, 50E6 seconds is 578 days. It's not out of the question to
have a third clock always sync-ed to GPS, fed off a 48V battery, and
drive it to the data centers twice a year to slave the local oscillators.
Thanks for catching my fat-finger. Yes, that's what I was fishing for.
--
These
Would it matter if the packet colided? NTP is using UDP and I can't
see from the packet analyser that it is expects a response back. When
it does work with a known good machine there is no acknowledgement of
the packet being sent. Do you think that there another level of
operation in the network
How did you compute that? Given that 2^32= ~4*10^9, it's hard to see
how 10^6 hosts spread at random in a 10^9 codespace could achieve 100%
collision probability.
The Birthday Paradox. Google it!
As soon as you have approx sqrt(N) samples out of universe of N values,
the chance of at
Since a regular ntp packet is just 48 bytes without extensions, the idea
that ADSL would make a difference is rather unlikely. The asymmetry is
related to the size of the packets but it affects TCP rather than UDP.
I'm not sure what sort of asymmetry you are thinking of for TCP.
I'm thinking of
In article 49920e17.6050...@tla.org,
n...@tla.org (John Ioannidis) writes:
The problem setup: two locations, both within the United States, neither
has roof access so no GPS reception is possible. How do you synchronize
them with better than 50-microsecond accuracy? Straight NTP over the
gpsd does not perform any filtering at all. it puts the timestamp
data from NMEA and PPS into shared memory and lets ntpd do all the
filtering via the shm driver.
I tweaked the shm driver a while ago. It's in ntp-dev.
It used to grab one sample per polling interval. Now it grabs
one per second
If ntpd knows where you are a single satellite is all that's needed.
No, you also need the appropriate software in the GPS receiver.
That's what makes timing boxes rather than the typical inexpensive
navigation units.
Does anybody know of any timing units that speak NMEA?
--
These are my
It would be interesting to know what kernel version those who are having
trouble with unstable drift in Linux are using. I am using kernel
2.6.27.7, and it is very stable, varying no more than 5 PPM, even across
reboots. It should be noted that I rebuilt my kernel with the timer
frequency set
I've seen a different frequency correction needed after a kernel is
installed.
That wouldn't surprise me. The calibration is a combination
of the hardware and the software. Somebody could easily
fix/tweak the software and change some of the details
of the calculations or the timing. The
Sounds like it is pretty useless for timing (unless you happy with 10s of
msec) No PPS, bluetooth delivery of information with all its latencies and
variability. Why are you advertising it in a time group?
I assumed it was spam. The spammer noticed that GPS had been
mentioned in this group so
Linux seme to be having a real real problem with its time calibration
routines. It's drift rate jumps on reboot by up to 50PPM from one
reboot to the next.
Really? I don't recall ever seeing that.
I thought it was well known. It's been discussed here several/many
times. I've seen jumps much
Seemed I made myself not totally clear: The system has NO network connection
to the outside world, but will be the time source of a little network. (NOT
internet-connected, for security reasons.) NTPDATE (which is deprecated
anyway) does not work with reference clocks, it can query servers
only.
Apparently a number of Linux machines completely locked up at the leap
second. Problems in the kernel ntp.c code apparently.
2 of mine locked up. They were running 2.6.25 and 2.6.26
1 worked. It was running 2.6.23.
Does anybody have any details on the bug or it's fix?
--
These are my
Which NMEA sentence announces the leap second?
I looked in the NMEA documentation from several vendors
and I didn't find anything.
(I guess I should have qualified my comment with no NMEA GPS receiver
advertises leap seconds)
If that's what you meant, I would agree.
But several other GPS
And if it is the frequency that is out ( as it always will be these days of
linux because of the bugs in the kernel frequency standardisation) then
that one step will not kick in until about an hour later ( and the system
could die a horrible death, because the phase offset intially is corrected
I'm missing something. My setup doesn't die. It just steps the clock,
and repeats the drift-off then step dance several times until the drift
gets close enough.
Maybe you aren't running Linux?
That's what I'm running.
--
These are my opinions, not necessarily my employer's. I hate spam.
Garmin specs say: The rising edge of the signal is aligned to the
start of each GPS second. This means edge on assert right? So flag2
should be 0?
Try it the other way and see what happens.
RS-232 signals are active-low so assert may mean low.
--
These are my opinions, not necessarily my
NTP doesn't seem to like 9600 baud with GPGGA. Reach is still zero.
Why are you surprised? NMEA says 4800 so that's what the NMEA driver in
ntpd uses.
I think there may be an option to use 9600. Check the documentation
and make sure it corresponds to the version of ntpd you are running.
--
You are probably detecting the wrong edge (wrong polarity) of the second
pulse.
So how in the world do I fix this?
There is a fudge parameter to use the other polarity.
Prior to having both NEMA and PPS running at the same time all was
working well with just PPS and the shm driver.
That
Another problem with PPS, specifically in the ATOM drivers is that the
driver provides no information about whether or not it is using the PPS
signal.
The ATOM driver can't use anything else so all you can get is
1 bit for working or not. Isn't the reach bit mask good enough
for that?
This is the ntpq -p output from 2 machines connected to Garmin GPS's.
The machines ip's of the 2 machines are 192.168.0.28 and .29. They
are about a millisecond apart! That's no better than the server
without the GPS. What did I do to deserve such lousy performance.?
remote
Okay the ppstest is asserting and clearing but still no ntpq -p reach:
The NMEA driver doesn't look at the PPS until it gets valid data
on the serial port.
What type of GPS unit are you using?
Have you changed any of the default settings? (like baud rate)
--
These are my opinions, not
I'm using Garmin LVC's. I used the windows config program on one of
them and changed the baud rate to 9600, turned the PPS on, and enabled
NEMA 3.x.
The NMEA driver in ntpd is not expecting you to change the baud rate.
There may be some way to configure it to use other baud rates, but I
don't
Maybe. I'm not too familiar with NMEA since the Meinberg GPS clocks mostly
use a different time string format which is compatible with our DCF77
receivers, which have already been existing before the first GPS clocks
became available.
I haven't been able to find any NMEA documentation that
1 - download ftp://time.nist.gov/pub/leap-seconds.3427142400
Is there an other source?
This site appears to be down.
That site is unlikely to be down for long.
Are you behind a NAT box? I need to use the passive mode for ftp.
--
These are my opinions, not necessarily my employer's. I hate
In article 0273857b-9ab1-4aaf-9529-c9b7eb932...@w39g2000prb.googlegroups.com,
dhavey dha...@gmail.com writes:
I ran the code in gdb and this is the stack trace. At refclock_nmea.c:
178 this code causes the crash
nmea_port = atoi(strtok(NULL,:));
I am not really sure of why strtok is used on a
18 Dec 13:11:16 ntpd[11838]: configure: keyword ning unknown, line
ignored
That looks fishy, but I don't know if it has anything
to do with the segfault.
--
These are my opinions, not necessarily my employer's. I hate spam.
___
questions mailing
In article ywn94p108yb7@ntp1.isc.org,
Harlan Stenn st...@ntp.org writes:
I'm glad it is working for you and I'd be even happier if we could figure
out why the NULL string got where it did earlier, as ntpd should never drop
core like that.
It might be just a simple bug. The code in that area
In article 0ea640c4-6e30-457a-8b80-6274ea367...@k36g2000pri.googlegroups.com,
dhavey dha...@gmail.com writes:
I just installed ntp-4.2.4p5 with the nmea patch and this configure:
./configure --disable-all-clocks --disable-parse-clocks \
--enable-NMEA --enable-LOCAL-CLOCK
and it
They take the time from the reflock along with the system timestamp (with
the intent to get the system timestamp as close as possible to the moment
the refclock timestamp is obtained), build the contents of the struct
refclockproc, and call refclock_process().
I think it's slightly more
I have already read http://www.eecis.udel.edu/~mills/ntp/html/howto.html
and started with a copy of refclock_local.c.
But from the documentation it is not clear, in what way the offset
should be calculated and used. E.g.:
offset = ref_clock_time - system_time;
or
offset = system_time -
That's why you normally configure four, five, or seven servers. These
magic numbers protect you against the failure of one, two, or three
servers respectively. Failure can mean anything from not responding
to responding with the wrong year!
That's missing the point I was trying to make.
I think you are assuming here, that the servers will fail one by one
with no one noticing or correcting the problems. This scenario seems
rather unlikely to me. Any publicly available server has hundreds or
even thousands of clients keeping an eye on it. If it goes belly up the
failure
The best way to measure the times in each direction is to setup
good clocks on both ends. You can do that with GPS clocks or
something like an ethernet that is connected to both systems.
Of course in that case you would be far better off to just use those gps
clocks as the time source!
I was
OK, strange. YOu can look at www.theory.physics.ubc.ca/chrony.html to see
the delays on my network-- it is local to a university building, but all
over the building. And I see essentially no difference between computers on
one side or the other. The delays on the 100Mbs parts of the network are on
Is there possibly a way of configuring the maximum acceptable latency of a
packet? That is, as long as you know that for some fraction of the day
(when the system is not under load) your latency is going to be less than
some threshold, say, 2 ms, configuring the system to just throw away all
I expect the delay over the wireless link is symmetric, but it is entirely
plausible that it is not. Are there any good utilities for analyzing the
directional delays of the network? Or would the existence of such a tool
get rid of some of the problems in and of itself.
The best way to measure
Which linux bug causes your frequency to vary? The only frequency issue
I've encountered is a slight variation in the dynamic boot time
measurement of the TSC (time stamp counter) frequency. This problem is
not so much a bug in my opinion and is easily fixed by changing the
clock source to
1) When the operating conditions suddenly change, the system diverges
dramatically, and sometimes becomes unstable/divergent. In particular, a
pathological case we have seen is when the wireless link is near saturation
for an extended period of time such as when copying over multi-gigabyte log
A 50PPM frequency error produces over a 100ms error in the system time,
before it settles down with a half life of about 1 hour. That means it
takes 6 hours to get rid of that 100ms error.
Even a non-timgeek might notice that.
The non time geeks I've worked with wouldn't notice anything
By staggered do you mean that none may live in the same stratum?
Staggered means all at different strata.
Correctly staggered adds the constraint that they must differ by at
least two from each other, as well.
Why do they need to differ by steps of 2?
--
These are my opinions, not
If you have an isolated network, it will drift unless you
have a local refclock. You can get a low cost GPS unit for
under $100.
On the other hand, you should be able to tune the drift
file by hand so that it is within a few seconds per day.
I don't know of a good description of how to do that.
2)then after logging as root i typr ntpd nothing is output.
It normally starts up in server mode. If you do a ps ax
you will probably see an ntpd running.
3)then i type ntpq i get the message:
ntpq:connect:network is unreachable
That's probably trying to tell you that somebody is already
I'm running CentOS 5 on my system and the only clock source I have available
is jiffies. Newer kernels should give you options like: acpi_pm jiffies hpet
tsc pit.
I've been happier since I added
clocksource=acpi_pm
to the boot command line.
TSC is the default, at least on most of the systems
I have three inhouse GPS receivers, in three separate cities. Each city
has two FreeBSD-based ntp servers, one of which is currently connected
to the local GPS, but the other is pre-configured so that in case of a
primary server crash, the serial cable can be moved over.
What sort of GPS
ntpd needs port 123 UDP open in order to receive the replies to its
polls, or broadcast packets.
That's the way the current code operates.
If you are running in client only mode, you don't really need
to use port 123 on the local system. It could use any port number,
but it might take a while
In article [EMAIL PROTECTED],
Steve Kostecke [EMAIL PROTECTED] writes:
On 2008-11-06, fenwayfool [EMAIL PROTECTED] wrote
Some time servers will not accept connections when the source port is
not 123.
Which ones?
I think that would complicate debugging. For example, I couldn't run
ntpdate in
Try switching it off, changing the value int he drift file by say
50PPM and
then switching it on again, and see how long it takes to recover from
that.
Why would I do that? The drift values rarely change by more than five,
certainly not by 50. If you are seeing a change of 50, then perhaps
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (David Cureton) writes:
Hi,
I am syncing a Linux 2.6.26 kernel to a Serial DCD PPS GPS source.
The kernel time has been running for quite some time with a ~160ppm
frequency error however inexplicably the ppm error over night simply
jumped to
Note, if you are running gps, why have a poll level 6? The recommendation
for ref- clocks is poll level 4?
Where/who does that recommendation come from?
--
These are my opinions, not necessarily my employer's. I hate spam.
___
questions mailing
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (John Ackermann N8UR) writes:
I am trying to configure my masquerading (NAT) firewall to allow the
outside world to see one of my internal servers. (The firewall is a
Linux system running fairly ancient Linux Router Project code).
I've set up what
Quite. A lot of people also use Google groups.
A lot of people ignore/drop everything from google-groupes
because they emit too much spam.
--
These are my opinions, not necessarily my employer's. I hate spam.
___
questions mailing list
That was what he said worst case initial error He should have said
127.999msec though I think:-)
Actually it is NOT the worst case scenario. Try a drift which is seriously
off instead. That takes much longer to settle down. First ntp has to notice
that the drift is off, and then has to start
It is more like 20m. And even for 2000km (Vancouver to Regina) on the
public CanadaNet network it is only 40ms.
The time-of-flight (speed of light) delay doesn't matter (much).
It's mostly a constant. (Routing shifts on long paths introduce
shifts.)
The problem is queueing delays. They aren't
Agreed. Which is also why I find it amazing that on my gps controlled
server, with a Regina level 1 backup, the regina offset is less than 1ms
even though the round trip time is 40-50 ms. Ie, assymmetric router delays
do NOT appear to be a problem.
Just one data point however..
Look at your
My own experience suggests that, at least with a hand-held GPS, it can be
a lot longer than 45 seconds. That figure may only apply if the GPS has a
180-degree clear view of the sky. But the GPS18 LVC does usually recover
quickly enough (mine has a less than 180-degree sky FoV).
The 45
It's the poll interval of ntpd. Ntpq does not poll! The poll interval
varies between 2^MINPOLL and 2^MAXPOLL. You have set MINPOLL=MAXPOLL=4
giving a poll interval of 2^4 or 16 seconds. This is usually the
correct choice for a GPS receiver.
Why do you say that? Or let me ask it another
A good idea might be to find someone who would program GPS/PPS support
for chrony. Many people would benefit from it. We also have a good
programmer working with us and he is already looking into things..
I keep thinking about it, but I am not a good programmer, and first one has
to understand
And it probably varies in frequency with temperature and age. And
probably no one cares if the frequency is off by a percent or two,
especially if it's off on the high side. Who is going to complain if
his 2.4 GHz processor is actually operating at 2.45 GHZ??
Actually, it's probably low.
I am actually using three seperate BU 303 GPS devices pointing in
different directions.
Beware of the leap-second bug.
I don't have a BU 303, but all the other SiRF units I've tried
are off by a second for some strange pattern.
http://www.megapathdsl.net/~hmurray/ntp/leap-gps.gif
That happens
DTRT = ?
Do The Right Thing
--
These are my opinions, not necessarily my employer's. I hate spam.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
We target for millisecond accuracy. As I understand, the oscillators on
standard PCs are mostly cheapest crap and there are way better
oscillators I could use to replace the original. Is that correct?
There are two parts to that crap.
One is that the actual frequency doesn't match the number
The driftfile also sometimes seems to do more harm than good - especially
after a reboot.
Some kernels do a calibration of clock against RTC clock. This will make
driftfile misleading.
There is a bug in the Linux calibration routine for the TSC mode
clock. It doesn't get a consistent answer.
Two of my systems injected leap seconds at the end of Aug and Sep.
A couple of others didn't.
I thought I saw some discussion of this, but I can't find it. Has
anybody else seen this? Was I dreaming about seeing something here?
Is the bug in the Linux kernel for not waiting until December, or
and where do I get it?
--
These are my opinions, not necessarily my employer's. I hate spam.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
A termistor on the crystal on the other hand might be useful to compensate
the temperature ( there is an alteration of ntp which also calculates the
temp compensation of the crystal and uses that to calculate the required
drift rate.-- unfortunately I do not remember its name of location on the
I have a NMEA GPS device that outputs the correct strings. However
due to where I have to position the device it doesn't always have a
lock on three satellites and then goes into Void mode. However the
time values are still being collected (It always sees at least one
satellite).
Which
It seems to me a topic related to initially getting the time set on a box is
the ability to determine the 'synchronization status' of ntpd.
There is another can of worms in this area. What do you do if
it doesn't get synchronized within X seconds? (say because
your network link is down)
--
101 - 200 of 324 matches
Mail list logo
