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
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
