From owner-freebsd-wireless@FreeBSD.ORG Fri Nov 23 13:39:47 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 DC593C6B for ; Fri, 23 Nov 2012 13:39:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7578FC17 for ; Fri, 23 Nov 2012 13:39:47 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so3322425wey.13 for ; Fri, 23 Nov 2012 05:39:46 -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=ceDKGNkHxNYXjkUMvcpP4Ff9yxPO8F7/NXDI6TNS97E=; b=wDVsX4O7Kps1sqJdk+LvoECw67hBo6fKE3pu+tIwgt3NP7fPildU0HLuGKAMFU0R6+ BXpF0YEbG/MJ6bZ5WUcDknhFXmEwgmBzPQmcENcoYcaZRw9X76Vx4AGCgy73+fpXitSB f50/hcwgfIPO3G8tNwA+/gjUfR9DBagA69/m0QnN9mblCbr8mauqYh2G6vM33Yp3e/PS 0nHu+EP3JTkByJcwOz7rHD11LtD6OuK9N7Z6+pMl46UIY5McAxFlDxtnS2wq5B67ploc W8opjmgMdfGs/d5YOe08nvXbAN9JHgLmEZshz8qHAaxOKaJ0TzZNNeKY9A17ZWrSuSmh TSVw== MIME-Version: 1.0 Received: by 10.180.7.197 with SMTP id l5mr9757334wia.13.1353677986456; Fri, 23 Nov 2012 05:39:46 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Fri, 23 Nov 2012 05:39:46 -0800 (PST) In-Reply-To: References: Date: Fri, 23 Nov 2012 05:39:46 -0800 X-Google-Sender-Auth: sEP9IqPJbaSlXug-tVccNA64Cvw 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: Fri, 23 Nov 2012 13:39:47 -0000 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. It's stable with no traffic, which is good. Beforehand, the TSF adjustment would cause the unit to fall markedly out of timing, and then it'd take a while to coverge back. Once it converged back, it would write a new timing configuration out which would adjust the TSF by a large amount and .. it'd fall out of timing again. I've added a whole bunch of extra debugging to if_ath_tdma.c to try and understand what's going on during this. 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. Adrian