SEO

I have a requirement where I need two Suns (both Netra T1s) to have
their clocks close to each other during an experiment that lasts 4
hours. During this time, neither Sun will have internet access and they
will not be networked to each other.

I suspect if I sync them by NTP before the experiment starts, then they
will not drift by more than 500 ms over a 4 hour period. Does that seem
reasonable? Has anyone actually ever made medium term (few hours)
stability measurements of the clocks in Suns?

Dave wrote:
> I have a requirement where I need two Suns (both Netra T1s) to have
> their clocks close to each other during an experiment that lasts 4
> hours. During this time, neither Sun will have internet access and they
> will not be networked to each other.
>
> I suspect if I sync them by NTP before the experiment starts, then they
> will not drift by more than 500 ms over a 4 hour period. Does that seem
> reasonable? Has anyone actually ever made medium term (few hours)
> stability measurements of the clocks in Suns?

It would be quite easy to set up cron job to call ntpdate every 4 hours
and check the messages logged in /var/adm/messages.

One of my x86 boxes drifts by about 250mS/hour while another drifts by
about 10mS/hour.

--
Ian Collins.

In comp.unix.solaris Dave <someplace@nowhere-nice.com> wrote:
> I have a requirement where I need two Suns (both Netra T1s) to have
> their clocks close to each other during an experiment that lasts 4
> hours.

What is your definition of "close?"

> During this time, neither Sun will have internet access and they
> will not be networked to each other.

Why then do they need their clocks to remain "close?"

Will they be in a place where they can receive a GPS signal?

> I suspect if I sync them by NTP before the experiment starts, then
> they will not drift by more than 500 ms over a 4 hour period. Does
> that seem reasonable? Has anyone actually ever made medium term (few
> hours) stability measurements of the clocks in Suns?

If you get no response in these groups and don't want to simply wait
four hours and see what happens, you could try asking in
comp.protocols.time.ntp (if you haven't already).

rick jones
wishes his systems were in a place where they could recieve a GPS signal...
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

Dave wrote:
> I have a requirement where I need two Suns (both Netra T1s) to have
> their clocks close to each other during an experiment that lasts 4
> hours. During this time, neither Sun will have internet access and they
> will not be networked to each other.
>
> I suspect if I sync them by NTP before the experiment starts, then they
> will not drift by more than 500 ms over a 4 hour period. Does that seem
> reasonable? Has anyone actually ever made medium term (few hours)
> stability measurements of the clocks in Suns?

Ntpd stores the frequency error of the clock in the drift file if you
configure a drift file. Most systems have a drift of less than 100 PPM
in absolute value. Some systems do a lot better than that; 25 or 30
PPM. Configure your drift file if you haven't already and see what the
frequency error is.

The systems will do better if you keep tight control of the temperature.

If you leave ntpd running on both systems, it will continue to
discipline the clocks based on the last information it had. If the
temperature remains stable the clocks should remain very close to each other

Dave wrote:
> I have a requirement where I need two Suns (both Netra T1s) to have
> their clocks close to each other during an experiment that lasts 4
> hours. During this time, neither Sun will have internet access and they
> will not be networked to each other.

Ick.

>
> I suspect if I sync them by NTP before the experiment starts, then they
> will not drift by more than 500 ms over a 4 hour period. Does that seem
> reasonable? Has anyone actually ever made medium term (few hours)
> stability measurements of the clocks in Suns?

It's possible... but too many variables.

If there was some way to sync to a local "accurate" clock for each
that would help. I know that's not much help.

Rick Jones wrote:
> In comp.unix.solaris Dave <someplace@nowhere-nice.com> wrote:
>> I have a requirement where I need two Suns (both Netra T1s) to have
>> their clocks close to each other during an experiment that lasts 4
>> hours.
>
> What is your definition of "close?"

I can accept 500 ms, but not any more.

>
>> During this time, neither Sun will have internet access and they
>> will not be networked to each other.
>
> Why then do they need their clocks to remain "close?"

One will be controlling a signal generator's frequency via a GPIB
controller fitted in the Sun. The other Sun will control the frequency
of a receiver via another GPIB controller.

I don't want the situation where the transmitter is at one frequency and
the receiver a couple of GHz away! (The crystals of the transmitter and
receiver will be locked to two rubidium sources, so stability of the
test equipment is not an issue, but somehow I need to ensure the
controllers direct them to the right frequencies at the right time.
Since they are going to be changed every few seconds, I can't put long
delays in the system.

> Will they be in a place where they can receive a GPS signal?

One possibly, the other definitely not Just to make matters worst,
there could be a wide (perhaps 25 deg C) difference in temperature
between the two.

However, you have given me an idea. It should be possible to generate
our own one pulse per second signal from a couple of rubidium
oscillators. However, I'm not sure if the Netra T1's have enough serial
ports, as one will be used to control the Suns. There are two serial
ports are marked "LOM A" and "Serial B". I assume I can can control the
machines from one of these and sync to `1 pps signal on the other, but
I'm not 100% sure of that.

>> I suspect if I sync them by NTP before the experiment starts, then
>> they will not drift by more than 500 ms over a 4 hour period. Does
>> that seem reasonable? Has anyone actually ever made medium term (few
>> hours) stability measurements of the clocks in Suns?
>
> If you get no response in these groups and don't want to simply wait
> four hours and see what happens,

Unfortunately I don't have both machines here.

> you could try asking in
> comp.protocols.time.ntp (if you haven't already).

I will try that. Also the time-nuts mailing list is another possibility.

> rick jones
> wishes his systems were in a place where they could recieve a GPS signal...

Generally I don't have a big issue with time. I sometimes look at the
time of the Sun when I have a train to catch, but generally exact time
is not an issue to me. But this experiment is a bit unusual.

Richard B. Gilbert wrote:
> Dave wrote:
>> I have a requirement where I need two Suns (both Netra T1s) to have
>> their clocks close to each other during an experiment that lasts 4
>> hours. During this time, neither Sun will have internet access and
>> they will not be networked to each other.
>>
>> I suspect if I sync them by NTP before the experiment starts, then
>> they will not drift by more than 500 ms over a 4 hour period. Does
>> that seem reasonable? Has anyone actually ever made medium term (few
>> hours) stability measurements of the clocks in Suns?
>
> Ntpd stores the frequency error of the clock in the drift file if you
> configure a drift file. Most systems have a drift of less than 100 PPM
> in absolute value. Some systems do a lot better than that; 25 or 30
> PPM. Configure your drift file if you haven't already and see what the
> frequency error is.
>
> The systems will do better if you keep tight control of the temperature.

That is definately not possible. One is going to be outside.

>
> If you leave ntpd running on both systems, it will continue to
> discipline the clocks based on the last information it had. If the
> temperature remains stable the clocks should remain very close to each
> other
>

In which case NTP might make matters worst than no NTP during the
experiment.

Chris Cox wrote:
> Dave wrote:
>> I have a requirement where I need two Suns (both Netra T1s) to have
>> their clocks close to each other during an experiment that lasts 4
>> hours. During this time, neither Sun will have internet access and
>> they will not be networked to each other.
>
> Ick.
>
>>
>> I suspect if I sync them by NTP before the experiment starts, then
>> they will not drift by more than 500 ms over a 4 hour period. Does
>> that seem reasonable? Has anyone actually ever made medium term (few
>> hours) stability measurements of the clocks in Suns?
>
> It's possible... but too many variables.
>
> If there was some way to sync to a local "accurate" clock for each
> that would help. I know that's not much help.
>


That is a possibility. I have one of these


http://www.thinksrs.com/products/PRS10.htm

which is a rubidium oscillator. I could get another and sync them both
to GPS. A bit more complexity than I wanted, but it might be necessary.

Ian Collins wrote:
> Dave wrote:
>> I have a requirement where I need two Suns (both Netra T1s) to have
>> their clocks close to each other during an experiment that lasts 4
>> hours. During this time, neither Sun will have internet access and they
>> will not be networked to each other.
>>
>> I suspect if I sync them by NTP before the experiment starts, then they
>> will not drift by more than 500 ms over a 4 hour period. Does that seem
>> reasonable? Has anyone actually ever made medium term (few hours)
>> stability measurements of the clocks in Suns?
>
> It would be quite easy to set up cron job to call ntpdate every 4 hours
> and check the messages logged in /var/adm/messages.
>
> One of my x86 boxes drifts by about 250mS/hour while another drifts by
> about 10mS/hour.
>


From those sorts of figures, I suspect I will be stuffed as one will be
outside with the temperature possibly below 0 deg C and the other in a
place which might be quite warm.

On 2008-03-20, Dave <someplace@nowhere-nice.com> wrote:
> Huge wrote:
>> On 2008-03-20, Dave <someplace@nowhere-nice.com> wrote:
>>> Rex Mottram wrote:
>>>
>>>> Put the indoor machine in the refrigerator.
>>>>
>>>> RM
>>> Unfortunately, that is not practical given the particular constraints I have
>>
>> Are the machines close enough together to connect a cable between them?
>>
>>
>
> No - otherwise it would be easy with NTP over ethernet.

Quite.

So, how far apart are they?

--
"Be thankful that you have a life, and forsake your vain
and presumptuous desire for a second one."
[email me at huge {at} huge (dot) org <dot> uk]