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