From owner-freebsd-wireless@FreeBSD.ORG Sat Nov 24 01:26:41 2012 Return-Path: Delivered-To: freebsd-wireless@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EFA76C97 for ; Sat, 24 Nov 2012 01:26:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx1.freebsd.org (Postfix) with ESMTP id 787828FC12 for ; Sat, 24 Nov 2012 01:26:40 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hm9so1699009wib.13 for ; Fri, 23 Nov 2012 17:26:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3H7P/yrFt71lox4YLFFIaVvNEinU0WnpNeB8LGbV8ro=; b=AyK4fqGQd43Iyn1QsA42xBNV+yV0qny2dttEDfMN9uoBnZQb3cQoss6xm8hAemOGmX PPLVE+gHmL2Mnhvny0aT0COFn0j50canET4p9oUDBPIUDkk16NFu3uKy1Yfc/Lm1KodR +Vc0Z+mlQEIzU1ntkAbdTYVAqXxMr4LucoEbVVEFiOc3KK8O1bHp0Z9rwz0Vk2MkNITU 1qHcQHY5YUZjJmVxTrDsy4VPAPJ+zYhHSEFCEo/mQt6xpLrVnQEOt4w3mKigGVw9Q9VK jkc3PxTVgoBtC5AHS7v8iyVXZ35KlIf8bmtv+nkPFQN1FFZNhJUrUXT0ufTD3F0TelBM ob7Q== MIME-Version: 1.0 Received: by 10.180.88.71 with SMTP id be7mr8367327wib.17.1353720399417; Fri, 23 Nov 2012 17:26:39 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Fri, 23 Nov 2012 17:26:39 -0800 (PST) In-Reply-To: References: Date: Fri, 23 Nov 2012 17:26:39 -0800 X-Google-Sender-Auth: xFVyvHQJZfgZVapQdyQdMjkRtvg Message-ID: Subject: Re: (Re) Verifying TDMA behaviour on -HEAD From: Adrian Chadd To: Michael Vale Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-wireless@freebsd.org X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 01:26:41 -0000 On 23 November 2012 05:39, Adrian Chadd wrote: > On 23 November 2012 05:28, Michael Vale 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