OpenBCM V1.08-3-g9b42 (Linux)

Packet Radio Mailbox

HB9ON

[OpenBCM Lugano JN46LA]

 Login: GUEST





  
N1URO  > NODES    21.01.21 08:16z 29 Lines 1541 Bytes #999 (0) @ WW
BID : 59349_N1URO
Read: GUEST
Subj: N2NOV > Re: NetRom Tutorial Document
Path: HB9ON<IW8PGT<IZ3LSV<DB0ERF<DB0RES<ON0AR<VE2PKT<N1URO
Sent: 210121/0810Z @:N1URO.#CCT.CT.USA.NOAM #:59349 [Unionville] $:59349_N1URO

*Moving this off SYSOP@WW

> With a starting point of 203 and the next step being 161, we have have 
> limited the length of nodes by using a MIN QUAL of 161.  I currently have 
> about 120 in my node table that is 161 or higher.

Have you ever worked a node via 300 baud HF? You get timed off of a node
at 80. Already you're at 120 with nodes having a qual of 161 so you've made
your site completely useless for those on HF who aren't familiar with the
nodes you may carry. FYI: for HF, with band conditions and retries it
takes just under 15 minutes for 300 baud to draw 80 nodes on a screen.
As a former NEDA member back in the day this was one of the considerations
for the RF enthusiast. Another policy of NEDA was no wired nodes were to
be broadcast out throughout the network as is with TARPN today.

Another issue to be concerned about is reverse ghosting which is where a
node 2 or more hops away is dropped by it's original neighbor to you BUT
you still receive it from broadcasts from a 3rd party that originally 
received it from you. This is one of the biggest issues with INP3 which
uses NetRom as it's transport and how the "Nodes Cloud" keeps growing
even though nodes vanish... a ping-pong effect of sorts.

The spec of NetRom to begin derating obs is 600 seconds so good nodes will
get dropped for 1/3rd it's life cycle. I suggest looking for Software2000's
book on NetRom since they're the developers of the protocol. I'd strongly
reconsider some of the logic you used in your draft.
---
SendBBS v1.1 by N1URO for LinFBB


Read previous mail | Read next mail


 18.04.2024 12:03:43zGo back Go up