Date: Fri, 23 Nov 2012 17:26:39 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Michael Vale <masked@internode.on.net> Cc: freebsd-wireless@freebsd.org Subject: Re: (Re) Verifying TDMA behaviour on -HEAD Message-ID: <CAJ-Vmoks=Yvqijf1y45OtdgF9fBUUs7zcuDHeapKUOULkv35%2BA@mail.gmail.com> In-Reply-To: <CAJ-Vmo=%2BKQ9odk0ULGxw6zzWF73GEDR-NvT4pbExmUE15J2Bow@mail.gmail.com> References: <CAJ-Vmokhdw4U-7gp7gUK6Q8upz_ExWS09kLvJgmcmNHAo-wf5g@mail.gmail.com> <CAJ-Vmon9viaRPDBZRfk4CtQ%2BgArPmfuWfJRthYjPNfD8gONjtg@mail.gmail.com> <D9B39BCE60C0420ABFC9F8957060630B@forexamplePC> <CAJ-Vmo=%2BKQ9odk0ULGxw6zzWF73GEDR-NvT4pbExmUE15J2Bow@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23 November 2012 05:39, Adrian Chadd <adrian@freebsd.org> wrote: > On 23 November 2012 05:28, Michael Vale <masked@internode.on.net> wrote: >> When I get back from my holiday I will test this on numerous multi-km ptp >> and ptmp links mate. > > Hold off for a bit, I'm seeing some (recovered) timing drift when I'm > doing iperf tests. It takes a while for it to trigger, but at least > now it does recover. [snip] > It would be nice if someone took a stab at understanding why the slot > timing estimate is falling so far "off" during busy traffic here. > Remember, the slot offset is based on the timestamp of the beacon > being transmitted at the master side and received locally, and it's > entirely plausible the reason I'm seeing overruns here is because the > NIC is overflowing its burst config and guard interval, causing the > master beacon to be delayed in TX. That would manifest itself as the > slot timing drifting in and out, as the master beacon ends up being > constantly delayed. .. or I could sit at an IHOP and hack on it a bit more. Here's a snapshot of the received beacons on the slave, and the TSF in said beacons: 986439736 (delta 49150) 986488888 (delta 49152) 986538040 (delta 49152) 986615556 (delta 77516) 986635102 (delta 19546) 986684248 (delta 49146) 986733414 (delta 49166) 986783802 (delta 50388) 986832958 (delta 49156) 986882104 (delta 49146) 986931256 (delta 49152) 986980408 (delta 49152) 987029560 (delta 49152) 987078714 (delta 49154) 987135640 (delta 56926) 987177018 (delta 41378) 987226170 (delta 49152) 987275320 (delta 49150) .. notice those big deltas different from ~ 49152uS? That coincides with the large traffic variance and swings in the slave timing calculations. Those timestamps are in the master beacons, not the RX timestamp. Ie, the master is delaying beaconing for a while. My 30 second guess is "traffic is overflowing the burst window somehow and not being killed." The newer chips support acutally killing frames outside of a TXOP burst window, but I don't think the relevant AR_PCU_MISC_MODE bit is set. In any case, the guard time is supposed to "guard" for that. I'll do a little more digging. Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmoks=Yvqijf1y45OtdgF9fBUUs7zcuDHeapKUOULkv35%2BA>