On Tuesday 19 February 2008 16:18:41 Benoit PAPILLAULT wrote: > The problem is pretty simple: > > * rs_tstamp is the lowest bits of the TSF when we received the packet > (don't know if it's sample at the beginning or the end of the packet) > > * on some beacons, hardware TSF is updated > > * later on, the software driver (be it ath5k or madwifi) tries to > combine the rs_tstamp and the new hardware TSF, which is obviously wrong!
basically that is true, but one curious thing i see (with both AR5213 and AR5414) is that the timestamp of beacons which are shorter than 74 byte (78 byte including FCS) is *correct*, even when the hardware TSF is getting updated! only for beacons bigger than that the timestamp gets unreliable. but i guess for practical purposes this is irrelevant ;) and we can just treat all timestamps of beacons which might have caused a TSF update as unrelieable. in case anyone is interrested here are the results of my experimentation with different beacon lengths: the numbers are the time difference in usec between the beacon timestamp and the extended rx timestamp. beacon AR5213 AR5213 AR5414 AR5414 lenght madwifi ath5k madwifi ath5k byte 0.9.4 0.9.4 ---------------------------------------------- 58 63 63 61 66 66 66 70 64 62 66 66 66 68 74 63 70 70 72 72 68 64 70 70 76 68 70 65 71 71 69 73 77 66 74 74 72 76 76 67 75 75 73 77 75 68 74 74 73 75 75 69 77 77 80 78 78 70 78 78 79 81 77 71 78 78 77 77 79 72 82 82 81 85 83 73 82 82 81 81 81 74 82 82 83 83 81 75 -- -- -- -- -- + +FCS (4byte)!!! while there are a few exceptions, the time difference increases with the increase in beacon length - this causes me to assume the timestamp is taken at the end of the packet, but unfortunately this are not too many samples and i can't measure bigger packets which is when it would get interresting... bruno _______________________________________________ ath5k-devel mailing list [email protected] https://lists.ath5k.org/mailman/listinfo/ath5k-devel
