| |
ZL3AI > APRDIG 21.01.07 22:51l 257 Lines 11364 Bytes #999 (0) @ WW
BID : 9591-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 31 #21, 1/4
Path: DB0FHN<DB0MRW<DK0WUE<DB0RES<F5GOV<F4BWT<IW2OAZ<ZL2BAU
Sent: 070121/0515Z @:ZL2BAU.#79.NZL.OC #:28313 [Waimate] $:9591-ZL3AI
From: ZL3AI@ZL2BAU.#79.NZL.OC
To : APRDIG@WW
Today's Topics:
1. Re: Periodic Disconnects from APRS-IS (Jason Winningham)
2. RE: Periodic Disconnects from APRS-IS (AE5PL Lists)
3. RE: GPS from Sprint data card (Earl Needham)
4. PCSAT-1 critical (Robert Bruninga)
5. Re: Periodic Disconnects from APRS-IS (Phillip B. Pacier)
6. Re: Periodic Disconnects from APRS-IS (Chris Howard)
7. RE: Periodic Disconnects from APRS-IS (Scott Miller)
8. RE: Periodic Disconnects from APRS-IS (Scott Miller)
9. Setting up a KPC-3+ with a Davis WX station (Stephen Brown Jr)
10. RE: Periodic Disconnects from APRS-IS (Chris Howard)
11. Re: Periodic Disconnects from APRS-IS (Joel Maslak)
12. RE: Periodic Disconnects from APRS-IS (AE5PL Lists)
13. Re: Periodic Disconnects from APRS-IS (Kurt A. Freiberger)
14. RE: Periodic Disconnects from APRS-IS (Scott Miller)
15. RE: Periodic Disconnects from APRS-IS (tvsjr)
16. Re: Setting up a KPC-3+ with a Davis WX station (Stephen H. Smith)
17. RE: 315 is dead :( (Dave Baxter)
18. RE: Periodic Disconnects from APRS-IS (AE5PL Lists)
19. RE: Setting up a KPC-3+ with a Davis WX station (Robert Bruninga)
20. Re: Periodic Disconnects from APRS-IS (Richard Montgomery)
21. Re: Periodic Disconnects from APRS-IS (Gregg Wonderly)
22. RE: Periodic Disconnects from APRS-IS (AE5PL Lists)
----------------------------------------------------------------------
Message: 1
Date: Thu, 18 Jan 2007 12:52:03 -0600
From: Jason Winningham <jdw_at_eng.uah.edu>
Subject: Re: [aprssig] Periodic Disconnects from APRS-IS
On Jan 18, 2007, at 11:08 AM, Scott Miller wrote:
>I don't know about Java's socket support, but I think in C it was a pretty
>simple configuration option.
I seem to recall the developers take some care to make sure they _disable_
buffering to avoid excessively delayed delivery (to the IS) that can result
in the duplicate suppression to fail.
There are conflicting needs here: large downlinks with good throughput for
downlinks vs. small uplinks with low latency tolerance. Not sure what the
answer is, but a filtered feed will significantly reduce the bandwidth
requirement on the downstream side of the connection.
-Jason
kg4wsv
------------------------------
Message: 2
Date: Thu, 18 Jan 2007 13:28:52 -0600
From: "AE5PL Lists" <HamLists_at_ametx.com>
Subject: RE: [aprssig] Periodic Disconnects from APRS-IS
This has nothing to do with programming language or how TCP works. This
has to do with what APRS is: a near real-time reporting system, and what
APRS-IS is: a very basic APRS packet transport system built originally on
TCP. Yes, it is very inefficient because the Nagel algorithm is turned off
(nothing to do with what language clients or servers are programmed in).
The Nagel algorithm has to be turned off if significant delays are not to
be incurred due to buffering of packets (which is what we saw a few years
ago before we started turning off the Nagel algorithm). Hope this clears
up why the protocol is inefficient and why it will stay that way when using
TCP.
Also, my posts had nothing to do with bandwidth at the server. The
bandwidth issue I spoke of is at the client and is primarily a processing
issue in the client software although it can also be problematic for
limited bandwidth residential configurations.
73,
Pete Loveall AE5PL
pete at ae5pl.net
>-----Original Message-----
>From: Scott Miller
>Posted At: Thursday, January 18, 2007 11:16 AM
>Subject: RE: [aprssig] Periodic Disconnects from APRS-IS
>
>Last time I looked at a TCP dump of an APRS-IS connection, it seemed to be
>making rather inefficient use of the bandwidth. I saw exactly one line per
>packet. For slow ports (message only, local filters) this is fine - it
------------------------------
Message: 3
Date: Thu, 18 Jan 2007 13:52:01 -0700
From: Earl Needham <needhame1_at_plateautel.net>
Subject: RE: [aprssig] GPS from Sprint data card
It isn't there, it's only on the S720 and the U720 USB card".
7 3
Earl
At 10:14 AM 1/18/2007, Frank Keeney wrote:
>I'm not finding this GPS "feature" on my Merlin S620
------------------------------
Message: 4
Date: Thu, 18 Jan 2007 16:18:21 -0500
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: [aprssig] PCSAT-1 critical
PCSAT-1 just crashed due to overload of users at 2110z on the 18th.
Fortunately I heard it during a pass, and was able to quickly restore the
low power settings before eclipse. But if PCSAT resets without a control
operator in view, we will lose PCSAT-1 for the next two months until the
March full sun period.
As of this moment, I turned off all alias digipeating to cut down on the
load to see if she will make it through eclipse. We ask all users to
adhere to the following situation:
1) Cease all operations at night
2) Limit your packets during the day to minimum to make contact
3) Never digipeat VIA W3ADO-1
The only exception to the rule #1 is for new users who have not had the
chance to try PCSAT-1 from their mobile D7 or D700 radio, to set an
overnight beacon at a 5 minute rate to see if they capture any packets
overnight. Since I turned off all aliases, such users participating in
that experiment will have to set their PATH to VIA PCSAT-1.
Bottom line. PCSAT-1 has had a great run since 1 January with over 100
users per day showing up on the web page http://pcsat.aprs.org. And we can
continue this operation as eclipses get longer and longer as long as we do
not overload it. The load she has been seeing the last week is not
sustainable.
We welcome activity, but need to reduce the load. Please cut back on y our
transmission rates.
If you see the callsign W3ADO-1 it means a reset.
If you see the callsign PCSAT-11 on 145.825, it means a reset
If you see the callsign W3ADO-1 on 144.39 over the USA, it means a reset.
If any sysop sees these conditions, please logon and restore PCSAT-1 to
low-powerbudget opertions.
Thanks
Bob, Wb4APR
------------------------------
Message: 5
Date: Thu, 18 Jan 2007 18:11:40 -0800
From: "Phillip B. Pacier" <ad6nh_at_arrl.net>
Subject: Re: [aprssig] Periodic Disconnects from APRS-IS
Steve Dimse wrote:
>
>On Jan 18, 2007, at 10:44 AM, Phillip B. Pacier wrote:
>
>>Ah! One of the main reasons why Tier 2 was created!
>
>Pete's post had nothing to do with Tier 2.
>
>This is a client issue, not a hub issue. The APRS IS stream has
>reached the point where some people's computer/software/internet
>connection cannot keep up with the full stream. This causes no
>problems for the hub. Pete's point was those people with this trouble
>should use a filtered feed, which is just as available on the core as
>on your servers. Many people want a full feed, and have systems that
>can handle it, and the core provides them the option to receive it there.
>
>People can make their own choice where they connect, but if you are
>going to turn every post involving the APRS IS into a commercial for
>your system, I will use it to remind people that the leaders of Tier 2
>have in the past demonstrated their contempt for their users by
>cutting off access to thousands of weather sites without warning,
>using them as pawns in a failed power play.
Ah, these emails are spinning so fast I need to take some Dramamine! Well,
I do appreciate the opportunity you open up to set the record straight.
Thanks!
Tier 2 is as reliable as ever, with well over 1,000 clients currently
connected. Our server uptimes are unmatched, and obviously the opinion of
1,000 plus users speaks for itself. To address the alleged cut-off of
access to thousands "weather sites" [?] without warning, nothing of the
such occurred with the malice that is being portrayed. Steve, you yourself
have been asking for years that the CW users be "released" (as if we had
them in a harness?) to you for over two years now. When we finally
complied, you couldn't handle it, were unprepared to handle it, or your
core service couldn't handle it, or a combination of those scenarios. When
we saw what was happening, and that the CW clients were continuing to
attempt to connect to our servers, we turned them back on. They will
remain on despite the propaganda and lies about our service posted now on
the CWOP web pages. Our attempt to comply with your request is what caused
thousands of station's data to be lost for less than a day's time. That is
all that happened, no matter how you try to spin it. We have been service
oriented from day one over five years ago when we saw the stress at the
core servers and sought a solution to resolve it. We have also made
several attempts to work with the core servers over the years, and all we
get is this spin, propaganda, and personal attacks. I'm always ready to
work with the core service sysops, but not under these present conditions.
Fortunately, when this lack of cooperation on the part of the core service
has ended up in a loss of quality of service to our clients, we have been
able to devise our own methods of dealing with the issues.
This post was not a commercial for Tier 2. Users can and will connect
where they believe the best service is available. 35 servers and 1,000+
users (and 3,000+ CW clients) later, I think our service and quality speak
for itself. I don't need to run commercials - again, the 1,000+ clients
choose for themselves where to connect. I merely stated that Tier 2 was
created out of the basis of the problem being discussed, and that the list
of Tier 2 servers on Pete's web list is incomplete, and the address to find
the complete information is available at www.aprs2.net. If you want a full
feed, connect to the core servers and I wish you the best of luck. If/when
it fails you, feel free to connect to a filtered feed at the core servers
or at Tier 2. Our servers are open and welcome to anyone who wishes to
connect. I never imagined having this much support. I guess it goes to
show we're doing something right!
>On the other hand, the core has plenty of capacity, with high
>reliability servers housed in professional data centers, and with
>operators that express the highest ideals of amateur radio,
>professionalism and service.
>
>>It should also be pointed out that round-robin DNS does not account
>>for a server becoming suddenly unavailable. If a server in the list
>>becomes unavailable, until the DNS zone file is updated and all of
>>the caching is reset, that server's IP will still be issued on the
>>pseudo-random basis. There is rotate.aprs.net and there is also
>>rotate.aprs2.net, but I recommend not using them for any reason.
>
>If a client has the ability to specify a list of servers, that is the
>preferred way. However, if the client only allows a single name, then
>rotate.aprs.net is much better than picking a single server's name.
>The core situation is monitored very closely, with human as well as
>automated means, and when a change is needed in rotate.aprs.net, it is
>made quickly.
Good point. I don't know of too many clients that only allow for one
server name to be entered, but that is certainly a situation where rotate
is useful, and also why Tier 2 has available rotate.aprs2.net. Again, users
can make their own decisions and I encourage all users to educate
themselves enough so that they can make their own decisions!
Thank you all for your time. 73!
Phil Pacier - AD6NH
Tier 2 Coordinator
www.aprs2.net
------------------------------
Read previous mail | Read next mail
| |
