[aprssig] Tier 2 Status
AE5PL Lists HamLists at ametx.comThu Jun 22 11:13:01 UTC 2006
- Previous message: [aprssig] Tier 2 Status
- Next message: [aprssig] Tier 2 Status
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> -----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
- Previous message: [aprssig] Tier 2 Status
- Next message: [aprssig] Tier 2 Status
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
