time sinchronization

Sat Feb 10 22:00:25 UTC 2007

On 2/10/07, Zbigniew Koziol <softquake-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> It did work on my computers in the past.
>
> Now, I maintain ubuntu server. That, it seemed, trivial thing, does not look
> trivial anymore.

I might wildly guess that this may be a case where Debian has
introduced several packages and put some common config into one or two
of them such that "fighting with the distribution" is getting you into
frustration.

> Would someone be kind enough to write a short, basic recipe for that?

1.  Install ntp

apt-get install ntp

2.  Make sure it has some servers listed in /etc/ntp.conf

There is a global pool of over 100 NTP servers that provide
round-robin services via DNS; if you specify "pool.ntp.org", you'll
use that pool, and not flood anybody.

> What, if any, software should I install?

ntp

>Which ports should be opened?

Port 123 needs to be open to UDP traffic.

> How to synchronize from command line?

For that, you need to install the separate package, ntpdate.

If ntpd is NOT running, you can, as root, run:

ntpdate pool.ntp.org pool.ntp.org myhost.org yourhost.org ...

> Is time.nsrc.ca appropriate for using?

Probably not, unless you're setting time for a large set of servers.

You should probably use pool.ntp.org instead.

Another entertaining option is to consider backtracing the servers
nearby you in your network.

For instance, if I trace a route out to somewhere (say slashdot), I
find a whole bunch of routers in the way.  Many of them are Cisco
routers that are running NTP.

knuth:~# traceroute slashdot.org
traceroute to slashdot.org (66.35.250.150), 30 hops max, 52 byte packets
 1  godel (192.168.1.1)  0.369 ms  0.300 ms  0.298 ms
 2  64.230.197.235 (64.230.197.235)  52.002 ms  52.169 ms  50.934 ms
 3  dis26-toronto63_Vlan112.net.bell.ca (64.230.222.81)  49.018 ms
47.679 ms  50.631 ms
 4  core4-toronto63_GE5-2.net.bell.ca (64.230.207.105)  51.990 ms
49.893 ms  50.249 ms
 5  core1-chicago23_pos12-0-0.net.bell.ca (64.230.147.14)  60.330 ms
61.197 ms  57.883 ms
 6  bx4-chicago23_POS3-0.net.bell.ca (64.230.203.50)  63.479 ms
60.386 ms  59.579 ms
 7  dcr1-so-3-1-0.chicago.savvis.net (208.175.10.85)  60.268 ms
59.505 ms  93.675 ms
 8  dcr2-so-2-0-0.Denver.savvis.net (204.70.192.133)  83.555 ms
85.276 ms  84.046 ms
 9  dcr1-so-2-0-0.SanFranciscosfo.savvis.net (204.70.192.114)  126.579
ms  128.396 ms  161.049 ms
10  dcr2-so-5-0-0.SanFranciscosfo.savvis.net (204.70.192.150)  126.611
ms  126.159 ms  124.423 ms
11  bhr1-pos-0-0.SantaClarasc8.savvis.net (208.172.156.198)  128.546
ms  125.492 ms  127.232 ms
12  csr1-ve243.santaclarasc8.savvis.net (66.35.194.50)  129.895 ms
128.189 ms  132.192 ms
13  66.35.212.174 (66.35.212.174)  132.563 ms  174.111 ms  128.656 ms
14  slashdot.org (66.35.250.150)  135.238 ms !C  128.849 ms !C  129.558 ms !C

Turning this into an ntpdate request:
knuth:~# ntpdate `traceroute slashdot.org 2> /dev/null | awk '{print
$2}' | tr '()' ' ' `
10 Feb 16:50:43 ntpdate[19518]: adjust time server 208.172.156.198
offset 0.000835 sec

I'm not sure that's 100% 'kosher,' but if argued with, I could argue
that these servers all volunteered to carry my traffic.  The argument
would be stronger if I restricted the list to the Bell servers nearby,
as I'm paying them for Internet services...

At any rate, I'd suggest trying to have some diverse set of servers
that *aren't* all the same tick/tock @ U(T).

FYI, it seems like a waste of time to me to try to find a server
geographically nearby.  When I run traceroute, I find that I need to
go thru Chicago to get back to anything at U(T).  That's going to be
common for anyone using Bell Sympatico.  I wouldn't be surprised if
Rogers users would discover similar to be true.

It appears that Sympatico hasn't any connections to the Toronto
Internet Exchange (torix.net), which seems silly to me; there ought to
be value to having direct quick access to geographically nearby
servers around Toronto.  Of course, they've never been accused of
being particularly bright...
-- 
http://linuxfinances.info/info/linuxdistributions.html
"...  memory leaks  are  quite acceptable  in  many applications  ..."
(Bjarne Stroustrup, The Design and Evolution of C++, page 220)
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists