| |
ZL3AI > APRDIG 21.01.07 21:42l 268 Lines 9535 Bytes #999 (0) @ WW
BID : 9584-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 31 #20, 3/3
Path: DB0FHN<DB0MRW<DB0ERF<DB0EAM<DB0SMG<DB0RES<DK0WUE<SP7MGD<VE2PKT<ZL2BAU
Sent: 070120/0306Z @:ZL2BAU.#79.NZL.OC #:28068 [Waimate] $:9584-ZL3AI
From: ZL3AI@ZL2BAU.#79.NZL.OC
To : APRDIG@WW
Message: 14
Date: Thu, 18 Jan 2007 06:49:33 -0800 (PST)
From: "Curt, WE7U" <archer_at_eskimo.com>
Subject: RE: [aprssig] New Local Info Initiative
On Thu, 18 Jan 2007, Dave Baxter wrote:
>I think you hit the nail on the head with....
>
>"...to tell the passing traveler exactly what one-and-only-one local
>repeater is best for the visiting traveler..."
>
>I suspect local politics will come into play, and there will never be a
>decision as to "which is best" etc.
>
>Cynicaly...
Hah! Well, maybe that would encourage those that don't like the particular
transmission to get trained up and equipped for APRS so that they can send
a competing object. More people into APRS!
He that has the equipment/knows how to use it makes the rules in this case.
;-)
--
Curt, WE7U. APRS Client Comparisons: http://www.eskimo.com/~archer
"Lotto: A tax on people who are bad at math." -- unknown
"Windows: Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
------------------------------
Message: 15
Date: Thu, 18 Jan 2007 07:44:46 -0800
From: "Phillip B. Pacier" <ad6nh_at_arrl.net>
Subject: Re: [aprssig] Periodic Disconnects from APRS-IS
Ah! One of the main reasons why Tier 2 was created! Pete's link below has
some of the Tier 2 servers available listed, but for a more complete list,
visit www.aprs2.net. We also have a UI-View type list created for easy
download. Use the URL: france.aprs2.net/APRServe2.txt - though I agree
with Pete that we should all be creating our own server lists for our own
needs.
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.
73
Phil - AD6NH
------------------------------
Message: 16
Date: Thu, 18 Jan 2007 11:07:21 -0500
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: RE: [aprssig] buoys...
>I assume that since you're only interested in Chesapeake Bay,
>you have sufficient coverage if you have an antenna for a
>digi up a hundred feet or so?
>
>You probably couldn't for instance, track an ambitious sea
>kayaker down the entire Pacific Coast, using the terrestrial
>APRS network.
Well, with the height of those mountains out there, I would think it would
be quite reliable out several miles. The only problem is the QRM on the
channel and the power that the Kayak would run. A tracker with a 30W amp
would be nice. The TX average power for 1 sec once every 2 minutes is only
1% of normal TX power, and so it does not take very much battery capacity
(just peak current).
Bob, Wb4APR
------------------------------
Message: 17
Date: Thu, 18 Jan 2007 10:18:02 -0600
From: "AE5PL Lists" <HamLists_at_ametx.com>
Subject: RE: [aprssig] Periodic Disconnects from APRS-IS
So no one is confused: my posts are regarding client connections to full
APRS-IS feeds where many (probably most) clients are not able to handle the
full feed. I am recommending people use any server's filtered port (core,
tier 2, or other) in preference over a full feed so their client will
perform better and not be subject to disconnects due to the client being
overwhelmed.
73,
Pete Loveall AE5PL
pete at ae5pl.net
------------------------------
Message: 18
Date: Thu, 18 Jan 2007 09:08:59 -0800
From: "Scott Miller" <scott_at_opentrac.org>
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
keeps the stream from getting held up in the TCP buffers. But for a full
feed, it seems like you'd be better off offering a port that'd send a
maximal length packet to reduce overhead. Should reduce the packet count by
about a factor of 10.
I don't know about Java's socket support, but I think in C it was a pretty
simple configuration option. Again, it's not what you want for everything,
but it seems like an easy way to save bandwidth.
Scott
N1VG
------------------------------
Message: 19
Date: Thu, 18 Jan 2007 09:14:29 -0800
From: "Frank Keeney" <kg6jve_at_gmail.com>
Subject: RE: [aprssig] GPS from Sprint data card
I'm not finding this GPS "feature" on my Merlin S620
Frank Keeney
Blog: http://www.unwiredadventures.com
Photos: http://snurl.com/unwirephotos
>-----Original Message-----
>From: Earl Needham
>
>The Novatel Merlin S720.
------------------------------
Message: 20
Date: Thu, 18 Jan 2007 12:22:37 -0500
From: Steve Dimse <steve_at_dimse.com>
Subject: Re: [aprssig] Periodic Disconnects from APRS-IS
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.
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.
Steve K4HG
------------------------------
Message: 21
Date: Thu, 18 Jan 2007 11:29:49 -0600
From: Gregg Wonderly <gregg_at_wonderly.org>
Subject: Re: [aprssig] Periodic Disconnects from APRS-IS
Scott Miller wrote:
>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
>keeps the stream from getting held up in the TCP buffers. But for a full
>feed, it seems like you'd be better off offering a port that'd send a
>maximal length packet to reduce overhead. Should reduce the packet count by
>about a factor of 10.
>
>I don't know about Java's socket support, but I think in C it was a pretty
>simple configuration option. Again, it's not what you want for everything,
>but it seems like an easy way to save bandwidth.
In Java, you can just use a BufferedWriter or BufferedOutputStream to make
sure that writes are optimized. I've been using the jdk1.5 concurrency
tools so that I can use a queue to stuff the outbound packets into, and
then just dequeue and write through a buffered outputstream, flushing when
the queue is empty.
Something like the following is a simple example without any attempts to
manage CR/LF in any special way.
PrintStream out = new PrintStream( new BufferedOutputStream(
sock.getOutputStream() ) );
LinkedBlockingQueue<String> queue = new LinkedBlockingQueue<String>();
String pktln;
boolean done = false;
while( !done ) {
pktln = queue.take();
out.println(pktln);
if( queue.peek() == null )
out.flush();
}
Gregg Wonderly
W5GGW
------------------------------
Message: 22
Date: Thu, 18 Jan 2007 11:43:23 -0600
From: "Bruce W. Martin" <aprs_at_almostanywhere.com>
Subject: Re: [aprssig] New Local Info Initiative
On Jan 18, 2007, at 8:49 AM, Dave Baxter wrote:
>I think you hit the nail on the head with....
>
>"...to tell the passing traveler exactly what one-and-only-one local
>repeater is best for the visiting traveler..."
>
>I suspect local politics will come into play, and there will never be a
>decision as to "which is best" etc.
It would seem that the DIGI owner will have the deciding vote even if
it is his one vote against 20 others.
Bruce
--
Bruce W. Martin, KQ4TV
Trustee for NT4UX
Nashville Linux User Group - Amateur Radio- Special Interest Group
NLUG-AR-SIG
------------------------------
aprssig mailing list
aprssig_at_lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
End of aprssig Digest, Vol 31, Issue 20
Read previous mail | Read next mail
| |
