Fujitsu
Not logged in » Login
X

Please login

Please log in with your Fujitsu Partner Account.

Login


» Forgot password

Register now

If you do not have a Fujitsu Partner Account, please register for a new account.

» Register now
NTP Time drift on Fujitsu PRIMERGY RX2540 M4 (GS01)
21.11.2017, 17:43
 
We observe NTP time drift on two of our new Fujitsu PRIMERGY RX2540 M4 (GS01) servers with certain linux kernel versions on Ubuntu Xenial (16.04.4). Currently tested: 4.10 (4.10.0-40-generic) and 4.13 (4.13.0-16-generic). Not affacted tested linux kernel version: 4.8 (4.8.0-41-generic).

So what do we observe?

Directly after boot we see

# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*ntp4.bit.nl .PPS. 1 u 1 64 1 0.329 -112.21 12.197
ntp1.bit.nl 193.0.0.229 2 u 1 64 1 0.343 -112.16 7.198
ntp2.bit.nl 193.67.79.202 2 u - 64 1 0.398 -109.36 10.170
ntp3.bit.nl 193.79.237.14 2 u - 64 1 0.424 -109.62 7.691

After a while (couple of minutes) the offset increases already to several hunderd:

ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*ntp4.bit.nl .PPS. 1 u 19 64 1 1.168 644.105 408.358
+ntp1.bit.nl 193.0.0.229 2 u 18 64 1 1.007 646.386 441.043
+ntp2.bit.nl 193.67.79.202 2 u 15 64 1 0.884 653.011 442.339
+ntp3.bit.nl 193.79.237.14 2 u 12 64 3 1.073 659.142 484.810

If we run the same system with a 4.8 kernel we get:

# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
-nscache2.dmz.bi 193.67.79.202 2 u 109 1024 377 0.515 0.053 1.962
+ntp3.dmz.bit.nl 193.79.237.14 2 u 32 1024 377 0.598 0.267 0.355
*ntp4.bit.nl .PPS. 1 u 978 1024 377 0.484 -0.007 0.049
+nscache1.dmz.bi 193.0.0.229 2 u 219 1024 377 0.391 -0.128 0.474

Older hardware (i.e. RX 2540 M1, RX 2530 M2, RX 1330 M3) do not have any "timing" issues no matter what kernel it runs.

We have changed many CPU power management settings but this does have any positive effect. Chrony (https://chrony.tuxfamily.org/) is able to get the time stable on this host. However, QEMU KVM guests with "KVM clock source" still have trouble keeping time.

Anyone has an idea what hardware / linux kernel changes might be the cause of this?

Quote
29.11.2017, 09:52
tbckr
( 6 )
 
Hi E. b.,

My apology for the delayed reply. We're looking into the matter and hope to hear back from the Ubuntu team soon. We'll be in touch as soon as their answer arrives.

Best regards,
Thomas

Thomas Community Manager
Quote
30.11.2017, 17:09  /  Latest edited: 30.11.2017, 17:10
 
We have done some additional testing to try and figure out which kernel may have introduced this.

The time drifting seems to have been introduced by the 4.10.0 kernel.

When running the 4.9.0 and 4.9.66 kernels we don't experience the time drifting.

We also installed some newer kernel versions, hoping there might be a fix in them, but with both 4.14.3 and 4.15-rc1 we experience the same drifting as mentioned before.

Hope this information helps

Quote
04.12.2017, 13:39
tbckr
( 6 )
 
Hi E. b.,

Unfortunately we have yet to hear from the Ubuntu team; but after relaying your additional info, we hope for an answer asap.

Best regards,

Thomas Community Manager
Quote
12.12.2017, 09:28
tbckr
( 6 )
 
Hi E.b.,

Unfortunately, we have to ask you for a little more patience; the issue is currently under scrutiny from our Ubuntu team in Japan. Hopefully we'll have more and better news by next week.

Best regards,

Thomas Community Manager
Quote
12.12.2017, 14:40  /  Latest edited: 12.12.2017, 14:41
 
Thanks you for letting is know this is still under investigation. Please let us know if and what we can do to speed things up.

Quote
14.12.2017, 13:21
 
Hello Thomas,

Thanks for your replies and involvement in this case.

Richard Slot

Quote
Reply
Share
Page 1/1 1