1 |
Am 05.01.2011 06:00, schrieb Dale: |
2 |
> William Kenworthy wrote: |
3 |
>> Is the clock almost in sync? - if its too far out ntp will silently fail |
4 |
>> to sync (by design - large scale time steps can be destructive for |
5 |
>> heavily active databases for instance) |
6 |
That's what i meant in my earlier post and what the extract of your logfile confirms. |
7 |
|
8 |
>> |
9 |
>> Check out the -g option to ntpd in 'man ntpd' |
10 |
>> |
11 |
>> or 'tinker panic 0' in ntp.conf |
12 |
>> |
13 |
>> Also, has ntp.conf specified a writable frift file in a directory that |
14 |
>> exists? |
15 |
>> |
16 |
>> ntp can be VERY complex when it doesnt "just work" :) |
17 |
+1 |
18 |
|
19 |
|
20 |
>> |
21 |
> |
22 |
> It syncs and adjusts the time. It just doesn't do it like my older rig. My old rig, when I booted it up, ntp would sync and in about a hour or so it would be accurate enough that it would only sync a few times a day. Since I have long uptimes, that worked out well. With this new rig, it syncs about every ten to 15 minutes and adjusts and just keeps doing the same thing. It never sets the drift file to a setting that allows it to go more than ten or fifteen minutes without resetting the clock. This is what is in messages: |
23 |
|
24 |
If i remember right your new rig is AMD-Phenom based?! - then just have a look at http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.4.2.7. |
25 |
If your clocksource is the tsc it's possible youre affected by this problem. |
26 |
At http://www.ep.ph.bham.ac.uk/general/support/adjtimex.html#issues is a "nice" illustration of the affect. |
27 |
|
28 |
|
29 |
Steffen |