| |
ZL3AI > APRDIG 31.08.03 10:24l 232 Lines 9414 Bytes #999 (0) @ WW
BID : 1840-ZL3AI
Read: GUEST
Subj: TAPR Digest, Aug 27, 2/7
Path: DB0FHN<DB0RGB<DB0MRW<OK0PPL<DB0RES<ON0BEL<SP7MGD<ZL2TZE<ZL3VML
Sent: 030829/1351Z @:ZL3VML.#80.NZL.OC #:7296 [Chch-NZ] FBB7.00i $:1840-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: ATTN users in Bowling Green, KY
From: "Michael J. Wolthuis" <wolthui3@msu.edu>
Date: Wed, 27 Aug 2003 10:34:54 -0400
X-Message-Number: 8
The following happened to make it into my system today via what appears
to be a band opening, but either way KY should pry check this out.
map.findu.com/7193LV
I can not find a valid amateur radio call on it anywhere. Maybe I am
missing something, but it doesn't appear tactical to me either.
Mike
Kb8zgl
----------------------------------------------------------------------
Subject: Re: ATTN users in Bowling Green, KY
From: "Sean \\The RIMBoy\\" <sean@rimboy.com>
Date: Wed, 27 Aug 2003 09:44:17 -0500 (CDT)
X-Message-Number: 9
On Wed, 27 Aug 2003, Michael J. Wolthuis wrote:
>The following happened to make it into my system today via what appears
>to be a band opening, but either way KY should pry check this out.
>
>map.findu.com/7193LV
>
>I can not find a valid amateur radio call on it anywhere. Maybe I am
>missing something, but it doesn't appear tactical to me either.
I know who this is. I've discussed this with someone else too. It was
proffered that if they're using a KPC3 that it can CW ID to meet the legal
requirements. (Discuss) Unfortunately I believe they're running a Tiny
Trak, though it does not appear that way in the packet info (the normal TT
text one sees).
It is a ham. I also happen to know that it's their license plate.
Sean...
--
Believing I had supernatural powers, I slammed into a brick wall.
--Paul Simon
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
KG4NRC http://www.rimboy.com Your source for the crap you know you need.
----------------------------------------------------------------------
Subject: RE: New fourth.aprs.net
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 27 Aug 2003 11:06:06 -0400
X-Message-Number: 10
On 8/27/03 at 9:16 AM AE5PL Lists <HamLists@ametx.com> sent:
>First, this server is not "my" server. Other than having written the
>software that it runs (as do 3 of the 4 core servers), I do not have
>anything to do with any of the core or tier 2 servers.
Oops, sorry, my mistake! Need to pay more attention to who is saying what!
>Second, my guess as to why port 10152 is restricted by a sysop is to
>reduce bandwidth and IP packet processing demands on their ISP while
>still providing quality service to users of filtered ports.
Well, they provide a full feed WITH a 30 minute buffer, which is an even
greater load than one without the buffer...
>Not at all. Your implication was that somehow the tier 2 server was
>doing buffering that the core servers do not.
No, actually that was not my point at all. This comment was about the lack
of access to a feed without the 30 minute buffer, nothing more.
>I have NEVER made the claim that tier 2 is "more reliable" than the
>core. But, at the same time, your "proof" does not substantiate that
>the core is "the most reliable" either. In fact, your "proof" is
>showing arizona.aprs2.net as reliable as the core servers. My statement
>is that the tier 2 servers are as reliable as the core and therefore
>just as capable of providing high quality feeds to both IGates and
>clients.
Again, mistaken identity, my apology.
As I say, it may well be that it is now as reliable. I know that at one
point it most certainly was not, and still, from a conceptual standpoint,
adding more servers in a path between any two stations is something likely
to decrease the reliability.
Let me once again reiterate the issue as I see it. There is a finite,
though small, possibility for any link between two servers to be down.
Given this, the perfect system would be a single server, with unlimited
horsepower, bandwidth, and absolute reliability.
Obviously this isn't possible, so we need a system with multiple servers.
Since we must depend on inter-server links, the most reliable topology is
one which requires a packet never need to travel more than a single link.
Furthermore, a monitoring system should be in place which checks the
function of each link.
The design of the present core meets this...any two people connected to the
core will have the packet travel through a maximum of one inter-server
link. Furthermore, each, and every inter-server link between the four
servers is individually monitored by one line in my server stats page. So,
if there is a problem, it can be detected and repaired quickly.
The tier 2 servers connect to the core, and also now to each other in an
arrangement analagous to the core. This latter interconnection does reduce
the maximum path length a packet could traverse, an improvement from their
original design, but a packet might still have to pass through 2 server
interconnects rather than one, DOUBLING the chance of an error.
Furthermore, there is no monitoring of the interconnects on the tier 2
servers, increasing the likelihood a problem may go undetected longer.
>As to the number of servers that a packet goes through to get to the
>"other side", there is a greater potential for problems due to the
>increased number of computers that the packet goes through. Of course,
>this is true for the Internet as a whole. A simple trace of an IP
>packet route will show that most routes go through a minimum of 10
>routers (usually 15 or more). In fact, with the non-core and core
>servers keeping their software up-to-date, placing multiple servers in
>the path does not increase the likelihood of lost packets.
I could not disagree more strongly. Any increase in path length increases
the possibilty for packet loss. Would you pick an ISP that doubled your
path, say 30 routers when you could have one with only 15? Do you think the
performance and reliability of these two ISP is really the same?
Even more significant, though, is that the analogy is flawed. If I'm using
routers to send packets from point A to point B, and there is a problem, I
know it, because I will not get the ACK back stating that my packet was
recieved at the destination. The APRS IS does not have such a system, so
the user will never know his packets are getting dropped because of a bad
link. A better analogy would be UDP rather than TCP, imagine the mess if
everyone on the internet changed from TCP to UDP!
TCP has its own monitoring built in...if a packet doesn't get through, you
don't get an ACK back. APRS IS core has its monitoring, available for all
to see. Tier 2 has no such monitoring.
>Once again, I stand by my statement that your continual baseless
>discouraging of the use of non-core servers is counterproductive to
>APRS-IS and is alienating to those people (the majority of connections
>to APRS-IS are via non-core servers) that run and use those servers.
Hopefully this repeat of my reason for advocating a single tier server
system has made it clear that in fact I do have a solid base for advocating
this design.
And once again, my apology for not paying more attention to who was saying
what.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: ATTN users in Bowling Green, KY
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 27 Aug 2003 11:11:28 -0400
X-Message-Number: 11
On 8/27/03 at 10:34 AM Michael J. Wolthuis <wolthui3@msu.edu> sent:
>The following happened to make it into my system today via what appears
>to be a band opening, but either way KY should pry check this out.
>
>map.findu.com/7193LV
>
>I can not find a valid amateur radio call on it anywhere. Maybe I am
>missing something, but it doesn't appear tactical to me either.
Can't say why he is doing it, but his comment contains his call KF4QZN:
http://findu.com/cgi-bin/raw.cgi?call=7193LV&time=1
Quite legal, since it appears he is sending the call every three minutes.
More interesting though is he seems to be sending a position every few
seconds!
Go get him, guys!
Steve K4HG
----------------------------------------------------------------------
Subject: Rules Question... Was Re: ATTN users in Bowling Green, KY
From: "Mike Yetsko" <myetsko@insydesw.com>
Date: Wed, 27 Aug 2003 11:23:22 -0400
X-Message-Number: 12
>>map.findu.com/7193LV
>>
>>I can not find a valid amateur radio call on it anywhere. Maybe I am
>>missing something, but it doesn't appear tactical to me either.
>
>It is a ham. I also happen to know that it's their license plate.
You know, from a 'security' standpoint, I would be more concerned about
broadcasting my license plate than my HAM call! But if you have ham
plates, then what's the difference?
And you know, this does bring up an issue... The FCC does not require
us to ID in the mode in which the 'meat' of the communications is taking
place. Perhaps maybe that shouldn't be the case.
I know, I know, there are exceptions. There may be times where the ID
in the data field would be an issue, or where you were doing RC, or other
telemetry.
But I wonder... IF there were to be a rule change...
Would it be best if the rules say ID in the 'main format' with exceptions?
Or would it be better to say "In these cases the main format should contain
the ID"?
Or even if the 'main format' has provisions for an ID, it should be used
to ID the transmission unless there are overriding concerns?
Or... Should the rules be left alone?
Mike
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
