beowulf in space

Jim Lux James.P.Lux at
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
>Beowulf mailing list, Beowulf at
>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
tel: (818)354-2075
fax: (818)393-6875

Beowulf mailing list, Beowulf at
To change your subscription (digest mode or unsubscribe) visit

More information about the Beowulf mailing list