perfsonar-user - Re: [perfsonar-user] Re: ultralight kernel and bwctl NTP: Status UNSYNC (clock offset problems likely)

Subject: perfSONAR User Q&A and Other Discussion

List archive

Re: [perfsonar-user] Re: ultralight kernel and bwctl NTP: Status UNSYNC (clock offset problems likely)

From: Michael Sinatra <>
To: Lincoln Bryant <>, Shawn McKee <>
Cc: Hironori Ito <>, Sarah Williams <>, perfsonar-user <>, "" <>
Subject: Re: [perfsonar-user] Re: ultralight kernel and bwctl NTP: Status UNSYNC (clock offset problems likely)
Date: Tue, 01 Apr 2014 12:47:30 -0700

Assuming that ntpd has been running this whole time without restarting,
and has had time to settle, how does it look now?

On 04/01/2014 12:03, Lincoln Bryant wrote:
> Yep, and ERROR too as a bonus.
>
> [root@uct2-s19
> etc]# ntptime
> ntp_gettime() returns code 5 (ERROR)
> time d6e58bfd.6417d000 Tue, Apr 1 2014 14:03:25.390, (.390988),
> maximum error 160516 us, estimated error 16 us
> ntp_adjtime() returns code 5 (ERROR)
> modes 0x0 (),
> offset 0.000 us, frequency 0.000 ppm, interval 1 s,
> maximum error 160516 us, estimated error 16 us,
> status 0x40 (UNSYNC),
> time constant 4, precision 1.000 us, tolerance 500 ppm,
>
> On Apr 1, 2014, at 2:02 PM, Shawn McKee wrote:
>
>> Hi Lincoln,
>>
>> Does 'ntptime' also show UNSYNC ?
>>
>> Mine shows:
>>
>> [smckee@umt3int02
>> ~]$ ntptime
>> ntp_gettime() returns code 0 (OK)
>> time d6e58ba9.bbb15b10 Tue, Apr 1 2014 15:02:01.733, (.733175930),
>> maximum error 479867 us, estimated error 797 us, TAI offset 0
>> ntp_adjtime() returns code 0 (OK)
>> modes 0x0 (),
>> offset 13.157 us, frequency 52.215 ppm, interval 1 s,
>> maximum error 479867 us, estimated error 797 us,
>> status 0x2001 (PLL,NANO),
>> time constant 10, precision 0.001 us, tolerance 500 ppm,
>>
>> Shawn
>>
>>
>> On Tue, Apr 1, 2014 at 3:00 PM, Lincoln Bryant
>> <
>>
>> <mailto:>>
>> wrote:
>>
>> Done.
>>
>>
>> [root@uct2-s19
>> etc]# /etc/init.d/ntpd stop
>> Shutting down ntpd: [ OK ]
>>
>> [root@uct2-s19
>> etc]# ntpdate ntp-1.uchicago.edu
>> <http://ntp-1.uchicago.edu/>
>> 1 Apr 13:57:57 ntpdate[866076]: adjust time server 128.135.247.50
>> <tel:128.135.247.50> offset -0.000439 sec
>>
>> [root@uct2-s19
>> etc]# /etc/init.d/ntpd start
>> ntpd: Synchronizing with time server: [ OK ]
>> Syncing hardware clock to system time [ OK ]
>> Starting ntpd: [ OK ]
>>
>> [root@uct2-s19
>> etc]# ntpq -p
>> remote refid st t when poll reach delay
>> offset jitter
>>
>> ==============================================================================
>> *lyceum.uchicago 128.10.19.24 2 u 1 64 1 0.296
>> 0.180 0.011
>> dns1.uchicago.e 169.254.0.1 3 u - 64 1 0.425
>> -0.418 0.066
>> dns2.uchicago.e 169.254.0.1 3 u 1 64 1 0.516
>> -0.539 0.046
>>
>> [root@uct2-s19
>> etc]# ntp
>> ntp ntpd ntpdate ntpdc ntp-keygen ntpq
>> ntpstat ntptime ntptrace ntp-wait
>>
>> [root@uct2-s19
>> etc]# ntpdc -c kerninfo
>> pll offset: 0 s
>> pll frequency: 0.000 ppm
>> maximum error: 0.022016 s
>> estimated error: 1.6e-05 s
>> status: 0040 unsync
>> pll time constant: 4
>> precision: 1e-06 s
>> frequency tolerance: 500 ppm
>>
>> --Lincoln
>>
>> On Apr 1, 2014, at 1:57 PM, Shawn McKee wrote:
>>
>>> Before you restart ntpd, you could run 'ntpdate <ntp-server>'
>>> to get your clock close. (you need ntpd off to do that)
>>>
>>> Then do 'service ntpd start'
>>>
>>> Shawn
>>>
>>>
>>> On Tue, Apr 1, 2014 at 2:55 PM, Lincoln Bryant
>>>
>>> <
>>>
>>> <mailto:>>
>>> wrote:
>>>
>>> Yeah, let me change this to just chime directly against our
>>> three campus servers.
>>>
>>> --Lincoln
>>>
>>> On Apr 1, 2014, at 1:54 PM, Shawn McKee wrote:
>>>
>>>> OK, that is at least part of the problem.
>>>>
>>>> The reach shows you are not regularly able to
>>>> connect to the NTP server. (it would be 377 if you
>>>> could).
>>>>
>>>> Also you really need to have 3 servers configured to
>>>> allow ntp to isolate bad time sources. Can you add
>>>> two more ? There are quite a few examples in any
>>>> of your perfSONAR-PS systems (check the web interface
>>>> for NTP servers)
>>>>
>>>> Shawn
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Apr 1, 2014 at 2:51 PM, Lincoln Bryant
>>>>
>>>> <
>>>>
>>>> <mailto:>>
>>>> wrote:
>>>>
>>>>
>>>> [root@uct2-s19
>>>> ~]# ntpq -p
>>>> remote refid st t when poll reach
>>>> delay offset jitter
>>>>
>>>> ==============================================================================
>>>> *uct2-grid9.mwt2 128.135.247.50 <tel:128.135.247.50> 4
>>>> u 9 64 37 0.151 0.114 0.043
>>>>
>>>>
>>>> [root@uct2-s19
>>>> ~]# cat /etc/ntp.conf
>>>> server uct2-grid9.mwt2.org
>>>> <http://uct2-grid9.mwt2.org/> burst iburst
>>>> restrict uct2-grid9.mwt2.org
>>>> <http://uct2-grid9.mwt2.org/> mask 255.255.255.255
>>>> nomodify notrap
>>>> restrict default ignore
>>>> restrict 127.0.0.1
>>>> driftfile /var/lib/ntp/ntp.drift
>>>> logfile /var/log/ntp.log
>>>>
>>>>
>>>> On Apr 1, 2014, at 1:49 PM, Shawn McKee wrote:
>>>>
>>>>> HI Lincoln,
>>>>>
>>>>> What does 'ntpq -p' show? What is in
>>>>> /etc/ntp.conf ?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Shawn
>>>>>
>>>>>
>>>>> On Tue, Apr 1, 2014 at 2:46 PM, Lincoln Bryant
>>>>>
>>>>> <
>>>>>
>>>>> <mailto:>>
>>>>> wrote:
>>>>>
>>>>> I believe what is happening is that the kernel
>>>>> UNSYNC flag never gets cleared.
>>>>>
>>>>>
>>>>> [root@uct2-s19
>>>>> ~]# /etc/init.d/ntpd restart
>>>>> Shutting down ntpd:
>>>>> [ OK ]
>>>>> ntpd: Synchronizing with time server:
>>>>> [ OK ]
>>>>> Syncing hardware clock to system time
>>>>> [ OK ]
>>>>> Starting ntpd:
>>>>> [ OK ]
>>>>>
>>>>> [root@uct2-s19
>>>>> ~]# ntpdc -c kerninfo
>>>>> pll offset: 0 s
>>>>> pll frequency: 0.000 ppm
>>>>> maximum error: 0.001516 s
>>>>> estimated error: 1.6e-05 s
>>>>> status: 0040 unsync
>>>>> pll time constant: 4
>>>>> precision: 1e-06 s
>>>>> frequency tolerance: 500 ppm
>>>>>
>>>>> 1 Apr 13:45:51 ntpd[865015]: synchronized to
>>>>> 192.170.227.136, stratum 4
>>>>>
>>>>> --Lincoln
>>>>>
>>>>> On Apr 1, 2014, at 1:41 PM, Lincoln Bryant wrote:
>>>>>
>>>>>> I should add that our UL kernel is actually a
>>>>>> derivative of the UltraLight kernel, rather than
>>>>>> UltraLight 'proper'. Specifically, we are running
>>>>>> kernel 3.2.13 for performance reasons.
>>>>>>
>>>>>> I had some relevant information for this, let me
>>>>>> see if I can dig it up.
>>>>>>
>>>>>> --Lincoln
>>>>>>
>>>>>> On Apr 1, 2014, at 1:38 PM, Shawn McKee wrote:
>>>>>>
>>>>>>> Both 'bwctl' and 'owping' want to have the
>>>>>>> local clock correctly synchronized.
>>>>>>>
>>>>>>> What does ntptime show on this host?
>>>>>>>
>>>>>>> What about 'ntpq -p' ?
>>>>>>>
>>>>>>> What is in /etc/ntp.conf ?
>>>>>>>
>>>>>>> Lincoln, Is there something you hit with the
>>>>>>> UltraLight kernel that is messing up ntp?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Shawn
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Apr 1, 2014 at 2:35 PM, Hironori Ito
>>>>>>>
>>>>>>> <
>>>>>>>
>>>>>>> <mailto:>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hello.
>>>>>>>
>>>>>>> do you know how to get around the issue of
>>>>>>> the following error when bwctl is run?
>>>>>>>
>>>>>>>
>>>>>>> [root@uct2-s20
>>>>>>> ~]# bwctl -T nuttcp -c
>>>>>>> aofa-pt1.es.net <http://aofa-pt1.es.net/> -f
>>>>>>> m -i 2 -x -t 100
>>>>>>> bwctl: NTP: Status UNSYNC (clock offset
>>>>>>> problems likely)
>>>>>>> bwctl: NTP is unsynchronized. Skipping test.
>>>>>>> Use -a to run anyway.
>>>>>>>
>>>>>>> Lincoln stats that it has something to do
>>>>>>> with ultralight kernel?
>>>>>>>
>>>>>>> Hiro
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>

[perfsonar-user] Re: ultralight kernel and bwctl NTP: Status UNSYNC (clock offset problems likely), (continued)

List archive

Re: [perfsonar-user] Re: ultralight kernel and bwctl NTP: Status UNSYNC (clock offset problems likely)