You are not logged in.
Hi,
I used LTG to generate periodic data packet in WARP. I set the period of data packets to be 10ms, set the beacon period to be 100ms, and used reference design and "No MAC". I hope that WARP can send data packets every 10ms.
By checking "timestamp", "time_to_done", and "time_to_accept" of data packets in the log file, I find what WARP actually do is
1. Send one beacon every 100ms
2. Send data packets every 2ms
That means WARP sends beacons strictly periodic, but sends data packets as fast as possible. Maybe it is because WARP buffers the data packets and send them out as fast as possible. Am I right? How can I disable such buffer mechanism? I want to control the timing to send data packets.
Thank you
Offline
The LTG framework creates packets in CPU High and enqueues them, just like any other transmit packet. The LTG period controls the packet creation rate (i.e. the rate at which packets are enqueued). If you select a packet creation period larger than the time required to transmit the packet, the actual transmit intervals should match the packet creation interval pretty closely.
What rate/length did you select for the LTG packets? How did you configure the LTG (C code changes? wlan_exp commands in Python?)? My guess would be you somehow enabled a fully-backlogged LTG rather than a 10 msec Tx interval.
Offline
Hi murphpo,
This is the code I used to generate LTG packets
node1_ltg_id = node1.ltg_configure( wlan_exp_ltg.FlowConfigCBR( dest_addr = 0xffffffffffff, payload_length=1400, interval = 0.01), auto_start=True)
This is not a fully-backlogged ltg. Because based on your comments, a fully-backlogged ltg means interval set to 0. In addition, I did not change any C code for ltg. I also tried to set the interval to be 30ms, and observed similar results. Is this result reasonable?
Thank you
Offline
That ltg_configure command looks right, and should result in transmissions with an average period of 10msec.
What CPU High application (AP, IBSS) are you using?
Can you provide more details on how you're computing the actual inter-Tx time from the node log? Are you using the "timestamp" field values from TX_LOW_LTG entries?
Offline
Hi murphpo,
I am using AP as CPU high.
The timing is calculated using the "TX_LTG". I used the "timestamp" as the unqueue time, and find they are exactly every 10ms. I then added "time_to_done" and "time_to_accept" to "timestamp" as the time data packets are transmitted. I found they are transmitted as fast as possible (every 2ms) after beacon.
At the receiver side, I also used wireshark to collect data packets and verify this phenomenon.
I find when I set the time interval to 1s, it is OK. But 10ms, 30ms, 100ms, it doesn't work.
Offline
In addition, how can I use tools like ping, iperf to generate data packets and send them through WARP AP? Just use a wire to connect my computer and Eth A of WARP?
Thank you
Offline
Regarding your Ethernet question,
The short answer is "yes." A computer plugged into Eth A of a WARP 802.11 AP will be visible by a computer plugged into Eth A of a WARP 802.11 STA if the AP and STA are associated. The 802.11 implementation will not issue IP addresses (i.e. we do not implement a DHCP server). You will need to hardcode IP addresses on the same subnet at each computer or let the computers self-assign.
The long answer is that Ethernet behavior implements the "integration function" specified in Annex P of the 802.11-2012 standard. Details about Ethernet Encapsulation are available here. One important subtlety to keep in mind depending on your experiments -- an AP design can create transmissions for any number of source MAC addresses. In other words, you can have many computers connected to an Ethernet switch along with the AP. This is because the AP implements a true Ethernet portal and has no Ethernet MAC address itself (it passes everything through). This is not the case for the STA. You can only have a single PC connected to the STA because, from the AP's perspective, there is only a single destination MAC address for any given transmission to a wireless STA.
Last edited by chunter (2015-Dec-01 10:07:01)
Offline
Regarding your LTG question,
The behavior you are seeing is correct. It sounds like you are running into the DTIM / Power savings feature of the 802.11 AP implementation. You are enqueing packets at 10ms intervals, but they are only being transmitted in bursts after every beacon transmission. 802.11 specifies this behavior because 802.11 STA clients often sleep to save power. When they wake up to hear a beacon, the AP takes the opportunity to send any queued multicast frames. The reason large intervals seem to work as you expect is because they are larger than the beacon interval (100ms).
You can disable power savings in the AP design to get the behavior you are expecting with the ap_configure command. Specifically, call
n_ap.ap_configure(support_power_savings=false)
This will make it so that the AP does not wait on a beacon before sending a multicast data frame. It will just send it whenever it is enqueued.
Last edited by chunter (2015-Dec-01 10:07:20)
Offline
Thanks for the advice.
We tried your suggestion to turn off the power saving mode, and now the packets can be sent periodically, such as 5ms or 10ms.
However, if we set the interval to be a smaller value, say 1 ms, the packets are sent out at 2ms period.
Could we change something to send out the data packets at a finer granularity, for example 300 us?
Offline
300µs is shorter than your packet duration, so there is no way for the PHY to put back-to-back packets on the air at that interval. For the size of packet you are sending, 2ms appears to be the fastest interval between transmissions that you can sustain. You can potentially get this a little shorter by sending shorter packets at higher PHY rates. Also keep in mind that, at a minimum, each packet will be separated by a minimum contention backoff window. That means 7*9µsec = 63µs of idle time on average if there are no losses or interference.
Offline
Thanks, sir
If the packet on-air time is 300us, are we able to send out the packets at 400us period (400> 300+DIFS waiting) using warp theoretically (suppose we use no-mac)? Do we need to consider some potential delay in this system?
Offline
Assuming that the 300µs covers the full on-air time (including all PHY overhead -- preamble, SIGNAL, service, etc), then yes that interval should work. The DCF has a random backoff between transmissions. When it chooses slot 0, the next transmission will occur a DIFS interval after the transmission. The interval will be longer for larger slot selections. Also, it's worth noting that interval is capable of being faster for your scenario of using multicast data transmissions. For unicast transmissions, you'd also have to wait for the ACK reception.
Offline