PACKET RADIO: Don't Digipeat!

Steve Wolf, W8IZ@W8IZ

(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.


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.


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.


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.


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.


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.


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



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.



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.


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



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.


Let me blast one more particularly nasty and destructive

activity of digipeaters ... one which harms the network and its


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


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!!!