WARP Project Forums - Wireless Open-Access Research Platform

The precision with the fine scheduler is pretty arbitary. In fact, in the release of the 802.11 Reference Design v1.0, the fine schedule has a precision of 64µs and the coarse timer has a precision of 102.4ms. We changed from powers-of-ten µs to powers-of-two µs to make it easier to hit the beacon interval Time Unit (TU). You can increase the precision of the fine timer even further by reducing the "FAST_TIMER_DUR_US" on line 51 of wlan_mac_schedule.h. That #define is currently set to 64. Setting it to, for example, 32 would double the precision of that scheduler.

The way the architecture of the scheduler works is that scheduled events are effectively timestamped when you call wlan_mac_schedule_event_repeated(). The scheduler periodically checks the timestamps of every scheduled event to see if enough time has passed for it to then call whatever callback you provided. The "FAST_TIMER_DUR_US" defines the period of time between these polls of the event timestamps. So, there is a tradeoff here. The lower you make that duration, the more burden you place on CPU_HIGH to be checking schedules and the less time you give it to be doing its other responsibilities like processing both wireless and Ethernet transmissions and receptions. My intuition is that the 64µs precision we have currently given the fine timer is very conservative. Our characterizations of CPU_HIGH have shown that it is very idle even during heavy traffic load. I expect you'll be able to pull FAST_TIMER_DUR_US down significantly without observing any degradations in performance.

Also, be aware of one corner case. The periodic timer uses an axi_timer core connected to CPU_HIGH's interrupt controller. The "mb_high_timer_Interrupt" interrupt line from that core can be seen in line 832 of the MHS file. We give that line the second highest priority among all interrupts (seen by its location in that vector assignment). If you set FAST_TIMER_DUR_US to 0, my guess is that the interrupt from the axi_timer will always be high. Since it is a very high priority, that means the design will be stuck processing that interrupt and will never get around to processing any of the lower-priority interrupts like Ethernet. Keep FAST_TIMER_DUR_US strictly greater than 0 to avoid this.

I have one followup question. After the packets are precisely scheduled by adjusting FAST_TIMER_DUR_US, are there any parts in the microblaze or the core that could affect the timely "transmission" (not schedule) of the packet? I mean implementation-specific delays in WARP, other than "natural" 802.11 MAC delays such as ch. access delays, etc.

The usual Tx packet flow enqueues new packets in the appropriate Tx queue. In the reference implementation the AP has one queue per associated node, plus dedicated queues for management and multicast data packets. The Tx queues are polled in a two level round-robin scheme. The first level is between data queues vs the management queue. The second level is among the data queues. Thus, the time between a packet being enqueued and being transmitted depends on lots of other state at the AP (number of associated nodes, backlog of management traffic, backlog of traffic to other nodes).

CPU High dequeues one packet at a time, copies it to a Tx packet buffer then notifies CPU Low. For backlogged traffic this occurs while CPU Low is still transmitting the previous packet. Thus, the time between dequeue and actual Tx depends on the timing of the previous packet's Tx, plus any intermediate Rx events.

If you want to control the precise time the DCF starts its access attempt for a given packet, you will need to modify frame_transmit() in CPU Low. Both CPU Low and High can poll the node's microsecond timer. For example CPU High could use a field in the tx_frame_info to specify the future time until which CPU Low should defer transmission; CPU Low could then block, polling the node's timer until the specified time.

Hi,

Following up with the previous post, what would be the most effective way to verify
if the packets are enqueued (not transmitted) at the precise timing?
Can pin 8 of the debug header(Tx Pending) be used for this purpose?

Plus, to my understanding, pins 12:14 (Sw Debug) can be accessed from microblaze (mac high/low)
for measuring software execution times. Would you please provide some guidelines as to how this can be done?

Thanks!