Order Tray | Contact Us | Home | SIG Lists

[aprssig] Tier 2 Status

AE5PL Lists HamLists at ametx.com
Thu Jun 22 11:13:01 UTC 2006


> -----Original Message-----
> From: Steve Dimse
> Posted At: Wednesday, June 21, 2006 10:06 PM
> Subject: Re: [aprssig] Tier 2 Status
> 
> Do you need capacity the number of people that connect to the 
> APRS in a 30 day period, or do you need to support those that 
> connect at the same time (plus a reasonable excess margin and 
> redundancy). For example, there have been 2205 CW reports in 

You need to be able to handle PEAK connections plus growth.  That is not
determined by taking a one hour snapshot and saying "that's the way it
is".

> data for a couple seconds and disconnect. Do you need to have 
> capacity for each of them to be connected constantly?

You have to take peaks.  Sometime talk to Dick about how many
connections he gets on the hour.  The throughput requirement is not just
tied to APRS data.  It is TCP/IP packets and the equivalent stack
overhead.  Every connect takes multiple packets plus every APRS packet
takes a respective ack due to the Nagle algorithm needing to be disabled
for APRS type data.  This is another reason why your numbers are way off
base.

> I can see where you got that number if you are using the q's, 
> but the great majority of those will be CW connections that 
> are simply not the same as a 24/7 IGate! Call me myopic if 

No, as I write this there are 5,446 HAM stations that have been
connected to APRS-IS over the past 30 days.  In addition, there were
2,773 CW stations connected over the past 30 days.  Even so, a 24/7
IGate may not generate as many packets as some of those CW stations
because of the TCP/IP overhead.

> has adequate followup yet!) but if you think the APRS IS 
> needs to have a dedicated connection for everyone that 
> connects once a month, you are grandiose! We should be 
> talking about the maximum number of simultaneous connections, 
> not the number of people spread out over a long, arbitrary time frame.

I am figuring on the peak as well as the average loads. Its called
"capacity planning" to those of us in networking fields.

> Where's the exponent? The problem is linear, n servers equals 
> n sysops, each of whose hub has n-1 connections to other 
> hubs. If managers where really afraid of linear increases in 
> complexity, we'd all still be living in villages!

Not linear but work the numbers any way that meets your agenda...

> If you are talking about the number of APRS (not CW) users, 
> I'd say even less.

As shown above, the 5000+ number was for ham stations (not CW).  BTW,
isn't CW APRS?

> As I say, EVERY time I have needed a site, I've gotten 
> multiple offers from very good sites, people that in fact do 
> have total control (like CTOs of large co-lo sites). Every 
> offer I have accepted has turned out to be real (and don;t 
> think I don;t lose a little sleep shipping an $8k server to 
> someone I never heard od before!) So whatever the percentage 
> is, it is adequate.

Every time?  And you shipped $8k servers to which core sysops for core
server use?  None.

> Again, I am not trying to convince you, or anyone else. I do 
> believe that the two tier system is inefficient, and my 
> purpose in jumping in here was to make it clear this is not 
> the way I designed the system, and that I do believe it could 
> be run more logically as a single core system.

There is nothing "inefficient" in a multitiered network.  That is the
same as saying "a distributed server system is inefficient so we need to
go back to mainframes for all our processing".  I remember IBM stating
that the 360 would take care of all our computing needs.  It didn't and
thank goodness our networks today incorporate distributed servers or
most businesses would still be in the pre-technology age.

As to your "design" (and I use that term loosely) of APRS-IS, the
multitiered network was in place long before I ever showed up on the
APRS server software scene (aprsD, AHub, even multiple APRServe
servers).  In fact, the javAPRSSrvr implementation greatly reduced
issues such as looping by restricting configuration issues your "design"
didn't account for.

> The fact is, it does work, and well. I just want to be able 
> to say "I told you so" when it stops working ;-)

Well, let's see.  It wasn't working when I started the javAPRSSrvr
project and it is working now.  Hmm, who should be able to say "I told
you so"?

73,

Pete Loveall AE5PL
mailto:pete at ae5pl.net 




More information about the aprssig mailing list