James,
Your email posting style makes it very difficult to follow threads where
you have posted replies.
Most mail reader programs follow the convention, that on a reply, they
automatically start with a header that identifies the last poster ("In
reply to message from xxx") and then "quote" the entire replied-to
message by prefixing each line with a chevron ">" in the first column.
If another person replies later the same process is usually used, so
when reading the latest message in the thread, one can determine the
sequence of replies, because the oldest has maximum chevrons preceeding
the lines, and the most recent comments have none. One can usually trace
up the message to find the "in response to"-type headers and figure out
who said what.
Here's a link with a discussion of these conventions:
http://en.wikipedia.org/wiki/Posting_style
You seem to use a simple text method in your replies that doesn't add
the chevron in front of the earlier stuff so your new reply and the last
poster look to be at the same current sequence level. What's more, you
often preceed your new reply lines with some random number of chevrons,
making it appear in most mail reader programs that this new portion
ought to be some much earlier part of the discussion. It also makes it a
difficult detective process to figure out who said what in that message
and any that follow.
I don't want to start a big netiqette discussion, and you certainly have
the right to do as you choose, but I would ask, that at minimum, you
don't put chevrons in front of your new reply lines when you respond to
previous messages.
-Rex
Lux, James P (337C) wrote:
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Hal Murray
Sent: Wednesday, July 29, 2009 2:51 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] looking for good description/generalized model for
time adjustments
Precisely so. And NTP may actually be the best model here. Does
NTP's "corrected output" meet the "must be monotonic and not
discontinuous" criteria (being too lazy to just go read the NTP docs,
which I have, and which I'll take a look at after lunch).
There is a lot of info available about ntp, you may have troubles finding
what you want, especially if you don't already know what you are looking for.
I'm being sloppy when I say "ntp". It's both a protocol spec (RFC-whatever)
and a reference implementation (ntpd) that is widely deployed.
<snip about ntp>
What OS are you using? FreeBSD is very good. Linux is not--so-good.
RTEMS and/or VxWorks (I'm using RTEMS, others with whom we communicate use a variety of other things. And we don't have network connections per se.. That's why I'm looking for more generic descriptions that aren't tied to things like packet definitions or peculiarities of IP routing. Basically, all of these things should be able to be boiled down to two things: a synchronization signal and a synchronization message.
The other mode is using a refclock. ntpd includes support of over 20
different types of clocks, many are no longer interesting. The key to
getting good time is something like a PPS pulse and kernel support to grab a
timestamp in the interrupt routing. There is also a batch of PLL code in the
kernel that I don't understand.
and it is that PLL code that is particularly interesting (Poul-Henning has
useful information in kern/time_tc.c, etc.)
For network traffic, ntp assumes the delays are symmetric. <snip>
In my application, we don't need to "probe the network" to figure out the latencies. We
know them apriori, and they are also "very small" compared to the required time
precision. The part I'm interested in is the automated reconciliation of the always varying
clocks/oscillators on the platforms, essentially trying to predict a bad clock with a good one.
---> But it *is* the master, by fiat. Here's a scenario: A schedule
is published that says: (MT = Master's time)
At 12:00.001MT Box A puts out a pulse
At 12:00.002MT Box B puts out a pulse
At 12:01.001MT Box A puts out a pulse.
Box A and Box B MUST follow Master Time, no matter how crummy it is.
ntp is trying for UTC, the one great time. But that comes from outside ntp.
You can simplify things a lot if you tell it (config file) to only use one
server.
For example, you could setup box A as the master and tell B to sync to it.
It may be better to setup another box in a stable environment and sync both A
and B to it. That gives B a stable target.
--> Can't do that in this environment. The master is the master, and all the slaves are
fore-ordained and must follow it as best they can. What I need to do, really, is figure out
what "best they can" is.
A Single board computer with non TCXO clock (on order of 10ppm
variability over short term) is the "system controller" and sets the
time schedules. It sends commands to devices which have TCXO clocks
(on order of 1ppm short term variability) saying "at time X do action
Y". It also periodically sends messages to the devices saying "At the
tone, my time is Z".
How good is your netework connection?
Negligible latency (at least in the context of the required time precision). In reality, it has a worst case jitter of about 1 microsecond and a mean latency of 0.5 microsecond (that is, a "tick" on one end of the link appears at the other end of the link with a uniformly distributed delay of 0-1 microsecond)
Think of it as if I had a piece of wire connecting the boxes, to do with
whatever I want. And then, on the side, I have a way to transmit messages
among boxes (which has greater latency and jitter)
10 ppm short term variability seems huge. The crystals I've looked at (in
PCs) are ballpark of 1 ppm per C. Do you have wide temperature changes short
term or nasty crystals? (or am I lucky?)
wide temperature ranges: The environment where you go from full sunlight (at
1.3kW/square meter) to full darkness, radiating to 3K blackbody (about -400W/sq
meter), and back to sun every 90-100 minutes). A cyclical variation of 10-20
degrees wouldn't be unusual, and it's not sinusoidal.. more like a low pass
filtered square wave.
It sounds a little backwards to have the machine with the lousy clock be the
one in charge. Can it get the time from any of the devices with better
clocks?
sadly, no.. that's one of the problems to solve.
What we would like is a) some algorithms to do this (and NTP type PLLs
are a decent way) and b) some formalism and rigor to choose operating
parameters (e.g. update every 1 second or every day or whatever)
There is a lot of formalism with ntp. I'm not familiar with most of it.
Picking parameters is a black art.
precisely so.. Lots of papers and presentations by Mills (and heck, he's been
out here to JPL, too), but there's a lot of empiricism in those filter tuning
parameters, I suspect.
Turns out that there are lots of applications in spaceflight where you need to
synchronize things that have different clocks (with relativistic effects, as
well as just long and varying propagation delay). For instance, NTP, by itself,
doesn't do a very good job synchronizing a clock on something orbiting the
moon. That's because the propagation delay properties are very different from
what NTP was originally designed for (network traffic through a bunch of
routers). You have a large, but systematic and predictable, range and range
rate variation on top of a 1 second delay.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
