X9SCM-F-O clock drift +1 second into the future when ntp running?

public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed

* X9SCM-F-O clock drift +1 second into the future when ntp running?
@ 2012-07-07 15:12 Justin Piszcz
  2012-07-07 19:43 ` Justin Piszcz
  0 siblings, 1 reply; 2+ messages in thread
From: Justin Piszcz @ 2012-07-07 15:12 UTC (permalink / raw)
  To: pool, linux-kernel

Hello,

I migrated from an X7SPA to an X9SCM-F-O and now gpsd/ntp no longer sync
with my GPS unit:
http://www.amazon.com/GlobalSat-BU-353-USB-GPS-Receiver/dp/B000PKX2KA

I did some digging and it looks like the system clock on this motherboard
with the latest BIOS (2.00a) runs 1 second too fast when comparing to other
NTP-synchronized machines.

When comparing the clock on this vs. an atomic clock, the system clock is ~1
second faster, which is probably why the GPS has problems syncing.

Is this a faulty motherboard clock or is this an issue with Ivy Bridge (I am
using an E3-1200 V2 CPU) with the X9SCM-F-O and BIOS 2.00a?

DMI Info:

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
        Vendor: American Megatrends Inc.
        Version: 2.0a
        Release Date: 06/08/2012
        Address: 0xF0000
        Runtime Size: 64 kB
        ROM Size: 8192 kB

NTP problem:

Problem, the x127 for the GPS:

$ ntpq -pn
     remote           refid      st t when poll reach   delay   offset
jitter
============================================================================
==
x127.127.28.0    .GPS.            0 l   11   16  377    0.000    0.363
100.414
*204.235.61.9    128.174.38.133   2 u   48   64   37   48.716  -985.27
326.767
+184.105.192.247 216.218.254.202  2 u   43   64   37   90.902  -987.55
332.766
+50.7.247.114    85.114.26.194    2 u   42   64   37  158.445  -985.19
330.627
+69.65.40.29     209.51.161.238   2 u   43   64   37   47.733  -984.50
329.232

Any idea why it consistently has a ~1 second offset?
Is there a good way to fix this?

Before, on the X7SPA I ran gpsd+ntp for years without any issues, it
synchronized perfectly.  Is this a BIOS issue?  Kernel problem or HW issue?

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

Full output:

# adjtimex -p            
         mode: 0
       offset: 0
    frequency: 1523449
     maxerror: 16000000
     esterror: 16000000
       status: 8257
time_constant: 3
    precision: 1
    tolerance: 32768000
         tick: 10015
     raw time:  1341673069s 873569969us = 1341673069.873569969
return value = 5

After 5-10 minutes without ntpd running, the clock had drifted -2.27 seconds
the other direction..

# ntpdate time.nist.gov
 7 Jul 11:03:32 ntpdate[374]: step time server 128.138.140.44 offset
-2.273077 sec

Justin.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* RE: X9SCM-F-O clock drift +1 second into the future when ntp running?
  2012-07-07 15:12 X9SCM-F-O clock drift +1 second into the future when ntp running? Justin Piszcz
@ 2012-07-07 19:43 ` Justin Piszcz
  0 siblings, 0 replies; 2+ messages in thread
From: Justin Piszcz @ 2012-07-07 19:43 UTC (permalink / raw)
  To: pool, linux-kernel

-----Original Message-----
From: Justin Piszcz [mailto:jpiszcz@lucidpixels.com] 
Sent: Saturday, July 07, 2012 11:12 AM
To: pool@lists.ntp.org; linux-kernel@vger.kernel.org
Subject: X9SCM-F-O clock drift +1 second into the future when ntp running?

Hello,

I migrated from an X7SPA to an X9SCM-F-O and now gpsd/ntp no longer sync
with my GPS unit:
http://www.amazon.com/GlobalSat-BU-353-USB-GPS-Receiver/dp/B000PKX2KA

I did some digging and it looks like the system clock on this motherboard
with the latest BIOS (2.00a) runs 1 second too fast when comparing to other
NTP-synchronized machines.

--

I've done some more reading and what I've found is anything over 500ppm ntp
cannot correct for; so is this would be a bad crystal/chip or is there
something else wrong here?

Supermicro X9SCM: (see the error_ppm) is all over the map:

# adjtimex -a
                                      --- current ---   -- suggested --
cmos time     system-cmos  error_ppm   tick      freq    tick      freq
1341688282      -0.731743
1341688292      -0.731619       12.4   9993   3497075
1341688302      -0.747186    -1556.7   9993   3497075   10009    659788
1341688312      -0.747117        6.9   9993   3497075    9993   3045513
1341688322      -0.747099        1.8   9993   3497075    9993   3378325
1341688332      -0.762636    -1553.7   9993   3378325   10009    344163
1341688342      -0.762650       -1.4   9993   3378325    9993   3470512
1341688352      -0.778221    -1557.1   9993   3378325   10009    566038

# adjtimex -a
                                      --- current ---   -- suggested --
cmos time     system-cmos  error_ppm   tick      freq    tick      freq
1341688564      -0.591964
1341688574      -0.575373     1659.1  10009    566038
1341688584      -0.574515       85.8  10009    566038   10008   1497763
1341688594      -0.558007     1650.8  10009    566038    9992   3789738
1341688604      -0.537084     2092.3  10009    566038    9988   1071325
1341688614      -0.568492    -3140.8   9988   1071325   10019   3744100
1341688624      -0.568774      -28.2   9988   1071325    9988   2919762
1341688634      -0.584618    -1584.4   9988   1071325   10004     49663

Old MSI motherboard (Pentium 4-- see how the PPM is roughly in the same
range)

#  adjtimex -a
WARNING: CMOS time is 30.02 min ahead of system clock
                                      --- current ---   -- suggested --
cmos time     system-cmos  error_ppm   tick      freq    tick      freq
1341690163   -1800.416735
1341690173   -1800.417111      -37.6   9996   2365500
1341690183   -1800.417499      -38.7   9996   2365500    9996   4904456
1341690193   -1800.417894      -39.5   9996   2365500    9996   4956019
1341690203   -1800.418297      -40.3   9996   2365500    9996   5007582
1341690213   -1800.418308       -1.0   9996   5007582    9996   5074664
1341690223   -1800.418327       -1.9   9996   5007582    9996   5134039
1341690233   -1800.418353       -2.6   9996   5007582    9996   5179351

Found this:
http://compgroups.net/comp.protocols.time.ntp/hopelessly-broken-clock/490495

set clocksource=hpet for boot options instead of TSC

Did not make any difference, still all over the map:

# adjtimex -a
                                      --- current ---   -- suggested --
cmos time     system-cmos  error_ppm   tick      freq    tick      freq
1341690087       0.238485
1341690097       0.240449      196.4  10015   1475154
1341690107       0.257408     1695.9  10015   1475154    9998   1744166
1341690117       0.274176     1676.8  10015   1475154    9998   2995729
1341690127       0.290927     1675.1  10015   1475154    9998   3106666
1341690137       0.291142       21.5   9998   3106666    9998   1697291
1341690147       0.275783    -1535.9   9998   3106666   10013   5458916
1341690157       0.276029       24.6   9998   3106666    9998   1494166

Has anyone seen anything like this before?
I checked all of the BIOS options, did not see anything out of the ordinary
here..

Justin.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-07-07 19:43 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-07-07 15:12 X9SCM-F-O clock drift +1 second into the future when ntp running? Justin Piszcz
2012-07-07 19:43 ` Justin Piszcz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox