| |
ZL3AI > APRDIG 21.01.07 22:51l 252 Lines 10409 Bytes #999 (0) @ WW
BID : 9593-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 31 #21, 3/4
Path: DB0FHN<DB0MRW<DK0WUE<DB0RES<F5GOV<F4BWT<IW2OAZ<ZL2BAU
Sent: 070121/0515Z @:ZL2BAU.#79.NZL.OC #:28305 [Waimate] $:9593-ZL3AI
From: ZL3AI@ZL2BAU.#79.NZL.OC
To : APRDIG@WW
Message: 14
Date: Thu, 18 Jan 2007 20:44:38 -0800
From: "Scott Miller" <scott_at_opentrac.org>
Subject: RE: [aprssig] Periodic Disconnects from APRS-IS
>(not delayed) delivery. Assuming that the minimum buffering time is the
>maximum buffering time is not understanding how the Nagel algorithm
>works and I recommend you review the extensive studies on this subject
>that have been done on protocols similar to APRS.
Nagle's algorithm alone is not the problem here. Read RFC896 - done right,
it'll result in only one MSS worth of data being buffered. Last I checked,
that works out to about 1/10 of a second worth of APRS IS data. The real
problem is when it's combined with delayed ACKs. See below.
As for the added overhead being negligible, I'm not sure about that. A
typical APRS packet is what, around 60 bytes? Call it 80 to be optimistic.
TCP and IP add 40 bytes of overhead to that. That's a 50% increase. But
you can fit 18 of those packets in one datagram - with 1440 bytes of data,
that 40 bytes of overhead is now less than a 3% increase. It's probably
not an issue for most users, but at hubs you're dealing with a significant
number of connections, and a one third increase in traffic is a lot.
But back to Nagle's algorithm. Here's John Nagle's own description of the
problem:
---
I really should fix the bad interaction between the "Nagle algorithm" and
"delayed ACKs". Both ideas went into TCP around the same time, and the
interaction is terrible. That fixed timer for ACKs is all wrong.
Here's the real problem, and its solution.
The concept behind delayed ACKs is to bet, when receiving some data from
the net, that the local application will send a reply very soon. So there's
no need to send an ACK immediately; the ACK can be piggybacked on the next
data going the other way. If that doesn't happen, after a 500ms delay, an
ACK is sent anyway.
The concept behind the Nagle algorithm is that if the sender is doing very
tiny writes (like single bytes, from Telnet), there's no reason to have
more than one packet outstanding on the connection. This prevents slow
links from choking with huge numbers of outstanding tinygrams.
Both are reasonable. But they interact badly in the case where an
application does two or more small writes to a socket, then waits for a
reply. (X-Windows is notorious for this.) When an application does that,
the first write results in an immediate packet send. The second write is
held up until the first is acknowledged. But because of the delayed ACK
strategy, that acknowledgement is held up for 500ms. This adds 500ms of
latency to the transaction, even on a LAN.
The real problem is that 500ms unconditional delay. (Why 500ms? That was a
reasonable response time for a time-sharing system of the 1980s.) As
mentioned above, delaying an ACK is a bet that the local application will
reply to the data just received. Some apps, like character echo in Telnet
servers, do respond every time. Others, like X-Windows "clients" (really
servers, but X is backwards about this), only reply some of the time.
TCP has no strategy to decide whether it's winning or losing those bets.
That's the real problem.
The right answer is that TCP should keep track of whether delayed ACKs are
"winning" or "losing". A "win" is when, before the 500ms timer runs out,
the application replies. Any needed ACK is then coalesced with the next
outgoing data packet. A "lose" is when the 500ms timer runs out and the
delayed ACK has to be sent anyway. There should be a counter in TCP,
incremented on "wins", and reset to 0 on "loses". Only when the counter
exceeds some number (5 or so), should ACKs be delayed. That would eliminate
the problem automatically, and the need to turn the "Nagle algorithm" on
and off.
So that's the proper fix, at the TCP internals level. But I haven't done
TCP internals in years, and really don't want to get back into that. If
anyone is working on TCP internals for Linux today, I can be reached at the
e-mail address above. This really should be fixed, since it's been annoying
people for 20 years and it's not a tough thing to fix.
The user-level solution is to avoid write-write-read sequences on sockets.
write-read-write-read is fine. write-write-write is fine. But
write-write-read is a killer. So, if you can, buffer up your little writes
to TCP and send them all at once. Using the standard UNIX I/O package and
flushing write before each read usually works.
John Nagle
---
Scott
N1VG
------------------------------
Message: 15
Date: Fri, 19 Jan 2007 00:09:15 -0600
From: "tvsjr" <tvsjr_at_sprynet.com>
Subject: RE: [aprssig] Periodic Disconnects from APRS-IS
>But I share your frustration. I'm about to pack up my IGate, I
>shouldn't need to choose political sides simply to enjoy a hobby.
I'm a lowly user, not anything special... but I too would like to see an
end to the dick-waving between Tier 2 and the core server admins.
This list is supposed to be for the discussion of APRS. It should be the
canonical source for recommendations on paths, gate configs, overall system
architecture. If you were a new D700 owner and were trying to figure out
how to configure your radio to work properly, and you happened upon this
list, what impression would you get?
I would call on the moderators/admins of this forum to put at end to this
BS or request it go to some other list or private email. Otherwise, I'll be
unsubscribing... and I don't think I'll be the only one.
Thanks for the bandwidth.
Terry/N5RSE
------------------------------
Message: 16
Date: Thu, 18 Jan 2007 23:09:50 -0800
From: "Stephen H. Smith" <wa8lmf2_at_aol.com>
Subject: Re: [aprssig] Setting up a KPC-3+ with a Davis WX station
stephen.brown75_at_gmail.com wrote:
>
>Some of my questions. How do I set a path instead of a generic alias?
>Is this done through the unproto command? For example, if I just want
>to send the data direct back to me, would my unproto be something like
>APRS via N1VLV-10? Or if I wanted to digipeat, APRS via KS4NG-7(our
>local digi that is closest to me), N1VLV-10?
The callsigns after VIA are the stations you are asking to serve as
digipeaters. Normally, on APRS (by contrast with classic connected packet)
this will be a generic alias callsign like WIDE2-2. You just leave VIA
blank if you want a direct path with no digipeaters getting involved. You
CAN place an explicit specific callsign in VIA (rather than the generic
WIDE2-2) if you want to limit digipeating to only one specific digipeater
(and prevent other digipeaters within radio earshot from also relaying the
data).
The station that is receiving this data (I presume N1VLV-10 is your
receiving station) and gating it into the Internet is not acting as a
digipeater in this role. It is the final destination only. It is
pointless to ask your destination station to digipeat the data again on RF
(which is what you are doing if you place your own callsign in the "VIA"
path of the weather station). [This assuming your station is even
configured to act as a digipeater.]
Normally an igate station will pass anything and everything it hears on RF
onward to the Internet, regardless of path. [ Unless explicit filters
have been set in the igate software to block certain kinds of traffic, or
if the RF user has placed "NOGATE" or "RFONLY" at the end of his VIA path.]
>Another thing, is there a way to set a WX symbol in the TNC itself, or
>am I to assume this is passed on from the datalogger in the WX station
>in the proper format to be xmitted?
Assuming you have the beacon text set to show the lat/long (as you should)
it's quite easy. See my web page at:
http://wa8lmf.net/aprs/APRS_symbols.htm
for details on how this is done.
--
Stephen H. Smith wa8lmf (at) aol.com
EchoLink Node: 14400 [Think bottom of the 2M band]
Home Page: http://wa8lmf.com --OR-- http://wa8lmf.net
NEW! TNC Test CD
http://wa8lmf.net/TNCtest
JavAPRS Filter Port 14580 Guide
http://wa8lmf.net/aprs/JAVaprsFilters.htm
"APRS 101" Explanation of APRS Path Selection & Digipeating
http://wa8lmf.net/DigiPaths
Updated "Rev G" APRS http://wa8lmf.net/aprs
Symbols Set for UI-View,
UIpoint and APRSplus:
------------------------------
Message: 17
Date: Fri, 19 Jan 2007 09:16:49 -0000
From: "Dave Baxter" <dave_at_emv.co.uk>
Subject: RE: [aprssig] 315 is dead :(
My yellow eTrex did something like that last year. Likewise, I thought it
had broken and was a bit P'd off, to say the least.
Eventualy, I checked with another RX (an old Magellan hand held) and the
sat's were still there OK, so I just left the eTrex out in the open for an
hour or so, and it sorted itself out, and now works just as well as before.
(Made me happy, for onece!)
I never did get to the bottom of why that happened.. It had not moved
100's of miles since last use, though it was left for a month with no
batteries in :-)
Garmin say in the book that there are no battery backed items in there, but
in the words of the song.. "It makes me wonder..."
I now leave it with batteries in, it's a lot less hassle when I do want it
in a hurry, and they don't seem to run down if it's not used.
The old Magellan by comparison eats batteries over a couple of weeks, even
if switched off! And then needs the same total refresh before it behaves
again, so I guess that definitely has battery backed memory.. The funny
thing is, it always seems to remember that the nearest "big" city, is
London (UK)... Hmmmmm....
The recently acquired GPS "Mice" (Thanks Heikki) must have flash ram in
them, or a lithium cell or something, as even a "cold" start, only takes
about 2 minutes, maximum.. A "Warm" start, is done and dusted in seconds
it seems.
73.
Dave G0WBX.
>-----Original Message-----
>From: Jim Duncan [mailto:jdbandman_at_earthlink.net]
>Sent: Thursday, January 18, 2007 1:47 AM
>To: joe_at_dellabarba.com; TAPR APRS Mailing List
>Subject: Re: [aprssig] 315 is dead :(
>
>The "Dems" probably turned it off to keep the Bush
>Administration from spying on you again, Joe...
>
>Jim, KU0G
>
>Joe Della Barba wrote:
>
>>My Magellan 315, which has worked perfectly until tonight, refuses to
>>acquire any satellites.
>>Is there some GPS jamming going on here in the Annapolis area or did
>>the thing just die on me?
>>73
>>Joe N3HGB
------------------------------
Read previous mail | Read next mail
| |
