From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail-pa0-f46.google.com ([209.85.220.46]:53012 "EHLO mail-pa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750894Ab2JXXdr (ORCPT ); Wed, 24 Oct 2012 19:33:47 -0400 Received: by mail-pa0-f46.google.com with SMTP id hz1so709588pad.19 for ; Wed, 24 Oct 2012 16:33:47 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20121024220813.GB6723@shredder> References: <20121024194547.GA19060@shredder> <20121024220813.GB6723@shredder> Date: Wed, 24 Oct 2012 16:33:46 -0700 Message-ID: (sfid-20121025_013351_149161_8A377730) Subject: Re: [ath9k-devel] ath9k_htc and reported mactime From: Adrian Chadd To: Thomas Pedersen Cc: ath9k-devel@lists.ath9k.org, linux-wireless , Bob Copeland Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On 24 October 2012 15:08, Thomas Pedersen wrote: >> Also, we should check to see whether the MAC is paying attention to >> any beacon frames > > How? For mesh mode support we currently just reuse the WDS AP firmware vif > opmode. > >> and updating _its_ timestamp using that beacon frame timer. That's >> one of the mesh-and-sta-and-ap-at-the-same-time problems - in >> STA mode, the TSF gets fudged based on the AP TSF. In other modes this >> doesn't necessarily hold. > > OK, but the TSF for AP shouldn't be automatically updated on other > beacons, right? Right but look at those AP macs, there's multiple overlapping TSFs there, right? * Each MAC AP has an incrementing TSF; * Multiple APs have different TSF spaces, they're not synchronised at all; * There's one RX TSF namespace - if the vif is in AP mode then it's free-running and not synchronising against any other TSF; * Thus the above makes sense to me. So far the beacon frames look correct and they're increasing; you're not obviously synchronising TSF against anything. Going back to the original question - you fetch TSF after you receive the packet, and sometimes the TSF in the frame is greater than the TSF read back by the ath9k TSF get method. The ath9k_htc tsf read is just 'tsf = ath9k_hw_gettsf64(priv->ah);', so it's doing direct register reads. That should be immediate, but it's USB so it may take a while. So hm, now you've made me open the ath9k_htc firmware source. I hate you. Let me look. Adrian From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrian Chadd Date: Wed, 24 Oct 2012 16:33:46 -0700 Subject: [ath9k-devel] ath9k_htc and reported mactime In-Reply-To: <20121024220813.GB6723@shredder> References: <20121024194547.GA19060@shredder> <20121024220813.GB6723@shredder> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org On 24 October 2012 15:08, Thomas Pedersen wrote: >> Also, we should check to see whether the MAC is paying attention to >> any beacon frames > > How? For mesh mode support we currently just reuse the WDS AP firmware vif > opmode. > >> and updating _its_ timestamp using that beacon frame timer. That's >> one of the mesh-and-sta-and-ap-at-the-same-time problems - in >> STA mode, the TSF gets fudged based on the AP TSF. In other modes this >> doesn't necessarily hold. > > OK, but the TSF for AP shouldn't be automatically updated on other > beacons, right? Right but look at those AP macs, there's multiple overlapping TSFs there, right? * Each MAC AP has an incrementing TSF; * Multiple APs have different TSF spaces, they're not synchronised at all; * There's one RX TSF namespace - if the vif is in AP mode then it's free-running and not synchronising against any other TSF; * Thus the above makes sense to me. So far the beacon frames look correct and they're increasing; you're not obviously synchronising TSF against anything. Going back to the original question - you fetch TSF after you receive the packet, and sometimes the TSF in the frame is greater than the TSF read back by the ath9k TSF get method. The ath9k_htc tsf read is just 'tsf = ath9k_hw_gettsf64(priv->ah);', so it's doing direct register reads. That should be immediate, but it's USB so it may take a while. So hm, now you've made me open the ath9k_htc firmware source. I hate you. Let me look. Adrian