The funny thing is that we had a power fail at the NOC this morning for a
few minutes, and while it was offline, along with the backhaul, I noticed
that ping times from the satellite to the AP (it's solar powered) fell back
to what I consider normal (15mS, stable). When the NOC powered up, and
before the boarder router (a Mikrotik) booted, I noticed that the ping times
stayed low and stable, from satellite-AP and from satellite-backhaul bridge.
As soon as the router came up, ping times went all to heck.
About the only changes between "normal" and now, is the addition of about
four Ubicom bridges as satellites, and the use of bandwidth limiting at the
Mikrotik border router. So, maybe it's the border router configuration and
not anything to do with TC. However, I disabled bandwith limiting
temporarily,
no difference.
Norm
----- Original Message -----
From: "Thomas Giger TGC" <thomas.giger@tgc.de>
To: "'Norm Young'" <npyoung@applegatebroadband.net>; "'Karlnet Mailing
List'" <karlnet@WISPNotes.com>
Sent: Friday, August 22, 2003 10:41 AM
Subject: RE: [Karlnet] Ping time differences
> > I've been noticing some rather serious jitter between our
> > client stations and our NOC or AP. When I ping from the
> > client radio out towards the NOC or AP, I see anything
> > between 15mS-300mS.
>
> That's what I would expect from a polled system. Note that the polling
> frequency has no correlation to your ping interval; the activity of other
> systems influence how frequently this (idle) client is being permitted to
> transmit. So some echo requests wait longer than others until they allowed
> on the air.
>
> > The ping time jitter has no correlation
> > to system load, but responds well if I load the client that
> > I'm testing from. (Start a download from the NOC towards
> > the client, and the ping times drop down to 20-30mS )
>
> That is because the PINGs can now "ride on the ACK packets" of your
> download.
>
> > Pinging back from the NOC to the client, I see stable 10mS or
> > less ping times.
>
> That is maybe because the base anticipates that if a packet goes out to a
> satellite, there is likely a paket to come back - so it will poll this
> satellite in its next round.
>
> > Is it even a problem?
>
> 300 ms (your worst figure) seems to be too much unless the base has many
> satellites and there is traffic to others. If the cell is idle and there
are
> not too many satellites being polled, it may be a sign of interference and
> retransmission.
>
> The question really is whether this was less significant in earlier
versions
> and if yes, if it is a side-effect from other optimizations in the recent
> releases. I seem to remember there was something on the KN website along
> with the release that talked about increased responsiveness in paket
> forwarding vs. RTT for lightly loaded satellites.
>
> regards,
> --
> true global communications GmbH
> Thomas Giger
> In der Au 27, 61440 Oberursel, Germany
> fon +49.6171.6381-0, fax +49.6171.6381-19
> www.tgnet.de || www.megaspeed-internet.de
> _______________________________________________
> Karlnet mailing list
> Karlnet@WISPNotes.com
> http://lists.wispnotes.com/mailman/listinfo/karlnet
>
|