| |
ZL3AI > APRDIG 28.09.03 12:27l 264 Lines 12867 Bytes #999 (0) @ WW
BID : 2005-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 25, 5/11
Path: DB0FHN<DB0RGB<DB0SL<DB0FSG<OE7XLR<OE9XPI<DB0CZ<DB0GV<DB0SIF<DB0FHK<
DB0ACC<ON0RAT<ON0DXC<WA7V<W7NTF<KD4GBA<ZL2BAU<ZL3VML
Sent: 030927/1341Z @:ZL3VML.#80.NZL.OC #:9140 [Chch-NZ] FBB7.00i $:2005-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: JFindu Has Moved
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Thu, 25 Sep 2003 12:52:41 -0500
X-Message-Number: 25
Thanks Bob. The previous locations will still get you there via
redirection. If someone was using http://www.aprs-is.net/jfindu/ or
http://jfindu.aprs-is.net/ for instance, they will get redirected to
http://www.jfindu.net/ Google's robot will update the paths over time
but until then people will be redirected just fine.
The redirection works if you have a predefined query. For instance,
http://www.aprs-is.net/jfindu/near.asp?call=AE5PL&metric=0&getallssid=
=true&firewall= will be redirected to
http://www.jfindu.net/near.asp?call=AE5PL&metric=0&getallssid=true&=
firewall=
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Subject: Re: Part 2/2 -Re: Take Control - oh let's just go backwards on things,
that's the solution NOT
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 25 Sep 2003 14:50:06 -0400 (EDT)
X-Message-Number: 26
Someone asked:
>Is the failure to dupe check RELAY and WIDE limited to Kantronics TNCs?
No, ALL Kantronics after 1998 and all PacComm's after 1996 do callsign
substitution on RELAY and WIDE and then will never digipeat that packet
again.* That is the function of call-substitution, to prevent dupes.
This of course assumes that people are putting the RELAY and WIDE's in the
proper fields in those TNC's. If they are using MYALIAS for RELAY or
WIDE, then the kantronics (and all other TNC's except PacComm) will not
dupe check. But no one should be using the MYALIAS Of WIDE if they can
afford to upgrade.
>We use UI-Digi almost exclusively in this area. Realistically UI-Digi
>is such a great replacement because the author will make changes as
>needed and you can burn your own settings that won't get lost due to
>power outage or other glitch. It also is pretty simple setup. No PC to
>worry about, no fancy TNC with multiports to go wacky. I see them on
>ebay every once and a while. There has to be hundreds or thousands of
>them in people's basements collecting dust. I keep 2 spares just in
>case we loose a digi due to lightning or whatever.
Yes, upgrading to UI-Digi gives lots of flexibilty. But unless I am
wrong about this, as you can tell, I am totally convinced that we can
solve almost of all of our problems if we take this new approach of
isolating WIDEn-N digipeaters out in the toolies where they are needed
and not letting them propogate DX traffic into our crowded LAN's hwere
they are not needed.
*** Footnote to paragraph above. If WIDE is combined with WIDEn-N, and
TWO digi's hear the packet simultaneously, then BOTH will digipeat the
packet and you may see a DUPE. Same goes for WIDEn-N too. This is the
nature of the network. These dupes are supposed to be minimized by
fratricide, that is, they both occur at the same time so they kill each
other back in the point of origin, though they do continue to propogate
outward. Again. some well meaining sysops have HACKED the DIGI's so that
they have different delays to make sure that there is no collision. THis
is BAD for the network and is just one of those hacks that appears good at
first inspection but is wrong because it eliminates the most fundamental
element of dupe elimination on which APRS was based, that is Fratricide.
Bob
----------------------------------------------------------------------
Subject: Re: Re: Part 2/2 -Re: Take Control - oh let's just go backwards
From: Bob Bruninga <bruninga@usna.edu>
Date: Thu, 25 Sep 2003 15:22:31 -0400 (EDT)
X-Message-Number: 27
On Thu, 25 Sep 2003, Jeff Thomas - KD4EVB wrote:
>There seems to be this ever evolving idea of what is right and wrong and
>there seems to be no end to state of flux and the impossibility to get a
>straight annswer on what standards/equipment we need to adopt, impliment and
>move towards, just confusion, knee jerk reactions, personal attacks, and on
>and on.
THere has always been one source of info and it has always been DIGIS.TXT
distributed with APRSdos.. The problem is that once everyone started
coming into APRS wihtout having used the original APRSdos, and reading
the docs, then fundamental understandings were missing and many people
without a full understanding of how all the little subtleties have all
been engineered to work well together began doing their own little local
hacks with little appreciation for the consequencies.
>I ran them that way for over a year, not a single complaint and
>things were a lot more reliable compared to the last two months around here
>with WIDE enabled and everything wide open (no pun intended). I didn't
>make the change without a lot of long hard thinking about it.
>
>Frankly I'm so **** tired of listening to the locals ***** because 144.390
>is **** unreliable or takes nearly half a minute before the digi can get an
>open channel to move their packets out due to idiots half a state away,
>trying to get to the igate is hit and miss,
And I can assure you, that turning offg WIDE does NOTHING to solve that
problem. Can't you see the discrepancy in what your two paragraphs are
saying? In one, you blame WIDE, in the other, you blame all the DX
packets coming in from half a state away. That is contradictory. WIDE is
the local *first* hop. THus, it cannot be the problem of DX packets.
WIDE3-3 can bring in packets from hundreds of miles away. That is the
problem.
>dupe/looping issues. Yeap, RELAY,WIDE and RELAY,WIDE,WIDE is the solution,
>see below:
>
>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
Wow, wrong conclusion!
No, what you are seeing here are problems with the WIDE3-3 on the end of
those packets! WIDE3-3 on the end is assuring that EVERY copy of that
packet will FLOOD the entire netowrk 5 hops in all directions! That is
every digi can hear 3 other digi's this is potentially over 94 copies of
the same packet! even if there were NO WIDE's at the begnining. Now 94
copies of a packet going to the surrounding 4 states IS THE PROBLEM!
And that is with only a path of WIDE5-5 with all WIDE turned off.
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.
I suggest that you transmit the ABOVE packet using only the path of
WIDE,WIDE and then count the result. In the SAME network where every digi
can hear 3 others, you will not see 94 DUPES, but only 4. THese four will
reach everyone within 2 digis of the SENDER and in most densly populated
areas that is enough to support the ALOHA circle of the 50 nearest
stations. In rural areas, try WIDE,WIDE,WIDE. In this same network,
the total number of packets will be 10. Now you are out 3 hops in ALL
direfctions and it is still only 10% of the QRM generated by the original
path.
People are just not thinking clearly. The problem is TOO much traffic
caused by TOO LONG HOPS. A 1200 baud APRS network on RF whether it is
from 10,000 foot m ountains or lots of small 100' digis, can support no
more than about 50 users reliably. People must start thinking CELLULAR
and reduce the size of their HOPS to match that 50 user radius. Anything
else is just fuzzy thinking...
>>I'm sure if I look thru the logs I'd find worse examples. One
>RELAY,WIDE,WIDE3-3 packet owns the **** channel for 8 seconds, handful of
>these and kiss the channel goodbye.
Yes, and the problem is NOT the RELAY,WIDE, it is the fact that the packet
is FLOODING the network 5 hops in ALL DIRECTIONS!
> IS the Kantronic's implimentation of
>things the problem? What's the solution, provide some data to look at, give
>us sysops some straight, clear, and data backed up scoop on the what path we
>need go down. I'm so sick of a thousand opinions I could just barf. You
>created this monster Bob, yeah I'm sure we did a lot of the mangling of it,
>but I value your thoughts. A few years ago you were harping that we all
>need to embrace WIDEn-n, now we're talking about killing it in many areas,
>what the ****?
Yes, that was back in 1994. But everything changed, and I cannot believe
it took me till last week to realize that WIDEn-N was now the number one
problem in most areas.
>Killing WIDEN in my opinion is far worse than turning WIDE
>off in an areas served by all WIDEN compliant digi's (what you were wanting
>not too long ago).
I NEVER wanted WIDE turned off. That is some bad info that some other
sysops have encouraged which is just flat wrong.
>I don't care if I impact a small percentage of folks if it's for the
>better of the majority of my local users, sorry.
Yes, it all depends on what people think is "better". TO some, "better"
means seeing 500 to 1000 people on their maps spread over the surrounding
4 states but having miserable local reliability. My definition of
"better" in APRS has always been LOCAL. That is, APRS should work
reliably at the local level and with a little deduction we have arrived at
that definition of "local" is that RF area that encompases about 50 uers.
Trying to bring in DX packets from hundreds of miles away to fill up
static maps with no one moving is just not what APRS is about.
>I'll agree to disagree with you on the WIDE, I'm only killing WIDE, not
>RELAY, not TRACE, not WIDEN. WIDEN done right is the closest thing we've
>got to a solution, we didn't just spend several ******* years battling along
>to get everyone to get digi's converted over to WIDEn/tracen compliance.
WIDEn-N works well where the path length is greater than 2 or larger.
But that changed in 1997 when Steve Dimse and Sprouls briught in the
internet. We jst cannot afford LONG paths in BUSY areas. No matter what
you do. SO get back to basics. Turn off the long paths.
Since we have not been able to do it through user education, then it is
time for local SYSOPS to take control over their local area and TURN OFF
WIDEn_N if it will help them reduce the traffic load on their local digi
so that it can serve its LOCAL area...
>My statement all along was not to change things due to just a few causing a
>problem, try to get the few to adapt or filter their butts off at the digi's
>igates. I've said all along each area is unique in it's needs and problems,
>it isn't a perfect world but we should be able to come up with baselines.
>Half the **** problem is we've got software writters putting out software
>setup for the "lowest common denominator" paths that are early 1990's
>obsolete anymore plus folks trying to mix them to come up with a "one size
>fits all" solution to the path conundrum.
>
>I've sat by and watched the various opinions and arguements float around
>back and forth on the APRS sig as to how to address a problem I think we can
>all admit we've got and is only going to get worse.....channel overload in
>many areas. I've got a stopgap "kludge" of a temp solution for my area, but
>I admit I don't have the solution I can put down in writting. I don't like
>turning WIDE off, but I've either go to make the best out of what we have
>around here or turn them off. Half the digi's around here are run by either
>individuals or private groups committing a lot of time, money, and equipment
>to APRS, all we want is some leadership, clarity and reasonable level of
>reliability on the system. Apparently that is too much to ask, instead we
>get the theory of the day on how to solve the issue day in and day out for
>at least the last couple years, yet nothing's changed while 144.390
>continues to decline.
I hate to say this, but if you would listen to me, you would have a
single point of leadership and you would have the right answers.
>How about we stop this fighting and attacking and get to work on solving the
>**** issue with something tangible and implimentable versus opinions that
>change by the week.
Yep, its easy. Either get the users to cut back their paths (has been
shown to never work) or turn off WIDEn-N at the digis that are
overloaded.
de WB4APR@amsat.org, Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
