Steve Kostecke wrote:
> There's nothing stopping him from implementing what he considers to be a
> solution himself. He could even distribute his modified version of NTP
> to anyone who wanted to use it.
Why should he do that when something already exists, although it is not
technically NTP? As
Hallo Noosh,
I look after a Hopf 6855, which is similar to your 6842 but
receives LF signals from DCF77.
I configured my Hopf clock as follows:
Serial output: 09600 bits/sec, 8 data bits, no parity, 1 stop bit, no
handshake
Mode byte 1: binary 0100
Mode byte 2: binary
Status and pu
David Woolley <[EMAIL PROTECTED]> writes:
> For the most accurate time, you need to connect the PPS outputs, which
> seem to be separate from the RS 232 interface. (It's not worth
> downloading the manual to check this without the exact version
> information.)
Hmm, isn't the PPS signal usually co
Quoting from the documentation of refclock driver 22:
"A radio clock is usually connected via a serial port and the
PPS source connected via a level converter to the data
carrier detect (DCD) pin (DB-9 pin 1, DB-25 pin 8) of the
same connector."
No doubt there are other ways of skinning this cat.
"Dennis Hilberg, Jr." <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>I recently snagged an Ultralink 325 WWVB receiver off Ebay to use as a
> refclock with an ntp server, hoping to peer that one and my gps-referenced
> ntp server together.
How far are you from Boulder? What is the
Rob Kimberley wrote:
> How far are you from Boulder? What is the period of the step you are seeing?
> If on a regular 24 hour basis, I'm guessing due to diurnal affects. Do you
> have a plot we can see?
>
> Rob Kimberley
You mean from Fort Collins? I'm about 1495 km from there.
I'll generate
Dag-Erling Smørgrav wrote:
> Hmm, isn't the PPS signal usually connected to one of the flow control
> pins?
That's how people typically get it into the computer, but in this case,
and I believe more generally, the user is responsible for arranging for
the signal to appear on that pin and at a l
David,
I don't know what you mean by "figure head", but this is probably what
is intended. The statistics such as root delay, root dispersion and
related statistics are in fact inherited from the system peer, but the
actual clock offset is computed as a weighted average. See the draft
MT{v4 sp
Dag-Erling,
The monitor and rate semantics are further elaborated in the recent
documentation posted to the web page.
Dave
Dag-Erling Smørgrav wrote:
> "David L. Mills" <[EMAIL PROTECTED]> writes:
>
>>The rate violation is caught in the MRU list, which can be retrieved
>>using ntpdc and the mo
Guys,
This is really silly. The Unruh agenda is clear. Should you choose to
limit the application space to fast local networks, the chrony choice
may or may not be optimal. Should you extend this space to the raunchy
global Internet, conviction will require diligent testing and analysis.
There
10 matches
Mail list logo