perfSONAR User Q&A and Other Discussion

[Alan Whinery <>]

The startup invoke for any less-than-10-year-old ntpd should be including "-g":

  -g     Normally, ntpd exits with a message to the  system  log  if  the
              offset  exceeds the panic threshold, which is 1000 s by default.
              This option allows the time to  be  set  to  any  value  without
              restriction; however, this can happen only once.  If the threshâ[m
              old is exceeded after that, ntpd will exit with a message to the
              system log.  This option can be used with the -q and -x options.

So I would think that running ntpdate is redundant.


On 4/1/2014 8:57 AM, 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 <> 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 <> wrote:

[root@uct2-s19 ~]# ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

*uct2-grid9.mwt2 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 burst iburst

restrict  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 <> 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 <> 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 -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