Obsolete Releases > SME 8.x Contribs
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: ---ntpd=service
MemLimit=12000000
NTPServer=smeserver.pool.ntp.org
SyncToHWClockSupported=yes
status=enabled
--- End code ---
Here's what I get from ntpq -pn:
--- Code: --- 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
--- End code ---
"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 ]
--- Quote --- blah blah blah
--- End quote ---
[ code ] 12345 12345 12345 [ /code ]
--- Code: ---12345 12345 12345
--- End code ---
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: ---*199.102.46.73 .GPS. 1 u 762 1024 377 38.800 -3.772 0.183
--- End code ---
Your 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: ---ntpdate -u 130.149.220.2
--- End code ---
(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.
Navigation
[0] Message Index
[#] Next page
Go to full version