Changes between Version 13 and Version 14 of 802.11/wlan_exp/app_notes/tutorial_token_mac/CPU_LOW

Timestamp:

Jul 14, 2015, 4:13:09 PM (9 years ago)

Author:

welsh

Comment:

--

802.11/wlan_exp/app_notes/tutorial_token_mac/CPU_LOW

@@ -239 +239 @@
 ----
 
-Finally, we need to make a change that is not technically critical to the operation of TokenMAC, but will make our lives much easier when we actually need to use it. One complication that arises from using timestamps to schedule events is that a node is capable of altering its timestamp an redefining when "now" is. This happens explicitly when you use the [https://warpproject.org/docs/mango-wlan-exp/node.html?highlight=time#wlan_exp.node.WlanExpNode.set_time set_time] method of wlan_exp. It also happens implicitly whenever a STA overrides its own timestamp with the timestamp of a received beacon from its AP. Whatever the reason, we should provide a way to tell the CPU_LOW application when the timestamp is about to change and by how much that change will be. We already created the {{{adjust_reservation_ts_callback}}} callback in the first change above. Now we just need to call it. The {{{wlan_mac_low_set_time()}}} in the MAC Low Framework is the only code that changes the underlying timestamp, so it is the best place to calculate the difference between the new timestamp and whatever the old timestamp was. Add the following snippet of code to the very top of {{{wlan_mac_low_set_time()}}} before it has a chance to actually set the new timestamp:
+Finally, we need to make a change that is not technically critical to the operation of TokenMAC, but will make our lives much easier when we actually need to use it. One complication that arises from using timestamps to schedule events is that a node is capable of altering its timestamp and redefining when "now" is. This happens explicitly when you use the [https://warpproject.org/docs/mango-wlan-exp/node.html?highlight=time#wlan_exp.node.WlanExpNode.set_time set_time] method of wlan_exp. It also happens implicitly whenever a STA overrides its own timestamp with the timestamp of a received beacon from its AP. Whatever the reason, we should provide a way to tell the CPU_LOW application when the timestamp is about to change and by how much that change will be. We already created the {{{adjust_reservation_ts_callback}}} callback in the first change above. Now we just need to call it. The {{{wlan_mac_low_set_time()}}} in the MAC Low Framework is the only code that changes the underlying timestamp, so it is the best place to calculate the difference between the new timestamp and whatever the old timestamp was. Add the following snippet of code to the very top of {{{wlan_mac_low_set_time()}}} before it has a chance to actually set the new timestamp: