On Fri, Mar 2, 2012 at 06:23, A C agcarver+...@acarver.net wrote:
And another one:
55988 22852.362 127.127.22.0 -0.21157
55988 22853.370 127.127.22.0 -nan
55988 22854.362 127.127.22.0 -0.21791
Given the lack of reports of similar misbehavior on other processors
and OSes, I think it's
This was an interesting observation coming from the clockstats file just
now:
55988 22592.366 127.127.22.0 -0.21783
55988 22593.366 127.127.22.0 -0.21600
55988 22594.366 127.127.22.0 -0.21418
55988 22595.367 127.127.22.0 -0.21236
55988 22596.366 127.127.22.0 -0.22054
55988
And another one:
55988 22844.362 127.127.22.0 -0.24620
55988 22845.362 127.127.22.0 -0.20438
55988 22846.362 127.127.22.0 -0.20255
55988 22847.362 127.127.22.0 -0.21073
55988 22848.362 127.127.22.0 -0.23891
55988 22849.363 127.127.22.0 -0.20707
55988 22850.362
On 2/26/2012 12:17 AM, Dave Hart wrote:
On Sun, Feb 26, 2012 at 03:37, Danny Mayer ma...@ntp.org wrote:
It could well be that rackety is sending KOD packets and this server is
not recognizing them as such. rackety has a heavy load under normal
circumstances so it may well do so. When it does
On 2012-02-26, Danny Mayer ma...@ntp.org wrote:
On 2/26/2012 12:17 AM, Dave Hart wrote:
On Sun, Feb 26, 2012 at 03:37, Danny Mayer ma...@ntp.org wrote:
It could well be that rackety is sending KOD packets and this server is
not recognizing them as such. rackety has a heavy load under normal
On 2/26/2012 10:27 AM, unruh wrote:
On 2012-02-26, Danny Mayer ma...@ntp.org wrote:
On 2/26/2012 12:17 AM, Dave Hart wrote:
On Sun, Feb 26, 2012 at 03:37, Danny Mayer ma...@ntp.org wrote:
It could well be that rackety is sending KOD packets and this server is
not recognizing them as such.
On 2/12/2012 4:55 PM, A C wrote:
I'm not exactly sure what happened but I may have caught the system in
the act of trying to run away. Below is the last two lines from the
peers log for one of the peers and below that is the output of ntpq
showing what happened to that peer immediately after.
On Sun, Feb 26, 2012 at 03:37, Danny Mayer ma...@ntp.org wrote:
It could well be that rackety is sending KOD packets and this server is
not recognizing them as such. rackety has a heavy load under normal
circumstances so it may well do so. When it does so the ntp timestamps
are going to be
The problem with THREE GPS receivers, or just about any other clock, is
that it it can too easily degenerate to the two server case. It is well
known that a man with two clocks can never be certain what time it is.
Four, five, and seven are the magic numbers for a robust configuration.
Most
A C wrote:
On 2/14/2012 01:49, David Lord wrote:
A C wrote:
On 2/13/2012 15:44, David Lord wrote:
Recent ntpd is supposed to handle that level of frequency
offset but most of my pcs have had the frequency offset
adjusted to be 10 ppm which is done when I build a kernel
with options PPS_SYNC
On Mon, 13 Feb 2012, A C wrote:
I'm not sure it's a good idea either but I would really like to
understand why a refclock clamps the polling interval at such a low
value when nearly every bit of documentation says we should be kind to
NTP servers and make sure the polling period is allowed to
On 2/15/2012 21:36, Michael Deutschmann wrote:
On Mon, 13 Feb 2012, A C wrote:
I'm not sure it's a good idea either but I would really like to
understand why a refclock clamps the polling interval at such a low
value when nearly every bit of documentation says we should be kind to
NTP servers
A C wrote:
On 2/13/2012 15:44, David Lord wrote:
Recent ntpd is supposed to handle that level of frequency
offset but most of my pcs have had the frequency offset
adjusted to be 10 ppm which is done when I build a kernel
with options PPS_SYNC and options TIMER_FREQ=119.
This kernel does
On 2/14/2012 01:49, David Lord wrote:
A C wrote:
On 2/13/2012 15:44, David Lord wrote:
Recent ntpd is supposed to handle that level of frequency
offset but most of my pcs have had the frequency offset
adjusted to be 10 ppm which is done when I build a kernel
with options PPS_SYNC and options
On 2/14/2012 1:43 AM, David J Taylor wrote:
A C agcarver+...@acarver.net wrote in message
news:4f398579.9060...@acarver.net...
[]
I'm not sure it's a good idea either but I would really like to
understand why a refclock clamps the polling interval at such a low
value when nearly every bit of
On 2012-02-15, Richard B. Gilbert rgilber...@comcast.net wrote:
On 2/14/2012 1:43 AM, David J Taylor wrote:
A C agcarver+...@acarver.net wrote in message
news:4f398579.9060...@acarver.net...
[]
I'm not sure it's a good idea either but I would really like to
understand why a refclock clamps
On Wed, Feb 15, 2012 at 04:22, unruh un...@invalid.ca wrote:
On 2012-02-15, Richard B. Gilbert rgilber...@comcast.net wrote:
Four, five, and seven are the magic numbers for a robust configuration.
Most sites will settle for four. The very paranoid or the very rich
might go for seven.
Four
A C wrote:
On 2/12/2012 16:38, David Lord wrote:
A C wrote:
I'm not exactly sure what happened but I may have caught the system in
the act of trying to run away. Below is the last two lines from the
peers log for one of the peers and below that is the output of ntpq
showing what happened to
On Sat, Feb 11, 2012 at 22:16, Chuck Swiger cswi...@mac.com wrote:
On Feb 11, 2012, at 11:58 AM, Dave Hart wrote:
On Sat, Feb 11, 2012 at 17:17, Chuck Swiger cswi...@mac.com wrote:
Have you tried to time the minimum clock reading time with RDTSC
or GetPerformance* counter calls?
I wrote a
On Feb 13, 2012, at 4:06 AM, Dave Hart wrote:
A clock is an oscillator and a counter. (Go read VMWare's
Timekeeping-In-VirtualMachines.pdf or PHK's
timecounter.pdf for considerably more detailed description
and examples if this is unclear.)
By your definition, NTP was developed and used
On 2/13/2012 01:53, David Lord wrote:
A C wrote:
On 2/12/2012 16:38, David Lord wrote:
A C wrote:
I'm not exactly sure what happened but I may have caught the system in
the act of trying to run away. Below is the last two lines from the
peers log for one of the peers and below that is the
On 2/13/2012 00:49, Dave Hart wrote:
You can force the remote sources to poll less frequently using minpoll
on their server lines. I make no promises that is a wise thing to do,
though. I presume there's a good reason ntpd does not raise the
polling interval on peers when the system polling
A C wrote:
On 2/13/2012 01:53, David Lord wrote:
A C wrote:
On 2/12/2012 16:38, David Lord wrote:
A C wrote:
I'm not exactly sure what happened but I may have caught the system in
the act of trying to run away. Below is the last two lines from the
peers log for one of the peers and below
On 2/13/2012 15:44, David Lord wrote:
Recent ntpd is supposed to handle that level of frequency
offset but most of my pcs have had the frequency offset
adjusted to be 10 ppm which is done when I build a kernel
with options PPS_SYNC and options TIMER_FREQ=119.
This kernel does have
On 2/13/2012 16:26, A C wrote:
On 2/13/2012 15:44, David Lord wrote:
Recent ntpd is supposed to handle that level of frequency
offset but most of my pcs have had the frequency offset
adjusted to be 10 ppm which is done when I build a kernel
with options PPS_SYNC and options
A C agcarver+...@acarver.net wrote in message
news:4f398579.9060...@acarver.net...
[]
I'm not sure it's a good idea either but I would really like to
understand why a refclock clamps the polling interval at such a low
value when nearly every bit of documentation says we should be kind to
NTP
I'm not exactly sure what happened but I may have caught the system in
the act of trying to run away. Below is the last two lines from the
peers log for one of the peers and below that is the output of ntpq
showing what happened to that peer immediately after. Note the offset.
This somewhat
A C wrote:
I'm not exactly sure what happened but I may have caught the system in
the act of trying to run away. Below is the last two lines from the
peers log for one of the peers and below that is the output of ntpq
showing what happened to that peer immediately after. Note the offset.
On 2/12/2012 16:38, David Lord wrote:
A C wrote:
I'm not exactly sure what happened but I may have caught the system in
the act of trying to run away. Below is the last two lines from the
peers log for one of the peers and below that is the output of ntpq
showing what happened to that peer
Dave Hart wrote:
On Fri, Feb 10, 2012 at 03:07, A Cagcarver+...@acarver.net wrote:
So far so good, it's running with reasonable offsets and jitter (PPS not yet
enabled).
But this is new to me in the logs:
10 Feb 01:41:37 ntpd[242]: ts_min 1328838097.185664676 ts_prev
1328838097.185550676 ts
Terje Mathisen wrote in message news:tekh09-1ro@ntp6.tmsw.no...
[]
Have you tried to time the minimum clock reading time with RDTSC or
GetPerformance* counter calls?
I wrote a tiny test program on my Win7-64 laptop, it got:
Reading the system clock 1000 times, minimum reading time =
So ntpd has been behaving reasonably well with the snprintf fix. I had
good results with only internet servers. My PPS and SHM refclocks were
set to noselect.
I removed the noselect on the PPS refclock and left flag3 set to zero
(no kernel discipline).
Everything seemed fine and then:
On 2/11/2012 01:21, A C wrote:
remote refid st t when poll reach delay offset jitter
==
x127.127.22.0 .PPS. 0 l 12 16 17 0.000 -27.265 16.503
127.127.28.0 .GPSD. 4 l 75 128 1 0.000 -16595. 0.122
69.65.40.29
On Sat, Feb 11, 2012 at 09:21, A C agcarver+...@acarver.net wrote:
So ntpd has been behaving reasonably well with the snprintf fix. I had good
results with only internet servers. My PPS and SHM refclocks were set to
noselect.
I removed the noselect on the PPS refclock and left flag3 set to
On Sat, Feb 11, 2012 at 09:42, A C agcarver+...@acarver.net wrote:
On 2/11/2012 01:21, A C wrote:
This is the more recent status though I'm not sure why the PPS is marked as
bad.
remote refid st t when poll reach delay offset
jitter
On Sat, Feb 11, 2012 at 08:11, Terje Mathisen terje.mathisen at
tmsw.no@ntp.org wrote:
Dave Hart wrote:
On Fri, Feb 10, 2012 at 03:07, A Cagcarver+...@acarver.net wrote:
So far so good, it's running with reasonable offsets and jitter (PPS not
yet
enabled).
But this is new to me in the
Hi--
On Feb 11, 2012, at 12:11 AM, Terje Mathisen wrote:
In this specific case, the minimum time to read the clock was measured
at ntpd startup to be 114 usec, so each raw OS clock reading is
OK, that's the problem right there: That value is obviously wrong!
The Win* OS clock is so dead
On 2/11/2012 06:51, Dave Hart wrote:
On Sat, Feb 11, 2012 at 09:21, A Cagcarver+...@acarver.net wrote:
So ntpd has been behaving reasonably well with the snprintf fix. I had good
results with only internet servers. My PPS and SHM refclocks were set to
noselect.
I removed the noselect on the
On Sat, Feb 11, 2012 at 17:17, Chuck Swiger cswi...@mac.com wrote:
Have you tried to time the minimum clock reading time with RDTSC
or GetPerformance* counter calls?
I wrote a tiny test program on my Win7-64 laptop, it got:
Reading the system clock 1000 times, minimum reading time =
24
On 2012-02-11, A C agcarver+...@acarver.net wrote:
On 2/11/2012 06:51, Dave Hart wrote:
On Sat, Feb 11, 2012 at 09:21, A Cagcarver+...@acarver.net wrote:
So ntpd has been behaving reasonably well with the snprintf fix. I had good
results with only internet servers. My PPS and SHM refclocks
On 2/11/2012 12:09, unruh wrote:
16 sec in 5 min is 50,000 PPM. It is hard to see how ntpd could do that,
unless it was stepping like mad (one of the problems with the highly
non-linear stepping that ntp likes to do). It is possible to make the
clock slew at that rate by using adjtimex, the
On Feb 11, 2012, at 11:58 AM, Dave Hart wrote:
On Sat, Feb 11, 2012 at 17:17, Chuck Swiger cswi...@mac.com wrote:
Have you tried to time the minimum clock reading time with RDTSC
or GetPerformance* counter calls?
I wrote a tiny test program on my Win7-64 laptop, it got:
Reading the system
On 2/11/2012 07:08, Dave Hart wrote:
On Sat, Feb 11, 2012 at 09:42, A Cagcarver+...@acarver.net wrote:
On 2/11/2012 01:21, A C wrote:
This is the more recent status though I'm not sure why the PPS is marked as
bad.
remote refid st t when poll reach delay offset
A C wrote:
On 2/11/2012 07:08, Dave Hart wrote:
On Sat, Feb 11, 2012 at 09:42, A Cagcarver+...@acarver.net wrote:
On 2/11/2012 01:21, A C wrote:
This is the more recent status though I'm not sure why the PPS is
marked as
bad.
remote refid st t when poll reach delay
On 2/11/2012 22:22, David Lord wrote:
A C wrote:
On 2/11/2012 07:08, Dave Hart wrote:
On Sat, Feb 11, 2012 at 09:42, A Cagcarver+...@acarver.net wrote:
On 2/11/2012 01:21, A C wrote:
This is the more recent status though I'm not sure why the PPS is
marked as
bad.
remote refid st t when
Since we seem to be going around a few times on this I'm going to
summarize the current hardware and software configuration of the system
so we're all on the same starting point.
The GPS data is read by gpsd on /dev/gps0 which is a symlink to /dev/ttya.
The PPS_ATOM is reading /dev/pps0 which
On Fri, Feb 10, 2012 at 03:07, A C agcarver+...@acarver.net wrote:
So far so good, it's running with reasonable offsets and jitter (PPS not yet
enabled).
But this is new to me in the logs:
10 Feb 01:41:37 ntpd[242]: ts_min 1328838097.185664676 ts_prev
1328838097.185550676 ts
Ron Frazier (NTP) wrote:
From that point of view, I think the only settings
I have access to in the power configuration are:
Minimum CPU Frequency - 20%
Maximum CPU Frequency - 100%
...
Seems like that might be a issue, try setting min max to the same?
--
E-Mail Sent to this
On Thu, Feb 9, 2012 at 03:47, A C agcarver+...@acarver.net wrote:
The latest version is now compiled and running. I'll let it go and see what
happens over the next week. Just as a point of reference, the system has
been without ntpd (or any other clock discipline) for about three days and
On 2/9/2012 05:04, Dave Hart wrote:
On Thu, Feb 9, 2012 at 03:47, A Cagcarver+...@acarver.net wrote:
The latest version is now compiled and running. I'll let it go and see what
happens over the next week. Just as a point of reference, the system has
been without ntpd (or any other clock
So far so good, it's running with reasonable offsets and jitter (PPS not
yet enabled).
But this is new to me in the logs:
10 Feb 01:41:37 ntpd[242]: ts_min 1328838097.185664676 ts_prev
1328838097.185550676 ts 1328838097.189745353
10 Feb 01:41:37 ntpd[242]: sys_fuzz 114000 nsec, this fuzz
On 2/9/2012 19:07, A C wrote:
So far so good, it's running with reasonable offsets and jitter (PPS not
yet enabled).
But this is new to me in the logs:
10 Feb 01:41:37 ntpd[242]: ts_min 1328838097.185664676 ts_prev
1328838097.185550676 ts 1328838097.189745353
10 Feb 01:41:37 ntpd[242]:
Ron Frazier (NTP) wrote:
I will admit that I've only skimmed your NTPD losing sync thread briefly.
... occasionally goes crazy and has offsets almost an order of
magnitude larger than normal.
Any CPU power management enabled?
--
E-Mail Sent to this address blackl...@anitech-systems.com
On 2/7/2012 14:34, E-Mail Sent to this address will be added to the
BlackLists wrote:
Ron Frazier (NTP) wrote:
I will admit that I've only skimmed your NTPD losing sync thread briefly.
... occasionally goes crazy and has offsets almost an order of
magnitude larger than normal.
Any CPU power
On 2/7/2012 19:12, Dave Hart wrote:
On Tue, Feb 7, 2012 at 18:46, Dave Harth...@ntp.org wrote:
On Tue, Feb 7, 2012 at 18:38, A Cagcarver+...@acarver.net wrote:
On 2/7/2012 10:21, Dave Hart wrote:
Thanks for the heads-up. Assuming by the C99 flag you mean it was
configured using
On 2/7/2012 5:34 PM, E-Mail Sent to this address will be added to the
BlackLists wrote:
Ron Frazier (NTP) wrote:
I will admit that I've only skimmed your NTPD losing sync thread briefly.
... occasionally goes crazy and has offsets almost an order of
magnitude larger than normal.
On 2/8/2012 3:02 PM, Ron Frazier (NTP) wrote:
On 2/7/2012 5:34 PM, E-Mail Sent to this address will be added to the
BlackLists wrote:
Ron Frazier (NTP) wrote:
I will admit that I've only skimmed your NTPD losing sync thread
briefly.
... occasionally goes crazy and has offsets almost an order
A C wrote:
BlackList wrote:
Ron Frazier (NTP) wrote:
I will admit that I've only skimmed your NTPD losing
sync thread briefly.
... occasionally goes crazy and has offsets almost an
order of magnitude larger than normal.
Any CPU power management enabled?
Not that I know of on a Sparc
On 2/8/2012 13:06, E-Mail Sent to this address will be added to the
BlackLists wrote:
A C wrote:
BlackList wrote:
Ron Frazier (NTP) wrote:
I will admit that I've only skimmed your NTPD losing
sync thread briefly.
... occasionally goes crazy and has offsets almost an
order of magnitude
BlackList wrote:
Any CPU power management enabled?
Good question, but, no. System is set never to sleep,
never to standby, never to shut down hard drive,
and hibernate only if on battery with critical low battery.
FYI, CPU power management differs from those system power
management you
On 2/7/2012 19:12, Dave Hart wrote:
On Tue, Feb 7, 2012 at 18:46, Dave Harth...@ntp.org wrote:
On Tue, Feb 7, 2012 at 18:38, A Cagcarver+...@acarver.net wrote:
On 2/7/2012 10:21, Dave Hart wrote:
Thanks for the heads-up. Assuming by the C99 flag you mean it was
configured using
It appears that ntpd is wedged again in libc. I'm not sure (but it's
likely) if this is the source of the random behavior lately with ntpd
spinning offsets out of control but I've ruled out the GPS by
noselecting the PPS signal, turning off kernel PPS and monitored the PPS
signal externally.
On Tue, Feb 7, 2012 at 17:37, A C agcarver+...@acarver.net wrote:
It appears that ntpd is wedged again in libc. I'm not sure (but it's
likely) if this is the source of the random behavior lately with ntpd
spinning offsets out of control but I've ruled out the GPS by noselecting
the PPS
On 2/7/2012 10:21, Dave Hart wrote:
On Tue, Feb 7, 2012 at 17:37, A Cagcarver+...@acarver.net wrote:
It appears that ntpd is wedged again in libc. I'm not sure (but it's
likely) if this is the source of the random behavior lately with ntpd
spinning offsets out of control but I've ruled out
On Tue, Feb 7, 2012 at 18:38, A C agcarver+...@acarver.net wrote:
On 2/7/2012 10:21, Dave Hart wrote:
Thanks for the heads-up. Assuming by the C99 flag you mean it was
configured using --enable-c99-snprintf, that flag didn't take. If
it had, you wouldn't be using libc's snprintf, you'd be
Hi A C,
I will admit that I've only skimmed your NTPD losing sync thread
briefly. I just wanted to share this loopstats file where my USB (no
PPS) GPS occasionally goes crazy and has offsets almost an order of
magnitude larger than normal. IE, normal offsets are in the 15 ms
range. Then,
On 2/7/2012 11:19, Ron Frazier (NTP) wrote:
Hi A C,
I will admit that I've only skimmed your NTPD losing sync thread
briefly. I just wanted to share this loopstats file where my USB (no
PPS) GPS occasionally goes crazy and has offsets almost an order of
magnitude larger than normal. IE, normal
On Tue, Feb 7, 2012 at 18:46, Dave Hart h...@ntp.org wrote:
On Tue, Feb 7, 2012 at 18:38, A C agcarver+...@acarver.net wrote:
On 2/7/2012 10:21, Dave Hart wrote:
Thanks for the heads-up. Assuming by the C99 flag you mean it was
configured using --enable-c99-snprintf, that flag didn't take.
68 matches
Mail list logo
