ve7gdh at rac.ca
Sun Jan 8 12:37:25 CST 2006
Wes KD4RDB wrote on Jan 8 2006
> I have seen similar problems with my tracker moving around town. I came
> to the conclusion that UI-View acting as an IGATE was delaying delivery
> of packets to TCP... I found that in each case a ui-view station would
> deliver a packet late anywhere from 120seconds to 500 seconds. It was
> suggested that the guy's internet connection was queuing packets but I
> found this hard to believe.
I have seen it in the Vancouver BC / Seattle WA area. To the best of my
recollection, in every instance that I looked into where this was happening,
a digi or IGate "way down" near Seattle was involved. I don't recall what
the IGate was using. The most reasonable explanation I had seen was that a
digi with a squelched radio had the squelch set too loose and it was storing
packets until the squelch closed.
See also the message from Richard K0AEM from a few minutes ago where he
observed a nearby UI-View IGate delaying some packets but while the CPU was
being overwhelmed with (or at least concentrating on!) a print job.
> That leaves me with the "If it quacks like a duck" cliché.
Good one, but I'm holding out for a bit more proof before I will conclude
there is only one cause or only one APRS client that is introducing out of
order packets - hi!. I think that any APRS client that hears a beacon will
gate it. The APRS-IS apparently takes care of dupes but only going back 30
seconds. UI-View32 has dupe checking, but to the best of my knowledge, it
only applies to beacons it is digipeating - not that it is gating.
73 es cul - Keith VE7GDH
"I may be lost, but I know exactly where I am!"
More information about the aprssig