| |
ZL3AI > APRDIG 21.01.07 22:51l 177 Lines 7210 Bytes #999 (0) @ WW
BID : 9594-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 31 #21, 4/4
Path: DB0FHN<DB0MRW<DK0WUE<DB0RES<F5GOV<F4BWT<IW2OAZ<ZL2BAU
Sent: 070121/0515Z @:ZL2BAU.#79.NZL.OC #:28315 [Waimate] $:9594-ZL3AI
From: ZL3AI@ZL2BAU.#79.NZL.OC
To : APRDIG@WW
Message: 18
Date: Fri, 19 Jan 2007 05:51:33 -0600
From: "AE5PL Lists" <HamLists_at_ametx.com>
Subject: RE: [aprssig] Periodic Disconnects from APRS-IS
Scott,
This thread you created is dead. RFC896 defines the Nagle algorithm, but
doesn't show (as it shouldn't) the net effects. I have told you what the
net effects are and what the studies done by numerous other network experts
have shown but you refuse to accept this. So, simply put: APRS-IS servers
and clients should and do disable the Nagle algorithm and should not buffer
packets. This is a non-issue and simply a distracter from the content and
intent of my original post. You can continue your posts on this subject
but as far as I am concerned the subject is dead because it is not going to
change.
My original post, which you have successfully distracted me from, bears
repeating: if your client is unable to keep up with the full stream,
whether because of the high amount of processing it has to do (most common)
or because of the limited bandwidth you have, please consider switching to
a server filter port (most servers support port 14580 as a user-defined
filter port). You will find your connections will be more reliable and
your client more responsive with the reduced packet processing your client
has to do.
73,
Pete Loveall AE5PL
pete at ae5pl.net
------------------------------
Message: 19
Date: Fri, 19 Jan 2007 08:35:33 -0500
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: RE: [aprssig] Setting up a KPC-3+ with a Davis WX station
>... to setup a Davis ProVantage II with a KPC-3+ to send
>out WX data back to my QTH to hit my igate...
>... this setup is located on a remote mountaintop...
>... I want to broadcast the WX data every 10 minutes
>direct to my station at home...
>there will be no digipeater functions...
I assume no digi is "needed" otherwise this is a real opportunity.... A
KPC3+ makes an excelent digipeater. Even if there are other digipeaters
nearby, then you have a great opportunity to make this an alt-input digi
for hearing weak signal or handheld APRS trackers. Just set up the TNC as
a full function APRS digi, put RX on 144.99 and TX on 144.39. This will
offer an alternate, uncongested input for local low power APRS stations.
Don't waste such a good site...
Please check out the remote SYSOP capabilityies of the KPC-3+ and also its
ability to send APRS telemety for monitoring such things as the battery
voltage and charge current, temperature, etc of your remote system. Also
you can change parameters remotely. Also you can have up to 3 remote
controolled on/off switches you can also control remotely with the KPC3.
One problem with these remote WX stations, is that their on-air format is
not "standard" APRS WX format and they are not therefore decoded by
mobiles. SO your approach of just linking it back to your station direct
makes sense and then your base station can then do the formatting to APRS
and sending it to the network. APRSdos had a mode that would do this. IT
would take raw WX data off the air, and then re-format it to standard
format, and then re-send it so that it showed properly on the front panel
of the D7 and D700 radios.
Maybe other programs do this too, etc...
Bob, WB4aPR
------------------------------
Message: 20
Date: Fri, 19 Jan 2007 09:18:26 -0600
From: Richard Montgomery <kb4ytm_at_gmail.com>
Subject: Re: [aprssig] Periodic Disconnects from APRS-IS
Pete,
Can anyone get this queue information? I see a few stations near me that
are constantly going "Igate Closed" and then transmitting
"<IGATE,MSG_CNT=33,LOC_CNT=10" so I guess they are reconnecting
immediately up disconnect. This occurs every 5 minutes or so on some
stations. Would be good to send them a quick msg to let them know how to
fix it.
Richard
KB4YTM
AE5PL Lists wrote:
>Are you having an issue where you get disconnected from an APRS-IS
>server periodically (sometimes as often as every minute)? Are you
...etc etc..
------------------------------
Message: 21
Date: Fri, 19 Jan 2007 09:31:27 -0600
From: Gregg Wonderly <gregg_at_wonderly.org>
Subject: Re: [aprssig] Periodic Disconnects from APRS-IS
AE5PL Lists wrote:
>This is not an issue of computer buffering but of TCP buffering.
Yes Pete, but when there is a flood of data, it make sense to send as much
data as you have in a single packet. Those return ACKs are part of the
overall latency applicable to the delivery of data between machines. So,
the fewer acks there are, the more opportunity there is for increased
bandwidth utilization.
Also, it occurs to me that most consumer highspeed internet services are
asymetrical in bandwidth, and those ACKs go out through the slow side.
This specific issue is what my sample algorithm was about. Write as much
as you have, without any delays. Setting the socket TCP_NODELAY, is an
additional step that is independent of this output optimization. The
larger packets will not have a negative impact on TCP_NODELAY. It will
simply reduce the number of ACKS needed and since they go through the lower
bandwidth side of the interface, that might be the turning point for some
users between consuming a full feed and not.
Gregg Wonderly
------------------------------
Message: 22
Date: Fri, 19 Jan 2007 09:40:15 -0600
From: "AE5PL Lists" <HamLists_at_ametx.com>
Subject: RE: [aprssig] Periodic Disconnects from APRS-IS
Hi Richard,
It is not completely straightforward because the queue information is only
available from the server they are connected to while they are connected.
That said, most of the issues are with full feeds from servers which are
primarily available from the core servers (most non-core servers wisely do
not offer full feeds to reduce their bandwidth requirements). Using your
browser, you can go to each of the core server status pages by accessing
their port 14501 (http://serveraddr:14501)
I will ask that people do this only to find out what ports are available
and to attempt to diagnose a specific problem like Richard has outlined.
javAPRSSrvr is not a web server and the status page should never be linked
to in other web sites nor should it be hammered by people who are want to
continuously monitor server connections. The status page was originally
incorporated in aprsD as a diagnostic display for sysops and I encourage
people to continue to view it as such (with the addition of determining
what ports are available on a particular server). Thanks to everyone for
their consideration in this.
As a long time user of APRS+SA, I will state that, except on the fastest of
machines, it cannot keep up with the full APRS-IS stream. This is not to
cast aspersions on APRS+SA; I like it and use it as my main station and
have for years. Brent was an early adopter of being able to define server
filters in the server definition file and I highly encourage APRS+SA users
to update their server file to reflect this capability.
73,
Pete Loveall AE5PL
pete at ae5pl.net
------------------------------
aprssig mailing list
aprssig_at_lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
End of aprssig Digest, Vol 31, Issue 21
Read previous mail | Read next mail
| |
