Topic: SME8 requests for time from NTP servers too often

[fgra00]

Helllo,
on my new SME8 installation, I recognize permanent traffic to my provider.
tcpdump shows frequently connection to ntp servers. (once per second and more often).
Whats going wrong, What to do?

When I disable  in server-manager  the NTP server "smeserver.pool.ntp.org", the connection is calm.
Activate the NTP-server function again results in  permanent traffic to various NTP-servers.

Thanks in advance for your help

[mmccarn]

Here's what I get from config show ntpd:

Code: [Select]

ntpd=service
    MemLimit=12000000
    NTPServer=smeserver.pool.ntp.org
    SyncToHWClockSupported=yes
    status=enabled
Here's what I get from ntpq -pn:

Code: [Select]

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.1.0     .LOCL.          10 l   44   64  377    0.000    0.000   0.001
+216.23.247.62   164.244.221.197  2 u  673 1024  377   34.921    1.455   0.274
+204.235.61.9    128.252.19.1     2 u  752 1024  377   30.175   -7.944   3.419
-199.4.29.166    209.51.161.238   2 u  676 1024  377    7.760  -21.172   0.520
*199.102.46.73   .GPS.            1 u  762 1024  377   38.800   -3.772   0.183
"when" counts up to "poll", then resets to 0 -- which I assume to mean my server is checking every 1024 seconds with the configured remote time servers, and every 64 seconds with the local hardware clock.

Virtual machines used to have time drift problems with the local clock - I don't know if these problems still exist (but I assume they do since they involved specific limitations in virtualization technology).  If your SME server is virtual, look around for the changes you need to make to your clock settings to keep the time stable.

[fgra00]

Hello,
thanks for your answer.
With  config show ntpd: I receive the identical like you.
But for  ntpq -pn  I receive following answer:

     remote           refid              st t when poll reach   delay   offset  jitter
==============================================================================
 176.31.45.66    62.149.0.30        2 u   57   64    7   62.468  -14.495  14.764
 212.18.3.18     212.18.1.106       2 u   59   64    7   58.742    4.129  15.129
 129.70.132.34   192.53.103.108   2 u   54   64    7   56.413  -13.794  15.048
 130.149.220.2   130.149.17.21     2 u   56   64    7   58.601   -4.446   9.319
 127.127.1.0     .LOCL.                10 l   53   64    7    0.000    0.000   0.001

Can you help me to explain this? 
What is to do to decrease the polling rate?
Best regards
P.S. How did you get the lines well organised in that nice blue frame ?

[janet]

fgra00

The two common formatting commands used in the forums are surrounded by square braces, and enclose the word quote at the start & /quote at the end
and
code at the start & /code at the end
Like as shown below but without the spaces
Let's see how this appears

[ quote ] blah blah blah [ /quote ]

blah blah blah

[ code ] 12345 12345 12345 [ /code ]

Code: [Select]

12345 12345 12345

[mmccarn]

Reference Links
ntp.conf: http://linux.die.net/man/5/ntp.conf
ntpq: http://morrison.oce.orst.edu/doc_link/C/a_doc_lib/cmds/aixcmds4/ntpq.htm
ntpdate: http://www.eecis.udel.edu/~mills/ntp/html/ntpdate.html

Observations
ntp polls the configured servers based on a combination of how fast your computer clock is drifting and the "minpoll" and "maxpoll" options. I believe that if your local time is too far off from your configured servers that ntp will assume there's some other problem and refuse to make changes.

The default value for "minpoll" is 6 (2^6, or 64s) and the default value for "maxpoll" is 10 (2^10, or 1024s).

Your clock is so far off that ntp thinks you need to resync every 64 seconds (the default minimum value), while my system only thinks I need to resync every 1024 seconds (the default maximum value).

On my sample output from "ntp -pn", the currently active time server is indicated with an asterisk:

Code: [Select]

*199.102.46.73   .GPS.            1 u  762 1024  377   38.800   -3.772   0.183Your output does not include the status indicators from the first column of output, or all of your results begin with a space indicating that the associated time server has been "Discarded due to high stratum and/or failed sanity checks".

On my output, the server preceded by a minus ("Discarded by the clustering algorithm") has an offset of only 21s - which is apparently too large to use - while the smallest offset in your listing is 56 seconds. 

I conclude that your system time is so far off that ntp is refusing to update it -- but keeps trying.

Recommendations
Manually updating the system clock from one of your ntp sources may fix your problem:

Code: [Select]

ntpdate -u 130.149.220.2 (I chose 130.149.220.2 from your output as the server with the smallest offset and jitter).

If manually setting your server time using ntpdate solves your problem, it would be great if you opened a bug report about "incorrect server time generates excessive ntp traffic" -- but only if you would have the time to cooperate in the testing of any solutions that get proffered.

[fgra00]

Hello, thanks  for your help and recommendations.

The server requests not every 64 seconds , see here the answer for tcpdump -i eth1:

22:46:32.546222 IP 192.168.1.2.ntp > bds2.bds-bayern.de.ntp: NTPv4, Client, length 48
22:46:32.547126 IP alvo.fungus.at.ntp > 192.168.1.2.ntp: NTPv4, Server, length 48
22:46:32.547214 IP 192.168.1.2.ntp > alvo.fungus.at.ntp: NTPv4, Client, length 48
22:46:32.560268 IP v.arin.net.domain > 192.168.1.2.45433:  34159*- 1/4/8 A w.arin.net (288)

When I'm right there are requests several times per second.
There were no status indicators in front of the  ntpq -pn results
Then I disabled with server-manager  the NTP-server . (Date and Time )
The  transfer via ETH1 was redued at once.

Like you recommended I updated the time manually from:  ntpdate -u 130.149.220.2

Finally I enabled the NTPserver via server-manager  to: NTPServer=smeserver.pool.ntp.org

Actually I have  following behaviour: with ntpq -pn:

Code: [Select]

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+178.63.212.146  192.53.103.108   2 u    3   64  377   59.589    2.807   2.857
+188.40.51.2     192.53.103.104   2 u    2   64  377   60.100    2.944   0.953
*131.188.3.220   .GPS.            1 u   55   64  377   65.340    1.893   0.799
-193.138.112.10  192.53.103.104   2 u   58   64  377   54.216   -1.006   0.719
 127.127.1.0     .LOCL.          10 l   62   64  377    0.000    0.000   0.001

There are status indicators and the Traffic is calm.
We will see if it stys OK until tomorrow. 
So far  thanks a lot for your help.

Regards Franz