Apologies for a long post, but I was unable to make it shorter.
I have been monitoring timekeeping performance on an environment which
contains 3 stratum 1 clocks and 4 Cisco routers running as stratum 2.
The stratum 1s use time which is derived originally from GPS, but fed
to the stratum 1 clocks
Hi Brian,
On 9 May, 19:06, Brian Utterback <[EMAIL PROTECTED]> wrote:
> Do you have the frequency data from the same period as the graph? What
> happened to cause the frequency to be off all of a sudden?
Loopstats weren't enabled so I don't have the frequency data. I'm out
of the office today but
On 9 May, 16:46, Unruh <[EMAIL PROTECTED]> wrote:
> Why would you use a solaris system? AFAIK its kernel timeing routines are
> primative. Use a Linux/BSD system.
This is an existing system which I don't have the means to change even
if I felt that Solaris were somehow intrinsically inferior to Li
On 12 May, 15:16, "Richard B. Gilbert" <[EMAIL PROTECTED]> wrote:
> Mike K Smith wrote:
> > Looks like I should be reducing maxpoll. I guess the design of NTP is
> > optimised for clocks with predictable drift rates, and a sudden
> > variation in drift rat
On 12 Sep, 22:14, David Woolley <[EMAIL PROTECTED]>
wrote:
> Howard Barina wrote:
>
> > Does an NTP servers take into account it's estimated offset in serving time
>
> There seem to have been a lot of questions asked in the last month that
> are based on the false assumption that "offset" measures
On 23 Jan, 03:18, anna_chen...@yahoo.com wrote:
> Hi, I need some help in interpreting the loopstats file, hope someone
> can help
> I have ntp configured so that it is generating the loopstats file, the
> file format is the following
>
> 54854 852.338 0.000779917 -85.871689 0.001363577 15.650605 1
Hi,
For testing purposes I want to configure an NTP server to run with a
small but known offset. I would like to test at the following offset
values 25, 90, 180, 350 and 2500ms.
I tried the naive approach first - I synced a Linux PC to a stratum 1
server and once it was stable I reconfigured NTP
> > For testing purposes I want to configure an NTP server to run with a
> > small but known offset. I would like to test at the following offset
> > values 25, 90, 180, 350 and 2500ms.
>
> What is this test intended to prove?
I want to understand how long it takes in practice for an offset to be
p
On 10 Mar, 14:29, Steve Kostecke wrote:
> On 2009-03-10, Mike K Smith wrote:
>
> >Steve Kostecke wrote:
>
> >>Mike K Smith wrote:
> Now that I thing about it, what happened when you applied that offset is
> that you "moved" the clock 90ms.
>
> >
On 13 Mar, 04:31, Joseph Gwinn wrote:
> The timeserver can be either a Symmetricom ET6010 GPS receiver feeding
> an IRIG-B002 time signal to a Symmetricom TS2100 Network Time Server, or
> a Spectracom 9383 NTP timeserver with built-in GPS receiver. The GPS
> receivers are driven from a common ant
On 31 May, 22:20, Brian Utterback wrote:
> Hal Murray wrote:
> > In article <1243711613.525...@news1nwk>,
> > Brian Utterback writes:
> >> David Woolley wrote:
>
> >>> It only requires 2. The argument about having four initially is about
> >>> having a clear majority even after rejecting one.
>
On 2 June, 14:31, Brian Utterback wrote:
> David Woolley wrote:
> > smithmi...@googlemail.com wrote:
>
> >> In the case below, will server 3 be treated as a falseticker because
> >> its offset lies outside the dispersion interval of the other two
> >> servers even though there is some intersection
Maarten Deen wrote:
> A while now I'm having some problems with my ntp setup.
>
> I have simple comfig file:
> $ cat /etc/ntp.conf
> # /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
>
> driftfile /var/lib/ntp/ntp.drift
> logfile /var/log/ntp.log
>
> server 0.nl.pool.ntp.org
>
13 matches
Mail list logo
