[Discuss-gnuradio] Re: synchronizing sound cards in a cluster (fwd)

[Eugen Leitl]

List's in the header, but I'm not sure John Gilmore is subscribed; sorry 
for eventual doublettes. (This is the last one, for real now).

---------- Forwarded message ----------
Date: Thu, 13 Mar 2003 18:25:41 -0800
From: John Gilmore <gnu at toad.com>
To: Jim Lux <James.P.Lux at jpl.nasa.gov>
Cc: Eugen Leitl <eugen at leitl.org>, beowulf at beowulf.org,
     discuss-gnuradio at gnu.org
Subject: Re: [Discuss-gnuradio] Re: synchronizing sound cards in a cluster

> Better than that, one doesn't need absolute sync for this application, so a 
> common signal distributed to all nodes might work.  A lot of the NTP 
> "clients" can take a "tick" on one of the serial port lines (like CD or 
> DTR), but I was wondering if anyone had actually done this on a cluster.

One way to deal with this is to sample the real signal on one channel
of a sound card, and sample a locally generated time reference on the
other channel.  Use a distribution amplifier to feed the same time
reference audio signal to each sound card in the cluster.  For the
accuracies you're worried about (1 us) you don't even have to cut the
wires to the same lengths.  Then process both the time reference
samples AND the real data samples, to determine how to sync up the
real data that you care about.

This will take twice as many sound cards than a scheme that would
actually synchronize the sample clocks on the sound cards, but then
again, this is easy to build out of cheap parts, and that is not.

The time reference signal can be the WWV audio signal:

  http://tf.nist.gov/stations/iform.html

To hear this signal, dial +1 303 499-7111 (or 2.5, 5, 10, 15, or 20
MHz).  GNU Radio code for interpreting it should be a simple and
useful contribution.  Or it can be something even simpler that you
generate locally, like a 1kHz tone lasting 0.1 second, which recurs
every second.  The basic idea is that the same "tick" signal shows up
on one channel, e.g. the left channel, of EVERY sound card,
synchronized to within tens of nanoseconds. 

Here's another way to think about this.  If you merely recorded all
the left-channels, you'd get a multitude of recordings of the same
simple "tick" signal.  Each of them will be recorded with a different
sound card, with crystals that have slightly different frequencies and
are drifting, with different interrupt latencies, etc.  Then process
all these left-channel samples in such a way that you learn exactly
how much drift and precision each of the sound cards has (relative to
each other, and relative to long term stable realtime as obtained from
NTP or a GPS clock).  Knowing how your predictable signal was
mutilated by your various sound cards will tell you how your
unpredictable signal was also mangled.  Then you can apply the right
corrective transformation to the real signal data that you've obtained
on the corresponding right-channels.

(If you want to be absolutely sure that the left- and the
right-channels are sampled at the same times and with the same clock
distortions, then try feeding the same "tick" signal to BOTH sides of
all the sound cards.  After doing the above processing, the corrected
right-channel data should consist of nothing but utterly solidly
synchronous ticking.  Replace any sound cards or CPUs that can't
reliably do this, THEN run your real data through those
right-channels.)

	John Gilmore

PS:  Can you tell us what your application is?  E.g. what real-world
problem you're trying to solve?

PPS: If you're only pulling in 35 or 40 Mbits/sec total, why not just
frequency-multiplex the signals in analog, and sample the entire thing
on a single wideband ADC card, rather than on 16 or 32 sound cards?
Then you're guaranteed to be using the same clock for all the signals.