| |
ZL3AI > APRDIG 31.08.03 10:31l 449 Lines 18349 Bytes #999 (0) @ WW
BID : 1841-ZL3AI
Read: GUEST
Subj: TAPR Digest, Aug 27, 3/7
Path: DB0FHN<DB0RGB<DB0MRW<OK0PKL<OK0PHL<SR6BOX<SR7BBS<SP7MGD<ZL2TZE<ZL3VML
Sent: 030829/1414Z @:ZL3VML.#80.NZL.OC #:7297 [Chch-NZ] FBB7.00i $:1841-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: ATTN users in Bowling Green, KY
From: "Mike Yetsko" <myetsko@insydesw.com>
Date: Wed, 27 Aug 2003 11:24:58 -0400
X-Message-Number: 13
>>map.findu.com/7193LV
>
>Go get him, guys!
Geesh, you have his call, a position every few seconds, and even his car
license plate! The only thing missing is the make and model of his
vehicle!
Mike
----------------------------------------------------------------------
Subject: Re: ATTN users in Bowling Green, KY
From: "Bruce Martin, KQ4TV" <aprssig@almostanywhere.com>
Date: Wed, 27 Aug 2003 10:36:50 -0500
X-Message-Number: 14
On Wednesday, August 27, 2003, at 10:24 AM, Mike Yetsko wrote:
>>>map.findu.com/7193LV
>>
>>Go get him, guys!
>
>Geesh, you have his call, a position every few seconds, and even his
>car
>license plate! The only thing missing is the make and model of his
>vehicle!
>
>Mike
I think it is Black, 2002 Chevy, Silverado, Extended cab, pickup truck.
----------------------------------------------------------------------
Subject: RE: New fourth.aprs.net
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Wed, 27 Aug 2003 11:19:21 -0500
X-Message-Number: 15
See below...
>-----Original Message-----
>From: Steve Dimse [mailto:k4hg@tapr.org]
>Posted At: Wednesday, August 27, 2003 10:10 AM
>Subject: [aprssig] RE: New fourth.aprs.net
>
>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. javAPRSSrvr's history port provides a full feed with a X
minute (X set by the sysop) dump of the last posit/object heard for each
station/object. This has nothing to do with buffering and I would
recommend that you no longer use that term to describe a history port as
it is inaccurate. If you don't like history cache or history dump, try
archive. At least "archive" represents what really is being sent.
>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.
Not true. Adding servers can actually increase reliability due to
routing, buffering, and dupe check issues.
>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.
Your monitoring system has nothing to do with how links are restored.
Your monitoring system only reflects whether all the servers are passing
the same packets and does not monitor the inter-server links.
>arrangement analagous to the core. This latter
>interconnection does reduce the
>maximum path length a packet could traverse, an improvement
Not really. That is not how port 1313 interconnects work and reducing
the number of servers a packet goes through really has nothing to do
with why they interconnect. In fact, I have never promoted
interconnection of non-core servers due to the complexity of maintaining
the lower level mesh networks.
>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.
You talk as if each server is going to introduce errors. This is simply
not the case. If the software is going to introduce errors, it will
through a single server and adding servers does not increase the
chances. We use TCP/IP for our connections and all are supported by a
full ack protocol.
>Furthermore, there is no
>monitoring of the interconnects on the tier 2 servers,
>increasing the likelihood
>aproblem may go undetected longer.
You may not monitor tier 2 interconnects (and you don't monitor core
interconnects either), but their sysops do.
>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?
Do you have any idea of how your packets are routed on the Internet?
You don't have any control. As I have said before, the performance and
reliability of the tier 2 servers is currently equal to the core servers
with regards to delivering the services that they do.
>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
>aproblem, 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!
Not true. We use TCP between all servers and therefore the same
mechanism that exists for routers exists for our servers (BTW, a router
is simply a network capable computer with specialized software).
>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.
No, as shown above, you have distorted actual network operation to try
to support your case. The people running aprsD, AHub, and javAPRSSrvr
as non-core servers provide beneficial services which can be utilized by
all APRS-IS users. The tier network design in APRS-IS has existed ever
since the day you opened up APRS-IS to non-core servers. And, the
tiered network design has been proven to provide many network, service,
and reliability advantages over a single core server design over and
over again in the history of all network design.
The core is important and having a reliable core is extremely important.
However, the core's reliability increases as loads are distributed to
non-core areas. It might be time for you to re-evaluate your "core
only" position and consider the benefits that a tiered network with a
reliable core bring to the APRS-IS community.
73,
Pete Loveall AE5PL
pete@ae5pl.net
"What ever happened to the IBM mainframe being the only computer in a
business?"
----------------------------------------------------------------------
Subject: Re: BEACON RATES
From: Gonzales Andy <agonzales@arc.nasa.gov>
Date: Wed, 27 Aug 2003 10:31:41 -0700
X-Message-Number: 16
Being new to ham and APRS but still recognizing that you could be
showing 6 miles separation, approaching, but actually be 0, and while
driving alone on I-5 to Eugene OR, from Sunnyvale, CA, here is what I
did:
I stopped at a convenient rest area and looked at my laptop to find a
potential "contact" heading towards me, and still about 15 miles
away. I set my warning radius to 8 miles and started off. When the
warning sounded I tried but "voice alert" with instructions to QSY
146.52 and also straight calls on ".52". No joy. I believe I even saw
a ham antenna pass at about the right time but did not get a contact.
I tried this on two different occassions with the same result. My
personal operating rules are that except for actual QSO's, I do not
actively operate any RF, GPS or PC equipment while driving alone so I
was not real agressive.
>On Tue, 26 Aug 2003, Randy Allen - KA0AZS wrote:
>
>> I run my D-700 at every 3 minutes normal mobile ops, and every 30
>> minutes when in my "Parked" mode.
>
>Hummh.. I just had a thought. I run mine at 2 minutes when mobile, but
>just realized that since I run Voice Alert, I can usually tell when
>someone else is nearby.
>
>What I should be doing is... everytime I hear a packet from someone
>nearby, I should hit my BCON button to toggle out a response packet. to
>match his. This way, we BOTH see the distance between us in real time.
>
>If you are running 3 minutes and I am running 2 minutes and we are in a
>passing situation (within feet of each other), Our radios could
>be showing as much as 5 miles apart even when we are within a mile of
>each other and closing...
>
>So I have often thought I need to be at 1 minute to be sure to get that
>fine detail when closing on someone, but now realize I can just keep it
>at the 2 or 3 minute rate and simply MANUALLY send out a few extra when
>close to someone....
>
>Hummh....
>
>Bob
--
Andy Gonzales
NASA / Ames Research Center
Moffett Field, CA 94035-1000
Bldg. N-244, Rm. 240
MS 244-19
agonzales@arc.nasa.gov
650-604-0309
----------------------------------------------------------------------
Subject: RE: New fourth.aprs.net
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 27 Aug 2003 14:03:24 -0400
X-Message-Number: 17
On 8/27/03 at 11:19 AM AE5PL Lists <HamLists@ametx.com> sent:
>See below...
>
>>-----Original Message-----
>>From: Steve Dimse [mailto:k4hg@tapr.org]
>>Posted At: Wednesday, August 27, 2003 10:10 AM
>>Subject: [aprssig] RE: New fourth.aprs.net
>>
>>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. javAPRSSrvr's history port provides a full feed with a X
>minute (X set by the sysop) dump of the last posit/object heard for each
>station/object. This has nothing to do with buffering and I would
>recommend that you no longer use that term to describe a history port as
>it is inaccurate. If you don't like history cache or history dump, try
>archive. At least "archive" represents what really is being sent.
>
>From dictionary.com:
3. Computer Science. To hold or collect (data) in a buffer.
This is exactly what APRServe, and later javAPRSrvr, do. They collect the
data, and when a user connects to that port, they get a dump of the buffer.
Just to prove that in fact this is a term in use in connection with
APRServe from the beginning, here is my original paper on APRServe
presented at the DCC in 1997:
http://www.aprs.net/vm/DCC97/aprserve.htm
"5. There should be a buffer of data to allow the immediate transmission of
all known information to a newly connected client. "
Sorry that you object to the terminology I chose 6 years ago, I hope you
can forgive me for not changing based on your personal preferences.
>>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.
>
>Not true. Adding servers can actually increase reliability due to
>routing, buffering, and dupe check issues.
I disagree strongly. Remember that the APRS IS is not like TCP, or IP
multicast protocols. TCP is point to point, and multicast is point to
everywhere. APRS IS is everywhere to everywhere...data enters at many
points, and the idea is to get data to everywhere that enters anywhere in
the system, and have no looping occurring.
In a TCP system, it is indeed nice to have multiple routes between two
destinations, that can indeed increase reliability. Same with multicast.
In the APRS IS though, given that a station is conencted at some point,
there is only one path for a packet to reach any core or other hub. This is
done through the use of port 1313, which sends data which enters a given
hub, and not sending the rest of the stream (which includes the data that
server already has).
Adding a spiderweb of interconnects in this case DOES NOT make it less
likely that a data point will get dropped, because there is still just a
single route that a packet will take to get to the servers. Yes, it makes
it more likely a packet will be seem SOMEWHERE, but not that it will be
seen EVERYWHERE, which is the goal of the APRS IS.
With the system as implemented, the greatest reliability would be with the
fewest number of links and the greatest monitoring of those links. Nothing
in the design of the second tier can change this fact.
Could the system be designed so that more connections meant greater
reliabilty? Sure, but then the system becomes totally reliant on the
software to reject all duplicate packets. Imaging this situation:
20 hubs or more, all connected to a few (or even all) of the others. The
connections are not using unvalidated port 1313 as presently on both core
and tier 2 networks, but validated full feeds. What happens? Well, each
server gets multiple feeds of the full stream, in the even of a hub
connected to all 19 others, 18 incoming streams are essentially wasted,
hopefully to be removed by the dup-checking routine. Now if something
happens in any of the links, there are still a multitude of other paths a
packet could use get to everybody.
This is do-able, though inefficient, the danger is that the dup checking
must be perfect to prevent loops.
Or, you could use levels...say one level is the core as it exists now, then
a couple of "masters" that read each server's stream, and when they see
something on one that doesn't appear on another in a few seconds, then send
it to where it is missing.
Or, you could combine these two...many hubs randomly interconnected, and
use the same "master" algorithm, but built into each of the hubs, where
data is sent upstream whenever it arrives from one source but is not seen
on another. Again, the risk is looping, but it is a little more efficient,
at the cost of additional programming.
There are probably many other ways the APRS IS could be made more reliable,
these are just off the top of my head. However, adding a second tier,
without increasing the paths a packet can take to reach the other hubs,
does nothing to increase reliability, and in fact decreases it on a simple
mathematical basis, as there are more things to go wrong.
>>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.
>
>Your monitoring system has nothing to do with how links are restored.
>Your monitoring system only reflects whether all the servers are passing
>the same packets and does not monitor the inter-server links.
That shows you do not understand what I am monitoring. For example, one
link in the core network is the 1313 connect initiated by second to first.
On that link second gets packets which enter the APRS IS core at
first...primarily those that are sent on validated connections to first,
but could also be packets from a modem attached to first's aprsd program
(obviously not an issue for 2,3, and 4 because your program does not have
the IGate function). A failure in this link will appear as increased
numbers on the first line of the stream statistics table.
There is no other failure that could account for high error rates
there...the low error rates that are seen are filtering differences between
the programs and the occasional packet that has a long propagation delay.
In other words, there is an exact 1:1 correspondence between each link
within the core network, and each line on the stream stats page.
>>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.
>
>You talk as if each server is going to introduce errors. This is simply
>not the case. If the software is going to introduce errors, it will
>through a single server and adding servers does not increase the
>chances. We use TCP/IP for our connections and all are supported by a
>full ack protocol.
Each server doesn't introduce errors, but it does increases the chance for
an error (namely a bad link or a crashed server) to occur. If more servers
increases the ability for the system to function if one goes down, then it
is a good thing, but the second tier does nothing to provide another path
in the event of a failure somewhere in either tier.
>>Furthermore, there is no
>>monitoring of the interconnects on the tier 2 servers,
>>increasing the likelihood
>>aproblem may go undetected longer.
>
>You may not monitor tier 2 interconnects (and you don't monitor core
>interconnects either), but their sysops do.
As I explained above, my server stats page absolutely monitors the
interconnects.
Perhaps their sysops do monitor their interconnects privately, but I find
it interesting that the core server stats page monitors the performance of
the its servers, while the tier 2 stats page monitors the number of
connections to its servers. In the last couple hours, Dick has locked findU
out of port 10152, making even the kludge comparison I had been doing
between first and his server impossible. I find this very interesting...is
there something to hide?
>>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
>>aproblem, 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!
>
>Not true. We use TCP between all servers and therefore the same
>mechanism that exists for routers exists for our servers (BTW, a router
>is simply a network capable computer with specialized software).
No, you are mixing layers. Yes, the connection between users and a hub, or
between the hubs, follows TCP protocol. This discussion concerns the
logical flow of data within the APRS IS. The Internet is the transport
mechanism that each of these links uses, these links are reliable, but not
perfect, there is a small but non-zero chance for failure in each router
the packet must pass. That routers, the Internet, and TCP are as reliable
as they are is the reason that there is not a large decrease in reliability
when you connect to a properly configured tier 2 server, 2 times a very
small number is still a very small number, but it still is twice as large
as it was.
You say that tier 2 servers make the network more reliable. Please, give me
an example of a failure that the tier 2 servers prevent.
Steve K4HG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
