| |
ZL3AI > APRDIG 03.10.03 09:40l 254 Lines 10793 Bytes #999 (0) @ WW
BID : 2064-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 30, 7/16
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<WB0TAX<N1UAN<ZL2BAU<ZL3VML
Sent: 031002/1420Z @:ZL3VML.#80.NZL.OC #:9561 [Chch-NZ] FBB7.00i $:2064-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Take Control of your DIGI part 4
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 30 Sep 2003 14:28:56 -0400 (EDT)
X-Message-Number: 28
On Mon, 29 Sep 2003, Tim Cunningham wrote:
>>Nope, what you and everyone else seems to be missing, is that it is
>>NOT the fault of callsign substition per se, it is many faults
>>compounded:
>
>Yes and no. The problem is not callsign substitution. The problem is
>dupe checking does not work properly when callsign substitution is
>employed.
No, an initial one or two dupes in the vicinity of the point of origin of
a packet IS PART OF THE SYSTGEM TO ENSURE RELIABILITY OF DELIVERY in the
local LAN. The design of APRS is aware of these and they go no further
than the point of origin *IF* the system is set up as designed:
1) Proper setting of DWait which can even eliminate them
2) THey go no farther than the FIRST digi!
It just ISNT a problem if APRS is used as it was designed (local) and the
only way it can possibly work (local), with short hops and the absence of
external QRM from long WIDEn-N that exponentially multiply QRM including
dupes..
>provided. There are too many duplicate packets because the digipeaters
>DO NOT handle dupe checking when callsign substituition alters the packet
>path. That was the whole point.
And my whole point is that it doesnt matter! If APRS was used as
designed and without the intent of everyone to FLOOD everyone else with
multiple copies of every packet from hundreds of users (includeing dupes)
then the problem is just not worth making local HACKS that kill the
system as a universal system that works WELL EVERYWHERE..
>The point is duplicate packets are amplified by the use of callsign
>substitution when dupe checking is broken..
Yes, but only when you are using them in a BROKEN
FLOOD-EVERYTHIG-EVERYWHERE system.
>Come on.... The reality is WIDE7-7 is no different than 7 WIDE's in the
>path. What I can testify is that WIDEn-N definitely does not suffer from
>dupes like RELAY and WIDE with callsign substittution.
That line of arguemnt makes no sense whatsoever to the current state
of the APRS network. 1) We can no longer afford WIDE7-7 nor wwwwwww
paths. ALso Wn-N has NONE of the 6 or 7 other advantages I have so
clearly illucidated.
>Just look in the examples I added to the original postings. WIDEn-N
>never duplicated only in the case of a misconfigured Kantronics using
>the ID method. I know this is the reality from what I can see locally
>and in the distance.
You are looking at a totally broken network, we BOTH agree that it is
totaly hosed. I have shown you how with callsign substituting and
proper network settings you can
IMPROVE BANDWIDTH,
IMPROVE RELIABILITY,
DECREASE QRM,
IMPROVE LONG HAUL long hop paths.
PATH TRACING ON ALL PATHS
POINT OF ENTRY IDENTIFICATION
Yet you keep arguing about wanting to get to a more efficient WIDEn-N
FLOODING system which accomplishes NONE OF THE ABOVE and only helps assure:
LESS BANDWIDTH due to increased out of area WIDEn-N QRM
WORSE Reliabiliy due to increased WIDEn-N QRM
WORSE long haul performance due to increased WIDEn-N QRM
NO automatic PATH tracing
NO point of entry identification
Yes, elininating callsign substitution IMPROVES the ability of WIDEn-N to
QRM greater areas and produce nothing but NEGATIVES on every aspect of the
network. We MUST GET AWAY FROM this BLIND protection of WIDEn-N as the
answer to everyting. It is the PROBLEM with everything...
>>I think some folks do have some confusion on this topic because we
>are making it confusing.
>
>Can you agree that WIDE7-7 is going to go in all the same directions as
>WIDE,WIDE,WIDE,WIDE,WIDE,WIDE,WIDE?
Nope, because in MY changed WIDEn-N paradigm, the WIDE7-7 will only
generate 7 instead of 196 copies in a linear path, or only X copies in a
LANn-N or NO QRM where the local networks are alrreayd saturated.
But all of these N-N algorithms CAN BE USED WELL! W,W,W,W,W,W,W
on the other hand should NEVER be used, and will be eliiminated by being
absolutely dissalowed as bad amateur practice...
>Of course it does and it takes up 42 more bytes than the WIDEn-N method.
But we CANNOT AFFORD in your system or mine to have 196 copies of
everybody's packets FLOODING hundreds of miles in every direction. Give
it up. WIDEn-N as a FLOODING algorithm in ALL directions is ABSOLUTELY
DEAD and we must get away from that concept IMMEDIATELY.
I have given very good ways to not only solve ALL the problems of WIDEn-N
as currently done, and have shown how we can use N-N routing to ADVANTAGE
and can do it at the local level while still yielding a single basis for
user education that is universal and works everywhere.
>There is no disagreement here. Yes, that is too many hops, but the point is
>lets compare apples with the end result. WIDEn-N does not suffer from the
>dupes like WIDE and RELAY. That is the reality of the digipeaters in the
>example.
But the dupes you are focused on are INSIGNIFICANT compared to the
advantages to going back to CALLSIGN SUBSTITUTION as the basis of APRS,
SHORT GENERIC HOPS ONLY, and the new WIDEn-N paradigm that solves all of
its BAD stuff and substitutes all kinds of good N-N stuff...
>>>What the digi's perform and what you explain do not match. That is why
>>>we are disagreeing. Please go back to the example. Better yet, let me
>>>paste here again:
What I am explaining is HOW it works in a system set up as it was
deisgned. What you are focused on is HOW BAD the current system is. We
both agree there completely..
>>>>Sorry, these examples are no good!
>
>You have got to be kidding me. These examples are no good?! Come on..
>They are the reality of the what happens on the network today. I agree it
>does not fit your perfect world scenario, but it is the reality here and now.
Yep, and it must be fixed. Your approach of ensuring the continuing
FLOODING of the network with HUNDREDS of copies of everyone's packets by
trying to IMPROVE the efficiency of WIDEn-N only makes it WORSE!!!
>3)That assumes we have a completely connected network outside of
>the area and we both know that is not a reality to the North, South, and
>West. It is a possibility to the WEST. I can point my beam toward Atlanta
>and catch all the activity, but the packets are not going to get past Fort
>Payne or Chattanooga most of the time.
What does Atlanta, have to do with APRS and the local LAN in Northern
ALabama over a hundred miles away and in a different state??????
End of this part
Bob
----------------------------------------------------------------------
Subject: RE: Cheap GPS receivers / RS232 / Digitraveller
From: "Donald Dillaby" <ddillaby@comcast.net>
Date: Tue, 30 Sep 2003 14:43:02 -0400
X-Message-Number: 29
Wish there were some left up in this part of the woods. Nothing in S. NH or
even Massachusetts.
Regards,
Donald Dillaby, KA1GOZ
----------------------------------------------------------------------
Subject: ***New*** TRACEn-N (LANn-N) Paradigm (2)
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 30 Sep 2003 14:57:56 -0400 (EDT)
X-Message-Number: 30
A FINAL summary of the *** new UITRACE LANn-N *** paradigm.
Now then we have EVERYTHING:
- RELAY and WIDE can work everywhere for 1 or 2 hop paths
- LINKn-N can work everywhere for linear paths where useful
- WIDEn-N can still work anywhere where it can be tolerated
- LANn-N can work anywhere for LAN's that may need 3 or more hops or so
- Universal USER training works everwhere
- FLOODING your QRM to everyone else outside of your area is BAD!
- FLOODING can be SQUELCHED by the local SYSOP
The KPC-3+ settings are:
UIDIGI RELAY,WIDE,XXXX,YYYYY
UIFLOOD WIDE,28,NOID (in BOONIES)
UIFLOOD LINK,28,NOID (in all other areas where "LINK" is the name
of a given linear LINK system of local value)
UITRACE LAN,28 (in all other areas where "LAN" is the name
of a given AREA LAN in your area)
Here is the UNIVERSAL set of rules that will now work everywhere:
GENERAL MOBILE PATH: RELAY,WIDE
GENERAL PORTABLE PATH: WIDE,WIDE or DIGI1,WIDE
Nationwide traveler: RELAY,WIDE2-2
LOCAL FIXED PATH: You MUST determine your ALOHA circle and set your path
no farther than what it takes to hit it.
1 hop USE WIDE
2 hop USE WIDE,WIDE or DIGI,WIDE
3 hop USE DIGI1,WIDE,WIDE or WIDE,DIGI2,WIDE, or WIDE,WIDE,DIGI3
LAN use LANn-N where "LAN" is the name (up to 5 characters) of
the designated LAN in your area. N only has to be
large enough to hit every digi in the LAN...
LOCAL FIXED PATH IN DESIGNATED LANS: In areas where SYSOPS have gotten
together and decided on a special "LAN" name that covers the total area of
interest (but still can contain no more than 50 to 100 users to stay below
the ALOHA limits) then in these areas, all fixed locals can use thse
paths:
1 hop USE WIDE
2 hops use LAN2-2
3 or more use LAN3-3 or n-N.
With the UITRACE implementing of your LANn-N, (instead of UIFLOOD) now you
do NOT have to MIX an initial WIDE,LANn-N which does propagate some dupes.
But you can use just the basic LAN3-3 path which will arrive at EVERY
digipeater in your X digi LANn-N with NO dupes and with full traceablity.
and injection point identificaiton. Yes, the path arrives as
SPECIALTY SUBNETS of XXXX, and YYYY: Notice that since we nolonger need
TRACE, we now have XXXX and YYYY that can be used to designated certain
digis to handle traffic for XXXX and YYYY specialties such as SAR or
SKYWARN...
The PROBLEM is, can HAM RADIO SYSOPS define useful LANn-N's that can serve
a specific purpose without EXCEEDING the ALHOA limits!
Good luck... If we are successful, then:
1) A MULTI fold increase in the usable bandwidth of your LAN
(every packet is designed to hit about X surrounding digis
(instead of 21 to 36 with generic FLOODn-N (3 hops))
2) A MULTI-SQUARED reduction in QRM (from all directions)
3) A MULTI-SQUARED imporvement in the reliablity of your network.
4) Universal operation everywhere using ONE universal setting
(starting with RELAY and WIDE)
5) FULL PATH TRACING of every packet (via callsign substitution)
(or the UITRACE feature of LANn-N when N is 3 or greater)
6) Point of injection identification of EVERY packet
7) Better performance of long haul WIDEn-N generic traffic through areas
that can support it. And no stigma attached to such use.
8) Automatic QRM limiting for LANn-N routing to only X copies for X
digipeaters independent of N.
9) Full length LINKn-N routing with only worst case 7 copies instead
of 100 to 200 copies.
And we can do it today...
Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
