The driftfile also sometimes seems to do more harm than good - especially
after a reboot.
How stable is your temperature? Are you rebooting a happy system?
(If so why?) Or are you powering up a system that has been off
for the night?
If your drift file is off, I would expect things like this:
Does it really make sense to get microsecond resolution on the glitches.
I doubt if whatever the UPS is using for an A/D is good for microseconds.
I've thought of using a wall-wart and some dividers to feed an audio
input channel. That would probably be good for 10s of microseconds.
I'm saving
I did get a look at the ntpd script today. Turns out the answer on
where it gets the ntp.conf file is right there, near the top, in the
line ntpconf=/etc/ntp.conf, even though the ntp man page points us
deeper in the /etc hierarchy.
The sysadmin I was working with was real annoyed, as the
No I suspect you ran /usr/sbin/ntpd, not /etc/init.d/ntpd
/etc/init.d/ntpd start should do EXACTLY the same thing as when the system
runs it on bootup.
If I recall, the line that worked was /etc/init.d/ntpd -c filename of
our ntp.conf file. I don't recall that sbin was involved.
Running
In article [EMAIL PROTECTED],
Uwe Klein [EMAIL PROTECTED] writes:
Hal Murray wrote:
There are a lot of low cost USB GPS gizmos that use the
SiRF Star III. They suck for timekeeping.
Is there a reason known for this?
I assume it's a software bug/feature. The problem is drift/wander
I am interested in getting a GPS clock to synchronize our internal
test network. I am curious to hear about relativley cheap and Linux
friendly GPS clock. (Less than $100 would be great)
The Garmin GPS 18 LVC is popular. Some assembly required.
(aka soldering) No big deal if somebody has a
[EMAIL PROTECTED] ~]$ strings /usr/sbin/ntpd|grep ntp.conf
/etc/ntp.conf
In the RHEL case, this would find exactly the wrong copy of ntp.conf,
being the one we were changing to no avail, not the one that NTP was in
fact using.
It's even worse than that. You aren't even sure that's
the
Yes, and that's where strace led me, where I found a script called ntpd.
How the service script interacts with this ntpd script isn't clear.
Environment variables seem to be implicated, but a listing of
environment variables is not helpful. Next week I'll digest it all.
I think there are
[man pages]
I'm happy to have more feedback on these issues.
My 2 cents...
I like man pages. apropos is where I start when I'm looking
for things.
I hate buggy documentation. That includes out of date man pages.
I'd be happy with dummy man pages that told me to look in
the HTML pages and
The rules about how often to query a daemon are not all that
complicated. The fact that there ARE rules is due to some history;
google for Netgear Wisconsin for the sordid details. For a second
opinion google for DLink PHK.
There is a good summary at:
NTP server misuse and abuse
That worked out of the box and all of a sudden just stopped.
Since I changed a lot of things in order to make the box work
fully-automatic, I can't say for sure if I broke something
or what happened.. Still I am very puzzled...
Maybe I overlooked something?
Here's some information:
Here's my
Note that serial port nmea is liable to be out by up to 1/2 sec and to have
a lot ( 10s of msec) jitter on it, since the end of the string received by
a slow serial port ( eg at 4800Bd, it takes an nmea sentence of about 60
characters 1/8 of a second to be delivered and will have a jitter of few
His question can be rephrased, what does ntpd do after it has sent the Kiss of
Death?
does it drop all subsequent packets? -- That sounds like a huge cost on the
ntp server-- ie imagine a popular server with 10,000 machines it has sent
the KoD to. It then has to scan that whole list for each
I wouldn't get terribly upset about it. Ntpd does not step the time
unless it is grossly wrong. Ntpd has been known to step *FORWARD* on
certain Windows and MAYBE Linux systems when heavy disk activity
resulted in missed clock ticks. I can't think of anything likely to go
wrong that would
Historically interrupts from the 32kHz clock have not been used, except,
possibly, in powered down states to initiate a restart from suspend or
hibernate. It is possible that has changed very recently, but they
certainly weren't used historically.
Well, at least one of us is confused. Or maybe
Correct, in that the linear correction will vary with temperature (and
could be matched closely by a quadratic)
I don't think you can measure the temperature and/or drift accurately
enough to make quadratic corrections interesting.
I am thinking of a least-squares fit to the drift data,
In article [EMAIL PROTECTED],
shy author [EMAIL PROTECTED] writes:
Has anyone thought about removing both the linear terms and quadratic
terms in the drift, by utilizing the temperature sensor readings
available on many of the latest motherboards?
Linear works pretty well. I think it would be
Should ntpd be able to listen for multicasts on interfaces that
get added/configured after ntpd starts?
Is this a common enough situation to justify the coding effort required?
It seems to me to be a hell of a lot easier just to configure all your
interfaces, or at least all you want to use,
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Peter Laws) writes:
1 Time(s): Clock: inserting leap second 23:59:60 UTC
RHEL 5.2 system running ntpq [EMAIL PROTECTED] Thu Jan 17 18:14:14 UTC 2008
(1) which is the default for that distribution. Grepping around in the
logs it appears that most
[drift 500 ppm]
It's almost certainly a hardware problem. Ntpd is telling you that the
clock is gaining, or losing, more than about 43 seconds (500 parts per
million) per day. 500 PPM is the maximum that ntpd can handle.
It could easily be a software screwup.
Unless you know it works on
In article [EMAIL PROTECTED],
David Woolley [EMAIL PROTECTED] writes:
Hal Murray wrote:
The quirk is that the drift changes when I run the monitoring
program. It changes more if I poll faster. It changed by
20 ppm when I was polling with a 10 ms delay and it's more
than 80 ppm and still
I'm setting up a small system to monitor things like line voltage
and temperature.
It uses a serial connection to a UPS box to get the line voltage.
The quirk is that the drift changes when I run the monitoring
program. It changes more if I poll faster. It changed by
20 ppm when I was polling
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (John Ioannidis) writes:
This may sound like an embarrassment of riches, but here is my problem:
I have some rack-mounted servers (IBM System x3650 to be precise) that I
need to synchronize with a PPS signal. The problem is, of course, that
the
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
I'm doing NTP exchanges to determine my clock offset. I use this to
adjust my clock frequency, but there's a lot of lag so I overshoot by
too much and it oscillates around the reference frequency. This is an
audio clock so
On April 30, the time offset started climbing and reached 14 ms in
approximately 90 minutes. ntpd started bumping the frequency offset,
down to -9.4 ppm.
Is this the Linux TSC bug? Are you running a recent Linux kernel?
Did you reboot the system at that time?
--
These are my opinions, not
I didn't check the amount of the jump. I would not expect a jump of more
than a few ppm (due to the crystal itself), and not more than about once a
year.
It was 3 or 4 ppm.
That's big enough that I think it very unlikely, but not impossible.
Even if it happened only once per year, somebody
In article [EMAIL PROTECTED],
Noob [EMAIL PROTECTED] writes:
Hello,
One of my systems had been running for ~6 weeks. During this time,
the frequency offset computed by ntpd remained stable between
-6.6 ppm and -6.2 ppm.
On April 30, the time offset started climbing and reached 14 ms in
Does the HPET support enable microsecond resolution for hardware clock
reads in Linux (the HPET hardware is supposedly capable of this)?
I don't know. A quick test with my kernel seemed to ignore
that chunk of the command line. I may have it turned off in
the config file.
--
These are my
I would like to connect to any server to receive a string where it is
written the istant time (possibly hh.mm.ss.xxx ). I found several sites
where I may read hh.mm.ss then downloading the page and reading it I could
get the string hh.mm.ss but
I don't know of any servers that do that.
In the
I am using NTPd and I have guessed that it uses the High Resolution Timer,
brought to the linux kernel since the 2.6.16 release.
Does anyone know if it said somewhere in the documentation or any other
official source, a trusty one.
ntpd just calls the kernel.
Recent Linux kernels have several
I haven't seen that problem since I added
clocksource=acpi_pm
on the boot time parameters.
What version of the kernel do you have? 2.6.17 does not have clocksource
parameter or an acpi_pm option. Is there anywhere where these different
clock parameters are defined?
I'm using 2.6.23.
Sorry it's actually difficult for me to precise this topic for
confidentiality reason of course and also because I'm an intern and thus
there for a short period. Hence I don't know exactly why myself. This is
just one of the requirement of my project.
Keeping a handful of machines synchronized to
I actually don't really understand why a GPS would improve my
synchronisation.
If your master server has GPS, its time will be more stable.
That means your clients can sync to a stable clock rather than
trying to track a clock that is wobbling around. (Things
are simpler and work better when
$!/bin/sh
if ! ntpq|grep '* name.of.router'/dev/null; then
mail -s NTP sync has been lost [EMAIL PROTECTED]
fi
And put the shell script into crontab to run every minute.
(your milage may vary)
That could lead to a lot of clutter in your mailbox.
--
These are my opinions, not necessarily my
Do you know any code that cares if that is wrong by 10% (which would be
10PPM) Ie, is 10% error insane?
Is 1% (1PPM)?
Ie, .05% seems a bit extreme for that.
I used to do a lot of performance measurements.
For the stuff I was doing, 10% is easy to spot. 1% is borderline.
--
These are
The problem here is that the distribution does not contain a decent
assortment of example configuration files for common configurations. So
the OS distributors/aggregators/vendors each cobble together their own
one size fits all configuration file.
But does a local refclock make sense in a
Well, no. 1 or 2 sec is 10-20PPM which is on the good side. 43 sec per day
is like 500PPM which is definitely on the high side. 5-10sec per day is
more typical. Note that chrony(on linux) will fix 43s/day. (It will use the
fast
slew-- ie changing the tick size-- as well as the slow slew.) ntp as
Can someone point me to a good document that
shows how to setup a Time Server? I have an
isolated network that cannot get to the Internet
to sync time. I have Solaris 8,9,10 and Red Hat Linux
Advanced Server 4 servers as potential time server
candidates.
I don't know of any document that covers
I assume that you mean to use both the refclock_atom and the refclock_nmea
drivers. (127.127.22.0 and 127.127.20.0)
The NMEA driver automagically uses the PPS stuff, whether you want
it to or not.
It would be nice to have a flag to disable that feature so you
could collect data on the NMEA text
My current problem is that drift settles at 82ppm (what I called 90 in
previous email) in one run and then 32ppm in another run (with a reboot
between). This is similar to the problem I had with stepping disabled
where drift would go from +500ppm in one run and then swing all the way
to -500ppm
Fine! Don't touch anything, happy man, or it might well tomber en
marche. Real men don't want the eleven-minutes mode. It is not only
extremely inaccurate by itself, but it also steps on the toes of those
tools that are able to manage the RTC properly.
Would somebody please collect this info on
As I've stated before, I don't believe the oscillator is really this
unstable, but I could be wrong. After all, my CPU measurements varied
much more than yours, especially from one run to the next. However, I'm
still open to the possibility that linux's approach to speed measurement
is less
The ntp log file shows when NTP steps the time. But then the potential harm
is already done. Especially if the time moves backward, our server might
have serious trouble. Is there a log event which indicates that the time is
going to be reset in order to enable us to take appropriate action
The basic idea is to do the time stamping in hardware deep in
the network adaper. That avoids lots and lots of jitter.
Yes, PTP can yield an accuracy better than 100 ns if both the NICs at the
clients and the server support hardware timestamping of sent/received PTP
packets.
I am still
Yes, PTP can yield an accuracy better than 100 ns if both the NICs at the
clients and the server support hardware timestamping of sent/received PTP
packets.
On the other hand, also *every* network node between the PTP endpoints has
to be PTP-aware and compensate the packet delay it introduces,
I am willing to believe, barring contrary evidence, that your faithfully
implimented the protocol. (and that the Linux people faithfully implimented
the protocol in the kernel discipline routines).
Don't be so quick to believe that things work as expected.
I seem to remember a report of some
In article [EMAIL PROTECTED],
Harlan Stenn [EMAIL PROTECTED] writes:
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Hal Murray) writes:
Hal I didn't find a reasonable place to insert it in the wiki so I parked
Hal it here for now.
Hal http://www.megapathdsl.net/~hmurray/hacks/read.c
How
I didn't find a reasonable place to insert it in the wiki so
I parked it here for now.
This is a hack that just reads a disk as fast as it can.
It was very good at tickling the lost-interrupt problem
on an old RH system which was not using DMA on the disks.
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Peter Laws) writes:
I've resuscitated a left-for-dead TS 2100 and now am in need of a Trimble
Bullet III, or equivalent, active GPS antenna.
It's a current item for Symmetricom and they want more dinero than I want
to put into this 12 year old
I've never used the GPS18LVC (I have a Motorola M12+T) but if you know
your exact location you only need one satellite to get the time. There
are four equations in four unknowns (lattitude, longitude, elevation,
and time). Not knowing any of these variables, you need four
satellites. Once
Does the GPS18LVC provide an oscillator to serve time even when there
are not enough satellites in sight?
No.
--
These are my opinions, not necessarily my employer's. I hate spam.
___
questions mailing list
questions@lists.ntp.org
So its the DISK I/O thats causing loss of ticks ?
My first Red Hat system defaulted to no-DMA for IDE disks. (Yes,
that was a long time ago.) With that setup, it was simple to generate
lots of lost timer interrupts: just keep the disk busy doing reads.
(Seeks don't count. Read consecutive
I have problem with my stratum1 box. My box include: freebsd
5.2-RELEASE without PPS , ntp-4.2.0_1, Intel Pentium III, 40 G IDE,
Germin GPSmap60 , connect with serial com. In GPSmap60 set as NMEA.
Freebsd box can get NMEA input string. My configuration of ntp.conf
like this:
server
Iam trying to install ISC NTP-4.2.4 on RHEL 4. But Im not able to start
the services.
I firstly removed the default rpm and then compiled the latest version,
configured the ntp.conf file, but Iam not able to start the service. I
give the command /etc/init.d/ntpd start. # prompt comes back.
I was talking about what people could expect from software that behaved
well; I think you are describing what ntpd actually does here. My point
was that ntpd's ability to tolerate really rotten links is irrelevant
for most users, who are only about 20ms away from their ISP's time
server, and
So, no, I am comparing apples to apples ( the offsets as determined from
the ntp packet exchange mechanism which both use and both report).
Another approach is to setup a 3rd machine to watch both.
--
These are my opinions, not necessarily my employer's. I hate spam.
First, somebody gets to decide if this is really a bug in the NTP code or if
it is a bug in GCC.
It could also be a glitch in the included header files.
--
These are my opinions, not necessarily my employer's. I hate spam.
___
questions mailing
What does all over the map mean. they will be withing a few tens of
microseconds of that server.
I'd expect a few to tens of ms rather than microseconds.
If you manually set the time on the server, I'd expect it to
take a while for the clients to catch up.
This question comes up often enough
However, you give me an idea. Why not shut down the burst when the clock
filter delivers the first sample? Gotta think about that.
That would make sense if the goal is to get an answer on a lossy
system.
I think the background in this discussion was not loss, but delays
in setting up
I am afraid I simply do not believe this. NMEA is lucky to get a ms not a
usec. The offset on the NMEA should be a lot bigger than .001
The NMEA driver includes built-in PPS support.
--
These are my opinions, not necessarily my employer's. I hate spam.
On recent Linux kernels, I think the drift file is always bad after reboot.
HZ=100, no dynamic ticks aka tickless system (CONFIG_NO_HZ not set). I think
I even tried with a kernel command line option lpj= but it didn't help.
If the system is rebooted, ntpd stabilizes to a new different drift
In article [EMAIL PROTECTED],
Bill Unruh [EMAIL PROTECTED] writes:
I have been keeping track of the clocks on my various systems. One is
synced using ntp from a GPS 18LVM pps source. The others are synced from
What is a GPS 18LVM?
I've seen it mentioned several times recently. From the
Currently I'm syncing against NMEA/PPS and seeing quiet a big offset:
remote refid st t when poll reach delay offset jitter
==
xGPS_NMEA(0) .GPS.0 l7 16 3770.000
To my pc I have connected a garmin 18lvc and a HBG radio clock receiver.
Now what I would like to do is:
- let the hbg receiver set the current time and when the HBG signal is
not available (bad reception or the 59 seconds while it is receiving
the broadcastmessage) use the PPS signal of the
Ok but the odd thing is: a friend of mine has the exact same garmin 18
lvc but not this big offset?
Your PPS isn't working. That could be either hardware or software.
What OS are you using? What version of ntpd?
What is your friend using?
How about taking your unit over to his place and
The radio receiver will be late by of the
order of millisec, while the gps will be on time to microseconds.
Of course you may not care, but someone who has two onboard time sources
would care, I would think.
The radio propagation delay can be fudged out.
How stable is
I am seeing strange behaviour on my _x86_64 Fedora 7 desktop
workstation with regard to the system-cmos time that `adjtimex'
reports.
That leaves the RTC doing the jumping. But having an RTC that is
runing nearly 1 ppm slower than my system clock and which jumps
ahead every 10 seconds seems
When I wrote that I was unaware of the html page. I'm a Unix guy and I
generally don't even consider looking for html docs - I am used to (and
expect) man pages.
Me too.
Would it help to ship dummy man pages that just pointed to
the html documentation?
--
These are my opinions, not
Why is the '.SHM.'-clock not even considered? Because of the negative offset?
Negative offsets are not a problem. They happen all the time.
My guess is that something your new driver is setting up
makes your clock look not-very-good. It's probably one of the
obscure constants that aren't well
Some stratum 2 servers I get time from are actually polling stratum 1's
that have a pretty significant round-trip (more than 70ms), so is this any
better than having my ntp getting its time from a stratum 3 or 4 that's
closer to its own upstream sources?
A long round-trip time isn't evil all
One possibility may be that the GBS18 has switched to Garmin mode
instead of NMEA mode.
That seems unlikely. You have to send it a sensible command.
Garbage on the line is not likely to do that.
On the other hand, maybe he ran some software that knows
about Garmin GPS units...
My GPS18
The nodes' drifts are high:
# cat /etc/ntp.drift
node-A: 499.206
node-B: 497.070
500 ppm is the limit.
The next day, after restarting ntpd on the nodes and resetting
the time on all nodes with ntpdate, everything worked as
expected with the time syncing properly, no false tickers, and the
assID‡73 status14 reach, 1 event, event_reach,
srcadrmaster1, srcport3, dstadr0.0.0.0,
dstport3, leap
You see, it's garbage again. It's hard to keep up under this circumstances.
My copy wasn't garbled.
It looked like this:
assID=8773 status=1014 reach, 1 event, event_reach,
Don't. Just have the Linux servers point to external servers like the
pool and then you don't have to change anything later. You are likely to
get better quality time service that way. Tardis is a bit short on
technical information so it's hard to tell what it does, how it does it
and how
It would be very handy if one could monitor NTP with the same tools used
for monitoring other aspects of performance, rather than having to use
special programs like ntpq and parse its output. I'm thinking of this an
addition to the present tools, though, not a replacement.
Is there anything
Too many packaging of ntpd configure a local clock driver
in their sample configuration.
Does anybody know why that got started?
What urban legend do we have to stomp out before that practice will go away?
--
These are my opinions, not necessarily my employer's. I hate spam.
1. Accord GPS Clock spits out NMEA at 9600 baudrate
The NMEA specs call for 4800. Is there some way to set
the Accord box to run at 4800? That seems only sensible
if they are in the NMEA market.
2. It has custom NMEA format for GPS (and the driver is
intended to use this )
I
I don't know; it seems to me better for the refclock driver to specify a
default set of comm parameters that will work for the standard device
that refclock supports, but have a universal mechanism that would allow
overriding those params from the config file and would work for any driver.
Over the years and with some effort several drivers now support more
than one device. All TrueTime models are supported by one driver; all
Spectracom models by another and all telephone modem services by a
third. With few exceptions, a NMEA radio is a NMEA radio and I strongly
suspect many of
Perhaps the best way is to add a completely new command refclock and
load it up with all kinds of options, including those now done by the
fudge command. The command would not need the dotted quad, which could
be replaced by the driver name already in a table. The syntax could in
principle be
The NMEA driver uses 3 mode bits. I think more are available.
The docs say that flag1 is unused for the NMEA driver.
It would be really nice if there was a clean way to specify the
baud rate.
Several of the NMEA units I'm familiar with allow you to set
the baud rate they use. I expect there
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (linux newbie) writes:
HI,
Need following clarification.
Our Application needs to have two individual hardware (with DSP processor)
to have same crystal clock freqency. Though individual boards are alike, due
to environmental factors there might be
It would be really nice if there was a clean way to specify the
baud rate.
This is a general issue -- there are other drivers (e.g. the HP 58503)
that also assume a fixed baud rate and parity/stop bits. They cause a
lot of problems when trying to use not-quite-identical hardware (as in
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] writes:
Does anybody know of any *practical* samples on how to
implement NTP/SNTP client?. The goal is to provide accurate
time for a program/client running on Windows Vista.
Just curious. Why do you want to roll your own as compared
to run one of
Yes. And one missing step:
After stopping ntpd, ntpdate -b [server].
The single most common cause of a large negative drift value
is a system whose clock has not been initialized before starting
ntpd (or has been stopped during a large time adjustment).
What vintage of ntpd are you using?
Routers generally do not do NTP in any way, shape, or form! They don't
need to know the time!
That's misleading.
Routers often include anti-spam/abuse mechanisims which get logged.
It helps if the time stamps on the log files are correct. It's easier
to get that if the router itself uses NTP
I don't think it's a hardware product defect. Because we have two of
them, and we had run the same test on both of the board, we still got
the same error. Thanks,
There are two kinds of hardware (or software) errors. One is a design
error. The problem happens all the time on all units. The
Why do you feel that your router needs to know the time?
Log files for security incidents.
--
These are my opinions, not necessarily my employer's. I hate spam.
___
questions mailing list
questions@lists.ntp.org
Would such a document really be all that useful? It seems to me that the
codebase is pretty small, and it should not be all that hard to figure out.
I use
grep whatever *.c
or
grep whatever -r .
If that doesn't work in the directory I'm working in,
then I cd .. and try again. After doing
I had my computer count the lines of code in one of the older versions,
about two years ago. 70,000 or so lines of code may be a small number
to you but it seems like a lot to me. I once looked at the code for the
Motorola Oncore driver to try to understand what was going on and failed.
It
The current SHM driver looks for a sample each polling interval.
The documentation for gpsd suggests using minpoll and maxpoll of 4.
I've fixed the SHM driver to look every second. The refclock
infrastructure already had a FIFO and code to process things
like this. This reduces the jitter
Although from all the other replies (thanks everyone), it sounds like
maybe there really just aren't tons of other cheap OEM options.
Your original request wanted a PPS signal. If you don't really
need that, you have a lot more options. There are many low cost
GPS units with USB connections.
On Linux, a simpler way can be to look at /proc/interrupts - e.g.
(probably Linux-version- and possibly config-specific):
$ (cat /proc/interrupts; sleep 10; cat /proc/interrupts) | \
awk '/timer/{prev=now; now=$2} END{printf %dHz\n, int((now-prev)/10)}'
This yields 41Hz on my Via C7
The second thing, is that ntp through NAT would get a variable latency
point (since NAT speed of most routers vary with router traffic load).
I think you are talking about CPU latency rather than wire latency.
(Wire latency doesn't depend upon NAT.)
My NAT box is a DSL router. The CPU is
I known now, in the recent kernel the internal frequency will be to 250
Mhz...
With my gentoo it's not a problem for me because i make myself my kernel ...
but if i take Mandriva or a another distribution how find this values ?
I assume you mean the scheduling clock which would be 250 Hz rather
server 192.168.1.1
# by default ignore all ntp packets
restrict default ignore
# allow localhost
restrict 127.0.0.1 mask 255.255.255.255
# accept packets from...
restrict 192.168.2.0 mask 255.255.255.0 nomodify notrap
restrict 192.168.3.0 mask 255.255.255.0 nomodify notrap
restrict 192.168.4.0
I'm very confused on how ntp do the timestamp. I'm running ntpd on
vxworks. It seems to me that the receive timestamp and the Transmit
timestamp are using two different clocks, because when I use ethereal/
wireshark to look up the information of the ntp packet,
the Recevie Time Stamp is: Jan 1,
In article [EMAIL PROTECTED],
Patrick Nolan [EMAIL PROTECTED] writes:
I'm located at a university. We have a master Stratum 1 server with a
GPS clock. We also have at least four Stratum 2 servers which are
synchronized with the master. These are all very close, with delay
and offset values
In article [EMAIL PROTECTED],
Patrick Nolan [EMAIL PROTECTED] writes:
On 2007-10-20, Steve Kostecke [EMAIL PROTECTED] wrote:
The hardware clock in a PC is made of exceedingly cheap components. A
common quartz wristwatch is a better clock.
I have noticed this. Until WWV-controlled clocks came
A bad clock frequency is a hardware issue!
Or a software bug. There have been troubles with roundoff
on the value of the tick size.
--
These are my opinions, not necessarily my employer's. I hate spam.
___
questions mailing list
201 - 300 of 324 matches
Mail list logo
