* TSFT @ 2012-11-17 6:26 Simon Barber [not found] ` <50A72E17.6070207-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> 0 siblings, 1 reply; 11+ messages in thread From: Simon Barber @ 2012-11-17 6:26 UTC (permalink / raw) To: radiotap-sUITvd46vNxg9hUCZPvPmw; +Cc: thomas-W/OLz77bvjtBDgjK7y7TUQ This is the current definition of TSFT: "Value in microseconds of the MAC's 64-bit 802.11 Time Synchronization Function timer when the first bit of the MPDU arrived at the MAC. For received frames only." My experience with TSFT is with Atheros cards, which record the timestamp at the end of the frame, not the start. Do you know the behaivour of any particular capture systems re: TSFT - where do they timestamp the frame? Furthermore for DSSS/CCK the definition above is reasonable, but for OFDM and HT (802.11n) the SIGNAL field (part of the PLCP header, not part of the MPDU) is part of the first data symbol. It would be much clearer to change the definition to state that the timestamp is at the start of this first SIGNAL/data symbol. Any objections to doing this, or preference to change the reference point to a different part of the frame? In my wireshark patch I've added options to interpret TSFT as the start of end of the frame. Simon ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <50A72E17.6070207-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>]
* Re: TSFT [not found] ` <50A72E17.6070207-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> @ 2012-11-17 6:48 ` David Young [not found] ` <20121117064848.GO21779-Gq8g4XVd89tWk0Htik3J/w@public.gmane.org> 2012-11-17 23:26 ` TSFT Thomas Pedersen 1 sibling, 1 reply; 11+ messages in thread From: David Young @ 2012-11-17 6:48 UTC (permalink / raw) To: radiotap-sUITvd46vNxg9hUCZPvPmw On Fri, Nov 16, 2012 at 10:26:31PM -0800, Simon Barber wrote: > This is the current definition of TSFT: > > "Value in microseconds of the MAC's 64-bit 802.11 Time > Synchronization Function timer when the first bit of the MPDU > arrived at the MAC. For received frames only." > > My experience with TSFT is with Atheros cards, which record the > timestamp at the end of the frame, not the start. Interesting. Is it consistent across the whole Atheros product line? > Furthermore for DSSS/CCK the definition above is reasonable, but for > OFDM and HT (802.11n) the SIGNAL field (part of the PLCP header, not > part of the MPDU) is part of the first data symbol. It would be much > clearer to change the definition to state that the timestamp is at > the start of this first SIGNAL/data symbol. Any objections to doing > this, or preference to change the reference point to a different > part of the frame? > > In my wireshark patch I've added options to interpret TSFT as the > start of end of the frame. I think we need 1) a methodology for an author to identify their device's reference point so that they can calibrate their driver to the standard and/or 2) a radiotap datum that identifies the reference point in use or 3) something entirely different. Dave -- David Young dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org Urbana, IL (217) 721-9981 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <20121117064848.GO21779-Gq8g4XVd89tWk0Htik3J/w@public.gmane.org>]
* Re: TSFT [not found] ` <20121117064848.GO21779-Gq8g4XVd89tWk0Htik3J/w@public.gmane.org> @ 2012-11-17 8:45 ` Johannes Berg [not found] ` <1353141950.9543.3.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org> 0 siblings, 1 reply; 11+ messages in thread From: Johannes Berg @ 2012-11-17 8:45 UTC (permalink / raw) To: David Young; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw On Sat, 2012-11-17 at 00:48 -0600, David Young wrote: > On Fri, Nov 16, 2012 at 10:26:31PM -0800, Simon Barber wrote: > > This is the current definition of TSFT: > > > > "Value in microseconds of the MAC's 64-bit 802.11 Time > > Synchronization Function timer when the first bit of the MPDU > > arrived at the MAC. For received frames only." > > > > My experience with TSFT is with Atheros cards, which record the > > timestamp at the end of the frame, not the start. > > Interesting. Is it consistent across the whole Atheros product line? Pretty much. > > Furthermore for DSSS/CCK the definition above is reasonable, but for > > OFDM and HT (802.11n) the SIGNAL field (part of the PLCP header, not > > part of the MPDU) is part of the first data symbol. It would be much > > clearer to change the definition to state that the timestamp is at > > the start of this first SIGNAL/data symbol. Any objections to doing > > this, or preference to change the reference point to a different > > part of the frame? > > > > In my wireshark patch I've added options to interpret TSFT as the > > start of end of the frame. > > I think we need 1) a methodology for an author to identify their > device's reference point so that they can calibrate their driver to the > standard and/or 2) a radiotap datum that identifies the reference point > in use or 3) something entirely different. FWIW, for the Atheros drivers we *just* added (1) to the Linux kernel, but for radiotap output we calculate the difference to the start of the frame, see here: http://git.kernel.org/?p=linux/kernel/git/jberg/mac80211-next.git;a=commit;h=f4bda337bbb6e245e2a07f344990adeb6a70ff35 (the patches for the drivers are separate, but simply change the _START flag to _END) I have no objections to (also) allowing this information to be in radiotap though, but I'm not sure we want to? Our (Intel's) device for example has the "on air rise" timestamp which is different again, so we could potentially end up with at least three different reference points? OTOH, I don't see more than these three making sense at all... johannes ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <1353141950.9543.3.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org>]
* Re: TSFT [not found] ` <1353141950.9543.3.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org> @ 2012-11-17 17:46 ` David Young [not found] ` <20121117174600.GQ21779-Gq8g4XVd89tWk0Htik3J/w@public.gmane.org> 0 siblings, 1 reply; 11+ messages in thread From: David Young @ 2012-11-17 17:46 UTC (permalink / raw) To: radiotap-sUITvd46vNxg9hUCZPvPmw On Sat, Nov 17, 2012 at 09:45:50AM +0100, Johannes Berg wrote: > On Sat, 2012-11-17 at 00:48 -0600, David Young wrote: > > On Fri, Nov 16, 2012 at 10:26:31PM -0800, Simon Barber wrote: > > > In my wireshark patch I've added options to interpret TSFT as the > > > start of end of the frame. > > > > I think we need 1) a methodology for an author to identify their > > device's reference point so that they can calibrate their driver to the > > standard and/or 2) a radiotap datum that identifies the reference point > > in use or 3) something entirely different. > > FWIW, for the Atheros drivers we *just* added (1) to the Linux kernel, > but for radiotap output we calculate the difference to the start of the > frame, see here: > > http://git.kernel.org/?p=linux/kernel/git/jberg/mac80211-next.git;a=commit;h=f4bda337bbb6e245e2a07f344990adeb6a70ff35 > > (the patches for the drivers are separate, but simply change the _START > flag to _END) Adjusting the NIC's TSFT in this way, so that the radiotap reference point is according to spec, sounds right to me. > I have no objections to (also) allowing this information to be in > radiotap though, but I'm not sure we want to? Given that the adjustment is easy, I'm pretty sure we should not waste radiotap header space to describe the TSFT. Wireshark doesn't already have more than two "interpretation modes" for radiotap headers, does it? That would be too bad. I realize that there may be already be a mode for a particular OS.... Dave -- David Young dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org Urbana, IL (217) 721-9981 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <20121117174600.GQ21779-Gq8g4XVd89tWk0Htik3J/w@public.gmane.org>]
* Re: TSFT [not found] ` <20121117174600.GQ21779-Gq8g4XVd89tWk0Htik3J/w@public.gmane.org> @ 2012-11-17 18:43 ` Johannes Berg 2012-11-17 18:56 ` TSFT Guy Harris 1 sibling, 0 replies; 11+ messages in thread From: Johannes Berg @ 2012-11-17 18:43 UTC (permalink / raw) To: radiotap-sUITvd46vNxg9hUCZPvPmw On Sat, 2012-11-17 at 11:46 -0600, David Young wrote: > > > > In my wireshark patch I've added options to interpret TSFT as the > > > > start of end of the frame. > Given that the adjustment is easy, I'm pretty sure we should not waste > radiotap header space to describe the TSFT. > > Wireshark doesn't already have more than two "interpretation modes" for > radiotap headers, does it? That would be too bad. I realize that there > may be already be a mode for a particular OS.... As I understood it, Simon is saying that he's adding one, but since he's using Linux, which will have the adjustment in a matter of days, it probably won't be necessary after all. johannes ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: TSFT [not found] ` <20121117174600.GQ21779-Gq8g4XVd89tWk0Htik3J/w@public.gmane.org> 2012-11-17 18:43 ` TSFT Johannes Berg @ 2012-11-17 18:56 ` Guy Harris 1 sibling, 0 replies; 11+ messages in thread From: Guy Harris @ 2012-11-17 18:56 UTC (permalink / raw) To: radiotap-sUITvd46vNxg9hUCZPvPmw On Nov 17, 2012, at 9:46 AM, David Young <dyoung-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org> wrote: > Wireshark doesn't already have more than two "interpretation modes" for > radiotap headers, does it? That would be too bad. I realize that there > may be already be a mode for a particular OS.... That's the only preference setting Wireshark's radiotap dissection code has. The OS in question is OpenBSD, as per http://www.radiotap.org/rejected-fields/FCS%20in%20header OpenBSD's other collisions are 15 for hardware queue: http://www.radiotap.org/suggested-fields/hardware%20queue rather than TX flags: http://www.radiotap.org/suggested-fields/TX%20flags and RSSI: http://www.radiotap.org/suggested-fields/RSSI rather than RTS retries: http://www.radiotap.org/suggested-fields/RTS%20retries but the latter two are suggested fields rather than defined fields. We could, I guess, define a "standard radiotap" link-layer type header value, and have dissectors that look at flags above 13 always handle those in the standard fashion and have programs that process radiotap headers in files either have a preference to control how to interpret the existing radiotap link-layer header type or just wire in one of the choices. I don't know whether that's worth the effort. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: TSFT [not found] ` <50A72E17.6070207-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> 2012-11-17 6:48 ` TSFT David Young @ 2012-11-17 23:26 ` Thomas Pedersen 2012-11-18 7:20 ` TSFT Simon Barber 1 sibling, 1 reply; 11+ messages in thread From: Thomas Pedersen @ 2012-11-17 23:26 UTC (permalink / raw) To: Simon Barber; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw Hi Simon, On Fri, Nov 16, 2012 at 10:26 PM, Simon Barber <simon-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> wrote: > This is the current definition of TSFT: > > "Value in microseconds of the MAC's 64-bit 802.11 Time Synchronization > Function timer when the first bit of the MPDU arrived at the MAC. For > received frames only." > > My experience with TSFT is with Atheros cards, which record the timestamp at > the end of the frame, not the start. There is already a patch in mac80211-next which accounts for this and normalizes frame TSFT to beginning of frame. > Do you know the behaivour of any particular capture systems re: TSFT - where > do they timestamp the frame? > > Furthermore for DSSS/CCK the definition above is reasonable, but for OFDM > and HT (802.11n) the SIGNAL field (part of the PLCP header, not part of the > MPDU) is part of the first data symbol. It would be much clearer to change > the definition to state that the timestamp is at the start of this first > SIGNAL/data symbol. Any objections to doing this, or preference to change > the reference point to a different part of the frame? Keeping the TSFT at start of MPDU is cleaner from the user's point of view. > In my wireshark patch I've added options to interpret TSFT as the start of > end of the frame. I'm not sure which patch you're referring to, but it seems cleaner to handle normalizing TSFT to a single reference in the kernel. Thomas ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: TSFT 2012-11-17 23:26 ` TSFT Thomas Pedersen @ 2012-11-18 7:20 ` Simon Barber [not found] ` <50A88C3D.5030809-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> 0 siblings, 1 reply; 11+ messages in thread From: Simon Barber @ 2012-11-18 7:20 UTC (permalink / raw) To: Thomas Pedersen; +Cc: radiotap-sUITvd46vNxg9hUCZPvPmw Unfortunately this patch does not do a very accurate calculation, so it makes the problem worse. It simply multiplies rate by the number of bits to get a time. This does not take into account the limited accuracy in rate (11n has fractional rates), nor does it consider the rounding into blocks caused by FEC, or symbols. As a result the data is made worse by the current code. Either the code should do an accurate fix, or it should record the raw value and let the end user correct it properly. Simon On Sat 17 Nov 2012 03:26:05 PM PST, Thomas Pedersen wrote: > Hi Simon, > > On Fri, Nov 16, 2012 at 10:26 PM, Simon Barber <simon-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> wrote: >> This is the current definition of TSFT: >> >> "Value in microseconds of the MAC's 64-bit 802.11 Time Synchronization >> Function timer when the first bit of the MPDU arrived at the MAC. For >> received frames only." >> >> My experience with TSFT is with Atheros cards, which record the timestamp at >> the end of the frame, not the start. > > There is already a patch in mac80211-next which accounts for this and > normalizes frame TSFT to beginning of frame. > >> Do you know the behaivour of any particular capture systems re: TSFT - where >> do they timestamp the frame? >> >> Furthermore for DSSS/CCK the definition above is reasonable, but for OFDM >> and HT (802.11n) the SIGNAL field (part of the PLCP header, not part of the >> MPDU) is part of the first data symbol. It would be much clearer to change >> the definition to state that the timestamp is at the start of this first >> SIGNAL/data symbol. Any objections to doing this, or preference to change >> the reference point to a different part of the frame? > > Keeping the TSFT at start of MPDU is cleaner from the user's point of view. > >> In my wireshark patch I've added options to interpret TSFT as the start of >> end of the frame. > > I'm not sure which patch you're referring to, but it seems cleaner to > handle normalizing TSFT to a single reference in the kernel. > > Thomas ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <50A88C3D.5030809-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>]
* Re: TSFT [not found] ` <50A88C3D.5030809-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> @ 2012-11-18 11:07 ` Johannes Berg [not found] ` <1353236845.9649.6.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org> 0 siblings, 1 reply; 11+ messages in thread From: Johannes Berg @ 2012-11-18 11:07 UTC (permalink / raw) To: Simon Barber; +Cc: Thomas Pedersen, radiotap-sUITvd46vNxg9hUCZPvPmw On Sat, 2012-11-17 at 23:20 -0800, Simon Barber wrote: > Unfortunately this patch does not do a very accurate calculation, so it > makes the problem worse. It simply multiplies rate by the number of > bits to get a time. This does not take into account the limited > accuracy in rate (11n has fractional rates), nor does it consider the > rounding into blocks caused by FEC, or symbols. As a result the data is > made worse by the current code. Either the code should do an accurate > fix, or it should record the raw value and let the end user correct it > properly. If we can, I'd say we should fix the calculations. The question is how we define it when the first bit of the MPDU can be fractional in a symbol? johannes ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <1353236845.9649.6.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org>]
* Re: TSFT [not found] ` <1353236845.9649.6.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org> @ 2012-11-20 22:43 ` Simon Barber [not found] ` <50AC0791.3040005-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> 0 siblings, 1 reply; 11+ messages in thread From: Simon Barber @ 2012-11-20 22:43 UTC (permalink / raw) To: Johannes Berg; +Cc: Thomas Pedersen, radiotap-sUITvd46vNxg9hUCZPvPmw One problem with fixing the calculations is that quite a lot of information is needed to do the calculation correctly. In Intel's case I don't know if Ness information is available, and this makes upto a 16us difference in the PLCP header length. Calculating the start of the MPDU from the end accurately requires knowing the FEC scheme, the MCS, the guard interval, the bandwidth. Is the FEC scheme known, or are all current cards only supporting BCC? Do you know if Intel supports extension spatial streams? If not the number is always 0. And FEC - is it always BCC? Simon On 11/18/2012 03:07 AM, Johannes Berg wrote: > On Sat, 2012-11-17 at 23:20 -0800, Simon Barber wrote: >> Unfortunately this patch does not do a very accurate calculation, so it >> makes the problem worse. It simply multiplies rate by the number of >> bits to get a time. This does not take into account the limited >> accuracy in rate (11n has fractional rates), nor does it consider the >> rounding into blocks caused by FEC, or symbols. As a result the data is >> made worse by the current code. Either the code should do an accurate >> fix, or it should record the raw value and let the end user correct it >> properly. > > If we can, I'd say we should fix the calculations. > > The question is how we define it when the first bit of the MPDU can be > fractional in a symbol? > > johannes > ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <50AC0791.3040005-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org>]
* Re: TSFT [not found] ` <50AC0791.3040005-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> @ 2012-11-21 10:42 ` Johannes Berg 0 siblings, 0 replies; 11+ messages in thread From: Johannes Berg @ 2012-11-21 10:42 UTC (permalink / raw) To: Simon Barber; +Cc: Thomas Pedersen, radiotap-sUITvd46vNxg9hUCZPvPmw On Tue, 2012-11-20 at 14:43 -0800, Simon Barber wrote: > One problem with fixing the calculations is that quite a lot of > information is needed to do the calculation correctly. In Intel's case I > don't know if Ness information is available, and this makes upto a 16us > difference in the PLCP header length. > > Calculating the start of the MPDU from the end accurately requires > knowing the FEC scheme, the MCS, the guard interval, the bandwidth. Is > the FEC scheme known, or are all current cards only supporting BCC? Good question, I don't really know. > Do you know if Intel supports extension spatial streams? If not the > number is always 0. And FEC - is it always BCC? I don't think our devices support extension spatial streams or anything but BCC. Overall though, I think there's an argument to be made here for simply introducing a new radiotap timestamp field that gives the timestamp at the end of the frame? This could be defined better and would be more accurate. I'm not sure I'd want to redefine the existing field in any way since there are probably a whole bunch of implementations out there that just stick whatever timestamp they have into the field, without regard for where it is in the frame, and without regard for aggregation. johannes ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-11-21 10:42 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-11-17 6:26 TSFT Simon Barber [not found] ` <50A72E17.6070207-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> 2012-11-17 6:48 ` TSFT David Young [not found] ` <20121117064848.GO21779-Gq8g4XVd89tWk0Htik3J/w@public.gmane.org> 2012-11-17 8:45 ` TSFT Johannes Berg [not found] ` <1353141950.9543.3.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org> 2012-11-17 17:46 ` TSFT David Young [not found] ` <20121117174600.GQ21779-Gq8g4XVd89tWk0Htik3J/w@public.gmane.org> 2012-11-17 18:43 ` TSFT Johannes Berg 2012-11-17 18:56 ` TSFT Guy Harris 2012-11-17 23:26 ` TSFT Thomas Pedersen 2012-11-18 7:20 ` TSFT Simon Barber [not found] ` <50A88C3D.5030809-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> 2012-11-18 11:07 ` TSFT Johannes Berg [not found] ` <1353236845.9649.6.camel-8Nb76shvtaUJvtFkdXX2HixXY32XiHfO@public.gmane.org> 2012-11-20 22:43 ` TSFT Simon Barber [not found] ` <50AC0791.3040005-vp0mx6+5gkqFX2APIN6yfw@public.gmane.org> 2012-11-21 10:42 ` TSFT Johannes Berg
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).