[time-nuts] Posting style Was: looking for good description/generalized model for time adjustments

Rex rexa at sonic.net
Wed Jul 29 23:17:51 UTC 2009


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: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] 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.
>>>>        
>>>>
>
>  
>





More information about the Time-nuts_lists.febo.com mailing list