| |
ZL3AI > APRDIG 28.09.03 12:07l 234 Lines 9967 Bytes #999 (0) @ WW
BID : 2009-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 25, 9/11
Path: DB0FHN<DB0RGB<DB0MRW<DB0SON<DB0SIF<DB0FHK<DB0ACC<ON0RAT<ON0DXC<WA7V<
WB0TAX<LZ3NP<YV6BTF<EA5AKC<KD4GBA<ZL2BAU<ZL3VML
Sent: 030927/1409Z @:ZL3VML.#80.NZL.OC #:9144 [Chch-NZ] FBB7.00i $:2009-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: I guess we're going to agree to disagree Bob. Part 3 of hopefully 3
From: "Scott Miller" <scott@home.miller.org>
Date: Thu, 25 Sep 2003 17:40:58 -0700
X-Message-Number: 35
I'll second that. Same goes for the APRS IS tier 2 debate. Keep the holy
wars off the list and publish something meaningful in PSR.
Scott
N1VG
-----Original Message-----
From: bounce-aprssig-31505@lists.tapr.org
[mailto:bounce-aprssig-31505@lists.tapr.org]On Behalf Of Georgette
Sampson
Sent: Thursday, September 25, 2003 3:49 PM
To: TAPR APRS Special Interest Group
Subject: [aprssig] Re: I guess we're going to agree to disagree Bob.
Part 3 of hopefully 3
Someone suggested the digi guru's all "engineer" the problem, and I
think that's a good course of action.
Gather the data, form an argument, and then publish it.
Seems that right now, all we have published arguments with no data.
This isn't an issue worth following right now (imho).
----------------------------------------------------------------------
Subject: Re: I guess we're going to agree to disagree Bob. Part 1 of ?
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 25 Sep 2003 21:01:56 -0400 (EDT)
X-Message-Number: 36
On Thu, 25 Sep 2003, Jeff Thomas - KD4EVB wrote:
>Bob,... I'm not going to agree with you just because it came from you,
>back it up with real world data is becoming my mantra.
In the previous email I did and it seemed to me to totally support the
concept of retaining the universality of RELAY/WIDE local routing and
givng sysops the option ofdisabling WIDEn-N where out-of-area packets are
flooding the network.
>I PROBABLY DIDN'T WORD IT THE BEST, BUT THERE IS NO CONTRADICTION GOING ON.
>THE PROBLEM IS ACTUALLY A COMBINATION OF BOTH, LOTS OF FOLKS RUNNING
>MULTIPART RELAY,WIDE,WIDE, OR WORSE AND A SMALL HANDFUL OF GUYS ABUSING
>WIDEN-N. THE RELAY,WIDE, WIDE OR RELAY,WIDE,WHATEVER IS CAUSING THE DUPES,
>THE DX STATIONS RUNNING BIGTIME WIDEN-N PATHS ARE JUST A TINY PART OF THE
>PROBLEM HERE.
That is not at all what I am hearing from others and not at all what I am
seeing. But it doesnt matter. My recommendation to cut out WIDEn-N is
only for areas WHERE it is a problem. Not where it is not a problem. In
a network that has every digi hearing say 3 other digis, WIDE3-3 generates
19 packets. In that same network, a path of WIDE,WIDE would only generate
7 or if you include some worst case DUPES, it migh generate a few more in
the immediate area of where it was launched, but no more further out.
>I CHOOSE TO TRY AND GET THE FEW WIDEN-N PROBLEM STATIONS
>FIXED BY CONTACTING THEM. THE NUMBER OF FOLKS CAUSING THE DUPE FESTS WITH
>RELAY,WIDE,WHATEVER ARE TOO MANY FOR ME TO EVEN CONTEMPLATE ADDRESSING VIA
>EMAIL.
But as I pointed out, yes there are some dupes, but if you cut off the
WIDEn-N on the end, then those dupes dont PROPOGATE all over creation...
They ONLY occur in the local vicinity of where they were generated (where
they provide redundancy) and because of callsign substitution, do NOT
propogate outward as they do if WIDEn-N is added to it...
>THE PROBLEM IS THE FOLKS RUNNING OUTDATED RELAY,WIDE AND ESPECIALLY 3 PART
>PATHS USING THIS ALIASES CAUSEING DUPES, THE PROBLEM STATIONS ARE SOMETIMES
>ON OUR LOCAL FRINGE AND SOME ARE OUT EVEN FURTHER BEING COMPOUNDED BY OUR
>TERRAIN FEATURES AND THE FACT THAT A LOT OF THE DIGIS CAN HEAR A LOT OF THE
>OTHERS...
You just have to define what you want APRS to do. If you want it to serve
local use RELIABLY and to serve ANYONE that comes into your area using the
national recommendatins, then keep RELAY and WIDE digipeating enabled.
If you are flooded by too many packets and too many dupes from out of area
coming in via WIDEn-N paths, then disable WIDEn-N locally and get control
of your local network locally.
I guess if your goal for APRS is to show hundreds of users all over 5
states, (at the expense of total lack of relaible local use) then sure,
your method of enhancing WIDEn-N and disabling RELAY/WIDE will work.
So just decide what you want to do.
My design for APRS was as a tactical real-time reliable local digital
communications system... I try to weigh all ideas against ONLY that
mission. If an idea is counter productive to that idea, then I am
opposed to it. If an idea helps that objective, then I am for it.
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: I guess we're going to agree to disagree Bob. Part 1 of ?
From: Steve Jones <s.jones@rogers.com>
Date: Thu, 25 Sep 2003 21:10:29 -0400
X-Message-Number: 37
on 9/25/03 8:40 PM, Bob Bruninga at bruninga@usna.edu wrote:
>>MASKED-12>S9PV8Q,K8SCH-10*,WIDE,WIDE3-3 [09/13/2003
>>01:17:50]:<UI>:`p>]l!ck/"6\}masked
>>MASKED-12>S9PV8Q,K8SCH-10,W8MWO*,WIDE3-3 [09/13/2003
>>01:17:51]:<UI>:`p>]l!ck/"6\}masked
>>MASKED-12>S9PV8Q,K8SCH-10,AB4WS-10*,WIDE3-3 [09/13/2003
>>01:17:52]:<UI>:`p>]l!ck/"6\}masked
>>MASKED-12>S9PV8Q,K8SCH-10,W8MWO*,WIDE3-2 [09/13/2003
>>01:17:53]:<UI>:`p>]l!ck/"6\}masked
>>MASKED-12>S9PV8Q,K8SCH-10,W8MWO*,WIDE3-2 [09/13/2003
>>01:17:53]:<UI>:`p>]l!ck/"6\}masked
>>MASKED-12>S9PV8Q,K8SCH-10,KD4EVB-10*,WIDE3-3 [09/13/2003
>>01:17:57]:<UI>:`p>]l!ck/"6\}masked
>>MASKED-12>S9PV8Q,K8SCH-10,W8MWO*,WIDE3-2 [09/13/2003
>>01:17:57]:<UI>:`p>]l!ck/"6\}masked
>>MASKED-12>S9PV8Q,K8SCH-10,KF4INN-10*,WIDE3-2 [09/13/2003
>>01:17:58]:<UI>:`p>]l!ck/"6\}masked
Seems to me that W8MWO is unnecessarily duping packets?
Wouldn't it benefit from some smarter digi software which would examine the
contents of the packet and reject the dupes?
--
Steve <s.jones@rogers.com>
----------------------------------------------------------------------
Subject: Re: I guess we're going to agree to disagree Bob. Part 2 of ?
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 25 Sep 2003 21:19:42 -0400 (EDT)
X-Message-Number: 38
On Thu, 25 Sep 2003, Jeff Thomas - KD4EVB wrote:
>BEST I CAN RECALL, FOR THE FIRST 6-7 MONTHS OF THIS YEAR I RAN BOTH OF THE
>NKY DIGI'S WITHOUT WIDE.... I DIDN'T JUST TYPE A
>OPINION UP AND SAY IT SOLVES THE PROBLEM, I TESTED MY THEORY AND FOUND IT
>HELPED 'PATCH' THE PROBLEM LOCALLY FOR THE TIME BEING.
Ah, but what problem did you fix? Yes, you cut packets but what other
prolems did you INTRODUCE?:
1) You no longer supported the national recommendaions for visitors
2) You disabled callsign substitution as a path tracing function
3) You killed APRS first-digi identification (identifying where a packet
entered the APRS system on RF.
The only thing you did was totally arbitrarily throw out a lot of users
packets. Of course you "solved the problem" of too many packets that way,
but shucks, you could use an AK-47 and shoot evedry third driver and solve
a lot of commuting problems too...
Again, you are too focused on local DUPES and not looking at the BIG
problem which is too many packets from too many users FLOOODING too big of
an area.
> THE LAST COUPLE MONTHS I
>OPENED THINGS BACK UP AND THEN THE CONGESTION GOT BAD ALMOST INSTANTLY.
>WITHIN A FEW HOURS I HAD ONE USER ASKING WHAT I CHANGED AND BY THE END OF
>THE FOLLOWING WEEKEND MY NAME WAS BEGINNING TO BECOME 'MUD' FOR TURNING WIDE
>BACK ON.
Ah, but maybe they dont understand or accept the big problem either.
>I'LL TRUST MY REAL WORLD OBSERVATIONS OVER UNSUBSTANTIATED
>OPINIONS OF WHAT SOMEONE SOMEWERE ELSE PERCEIVES AS THE 'RIGHT WAY' TO DO
>THINGS AND TEXT BOOK THEORIES ANYDAY.
And that is why APRS is falling apart due to local hacks that dont see the
forest for the trees.
>I'VE NEVER ENDORSED ANY SYSOP MAKING
>DRASTIC CHANGES TO THE APRS DIGI INFRASTRUCTURRE WITHOUT CAREFULL STUDY AND
>CONSIDERATION OF THE IMPACT. I REALIZE I CAN MAKE EVERYONE HAPPY, SO I
>CHOOSE TO MAKE THE MAJORITY HAPPY BY DOING WHAT SEEMS TO WORK FOR MY
>SITUATION.
I guess we disagree on what "seems to work" and what "work" really
means. I am only trying to provide input to that "careful study" so that
local sysops don't go out and throw out the baby with the bathwater.
>"Now if APRS users in that area would realize that EVERYONE FLOODING the
>network across 4 states cannot possibly handle the 300 users that are
>trying to do that, then you might make some progress.?"
>
>AMEN BROTHER, COULDN'T AGREE MORE BUT WITH ONE EXCEPTION. IT'S NOT THE FEW
>WIDEN IDIOTS CAUSING THE PROBLEM DOWN HERE. IT'S THE BIG PERCENTAGE OF
>FOLKS RUNNING THE OLD DEFAULTS OR WORSE. I DON'T CONDEM WIDEN BECAUSE A
>HANDFUL OF FOLKS (AT MOST AROUND HERE) ARE ABUSING IT, WIDEN IS A MUCH MORE
>POWERFUL DIGI PATH WHEN DONE RIGHT.
But "POWREFUL" in your terms means MAXIMUM FLOODING.
I am now coming to realize that "POWERFUL" means MAXIMUM DAMAGE to the
network and it should be restricted to ONLY those low population areas
where it is needed. and NOT flooding out in ALL directions without bound.
>YEAH, 'DONE RIGHT' IS THE KEY WITH ANYTHING. WHAT ARE WE GOING TO DO
>WHEN THIS HITS SAY 600 USERS? HUMM, MY POINT EXACTLY WHY WE NEED TO USE
>WIDEN RIGHT TILL WE COME UP WITH A BETTER WAY AND BETTER PROTOCOL.
If you are trying to support more than about 50 uers on the local 144.39
1200 baud channel then you are already beyond the point of total failure.
Finding new ways to EFFICIENTLY flood those local areas is only making
things worse...
>SO YOUR SAYING WE SHOULD TOLERATE A FEW DUPES? I'M SAYING THAT WITH WIDEN
>DIGIS AND FOLKS USING GOOD WIDEN PATHS WE DON'T HAVE A DUPE ISSUE AT ALL
If you dont have some dupes, then you are certainly MISSING some packets
that got lost in the first place. I would prefer some dupes than having a
lack of reliability at the local level. ANd if your local distribution
is based on callsign-substituting WIDE digipeaters then the few extra
dupes do NOT propogate outward to surrounding areas, becuse no digi will
digipeat its own callsign substituted WIDE packet twice...
de WB4APR, Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
