Koozali.org: home of the SME Server
Obsolete Releases => SME 8.x Contribs => Topic started by: fgra00 on January 20, 2013, 03:35:20 PM
-
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
-
Here's what I get from config show ntpd:
ntpd=service
MemLimit=12000000
NTPServer=smeserver.pool.ntp.org
SyncToHWClockSupported=yes
status=enabled
Here's what I get from ntpq -pn: 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.
-
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 ?
-
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 ]
12345 12345 12345
-
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:*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: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.
-
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:
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