130
node should know about, and your neighbor's neighbor will also have "good" nodes, as
well as your neighbor's neighbor's neighbor, and so on. Once "good" neighbors have
been established, the quality to assign to each neighbor will have to be determined
experimentally in order to control the listing of marginal destination nodes that will
appear as a result of receiving neighbor node broadcasts.
As a practical point, once a distant node is 3 or 4 RF hops away from your node, having
it listed in your nodes table is not a good practice unless the path is extremely reliable.
The chances of a user being able to access a node this distant diminishes greatly as the
number of RF hops increases beyond this point. Also, allowing destination nodes to
appear in your nodes table that are more than 3 or 4 hops away will result in very large
nodes tables being generated. When your node receives a nodes broadcast from a
neighbor node, K-Net will automatically calculate a quality to all the nodes contained in
that broadcast. If the computed quality is less than MINQUAL, that distant node is not
added to your nodes table. Therefore, it is desirable to have a combination of route
quality and MINQUAL that will only allow nodes that are 3 or 4 node hops away to
appear in your nodes table.
As an example, if your "good" neighbor node (A) has a "good" neighbor node (B), and
node (B) has a "good" neighbor node (C), your node has a good chance of reliably
reaching node (C). The computed quality at your node for distant node (C) must be
greater than MINQUAL in order for it to be listed in your nodes table. If a quality of 70 is
assigned to all neighbors in this example, your node would assign a quality of 5 for
distant node (C), computed as follows (it helps to draw this out on paper): The quality
from (B) to (C) is 70, when (B) broadcasts (C)'s quality as 70, (A) multiplies 70 by 70
and divides by 256 to arrive at a quality of 19 for (C). When your neighbor (A) does a
node broadcast, his broadcasted quality of 19 for (C) is multiplied by your path quality
for (A) and divided by 256, resulting in a quality of 5 for distant node (C) (19 times 70
divided by 256). Since 5 is probably below your MINQUAL, distant node (C) will not be
listed in your nodes table even though it is probably useable. What to do? You could
change the quality to your neighbor (A) to 255. This will result with your node assigning
a quality of 18 for distant node (C), but it does not leave much room for a special case
route that may be 5 or 6 hops away. This will also cause your neighbor (A) to propagate
further than desired in the network; creating useless routing. As a compromise, lock the
quality of (A) to 140. If your neighbor node (A) would also lock in a quality of 140 for his
neighbor (B) and node (B) would do the same for node (C), then your node would now
assign a quality of 41 for distant node (C), leaving some "wiggle room" for other nodes
as they join the network. Now a MINQUAL setting of 41 will allow these "good" distant
nodes to be listed in your nodes table.
If you work through the above exercise a few times using different quality values, it
becomes apparent that there are many settings of quality that will produce the desired
effect as long as all sysops adhere to a common guideline. However, the quality values
used in the above example were not just "picked out of the air": 140 is a reasonable
quality to assign to a good 1200-baud neighbor, since this allows good distant nodes to
appear in your nodes table while also limiting node propagation. It also leaves room in
the quality range for ultra-reliable routes.
This is where good neighbor relationships with other sysops in your area become
important. Neighbor node quality must be continually examined in order to arrive at a
To Next Page
Loading...
