beowulf in space
James.P.Lux at jpl.nasa.gov
Mon Apr 14 19:57:52 EDT 2003
At 01:32 PM 4/14/2003 -0700, Karen Shaeffer wrote:
> > ground navigational cluster... certainly we can achieve a very high
> velocity for our death plunge into the Sun's outer atmosphere...
> Computational real time observations within those few precious moments
> before the probe vaporised would certainly be enhanced by an on board
> beowulf cluster... You asked for speculation, as to an application... I
> think this is perhaps one.
>This is getting silly. You still need to transmit the data back to earth. It
>has already been asserted that it is far more efficient energy wise and cost
>wise to transmit data than to process it.
This is not necessarily true... While the scientist generally prefers to
get the raw data (it allows deferring some of the analysis work to a later
time, and, it reduces the risk of making a bad design decision, because you
can go reprocess later), in many, many cases it is NOT cheaper to send the
data back to earth than to process it in situ and send the processed data.
Most spacecraft are severely power constrained, and that sets the basis for
the tradeoff of joules expended on processing vs joules expended on sending
data (hence my earlier posts about MIPS/Watt being important). Inherent in
the fact that one CAN do processing is that the raw data must contain some
redundancy, and the processing, in an information theoretic sense, consists
of removing the redundancy (consider it as "lossless compression" if you
will). For an arbitrary communication link, the key thing is the received
energy at the other end compared with the noise energy (usually talked
about in terms of Eb/No). You can divvy up the energy in a lot of ways:
1) You can send each (nonredundant) bit multiple times, increasing the
energy for each information bit, thereby improving the signal to noise
ratio for that bit. There are lots of clever schemes for how you do this
(generically called "coding"). Essentially, you put some amount of
redundancy back into the data stream, and then remove it at the receiving end.
2) You can not bother removing the redundancy in the first place,
transmitting more bits, with less power per bit.
I would contend that in an idealized case, the raw sensor data is unlikely
to be an efficient coding strategy for the actual information contained in
the data. Consider a trivial case where the sensor measures the slowly
varying (timeconstant >1 second) temperature of the spacecraft 100 times a
second with an accuracy of 8 bits. Clearly, there is a very high
correlation between one measurement and the next, so the actual
"information" in each sample is quite small. A "send the raw data" strategy
would require 800 bits/sec of bandwidth.
One could trivially encode it by averaging 10 measurements at a time into
an 8 bit average, probably without losing much data. If one was worried
about excursions, one could also transmit the min and max values, for a
total of 240 bits/second.
One could also use any of a number of simple lossless compression schemes
to greatly reduce the bit rate.
The question to be answered, in a real system, is it better to put your
precious joules to work sending all those 800 bits, and not spend any on
the processing, hoping that the greater error rate from the low joules/bit
can be overcome by ground processing, OR, should one do some onboard
processing, say lossless compression, putting more joules in each of the
fewer bits (less some amount of energy used in the compression process),
then transmit those fewer bits using some form of coding, which increases
the transmitted bit rate.
It all depends on the link budget, and how close you are to the ragged edge
of the Shannon limit.
> So you should invest in a system
>that can transmit all the raw data back to earth. Then you even have the
>benefit of saving the raw data set for future computations as more is
There's also the possibility that it is not feasible to send all data back,
and that it HAS to be processed at the sensor. SRTM is a good example of this.
> Karen Shaeffer
> Neuralscape, Palo Alto, Ca. 94306
> shaeffer at neuralscape.com http://www.neuralscape.com
>Beowulf mailing list, Beowulf at beowulf.org
>To change your subscription (digest mode or unsubscribe) visit
James Lux, P.E.
Spacecraft Telecommunications Section
Jet Propulsion Laboratory, Mail Stop 161-213
4800 Oak Grove Drive
Pasadena CA 91109
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
More information about the Beowulf