[net.sf-lovers] Human transportation by UUCP

dewar@calgary.UUCP (Alan Dewar) (10/10/85)

In <344@proper.UUCP>, Carl Greenberg writes:
> 	If you can do that, look at travel.  If I want to go over and visit
> a friend of mine on the USENET, I leave a backup copy at home in case UUCP
> fails and my friend will just download the copy that travels.  ZAP!  I can
> take a short vacation in the time it takes for this message to travel to
> him.
> 						Carl Greenberg

Interesting idea!  I wonder how long it would take to transport the typical
human via UUCP....  Well, let's assume a mass of, say, 50 kg.  If we assume
that the average molecule in the human body is water, then we've got
approximately ( 5e4 g * 6e23/18 molecules/g ) = 1.7e27 molecules.  Let's
assume an effective throughput of 800 baud.  (We may want to add extra
error checking which will slow this down.)  If we manage to come up with,
say, a dozen data compressions, each of which compresses the data by an
order of magnitude, and if the initial data requires one bit per molecule
to represent, then it should take us ( 1.7e27 bits / 800 bps / 1e12 ) =
2e12 seconds, or about 63000 years.  Hmmm, looks like this is going to be
a longer vacation than we had anticipated....

Well, we're not about to be discouraged by this.  Instead, let's turn it
around and figure out the effective baud rate of a human walking across
the country.  We'll pick a distance of 4000 miles or so, an average walking
speed of 2 mph, with time out for eating and sleeping leaving about 8 hours
per day for actual walking.  That gives us a data transfer rate of roughly
( 1.7e27 bits * 2 mph / 4000 miles * 1/3 ) = 2.8e23 bits per hour, or
about 1e27 baud.  Hey, that's pretty good!  Even if the human body has an
information content of only, say, 1 part in 1e15, that still gives us
1e12 baud.  The catch, of course, is that the data has been severely
corrupted by the time it arrives at its destination.  Oh well, you have
to expect to lose something at that kind of data transfer rate.

Alan Dewar
..!{ihnp4,ubc-vision}!alberta!calgary!dewar
dewar.calgary.ubc@csnet-relay.ARPA

mr@hou2h.UUCP (M.RINDSBERG) (10/11/85)

> In <344@proper.UUCP>, Carl Greenberg writes:
> > 	If you can do that, look at travel.  If I want to go over and visit
> > a friend of mine on the USENET, I leave a backup copy at home in case UUCP
> > fails and my friend will just download the copy that travels.  ZAP!  I can
> > take a short vacation in the time it takes for this message to travel to
> > him.
> > 						Carl Greenberg
> 
> Interesting idea!  I wonder how long it would take to transport the typical
> human via UUCP....  Well, let's assume a mass of, say, 50 kg.  If we assume
> that the average molecule in the human body is water, then we've got
> approximately ( 5e4 g * 6e23/18 molecules/g ) = 1.7e27 molecules.  Let's
> assume an effective throughput of 800 baud.  (We may want to add extra

What if we use a throughput of a the full bandwidth of a fiber cable.
Say 2 Ghz. , then 1Gbit/s (~maximum) . This is still too slow.
Therefore we must wait about 100 years till we can do this.

> error checking which will slow this down.)  If we manage to come up with,
> say, a dozen data compressions, each of which compresses the data by an
> order of magnitude, and if the initial data requires one bit per molecule
> to represent, then it should take us ( 1.7e27 bits / 800 bps / 1e12 ) =
> 2e12 seconds, or about 63000 years.  Hmmm, looks like this is going to be
> a longer vacation than we had anticipated....
> 
> Well, we're not about to be discouraged by this.  Instead, let's turn it
> around and figure out the effective baud rate of a human walking across
> the country.  We'll pick a distance of 4000 miles or so, an average walking
> speed of 2 mph, with time out for eating and sleeping leaving about 8 hours
> per day for actual walking.  That gives us a data transfer rate of roughly
> ( 1.7e27 bits * 2 mph / 4000 miles * 1/3 ) = 2.8e23 bits per hour, or
> about 1e27 baud.  Hey, that's pretty good!  Even if the human body has an
> information content of only, say, 1 part in 1e15, that still gives us
> 1e12 baud.  The catch, of course, is that the data has been severely
> corrupted by the time it arrives at its destination.  Oh well, you have
> to expect to lose something at that kind of data transfer rate.
> 
> Alan Dewar
> ..!{ihnp4,ubc-vision}!alberta!calgary!dewar
> dewar.calgary.ubc@csnet-relay.ARPA
> 
>