synchronizing sound cards in a cluster

[Robert G. Brown]

On Fri, 14 Mar 2003, Andrew A. Raines wrote:

> Jim Lux <James.P.Lux at jpl.nasa.gov> writes:
> 
> > One can fairly easily synchronize to a millisecond over Ethernet,
> > but this application needs sync to, at worst, 1 sample time (20
> > microseconds) although order of a microsecond would be nice.
> 
> clockspeed[1] can alleviate clock drift on the order of nanoseconds
> on Solaris and microseconds on Linux (i386 only).  The drift is

The AMD athlons also have fully compatible rdtsc calls.  So "i386 from
pentium on including the athlons" (just to be picky and reassure AMD
users).

This actually looks like a lovely idea, and should be able to eliminate
drift, but one still has to worry a bit about absolute time
synchronization after boot (where it starts by reading the onboard clock
from the BIOS).  I don't know how accurate these clocks are, but their
drift cannot be compensated for by a CPU-based correction so you still
have to work out synchronization to an external entity before locking to
the CPU clock.

   rgb

> even stored in attoseconds, and it counts leap seconds correctly.
> 
> If you're interested, have a look at Frank Tegtmeyer's work[2] for
> an elegant README-automation solution.
> 
> -Drew
> 
> Footnotes: 
> [1]  http://cr.yp.to/clockspeed.html
> 
> [2]  http://fte.tegtmeyer.net/djbware/clockspeed_setup.html
> 
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
> 

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu