1 |
On 26/04/2013 19:11, Nick Khamis wrote: |
2 |
>>> >> Thank you so much for your response, and I totally understand the |
3 |
>>> >> effort vs. benefit challenge. However, is it really that much |
4 |
>>> >> trouble/unstable to setup our own ntp |
5 |
>>> >> server that syncs with our local isp, and have our internal network sync |
6 |
>>> >> on it? |
7 |
>> > |
8 |
>> > |
9 |
>> > No, it's not THAT much effort. You can get by with installing ntpd on a |
10 |
>> > single machine, pointing it at the upstream time server and pointing all |
11 |
>> > your clients to it. It's clearly recorded in the config file, you can't |
12 |
>> > go wrong. |
13 |
>> > |
14 |
>> > It's understanding how this weird thing called time works that is the |
15 |
>> > issue. Take for example leap seconds..... urggggggggggg... |
16 |
>> > |
17 |
>> > The basic question I suppose is why do you want to do it this way? What |
18 |
>> > do you feel you will gain by doing it yourself? |
19 |
>> > |
20 |
>> > |
21 |
>> > -- |
22 |
>> > Alan McKinnon |
23 |
>> > alan.mckinnon@×××××.com |
24 |
>> > |
25 |
>> > |
26 |
>> > |
27 |
> Hello Alan, |
28 |
> |
29 |
> Thank you so much for your time. Our voip cluster time always vary for |
30 |
> some reason.... |
31 |
> And with long distance, that could mean upwards to a dollar a call. |
32 |
|
33 |
|
34 |
Ah, OK. That changes things quite a bit. I have a little bit of |
35 |
experience with that - I work for a large ISP, we have a large VOIP |
36 |
department and we run a stratum 2 time server that serves most of the |
37 |
country. |
38 |
|
39 |
First things first: you can't just stick any old upstream ntp server in |
40 |
your config and walk away. You are then reliant on the quality of that |
41 |
upstream, and far too often other time servers operate on a "good |
42 |
enough" policy - if it's accurate to about a second, it's good enough |
43 |
(and for desktop users i.e. most ISP clients, it is good enough). |
44 |
|
45 |
I don't know how big your operation is, if you have budget I suggest you |
46 |
invest in a proper master time source that is GPS-driven. We have a |
47 |
Symmetricom (http://www.symmetricom.com) but it's a mature market with |
48 |
several vendors. Shop around, prices are less than you'd expect (about |
49 |
the same as a decent mid-range server and much less than Cisco's routers...) |
50 |
|
51 |
Weather can get in the way, so back up the device with a decent second |
52 |
upstream. I have a good one available run by the Science and Technology |
53 |
Research part of the Dept of Trade and Industry and the third option is |
54 |
all the other big ISPs around. |
55 |
|
56 |
Depending on your accuracy needs you could get away without the GPS unit |
57 |
and just use a good upstream, but I'd fight for the budget for it - tell |
58 |
management it puts control of billing back in your hands, they always |
59 |
fall for that one :-) |
60 |
|
61 |
So the summary would be that I reckon ntpd will do what you want as long |
62 |
as you chose good reliable time sources. With that in hand, the config |
63 |
is easy as rather well documented. Shout here ont he list if you need a |
64 |
hand with this when you come to deployment time |
65 |
|
66 |
|
67 |
|
68 |
|
69 |
-- |
70 |
Alan McKinnon |
71 |
alan.mckinnon@×××××.com |