PACKET RADIO: Don't Digipeat!
(This text from the W8IZ packet radio bulletin
board. It's formatted to fit a 80 character screen.)
Some questions have arisen over why digipeating is less
efficient than working through nodes. Let me try to explain the
problem ... my thanks to WA8DED and some Statistics Professor at
Ohio State for information I have plagiarized here.
IN THE BEGINNING
When packet began, there were no thoughts of digis, nodes and
the like. Two stations connected to each other and typed. Simple!
Someone thought that making the availability of "repeating" a
packet would be a neat feature. The digipeater was born.
Eventually, there were provision for eight digipeaters allowed in
the AX.25 protocol upon which our system is built.
ERROR CONTROL IN DIGIPEATERS
Digipeaters do not participate in error control. They hear a
packet, decode it and look for information relating to their need
to use or digipeat it. If there is no use or digipeat information
relevant to its duties, the processor does its logging for the
HEARD list and then it discards it. If the packet is to be
digipeated, an adjustment is made to the packet to show
it was digipeated and it is repeated back onto the air.
No information is sent back to the originating station
about if the packet was successfully received and sent. The
digipeater does not check back with the sending station to tell it,
"HEY! I got your packet and sent it on its way!". Nor does the
digipeater check to see that the station next on the list gets the
packet that the digipeater sent. It sends it and forgets about it.
It could care less if the station next on the list gets it or not.
ERROR CONTROL IN NODES
Nodes ... like NET/ROM, The Net, K-Nodes, etc., do error
control. When you send a packet to another station via the node,
the node lets everyone know the status of the packet. When the
node hears a packet, it disassembles and analyzes the information.
If the node is next in the list, it starts a string of
acknowledgment and forwarding.
First, the node sends an acknowledgment back to the sending
station. It tells the sender, "HEY! I got it and I am now
responsible for sending it on ... I will take care of it for you!".
The sender sits tight and waits.
The node now looks for the next station to send the packet to.
It sends it out and waits for that station to acknowledge the
packet. If the other station reports receiving it, it then knows
that it successfully did its job and sits back and waits for the
next packet.
SO WHY DO WE NEED ERROR CONTROL?
Let's say that we need to send a packet to a station five hops
away. First, let's do it with digipeaters. Let's also assume that
the channel is in real good shape. Let's say that the packets get
to the digipeaters and are successfully decoded 90% of the time on
each hop.
PAY ATTENTION!
Now, listen up. Here is where it gets confusing!
We are pretending that the chance of making each hop is 90%
... if you believe that too low, go back to the network and try it
... 90% is VERY optimistic. We need to hop ten times to get a
packet through. The first five get the packet from the sender to
the receiver and the second five hops are from the receiver to the
sender to acknowledge that the receiver got the packet. The chance
of that packet making ten error free hops where each hop has a 90%
probability of success is less than 35%!!! (About 34.88 ... 0.90
raised to the tenth power ... each trial is independent therefore
you have the probability of a successful event equaling the
products of the probability of each single event.) Get that! 35%
chance ... that means you have to send the average packet three
times to get it through.
WE ARE NOT DONE YET!
The AX.25 code assigns a wait of about 72 seconds to a five
hop digi path (36 seconds to the station and 36 seconds back). Get
that! 72 seconds.
On an average packet you have to wait 3 packets per success
times 72 seconds or 216 seconds ... 3 minutes and 36 seconds per
packet.
YOU GOTTA BETTER WAY?
Yeah ... it is called a node. Let's review ... it has been
about 60 seconds since we talked about them. A node acknowledges
your packets and insures they are sent through the network to their
next hop. You send a packet to a node and instruct it to carry it
through to another node. The node hears your packet and tells you
that it successfully received the packet. You sit back confident
that the node will take care of things for you.
The node will send it onto the next node and then await an
acknowledgment just as you did. Your packet will go until the
last hop is made.
Probability of making all five hops? 90%! Each is insured by
an acknowledgment. If the hop fails on the first attempt, it
tries again and again and again. That is our definition! The
chance of making any one hop is 90%. Therefore, the chance of
making all five hops is 90%.
Now ... on to timing. The time defined by AX.25 if the path
was a solid 100% is about 10 seconds per five hop path. An 800
percent improvement. If any path fails on the first attempt, there
will be an additional delay defined by the FRACK (frame
acknowledgment delay) of the node. Let's say that the node's frack
is 4 seconds. Rather than have to resend the whole packet over
again after a 72 second delay, the node that did not get the packet
receives a retry after four seconds.
SO WHY CAN'T I TALK TO TAMPA, FLORIDA
ON A TWO METER NODE ROUTE?
There are a bunch of different reasons.
First off, nodes are spaced and timed in such a way as to
allow maximum use to the network. That means that they are set up
for their primary use. VHF DX'ing is not their primary use.
Second, the longer the path the more likely you are going to
encounter a hole in the network. This might be a node that is
spaced a little too far out of the way of its adjoining node and is
therefore less likely to hear and work on the packets. We have
some of those.
Third, some areas do not want long distance connects. They
set up their nodes and networks to prohibit just such connects.
Fourth, long distance travel on the network becomes
communicating NOT through a <L>ocal <A>rea <N>etwork (LAN). You
transverse this and begin moving on a <W>ide <A>rea <N>etwork
(WAN). That means that you and everyone else in NEOH are using the
only way to NWOH or NCOH. Everyone is being funneled into a
smaller and smaller pipe until the pipe just gets all clogged up.
Before you find yourself in another LAN with more elbow room, you
find yourself disconnected.
SO WHAT CAN I DO?
If you reaaaaaaly want to make long distance connects, get on
HF Pactor! 80 meters would be excellent for a path into Columbus
and Michigan. There are a number of texts on how to do that in the
downloads in the NO8M PBBS. The PACKET subdirectory lists more
how-to files. The ANTENNA subdirectory contains an eight part
story about NVIS antennas that would be great for packet. The 9th
Computer Networking Conference book has a couple of spots about HF
packet.
CONCLUSION
OK ... what can I do to improve things?
It take gobs and gobs of money, cooperation and time to make
a network work. We have none of the above. Our NEOH network is
primarily the product of the good (bear with me) nature and
philanthropy of our primary node operator, K8EIW. He has gone too
far out of his way to provide us with what we have. Due to his
nodes, we are able to reach areas that "connect" us to other areas.
That is why they are in designed areas. If you are not right on that
path, good luck. Not too many people, especially here in NEOH,
are going to donate $1000.00 per node, the site and the time to
maintain it just for the good of the network. Take a look at a
node list and see how many Don has set up ... for the good of
the network.
Rather than go willy-nilly tither and yon with more LANs, more
digipeating, and the like, perhaps we could work together.
I have already showed you why, in a disaster, you will not be
digipeating messages to Columbus.
NO8M practiced by handling 39,006 messages a year. The
NETWORK in NEOH handled a heck of a lot more than that figure ...
to Columbus and to every part of the globe.
You can help with that!
Let's build a 9600 baud network! Let's put some nodes in the
southwest and far-far west area of NEOH. Lets get some nodes in
the far-far east edge. Lets get better coverage into many areas.
ONE MORE THING
Let me blast one more particularly nasty and destructive
activity of digipeaters ... one which harms the network and its
users.
When AX.25 was written, priority was given to digipeated
packets. There were no nodes and digis were about all you had.
Hence, digis get on the air (in many cases) before all the other
packets.
Now, enter some ... ham ... that feels the need to digipeat
his (yuck) beacon onto every corner of the state. We now have a
packet that is added to a clogged pipe of no use and the danged
thing even has priority!
Use "D PACKET/BEACONS2.NO!" on NO8M for the story by Bob,
K3RC. Bob was walking his dog one night and noticed that it seemed
to need to lift its leg on every tree and post along the way. Bob
states that were the dog to have its version of a digipeater, every
tree in Ohio would be marked!!!
NCARC PBBS