| 1 |
Am Mittwoch, 4. Februar 2009 14:57:28 schrieb Alan McKinnon: |
| 2 |
|
| 3 |
> ntpd is really designed for Unix servers with 3 digit uptimes and clocks |
| 4 |
> not assembled by Mickey Mouse's younger brother (which seems to include all |
| 5 |
> pcs ever made.....) |
| 6 |
|
| 7 |
Errh, no. It is designed for exactly those machines, so that they are |
| 8 |
independant of their hardware (Mickey Mouse) clock and of course to keep them |
| 9 |
all in sync with each other (and the Unix servers they connect to). |
| 10 |
|
| 11 |
> Most folk are better off with ntpdate run from a cron. When run, it checks |
| 12 |
> the upstream time and immediately corrects the local clock to that time. |
| 13 |
> Schedule it for once an hour or so, depending on your bandwidth and local |
| 14 |
> ntp site's policies. |
| 15 |
|
| 16 |
That does exactly what NTP tries to avoid: Time jumps. |
| 17 |
|
| 18 |
So when you're not connected to the net permanently, one has two choices: |
| 19 |
|
| 20 |
1) Choose one of your machines as the ntp time server which delivers the time |
| 21 |
of its internal clock and synchronize each others time with this one. In the |
| 22 |
end it only matters that the time is correct in _your_ own network, isn't it. |
| 23 |
|
| 24 |
2) If even the most accurate internal clock on your network is not accurate |
| 25 |
enough, plug an accurate time source into one machine you choose as time |
| 26 |
server, then goto 1). |
| 27 |
|
| 28 |
Bye... |
| 29 |
|
| 30 |
Dirk |
Archives