Hi,
On 02/15/2013 02:58 PM, Johannes Berg wrote:
On Fri, 2013-02-15 at 14:48 +0100, Marco Porsch wrote:
I'm talking about this API:
mesh_neighbour_update:
...
tsf = drv_get_tsf()
...
sync_ops->rx_bcn(..., tsf)
mesh_sync_offset_rx_bcn(..., t_r):
...
if (have_better_timestamp)
t_r = get_better_timestamp()
You can hardly claim that's an intuitive API.
Hm, alright. Just saying that ieee80211_mps_sta_tbtt_update still uses
the unchanged TSF value. But hey :)
Well, that function doesn't exist in this patch...
What would be more favourable then?
I guess you can tell I'm not in a good mood today. I think any use of
get_tsf() for operation is a complete waste of time, there's no way you
can get the timings correct. You could be preempted, and suddenly sleep
for a few tens or hundreds milliseconds, so none of this makes any
sense... To properly do it you have to do calculations in relative times
and let the device apply them.
I don't get your last sentence here. Maybe you can elaborate?
Concerning timestamp vs. TSF usage; wow - I tested it when using the
timestamp value for TBTT scheduling. Works fine. Works even better than
TSF as it slightly reduces the measured wakeup overhead.
Hm, I was sure the TSF as in *now* would be more appropriate than the
TSF at receipt time... But either way, if it works better and is less
ugly, it is a win-win =)
I'll send an updated patch with the more intuitive API.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
