I've seen three replys, all asking why I need a stratum one source. Here's the background:
I'm at the University of Puget Sound where the Technology Services group runs some stratum two servers relying on a well-known stratum one server in Seattle (I'll call BB). Just for the fun of it, last summer I plugged a Garmin GPS17HSV into one of my systems to provide pulse-per-second discipline to the system's clock. When I did, I added that BB to my list of time sources. The kernel tracked the GPS fairly well, staying under +- 200 us difference; the difference from BB stayed in the same range, but showed lots more moment-to-moment changes. When I booted to the latest kernel and restarted ntpd on February 4th, the system followed the GPS clock much more closely, generally +- 10 us; BB still had a +- 200 us range of time difference. Then the probem arose: On Febrary 27 the difference between the system's clock and BB started to diverge. This caught my attention and after a few days confusion I added some more stratum one servers to my list in an attempt to determine where the problem was. I found that another GPS based server matched BB fairly closely; three other ACTS based servers hovered near the GPS based servers, but had much more variation. There was one ACTS server which was very stable, but was offset from the others by 8 ms in the other direction, i.e., my system fell between the cluster and the outlier.. This discrepancy reached a peak of nearly 9ms on March 5th and is on its way back to agreement with my GPS clock. I'd like to connect to some nearby stratum one servers where the round trip delay and jitter is less than the offset. That'll limit the possiblity that the divergence is due to asynchronous delay. In addition, I'd like to talk to the administrator of those sites to see if they connect to other stratum one servers, and if they've seen any divergence. I hope that I can resolve this before this summer so I can enter one of our CS dept servers into the NTP pool. -- Randolph Bentson [email protected]
