X9SCM-F System clock issue (crystal clock)

[war9200]

Hi,

Anyone have an X9SCM-F with an Ivy Bridge CPU?

Copied here:
http://www.gossamer-threads.com/lists/linux/kernel/1562607

Here is my super micro X8DTH-6F:



$ ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
+38.109.218.175 192.43.244.18 2 u 25 64 1 57.070 -2.652 2.037
-96.44.157.90 173.244.211.10 3 u 24 64 1 82.532 -9.315 0.635
*205.196.146.72 128.59.39.48 2 u 23 64 1 39.337 -5.478 0.736
+169.229.70.95 128.32.206.55 2 u 22 64 1 84.710 -7.677 0.703


Here is my new X9SCM-F w/Ivy Bridge CPU (2.0a BIOS/latest)

$ 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

Anyone have this Mobo with an Ivy Bridge CPU that also runs NTP or a GPS?
Can show ntpq -pn output?

 

[Drudenhaus]

I have an X9SCL+-F, but I'm afraid I'm not using an IB CPU (G630T). ntpq -pn reports offset and jitter similar to your X8 board.

 

[brutalizer]

Recently we inserted a leap second. Last week or so. Leap year, leap second.

So sunday had 61 seconds. It is maybe the extra second you are seeing.

 

[war9200]

It eventually did come down, but yeah that leap second may be an issue as well..




-----Original Message-----
From: Dave Hart
Sent: Saturday, July 07, 2012 7:34 PM
To: Justin Piszcz
Cc: pool@lists.ntp.org
Subject: Re: [Pool] X9SCM-F-O clock drift +1 second into the future when ntp
running?

Something's unhappy. I'd add "noselect" to the server 127.127.28.0
line so it uses only the network sources to steer the clock and see if
eventually the offset and jitter for network sources comes down into
the range you see on the other supermicro system. If it does and the
jitter for the SHM driver settles down to better than the jitter from
network sources, you can use the offset of the SHM driver to tweak
your fudge and remove noselect to once again enable ntpd to steer the
clock to match the SHM driver. Keep an eye out for repeated steps --
that's a sign your clock rate is off by more than 500 PPM.

Good luck,
Dave Hart

--

Thanks, overnight, it did come down:

$ ntpq -pn
remote refid st t when poll reach delay offset
jitter
============================================================================
==
*127.127.28.0 .SHM. 0 l 7 16 377 0.000 13.537
5.075
+64.6.144.6 128.252.19.1 2 u 30 64 377 68.393 -3.682
1.400
-204.235.61.9 209.51.161.238 2 u 41 64 377 46.560 -15.125
1.302
-108.61.73.244 129.7.1.66 2 u 9 64 377 23.200 -10.460
2.064
+67.18.187.111 38.106.177.10 2 u 6 64 377 50.089 -7.486
2.403

However I'll still talk to SM because my other board looks like this after 5
min from boot, not sure why this one takes so long to come down to normal
levels.

Justin.