[Beowulf] precise synchronization of system clocks

[Vincent Diepeveen]

Hmm,

The European Union waited a bit long introducing its own equivalent  
and it should
be online within a few years, it is called Galileo and it is 1 meter  
accurate for everyone.

Also with the garantuee of it not getting switched off; which happens  
so easily with GPS,
even the smallest threat of war is enough, and it is difficult to  
follow logics in Washington there.

In one speech that's on his site Obama for example mentions he wants  
to get rid of Venezuelan oil,
whereas in the convention he didn't mention Venezuela. Chavez now is  
gonna build a nuke,
to garantuee his presidency.

What's status of Venezuela?

It exports massive amount of oil, can The Dutch Antilles, just close  
to Venezuela,
be sure of the GPS signal?

On GPS technical data i'm not sure what i'm allowed to quote, so  
let's not do it.
Let's not even comment how far off or on Robert is.

Vincent

On Sep 30, 2008, at 5:37 PM, Robert G. Brown wrote:

> On Tue, 30 Sep 2008, Lux, James P wrote:
>
> This is a very nice response, and I think you're on a very good track.
> IIRC from discussion a few years ago, GPS can yield what,  
> microsecond or
> better timing (if used to adjust drift and resync all clocks)?  In
> principle sub-microsecond, since a microsecond is order of 300 meters
> and GPS can get you within 30.
>
>> The GPS synchronization problem is actually substantially easier.   
>> The
>> propagation delay from satellite to receiver is varying in a very
>> predictable manner (in fact, the nav solution solves for it); the  
>> signal is
>> specifically designed for accurate timing (i.e. A PN  code  
>> generated from a
>> Cs clock is a darn good way to transmit timing and frequency  
>> information)
> ...
>> Keeping it beowulf'y, if you want fine grained synchronization so  
>> that you
>> don't lose performance when doing barriers, you're probably going  
>> to need
>> some sort of common clock.  The typical microprocessor crystal  
>> just isn't
>> good enough.  Actually, though, when talking about this sort of  
>> sync, aren't
>> we getting close to SIMD sort of processing?  Is a "cluster of  
>> commodity
>> computers" actually a "good" way to be doing this sort of thing?
>
> There is a natural synchronization driven by task advancement and
> barriers already.  The problem, I think, is in getting "everything  
> else"
> to be at least moderately synchronous, as it is the noise of this that
> degrades the otherwise synchronous task is it not?  If one could
> convince the kernel to "start" all of its housekeeping task timeslices
> within (say) 1 usec worst case across all nodes, you would effectively
> parallelize and synchronize this noise.  I don't think it would be
> necessary to shoot for true SIMD-like advancement, clock by clock --
> only to drive systems into a (nearly) identical state so that one  
> CPU is
> only rarely waiting on another because of a random out-of-step  
> timeslice
> being allocated to something outside of the task.  Organization OF the
> task is up to the parallel programmer, I would think, but it is
> generally done under the assumption that the loss of occasional
> timeslices doesn't much matter, only they do.
>
> However, I would think it would require a lot of work to get the
> kernel(s) to respect a usec-synchronized clock, assuming that one  
> could
> constrain the hardware so that it didn't generate too much random  
> (e.g.
> interrupt) noise on its own.
>
>    rgb
>
> -- 
> Robert G. Brown                            Phone(cell): 1-919-280-8443
> Duke University Physics Dept, Box 90305
> Durham, N.C. 27708-0305
> Web: http://www.phy.duke.edu/~rgb
> Book of Lilith Website: http://www.phy.duke.edu/~rgb/Lilith/Lilith.php
> Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977
>