Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mcvax!hp4nl!philapd!ssp1!roelof
From: roelof@idca.tds.PHILIPS.nl (R. Vuurboom)
Newsgroups: comp.arch
Subject: Re: Time Sync in MP System
Summary: Don't
Message-ID: <130@ssp1.idca.tds.philips.nl>
Date: 5 Jun 89 16:29:05 GMT
References: <2280007@hpsal2.HP.COM> <28200330@mcdurb>
Organization: Philips Telecommunication and Data Systems, The Netherlands
Lines: 30

In article <28200330@mcdurb> aglew@mcdurb.Urbana.Gould.COM writes:
>
>>How can I initialize and maintain time synchronization in a
>>multiprocessor system?  To put this in context, I am seeking an
>>approach that can be used by the IEEE CSR Standard, which will
>>be included by reference in Futurebus+ and SCI.  
>>
>Do not resynchronize the counter!  That sort of resynchronization
>leads to "time warps" which dramatically reduce the usefulness
>of the clock counter for high resolution time measurements,
>performance evaluation, etc.
>
I am inclined to agree you. A while back I was doing some work on a
Distributed Real-time Multiprocessor Operating System (called appropriately 
enough DRM System) and we spent a lot of time worrying about this
synchronization issue. The conclusion we drew was that it really wasn't
worth the bother. If an application could weather the "time warps"
introduced during resynchronization then it could probably weather
the oscillator drift in the first place (milliseconds per year?).
Vice versa if an application demanded that sort of synchronization 
then it could have a rough time weathering its way through synchronization 
bouts. 

In the days of granddad's tick-along all of this could have been pretty
hot stuff but with the accuracy of todays clocks this particular 
synchronization issue between distributed processors may have become a 
moot point.
-- 
Roelof Vuurboom  SSP/V3   Philips TDS Apeldoorn, The Netherlands   +31 55 432226
domain: roelof@idca.tds.philips.nl             uucp:  ...!mcvax!philapd!roelof