| |
ZL3AI > APRDIG 29.09.03 18:11l 283 Lines 13097 Bytes #999 (0) @ WW
BID : 2016-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 26, 1/7
Path: DB0FHN<DB0RGB<DB0MRW<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<LU6DTS<VK3AVE<
ZL2BAU<ZL3VML
Sent: 030928/1333Z @:ZL3VML.#80.NZL.OC #:9238 [Chch-NZ] FBB7.00i $:2016-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Friday, September 26, 2003.
1. Re: I guess we're going to agree to disagree Bob. Part 1 of ?
2. Re: I guess we're going to agree to disagree Bob. Part 2 of ?
3. Re: I guess we're going to agree to disagree Bob. Part 2 of ?
4. OZ RADAR MAP Calibration
5. APRS Then and Now [was: I guess we're going to agree...]
6. XASTIR and ImageMagick
7. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
8. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
9. WIDEn-N dynamic filtering...
10. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
11. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
12. Re: XASTIR and ImageMagick
13. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
14. WIDEn-N filtering
15. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
16. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
17. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
18. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
19. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
20. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
21. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
22. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
23. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
24. Next generation APRS mapping idea
25. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
26. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
27. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
28. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
29. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
30. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
31. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
32. APRS Grass growing...
33. Emergency Power lights.
34. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
35. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
36. Re: WAS: TRACKING THIEF IS: 911 and GPS Phones
37. RE: Emergency Power lights.
38. Re: APRS Grass growing...
39. Re: I guess we're going to agree to disagree Bob. Part 3 of hopefully 3
40. Re: Emergency Power lights.
41. Re: Part 2/2 -Re: Take Control - oh let's just go backwards
42. Re: WAS: TRACKING THIEF IS: 911 and GPS Phones
43. Re: WAS: TRACKING THIEF IS: 911 and GPS Phones
44. Re: Emergency Power lights.
----------------------------------------------------------------------
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 23:32:04 -0400 (EDT)
X-Message-Number: 1
On Thu, 25 Sep 2003, Georgette Sampson wrote:
>The "WIDE digipeater is better than the WIDEN-N digipeater" or
>vice-versa, are arguments that have no meaning when you have a real
>computer device.
>
>Suppose you had a Compact Flash configured as a hard drive, a large
>RAM drive, and a bunch of regular RAM? Would a WIDE or WIDEN-n
>digipeater be your goal?
Ah, apples and oranges. By all means, we need all kinds of new "node"
hardware and software and better algorithms, and higher data rates! there
have been all kinds of good ideas. GO FOR IT. I would LOVE to see
everyone go replace the thousand digipeaters with all these great
ideas....
But I am NOT addressing any of those issues. I am only looking at ways to
solve the OVERLOAD problems WE have NOW, TODAY with the installed base of
KPC-3 TNC's using WIDEn-N, that can be fixed with a single command. No
more. No less.
>I know that I would probably come-up with a system that did quite a bit
>of analysis, and table searches before it ever transmitted a thing.
>Maybe the problem is that proper DUP checking is not possible with the
>technology at hand, and blindly re-transmitting what is essentially
>garbage data, rather than only allowing valuable non-redundant tactical
>data to flow, is the problem.
Good ideas. GO implement them, and get them installed all across the
country and lets move forward. But continuing to support the
continuation of LONG-HOP WIDEn-N FLOODING is killing us... in my opinion.
Bob
----------------------------------------------------------------------
Subject: Re: I guess we're going to agree to disagree Bob. Part 2 of ?
From: Bob Bruninga <bruninga@usna.edu>
Date: Fri, 26 Sep 2003 00:45:10 -0400 (EDT)
X-Message-Number: 2
On Thu, 25 Sep 2003, Jeff Thomas - KD4EVB wrote:
>I'll put up 24x7 logs for a few days prior and a few days after I do the
>switching off of WIDE. Real world data, you and anyone else can feel
>free to review and comment on. I could be wrong in where the problem
>lies, I'm certain though that this measure addresses one of the issues.
>Opinions on how proper my move is, well we'll just let history and the
>logs show what they show.
I guarantee that it WILL BE SUCCESSFUL, because your measure of success
is how many DUPES you eliminate. Eliminating WIDE *WILL* reduce the
number of dupes. No question! But I have already showed 5 UNINTENDED
consequences that overall DEGRADE local performance and reliability.
Where we DISAGREE is that I claim that elimination of DUPES via disabling
of WIDE and RELAY is NOT the best measure of network reliability at the
local level! Elimination of out-of area packets is the BETTER fix that
has LESS impact on local reliability.
>">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."
>
>As for part 1, gee I'm really going to loose sleep over that.
ANd that attitude is why APRS is being killed by myopic local sysops
hacking away at the system to eliminate local packets so that they can
bring in more DX...
>By the way, cutting packets is exactly what I'm after. If I break a few
>old things rarely noticed by 99% of the users anyways, then you know
>what...that's a ratio of dissatisfied customers I can live with for a
>more reliable local channel. Does it fix the ultimate problem at the
>source, nope, but no one else is suggesting anything better with data to
>back it up YET. We've got plenty of opinions though, grin.
Just plain wrong thinking. It wont make it more reliable. It will just
continue to collect too many packets from TOO FAR AWAY and the local
reliablity will not be improved at all...
>part 3, combination of the above answer, 99.9% of the time...who cares.
that is the problem 99.9% of those probably dont have a clue about the
details of optimum performance and therefore absolutley they dont care.
But letting disinterest of 99.9% of the users drive network design is a
poor way to design a network for best operation.
>>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 every third
>>driver and solve a lot of commuting problems too..." but it is not
>>a good fix for the locals.
>
>In my monitoring last fall, I didn't seem to notice this at all. I hate
>to tell you, the impact for the vast majority if not nearly 99.% of the
>local users is not as bad as you'd like to make it out to be, sometime
>the pros outweigh the cons. I threw out the loops and dupes coming in
>from the outer ring of my coverage area of concern.
Nope, eliminating WIDE LOCALLY cannot do that. It only impacts local
dupes. TO eliminate dupes in your outer ring, you would haev to eliminate
WIDE at all surrounding digis out N-N hops in all directions.
I say again. A local SYSOP cannot control the influx of DUPES from out of
area by turning off WIDE. But HE can control them by turning off WIDEn-N
in HIS digi and if needed the next tier outward. That is all I am saying.
If he wants to take control. then he has the option of turning off
WIDEn-N. If he wants to leave the ability of hundreds of surrounding
distant stations to flood his local net, then he can leave WIDEn-N ON
and turn off WIDE. Does nothing to eliminate out-of-area QRM...
BOTTOM LINE:
DISABLE WIDE:
- reduce dupes
- reduce local reliability
- reduce commonality
- increase vulnerability to DX interference
DISABLE WIDEn-N:
- reduce traffic load
- IMPROVE local reliability.
Take your choice.
de WB4APR, Bob
----------------------------------------------------------------------
Subject: Re: I guess we're going to agree to disagree Bob. Part 2 of ?
From: Bob Bruninga <bruninga@usna.edu>
Date: Fri, 26 Sep 2003 01:06:21 -0400 (EDT)
X-Message-Number: 3
On Thu, 25 Sep 2003, Jeff Thomas - KD4EVB wrote:
>...yet you feel it appropriate to tell digi sysops to feel free to kill
>our most modern digipeating protocol cause some guy running WIDE5-5 over
>there (and maybe a few others) has irked you off?
Huhh?
WIDEn-N is not modern. I conceived it in 1994. Back then IT WAS NEEDED
because you had to have WIDE4-4 to even find 50 users. A LOT has happened
since then:
1) IGates (and GLOBAL connectivity)
2) now 20,000 users, not just 500
3) We have some great WIDEn-N networks that cover vast areas.
WIDEn-N is still the BEST WAY TO GO FOR LONG HAUL PACKETS in areas that
can afford the load. We should capatilize on that and continue to make
WIDEn-N do GREAT things for us. But conversly, where the network is
OVERLOADED, turning off out-of area DX packets by simply disabling WIDEn-N
digipeating in some digis is a tool that SYSOPS can use to get control otf
their local networks and make them MORE RELIABLE for local traffic.
>... just because a few idiots are bothering your area with incosiderate
>settings, you suddenly want to toss out the baby, the bathwater, the
>tub, and rip out the bathroom walls too.
Nope. Dont know where you got that idea. We dont have a WIDEn-N problem
in our area. Fully 50% of ALL the digis in the greater Washington DC area
do not support WIDEn-N. And those that do are not in the high population
density area. They are in long chains up the lightly populated CELMARVA
coast and up the Appalachain valley wherer they do GREAT long haul
traffic.
>"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..."
>
>Well, then you're probably right for around here (got 473 stations in the
>logs right now for 24 hours) and we're just screwed regardless of what I do
>huh? We're usually in the lower 300 range...
But didn't you also tell us that your local users are complaining of
total lack of LOCAL reliability? And Havent you said that the problem is
BIG? And aren't we having this argument becuase you are turning off WIDE
in your digis to eliminate the traffic load in an attempt to gain
reliability? Then it doesnt take much to conclude that having 473
stations FLOODING into your network is *the problem* and that throwing out
WIDE digipeating to eliminate a few local dupes is not the way to fix it.
>boy kiss local reliability goodbye, the digi's TNC DCD light probably looks
>"stuck on" right now, it isn't far from that normally....I've even got a 1
>minute MPEG movie I'll toss up on the site here in a few days, you can see
>it with your own eyes how bad it is out here.
Then how can you conclude that having 473 stations FLOODING your local
network that can only support about 50 reliably is NOT the problem????
>Let me remind folks of a little story about packet radio in the 80's and
>early 90's. Everyone took the easy route and tried to build wide
>coverage networks based upon a single 1200 baud 2m frequency versus 1200
>baud user channels and 9600 baud backbones. We preached the folly of
>this till blue in the face. Most of these single freq networks failed
>miserably and faded away, helped in the mid 90's by the internet boom
>and this thing called APRS. Looks like we're doomed to never learn from
>our past with APRS also.
Yep, you gotta cut out that OUT-OF-AREA traffic if you want to every
operate a relaible local area network. Some people never learn. We sure
agree here...
>My applogies to the list for all the "list bandwidth" but I feel this is
>aattitude threat to WIDEN (that has little to any basis) needs to be
>addressed, argued, and discussed.
It is not a threat. It is a way to make WIDEn-N work better for us, by
fine tuning the network to let WIDEn-N work WELL where it is needed and to
not FLOOD good local netowrks where it is not needed. And to put the
control of that decison at the LOCAL level where it can do the most good
soonest.
de WB4APR, Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
