This is a discussion on NTPD concurrent clients limit - NTP ; "Phil" writes: >Danny and Gang, u didn't read the posts. >We have our own ntp servers, actually east and west and possibly more in >future >Everything is under out control. I have seen some rouge pool servers in the >past, ...
>Danny and Gang, u didn't read the posts.
>We have our own ntp servers, actually east and west and possibly more in
>Everything is under out control. I have seen some rouge pool servers in the
>past, I wanted eliminate that anyway.
>Fact is we have also been experimenting with replacing clocks in larger
>multi cpu servers with an OCXO timebase board that is phase locked to
>external gps disciplined rubidium standards. Servers will not be an issue,
>bandwidth could be. It may wind up being a modified ntp, but since it's not
>for public access as such, who cares
>Hope that is clear enough, your fears eliminated !
Fears for the poor public servers eliminated. Fears for your system not. I
am wondering if you have really thought through your system. You are trying
to slave a local "timebase board" to rubidium standards remotely located.
That means you must go through the net to get at the standard. The net is a
very noisy place. Your packets suffer all kinds of delays-- random,
asymmentric, time dependent, etc. Ie, you will not get anything like the
accuracy you are probably hoping for. An ordinary PC linked to a cheap PPS
GPS receiver can get a few microseconds accuracy. A clock linked to the
best rubidium controlled clock 1000 miles away will be good to get
millisecond accuracy because of all that network noise.
Ie, you should carefully read the ntp docs to see what the design is.
Note also that the design of chrony which in its clock discipline is very
different from ntp, seems to have advantages of a factor of 2 or 3 over the
ntp model at least in the configurations I have tested. But a factor of 2
is not a factor of 100-1000 which is what you would loose from the network.