[aprssig] The new N-N paradigm summary (fwd)

[Robert Bruninga]

>>> aprs at kd4rdb.com 1/4/05 7:26:39 AM >>>
> The problem with WIDE,WIDEn-N comes in when, say 2 WIDE 
> stations hear my packet and the next WIDEn-N digi hears both.
> It'll digipeat both 

Yes, setting UIDWAIT to 0 helps, but the real solution to that 
problem under the New n-N Paradigm is to stop using UIFLOOD
for anything except linear LINKn-N's.  If a digi wants to keep
WIDEn-N then at least he should move it to UITRACE parameter
so that users can use the simple dupe-free WIDE2-2 and still
get source-digi identification and abandon the leading WIDE.

So if WIDEn-N is still going to be used, at least lets get those
digis to move it to the UITRACE parameter instead of UIFLOOD.


Quoting Cap Pennell <cap at cruzio.com>:

> I'd simply like to register my opinion (before slipping off on a
trip, so
> unfortunately I won't see any replies).  I think this is a
short-sighted
> idealistic plan, in search of a problem.  That would be okay, and I
haven't
> complained before now because it seemed like another harmless idea. 
But now
> that it's become an idea to move away from WIDEn-N it has too much
potential
> to cause excessive harm to our existing modern fully WIDEn-N capable
VHF
> network in California (and throughout the Western US).  The existing
full
> WIDEn-N network in California and adjacent states _is working_.  I've
seen
> different problems on the East coast where not all the digis are
WIDEn-N
> capable, but that's not the situation in the Western US.  The
WIDEn-N
> network _works_ for hundreds of APRSers here.  It works _beyond_ the
"ALOHA
> circle".  It works _with_ our high altitude WIDEn-N digis.  The
"reduced
> throughput" problem on VHF is tolerable, and declining.  There really
aren't
> many severe negative consequences of "reduced throughput due to
packet
> collisions on VHF" except slow message ACKs for those keyboarding. 
The VHF
> WIDEn-N APRS network is amazingly resilient!  Warnings of a VHF net
"death
> spiral" have been greatly exaggerated.  More of our users are
learning that
> simply WIDE2-2 is a good path for general use, and it works.  It's
better
> than a path that includes any commas.  Using only WIDEn-N or
TRACEn-N
> produces no dupes.  Kantronics TNCS do not do any dupe checking on
packets
> other than with pure WIDEn-N and TRACEn-N paths.  RELAY or WIDE or
TRACE
> aren't much needed, and digipath commas cause loss of dupe-checking
in our
> Kantronics TNCs. Going back to RELAY,WIDE (or worse yet
RELAY,WIDE,WIDE)
> would be a step backward in California.  For years, we've been
educating
> local users that using only WIDE2-2 or TRACE2-2 will do the job for
the VHF
> community of APRS users, especially considering very few places in
> California are more than 2 hops from an IGate.  This has slowly been
paying
> off in our fully WIDEn-N capable network over the past few years,
> especially.  Most users have learned to avoid overly broad digipaths
(if
> they've learned anything) by now.  Many have learned to avoid commas
in
> their digipaths.  We're making good progress, and our VHF traffic
load is
> _declining_, despite new stations appearing regularly.  The Western
US,
> besides being more complete as a pure WIDEn-N network than the East,
is just
> different topographically, too.  Interstates?  We have high digis
> overlooking the LA Basin that cover big stretches of 5 or more
interstate
> freeways at once, and I-5's 800 miles in California can be covered by
only a
> few WIDEn-N digi hops.
>
> So, why lose (throw away) this progress we've worked so hard for so
many
> years to produce?  Is there really some new "enforcement" plan or
idea that
> is worth more than all the courteous effort that's already been
expended in
> educating ourselves and our fellow hams on VHF?  I don't think so.  I
know
> some feel frustrated with the slow effort of education, elmering, and
some
> aren't much good at it.  But I think "nationally" throwing out
WIDEn-N in
> favor of LINKn_N or equivalent is like throwing the baby out with
the
> bathwater.
> 73, Cap KE6AFE
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org 
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig 
>


_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org 
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig