You are not logged in.
Dear murpho, in relation to your reply for the point 2) of my previous answer my question is : when you said that the flow of transmission ACK-->DATA to the same station can be implemented in software do you mean that I can act just in the function frame_receive() in wlan_mac_dcf.c? If yes, should i add after the code above you indicated to me, a portion of code that follows the same mechanism you explained to me (and present in the code above for ACKs) to set another "cycle" of the auto_tx_state machine but in this case for transmitting the DATA packet?(Here the problem is that I can't call the fuction wlan_create_data_frame () to prepare a data packet).
Notice that frame_receive() is called from two places- from main(), if there is a reception when CPU Low is otherwise idle, and from frame_transmit(), if a reception starts while the MAC is deferring a transmission.
In the first context (from main()) there is no packet ready to transmit, so transmitting a DATA from from the context of frame_receive() would be hard, as no DATA packet has been passed down from CPU High. You would have to poll the mailbox to check if a new packet is ready, then prepare it for transmission, then transmit it, bypassing the normal frame_transmit() flow.
In the second context (from frame_transmit()) the packet has already been submitted to the MPDU Tx state machine for eventual transmission. This state machine waits for the backoff counter to reach zero, then triggers the PHY Tx. The only way to clear this state is to reset the MAC core. A flow like this might work:
-DATA from CPU High
-frame_transmit() submits DATA to MPDU Tx state machine
-frame_transmit() polls Rx while waiting for Tx
-frame_receive() gets new Rx
-frame_receive() decides to replace pending DATA with immediate DACK
-frame_receive() updates packet header, enables auto-tx, waits for Tx to start, then resets MAC core
One complication here is how to deal with responses to the DACK - if your protocol requires an ACK response, you will need to implement a post-DACK timeout and some sort of re-transmission scheme. This is a complicated state machine - you will need to map out exactly what exchanges are possible and how each sequence should be handled. We're happy to explain how our DCF implementation works, and how to manipulate its behavior, but we cannot explain exactly how to implement your custom protocol.
Offline
Dear murpho,
thank you for your previous reply.
I have some doubts for what you were meaning in the previous reply, but for now it's fine. At the moment I'm doing a simpler task, working with the simplest possible setup of one AP and one STA. I wrote in the code of high_ap that whenever it receives a DATA packet from the station it sends in turn a DATA packet to it (indipendently to the fact it's already transmitting or not).
I have only modified the code in that file and so I haven't touch the code in the high_framework and lower MAC levels and so the transmission of these packets are subjected to the usual DCF policy, backoff and waiting time to access the channel before the transmission.
How can I do from C code in order that this kind of "reply DATA packets", when passed from the upper MAC, to the lower MAC up to the Tx state machine in the MAC core, are sent immediately over the channel without waiting any backoff, SIFS or other time? Since I think I should act at LOW_MAC level, how can the program distinguish these packets as "special" and treat them in a different way?
Thank you!!
Offline
How can I do from C code in order that this kind of "reply DATA packets", when passed from the upper MAC, to the lower MAC up to the Tx state machine in the MAC core, are sent immediately over the channel without waiting any backoff, SIFS or other time? Since I think I should act at LOW_MAC level, how can the program distinguish these packets as "special" and treat them in a different way?
The CPU High -> Low interface for Tx packets uses a ping-pong buffering scheme. CPU Low operates on one Tx MPDU at a time. Once CPU Low sends the ACCEPT message to CPU High, the low-level MAC code works through the DCF state machine to transmit/re-transmit the MPDU. When it's finished, CPU Low sends the DONE message to CPU High, then checks for a new packet in the other buffer (ping -> pong -> ping, etc.).
CPU Low will process receptions in two contexts:
(a) While idle (not trying to transmit an MPDU)
(b) While deferring an MPDU transmission
If CPU Low is not already deferring an MPDU transmission when it receives a packet (case (a)) there is no DATA packet available to send. And there isn't time to request fetch one from CPU High and meet the Rx - SIFS - Tx timing.
In case (b) a Rx_DATA - SIFS - Tx_DATA exchange is possible is if CPU Low has already accepted an MPDU for transmission, is deferring, receives a frame, then decides to accelerate its MPDU transmission to immediately follow (or replace) the ACK.
Offline
Dear 802.11 developers,
thank you again for your time and yuor answer.
I would like to ask you some further questions about the reference design for 802.11 and related mechanism and have your opinion about the behaviour I'm obtaining in the tests. I summarize briefly my situation in order to let you understand what I'm working on and what I'm trying to do.
I'm working with three WARP boards (one AP and two STAs) to do my experiments. I'm using the reference design 802.11 v0.81 with an extended version of your throughput python script to collect the data of throughput between the nodes. I have seen that last week you published a new version of the reference design, but I believe that for my scope doesn't change using the old version or the new one.
I'm interested in working on wifi so I'm using three identical and common omnidirectional wifi antennes each one connected to the RF A of the board. When I run the tests I place the AP to be in a central position with respect the two STAs boards.
The first step of my work is to test the 802.11 DCF behaviour in terms of (uplink/downlink and network) throughput vs increasing network traffic load when the three boards compete to access the channel. The scope of this first step is to show the unfairness problem of DCF when the AP has much more data to send than the client STAs. For this in the python script I set 4 identical LTG flows : STA1-->AP, STA2-->AP, AP-->STA1 and AP-->STA2.
In these conditions I noticed that the WARP board programmed as AP blocks usually when it runs for long time and the traffic load it has to manage increases. The channel errors I obtained in the experiments are quite low (99% of transmitted packets were received correctly by and from the AP).
Apart from this I would like to point out the following:
1) In all my previous tests with the boards I haven't modify the default value of tx_gain for the nodes that is set to 45 and I obtained graphs of downlink throughput (AP-->STA1 + AP-->STA2) and uplink (STA1-->AP + STA2-->AP) differently from what I expected : in theory in saturation conditions (when the traffic of the network is sufficiently high)the DCF mechanisms ensure an equal share of the channel between the participants, in this case 1/3 (3 participants) for each competing stations and so I expect to obtain from the saturation point a (more or less) stable downlink throughput equal to the average per station uplink throughput (demonstrated by computer simulations tests). What I noticed in all my tests with the default tx_gain parameter of 45 is that the downlink is almost always penalized with respect to the uplink. I have obtained even an unbalance of 14 Mbps in uplink and 2 in downlink. I have tried to change this tx_gain parameter and I noticed that this has an influence on the results I'm obtaining. For now the results closer to what I'm expecting are obtained with tx_gain for the AP set to 47 and for the two STAs set to 30. I have seen in your code that this value should be between 0 and 63, but I haven't understood what this value exactly is. Could you please explain to me what this value is in the practice, the scale you use, its influence on the transmissions and in your opinion the correct values I have to set it for each node in my case in which the AP transmit double traffic (2 LTG flows) respect to each STA (1 LTG flow each) in order to let the board behave in the right way.
2) Again respect to the previous aspect in which the downlink is always penalized with respect to the uplink do you think that the fact that the AP has two LTG flows to transmit and two in input (total 4 to manage) and a single antenna, while each STA has only one LTG flow to transmit and one receiving in input (total 2 to manage) could be a possible cause of problem? I think this question is strictly related to the values to set for tx_gain. Maybe the single antenna in AP is not able to cope with the total load it has to manage to keep up with the stations.
If in your opinion, this could be the cause of problem is it possible to do a test in which I use two antennas for the AP (one in RFA and one in RFB) and say connect the LTG to and from the STA1 to antenna A and the ones to and from STA2 to antenna B and run the experiment in this way in which each antenna has only two LTG flows to manage (instead one has 4 ) and collect the data in the same way through WARPnet? If yes, what should I do to run this experiment?
3) Another frequently encountered problem, already mentioned in one of my previous question on the forum, is
that in each test one of the two station gains the channel more than the other even if the two stations are at the same distance from the AP. This appears essentially when the network traffic load is sufficiently high to be in saturation. I have done some test and it seems to me that one of the boards transmit less data (with equal and default tx_gain set to 45) than the other two. The three WARP v3 boards rev 1.1, have been purchased in three different instant of time in the last two years and they serial number are W3-a-00112, W3-a-00220 and W3-a-00339, the one that suffers this problems is latter that is the more recent. Do you think that this could be possible? Maybe it transmit with less power than the others. If this hyphotesis could be true in your opinion can you indicate to me a proper solution to counteract the problem?
The second step of my work concerns of implementing a modified "bidirectional" version of DCF protocol (also this already mentioned in my previous questions on this discussion and answered by you) that can allow a station when receiving a data packet to transmit in turn a data packet immediately without waiting the dcf classical mechanisms and timing to access the channel. For now I have tried to implement and test a simpler version of what I would like to do, without defining any new packet.
4)This idea concern in make the AP transmit an immediate data packet whenever it receives one from the two stations. For this purpose I have put in the function "mpdu_rx_process" of AP in CPU_HIGH a portion of code that when the
received header is of "SUBTYPE DATA" it creates a data frame, set the header as usual, set the flags field of the packet = 1(as a way to mark this kind of packets) by means of the function "wlan_mac_high_setup_tx_frame_info", enqueue and check the tx_queue as usual. In order to allow the transmission immediate of this kind of packets, without having to wait for backoff, I have put in the "frame_transmit" function in wlan_mac_dcf.c, before the set of instructions that write the SIGNAL field, set the phy tx_signal and submit the MPDU for transmissions , that if (mpdu_info->flags == 1) then n_slots = 0 (instead that random) that means setting a zero backoff in tx_state_machine and so transmitting this packet immediately. Since I don't have the possibility to work with an oscilloscope to verify that this kind of "reply" packets are effectively transmitted immediately over the channel, i have to "trust" in the code. Could you please say to me if the way I did is correct to transmit immediately a packet over the channel? otherwise how can I proceed ?
5)I have seen alternatively in phy_util.c the presence of the functions "void wlan_tx_buffer_sel(u8 n)" and "wlan_tx_start()" that from what I understood can allow to reach the immediate transmission directly skipping the tx in hardware through the state machine. I would like to know how these functions should be used in practice to transmit data packets ?
Thank you very much for your help.
Last edited by frenk88 (2014-Apr-17 14:42:55)
Offline
frenk88,
You may want to look more closely at a phenomenon called "capture" that will allow a strong STA to essentially over-power a hidden STA because of the relative RSSI of the two incoming STA's signals. There are two reasons I don't think this is the case in your scenario:
1. Because of the "nice" CSMA clique you've constructed in the lab, the nodes are most likely not hidden from each other.
2. As of right now, I don't believe that the 802.11 Reference Design implements any sort of intentional packet capture (read: can discard a weak packet currently being received to lock on to another, stronger packet).
Finally, given your application, you might want to look at a paper written at Rice a while back:
http://networks.rice.edu/ext/oar/index.html
Last edited by NuisanceParameter (2014-Apr-17 11:37:06)
Offline
Just to followup- we're not ignoring your questions. We're running experiments trying to reproduce asymmetry when many flows are running simultaneously. Our early tests suggest the DCF implementation is working fine, but we suspect the default physical carrier sensing threshold may be too high. This could lead to poor recovery from collisions, with some nodes responding worse than others. You can try the same tests by modifying the threshold in wlan_phy_util.c. Look for the line wlan_phy_rx_set_cca_thresh(PHY_RX_RSSI_SUM_LEN * 750); The value (750 here) is on a scale of [0,1023], where 0 is the lowest Rx power threshold for physical CCA.
We'll writeup and post results as soon as they're ready.
Offline
Thank you.
I will try to run experiments as you suggest modifying this value on the physical layer.
Waiting for your kind reply, best regards
Offline
Thanks for your patience. We have been running a bunch of multi-flow experiments and are now ready to share the results of that study. We have written an app note of some of the experiments here.
Like you, when we first ran the multi-flow over-the-air experiment, we observed throughput asymmetries that we could not initially explain. Worse, these throughput asymmetries seemed transient -- we would run an experiment in the morning and everything looked great, then running the same experiment later would produce radical throughput asymmetries. Using the WLAN Experiments Framework from the v0.9 Reference Design, we were able to dive deep into the results and eventually came up with an explanation for our asymmetries: physical carrier sensing. I can't be sure this is what you are seeing, but I think it's useful for us to document what we saw.
As the above app note discusses, physical carrier sensing has a profound effect on the performance of each flow in this experiment. As murphpo mentioned in the last response, the default physical carrier sensing threshold is set to 750 out of 1023 -- which corresponds to around -50dBm of Rx power. Take a look the plots of rx power in the app note: by sheer luck, we were running an experiment right in this regime. As it turns out, some of our kits were receiving at powers slightly above this threshold and some of them were receiving slightly below. Furthermore, channel fading made kits drift above and below this threshold. In short, physical CS wasn't consistently "enabled" on all of our kits throughout the whole experiment. This had the initially difficult-to-see effect of a transient hidden node problem.
To show what I mean, I just ran another experiment using the same experimental setup as described in the app note, but here I intentionally disabled physical CS at STA_1 and left it enabled at a low threshold on the other two kits. This is effectively the scenario we occasionally found ourselves in, when STA_1 was receiving packets below the 750 threshold but everyone else was receiving packets above the threshold.
Results:
Throughput histogram
STA_1 (who has physical CS disabled) is penalized heavily relative to the other flows. This is the asymmetry we initially had trouble explaining.
CW vs. Time
It's contention window is consistently higher than other flows, indicating that collisions due to failed CS is likely to blame.
Relative Tx Offsets of Collisions
This graph is the most compelling. Not only can you see the Flow 3 (STA_1 -> AP) has many collisions where the relative start times are > 1 slot, you can see the mean is nonzero. When collisions occur for Flow 3, its because the STA_1 started *after* another transmission. The reverse doesn't happen because they are able to CS the transmission of STA_1
I strongly recommend using the WLAN Experimental Framework to run your tests to allow you to see these sorts of effects. We'll be posting our code for the experiments that produced these results shortly after we clean it up. Also -- I know a big part of what you have seen is PHY rate dependent behavior. We haven't had a chance to run higher rate experiments yet. I'll reply and let you know what we find up there. In the meantime, it would be worthwhile to see if you can reproduce the expected throughput results at lower rates and lower physics CS thresholds.
Offline
We finished running a set of experiments for each of the 8 PHY rates that we support (6Mbps through 54Mbps). We posted those results in an appendix to the app note.
Offline
Dear chunter,
thank you for your reply and your comment of your results.
I have read your reply and the full experiment results discussion in the app notes.
Differently from your setup for the test you did with wifi antennas, in order to do my experiments I placed the AP in a middle position in order to have a station in an upper position and a station in a lower position respect to the AP : this results in a distance of about 40 cm between the AP's antenna and each STA' s antenna and a higher distance between the two stations antennas(say 80 cm). This position of the boards is jusified by the fact that is the one, between all the ones I tested, that seems to allow me to obtain the better results in term of throughput results as expected.
Moreover differently from you all my experiments have been based on the reference design 802.11 v0.81 and its experimental framework, but I don't think this matter on the results. i hope I can continue using the reference design 0.81 and its experimental framework because I have all the python script working for it, but if you think that for any reason I should switch to 0.9 let me know.
I notice the asymmetries when I run my python script that , performing a loop , set at each iteration the 4 equivalent LTG flows with payload of 1400 and decreasing packet generation interval between the iteration in order to generate an increasing traffic into the network at each test. The script calculate and collect in a file the data of downlink and uplink throughput vs increasing network load : each throughput point associated to a specific iteration is the result of a 1 minute test (each thput test per iteration last one minute). The assimmetries I have are essentially between the two uplink LTG flows (STA1-->AP and STA2-->AP) in which one of the two is always penalized and, in saturation traffic network condition, the total downlink (sum of the two outgoing flows from the AP) should be equal in teory to the uplink/2 since each competing station (including the AP) should gain the channel for equal time and so 1/3 each.
As you correctly said, a cause of the higher relevance of this problems and instability are due to the higher rate I'm using : mostly of the experiments I have done so far are at a rate of 54 Mbps and 48 Mbps since I'm interesting in obtaining the maxiumum achievable (uplink/downlink and network throughput) results of 802.11g. You seems to not have my problems at this higher rate from the results I see on the experiments through coaxial cable. Unfortunately, I can't reply your experiments with coaxial cable and attennuators because I don't have this kind of stuff.
1) Do you think that my problems could be both due to what you described of physical carrier sensing?
2)I'm not sure to have full understood the meaning of the physical carrier sensing threshold. it is the minimum power at which a station should receive packets in order to "trigger on it" the carrier sensing mechanism for its transmissions, right? So, for example, if STA1 receives pkts from the AP with a power below the threshold, while STA2 receives pkts from the AP with a power above the threshold then STA1 doesn't perform carrier sensing , while STA2 does and the transmission LTG flow for STA1 is penalized respect the one for STA2 and happens that the STA2 transmit more data correctly? Is it correct what I understood?
3)At the end, for you if the problem i have can be fully justificable to this aspect, can I mantain the default value of the physical carrier sensing thresold of 750 or should I lower this value in order to try to minimize the discussed problem and then repeating the experiments? If yes, which value do you suggest to set for the threshold? Moreover, should I try to change this threshold on a per station basis (different threshold for each station) or unique for all?
how can i find the correspondence between the value of the threshold and the value of rx power in dbm? The -70 dbm at which value of the threshold corresponds?
4)In order to run your experiment did you use the default value of 45 for the tx_gain for each different node even if the AP has two ongoing flow to manage? As I mention in point 3) of my previous post I obtain the better results for thput as expected in saturation (downlink equal more or less to average per station uplink)when the tx_gain of AP is set to 47 and 30 for the two stations, while if i use the default 45 for the three, the downlink is always below then the average uplink.In which way this parameter of tx_gain, that to be honest I don't know exactly what is, can influence the experiments and have an impact on easing the asymmetries and in relation to the carrier sensing aspect? I don't understand if this value of tx_gain can be somehow related to the physical carrier sensing discussion
4)In relation to the questions of point 4) and point 5) I made in the same previous post about the "bidirectional" communication version of DCF could you please give me your opinion/suggestion on them?
5)As a latter point I would like to let you notice a thing related to our early discussion present in this same post about the value of SIFS, DIFS, EIFS and ACK timeout. I have take a look on the values you set for them in the reference design 0.9 (wlan_mac_low.h) and I have seen that you modified them according to our discussion. In wlan_mac_dcf.c I have seen that when you prepare the autoresponder you subtract TX_PHY_DLY_100NSEC to T_SIFS*10, while in wlan_mac_low.c you did : wlan_mac_set_TxDIFS(((T_DIFS-PHY_RX_SIG_EXT_USEC)*10)-(TX_PHY_DLY_100NSEC))
I think that, to be coerent to the values of SIFS and DIFS, also here you should only subtract TX_PHY_DLY_100NSEC and not PHY_RX_SIG_EXT_USEC (and so leave wlan_mac_set_TxDIFS(((T_DIFS-PHY*10)-(TX_PHY_DLY_100NSEC)) ), otherwise the final value of DIFS is not the correct one. Am I right?
Thank you again for repy and your infinite patience. i appreciate any comments and hints.
Offline
frenk88 wrote:
this results in a distance of about 40 cm between the AP's antenna and each STA' s antenna and a higher distance between the two stations antennas(say 80 cm). This position of the boards is jusified by the fact that is the one, between all the ones I tested, that seems to allow me to obtain the better results in term of throughput results as expected.
With a topology this small and close together, you definitely want to pull the transmit power down. At the 1m spacing we used in the app note, we pulled the Tx power down from the default 10dBm to -5dBm. This resulted in a received power of ~-50dBm, which is plenty for any of the 8 rates we support.
frenk88 wrote:
Moreover differently from you all my experiments have been based on the reference design 802.11 v0.81 and its experimental framework, but I don't think this matter on the results. i hope I can continue using the reference design 0.81 and its experimental framework because I have all the python script working for it, but if you think that for any reason I should switch to 0.9 let me know.
The v0.8 Reference Design is a snapshot of the SVN repository at rev. 2800. The v0.91 Reference Design is a snapshot of the SVN repository at rev. 3408. Those 608 revisions are almost entirely improvements in the WARPnet experiments framework you are using. I highly recommend moving over to the new design so that you can use all of the new features like the event log (which we used heavily in the app note).
frenk88 wrote:
As you correctly said, a cause of the higher relevance of this problems and instability are due to the higher rate I'm using : mostly of the experiments I have done so far are at a rate of 54 Mbps and 48 Mbps since I'm interesting in obtaining the maxiumum achievable (uplink/downlink and network throughput) results of 802.11g. You seems to not have my problems at this higher rate from the results I see on the experiments through coaxial cable. Unfortunately, I can't reply your experiments with coaxial cable and attennuators because I don't have this kind of stuff.
Does the relative asymmetry improve at all if you lower the Tx power? One thing we did notice is that the 10dBm default Tx power might be a little too high. It doesn't seem to matter for the lower rates, but at the higher rates we did notice quite a few transmission errors due to the well-known OFDM PAPR issue. Backing Tx power off from 10dBm to 5dBm in the app note's appendix addressed that. You'll want to pull it down anyway given the small, close, line-of-site topology you are working with.
frenk88 wrote:
1) Do you think that my problems could be both due to what you described of physical carrier sensing?
It's definitely possible, but I can't say for certain. It was the cause of asymmetry for us. Once you migrate to the 0.9 release and once we clean up and post our test scripts, you can use those to directly analyze the log of events from your experiment. It might show you definitively if this is happening.
frenk88 wrote:
2)I'm not sure to have full understood the meaning of the physical carrier sensing threshold. it is the minimum power at which a station should receive packets in order to "trigger on it" the carrier sensing mechanism for its transmissions, right? So, for example, if STA1 receives pkts from the AP with a power below the threshold, while STA2 receives pkts from the AP with a power above the threshold then STA1 doesn't perform carrier sensing , while STA2 does and the transmission LTG flow for STA1 is penalized respect the one for STA2 and happens that the STA2 transmit more data correctly? Is it correct what I understood?
Yes, you are correct. One additionally subtlety is that there are actually two forms of carrier sensing in 802.11: physical and virtual. If STA_1 is currently receiving a packet from anyone else, it will not start a transmission during that reception even if that reception is below it's physical carrier sensing threshold. Where this breaks down is collisions. Suppose STA_2 and AP both transmit at the same time. STA_1 may not even recognize that there is something to receive because the collision can so thoroughly destroy the potential reception (i.e., the PHY's SIGNAL field gets corrupted and reception is cancelled). In this case, if the collided packets power do not exceed the physical carrier sensing threshold, then STA_1 may try to start transmitting in the middle of the collision between STA_2 and AP.
frenk88 wrote:
3)At the end, for you if the problem i have can be fully justificable to this aspect, can I mantain the default value of the physical carrier sensing thresold of 750 or should I lower this value in order to try to minimize the discussed problem and then repeating the experiments? If yes, which value do you suggest to set for the threshold? Moreover, should I try to change this threshold on a per station basis (different threshold for each station) or unique for all?
how can i find the correspondence between the value of the threshold and the value of rx power in dbm? The -70 dbm at which value of the threshold corresponds?
The [0, 1023] threshold is a threshold on the 10-bit ADC sampling the RSSI signal from the transceiver. This digital value can be mapped onto a power in dBm. Figuring out that mapping is a little convoluted, involving performing a linear fit of the data in the MAX2829 transceiver datasheet that describes the input power -> voltage mapping on the RSSI port. We've done this fit already and made a C-function that the 802.11 Reference Design uses to map RSSI on to dBm. For the purposes of the discussion here, the physical CS threshold can be mapped as such:
thresh_power = (200/3069)*thresh_digital - (280/3)
So, the default threshold of 750 is actually a very-high power of ~-44dBm. Anything less than -44dBm of undecodable energy is effectively ignored by the CS subsystem. For what it is worth, the standard states:
802.11-2012 Standard wrote:
The start of a valid OFDM transmission at a receive level equal to or greater than the minimum modulation and coding rate sensitivity (–82 dBm for 20 MHz channel spacing, –85 dBm for 10 MHz channel spacing, and –88 dBm for 5 MHz channel spacing) shall cause CS/CCA to indicate busy with a probability > 90% within 4 μs for 20 MHz channel spacing, 8 μs for 10 MHz channel spacing, and 16 μs for 5 MHz channel spacing. If the preamble portion was missed, the receiver shall hold the CCA signal busy for any signal 20 dB above the minimum modulation and coding rate sensitivity (–62 dBm for 20 MHz channel spacing, –65 dBm for 10 MHz channel spacing, and –68 dBm for 5 MHz channel spacing).
To be strictly standards-compliant, the threshold should probably be set to 480 (which maps to -62dBm). We dropped it all the way down to -77dBm (threshold of 250). That was probably an overkill, but it did ensure that all three nodes were in CS range of one another.
Long story short -- you probably want to pull the threshold down. I'd say try 250 just to see what happens and see if it has any effect.
frenk88 wrote:
4)In order to run your experiment did you use the default value of 45 for the tx_gain for each different node even if the AP has two ongoing flow to manage? As I mention in point 3) of my previous post I obtain the better results for thput as expected in saturation (downlink equal more or less to average per station uplink)when the tx_gain of AP is set to 47 and 30 for the two stations, while if i use the default 45 for the three, the downlink is always below then the average uplink.In which way this parameter of tx_gain, that to be honest I don't know exactly what is, can influence the experiments and have an impact on easing the asymmetries and in relation to the carrier sensing aspect? I don't understand if this value of tx_gain can be somehow related to the physical carrier sensing discussion
The 0.91 Reference Design has abstracted away the tx_gain target to be in terms of Tx power in dBm. Furthermore it can be set directly in your Python script. For the over-the-air test, we dropped to -5dBm, which corresponds to a tx_gain target of 15. For the over-the-RF-cabline tests in the appendix, we used a Tx power of +5dBm, which corresponds to a tx_gain target of 35. The mapping between Tx power (in dBm) and Tx gain is:
tx_gain = 2*tx_power + 25
frenk88 wrote:
5)As a latter point I would like to let you notice a thing related to our early discussion present in this same post about the value of SIFS, DIFS, EIFS and ACK timeout. I have take a look on the values you set for them in the reference design 0.9 (wlan_mac_low.h) and I have seen that you modified them according to our discussion. In wlan_mac_dcf.c I have seen that when you prepare the autoresponder you subtract TX_PHY_DLY_100NSEC to T_SIFS*10, while in wlan_mac_low.c you did : wlan_mac_set_TxDIFS(((T_DIFS-PHY_RX_SIG_EXT_USEC)*10)-(TX_PHY_DLY_100NSEC))
I think that, to be coerent to the values of SIFS and DIFS, also here you should only subtract TX_PHY_DLY_100NSEC and not PHY_RX_SIG_EXT_USEC (and so leave wlan_mac_set_TxDIFS(((T_DIFS-PHY*10)-(TX_PHY_DLY_100NSEC)) ), otherwise the final value of DIFS is not the correct one. Am I right?
Yes, I think you are correct. Great catch. I'll confirm with the other designers of the 802.11 design.
---- From your earlier post ----
frenk88 wrote:
The second step of my work concerns of implementing a modified "bidirectional" version of DCF protocol (also this already mentioned in my previous questions on this discussion and answered by you) that can allow a station when receiving a data packet to transmit in turn a data packet immediately without waiting the dcf classical mechanisms and timing to access the channel. For now I have tried to implement and test a simpler version of what I would like to do, without defining any new packet.
4)This idea concern in make the AP transmit an immediate data packet whenever it receives one from the two stations. For this purpose I have put in the function "mpdu_rx_process" of AP in CPU_HIGH a portion of code that when the
received header is of "SUBTYPE DATA" it creates a data frame, set the header as usual, set the flags field of the packet = 1(as a way to mark this kind of packets) by means of the function "wlan_mac_high_setup_tx_frame_info", enqueue and check the tx_queue as usual. In order to allow the transmission immediate of this kind of packets, without having to wait for backoff, I have put in the "frame_transmit" function in wlan_mac_dcf.c, before the set of instructions that write the SIGNAL field, set the phy tx_signal and submit the MPDU for transmissions , that if (mpdu_info->flags == 1) then n_slots = 0 (instead that random) that means setting a zero backoff in tx_state_machine and so transmitting this packet immediately. Since I don't have the possibility to work with an oscilloscope to verify that this kind of "reply" packets are effectively transmitted immediately over the channel, i have to "trust" in the code. Could you please say to me if the way I did is correct to transmit immediately a packet over the channel? otherwise how can I proceed ?
I think this will work, but there are a couple of subtleties of doing it this way:
1) The transmission won't be a SIFS interval after the reception. It will be sometime after. The only way we were able to transmit ACKs a SIFS after a reception is by constructing the packet mid-reception and prepping the automatic response hardware. This means that when your packet does send, it will be sometime later, potentially even after a DIFS where other nodes are starting to contend.
2) In this setup frame_transmit won't be called immediately if CPU_LOW is currently dealing with another transmission. Say, for example, that the AP is currently sending to STA_1 and backing off between retransmissions. You might receive a packet from STA_1 and try to send down a new Tx from CPU_High in response to that transmission. The message from CPU_HIGH won't be processed until the ongoing packet to STA_1 is complete (either successfully or failure). If your AP *only* sends traffic as a response to receptions, I think it's fine, since there wouldn't be any ongoing transmission to stall your new transmission.
frenk88 wrote:
5)I have seen alternatively in phy_util.c the presence of the functions "void wlan_tx_buffer_sel(u8 n)" and "wlan_tx_start()" that from what I understood can allow to reach the immediate transmission directly skipping the tx in hardware through the state machine. I would like to know how these functions should be used in practice to transmit data packets
I need to discuss this with murphpo. Either he or I will weigh in on this in another reply.
Offline
I talked to murphpo about your last question. I think those two functions will let you do what you want. It will immediately kickstart the transmission and bypass the hardware DCF. Important caveat: you need to make sure that the TX state machine is completely idle before you do this. If the DCF hardware is currently running (for example, in a backoff), using these low-level functions will produce unpredictable results. Said another way, you need to be outside of the context of frame_transmit() before you can safely use those functions.
Offline
Dear chunter,
thank you for your reply. I understood useful things that previously I didn't know.
Summarizing all what you suggest to me to do in order to work with my close topology is
- switch to the latest reference design and when you will load your code I will try to do the experiment to test the asimmetry between the different flow
- use a css physical threshold of 250 instead that the one by default of 750
- use a lower transmission power
I hope the cause of problem can be fully associated to the fact we discussed of physical carrier sensing even if today I concluded something that maybe can discard this as the possible cause. Now I will explain to you this:
Observing the informaton displayed in the putty terminals of the boards (uart menu) I have seen that using the already mentioned tx_gain for the AP of 47 (tx_power = 11 dbm) and for the STAs of 30 (tx_power=2.5 dbm), and equal antennas RUBBER DUCK WIFI with a gain of 2.2 dbi ( from the datasheet :http://www.l-com.com/multimedia/datasheets/DS_HG2402RD-RSF.PDF) I can observe from Putty that rx_power between the boards stations are different : from STA1 the AP receives packets with power -73 dbm, while from STA2 it receives packets with power -78 dbm, while the two stations receives packets from the AP with power around - 70 dbm.
Since in all my tests i have used the same topology (same position of the boards)without modifying the default threshold of 750, from our discussion, this means that the physical carrier sensing mechanisms never were active for any of the 3 boards in all the tests I performed. If this is true, I conclude that the asymmetries can no more be explained with the fact, as happened to you, that one board performs physical carrier sensing while another doesn't, because no one performed this mechanism.
1)Do you agree with me on this? if this is true the cause of the problem is again a mistery.
Maybe I should give up with this setup I'm using and move the boards more distant between them. i don't think I can work like you at a distance of 1m, because the antenna I'm using have a lower gain than the one you used but maybe i can compensate the 5 dbm in difference between the gain of your antennas and my antennas with a 5 dbm-higher transmission power than the one you used. This means that i should use for all the boards a tx_power of 0 dbm use the same your topology with the boards distanced of 1m and, if all make sense, I should obtain a rx_power like the one you obtained of around - 50 dbm. I should understand how to match these factors to let my experiment work like yours.
2)I have download the reference design 0.91 and tried to compile in Xilinx, but following the same procedure as usual with the previous reference designs in order to have a "working" workspace i get a number of compilation errors related to the absence of some header files in the different project and in particular for wlan_mac_low_framework and high_framework(xparameter.h, xil_types.h, warp_hw_ver.h, xilnet_config.h, xaxiethernet.h, xaxidma.h, xintc.h ).
What is the cause for these errors? What I shoud do in order to fix them?
3)Last. About your suggestion in how to use the two funcions to skip the tx_state_machine to trasmit immediately packets:
chunter wrote:
Said another way, you need to be outside of the context of frame_transmit() before you can safely use those functions.
Do you think that can be a "safe" place to use them in frame_receive, when a packet of data is correctly received from a station, and reply with an immediate data packet directly at this point with the two functions? In other words do you think the following can works fine without any further thought :
if(!WLAN_IS_CTRL_FRAME(rx_header)) {
//This packet should be passed up to CPU_high for further processing
if(unicast_to_me){
//This good FCS, unicast, noncontrol packet was ACKed.
mpdu_info->flags |= RX_MPDU_FLAGS_ACKED;
wlan_tx_buffer_sel(pkt_buf) ;
wlan_tx_start();
}Otherwise where do you suggest to use the two?
Thank you
Last edited by frenk88 (2014-Apr-26 04:33:16)
Offline
Just for your information, we updated the multi-flow app note with the data gathering and analysis scripts as well as the actual log data we pulled from out experiment. These scripts rely on the newly-posted Mango 802.11 Reference Design v.92 (which had some small but important bug fixes from v.91 -- it should be an easy upgrade from 0.91 to 0.92)
frenk88 wrote:
Observing the informaton displayed in the putty terminals of the boards (uart menu) I have seen that using the already mentioned tx_gain for the AP of 47 (tx_power = 11 dbm) and for the STAs of 30 (tx_power=2.5 dbm), and equal antennas RUBBER DUCK WIFI with a gain of 2.2 dbi ( from the datasheet :http://www.l-com.com/multimedia/datasheets/DS_HG2402RD-RSF.PDF) I can observe from Putty that rx_power between the boards stations are different : from STA1 the AP receives packets with power -73 dbm, while from STA2 it receives packets with power -78 dbm, while the two stations receives packets from the AP with power around - 70 dbm. Since in all my tests i have used the same topology (same position of the boards)without modifying the default threshold of 750, from our discussion, this means that the physical carrier sensing mechanisms never were active for any of the 3 boards in all the tests I performed. If this is true, I conclude that the asymmetries can no more be explained with the fact, as happened to you, that one board performs physical carrier sensing while another doesn't, because no one performed this mechanism.
1)Do you agree with me on this? if this is true the cause of the problem is again a mistery.
Maybe I should give up with this setup I'm using and move the boards more distant between them. i don't think I can work like you at a distance of 1m, because the antenna I'm using have a lower gain than the one you used but maybe i can compensate the 5 dbm in difference between the gain of your antennas and my antennas with a 5 dbm-higher transmission power than the one you used. This means that i should use for all the boards a tx_power of 0 dbm use the same your topology with the boards distanced of 1m and, if all make sense, I should obtain a rx_power like the one you obtained of around - 50 dbm. I should understand how to match these factors to let my experiment work like yours.
Couple of things:
1) I definitely wouldn't go higher than a tx_gain of 45. I'm pretty sure that 45 is too high for the higher rates, let alone 47.
2) You are seeing a tremendous amount of path loss in that setup. You should be seeing powers ~-30 dBm with that configuration, not ~-70dB. That data sheet for your antenna states that it is a reverse polarity SMA connector. As stated in the WARPv3 Hardware User Guide, WARP v3 uses a standard polarity SMA connector. Unplug your antenna and take a look at the two connectors. The connector on the antenna should have a pin that mates with the RF connector on WARP v3. I suspect you will see that neither side has a pin, and instead you are only seeing signal that manages to couple across the air gap. I think that is where all your signal is going.
I agree that probably none of your boards were properly carrier sensing the transmissions from other boards. That said, it's possible that some of your boards were carrier sensing other 802.11 devices on the same channel. You should definitely try re-running your experiments with the correct antennas, lower physical CS threshold, and lower Tx Powers.
frenk88 wrote:
2)I have download the reference design 0.91 and tried to compile in Xilinx, but following the same procedure as usual with the previous reference designs in order to have a "working" workspace i get a number of compilation errors related to the absence of some header files in the different project and in particular for wlan_mac_low_framework and high_framework(xparameter.h, xil_types.h, warp_hw_ver.h, xilnet_config.h, xaxiethernet.h, xaxidma.h, xintc.h ).
What is the cause for these errors? What I shoud do in order to fix them?
Could you copy and paste the compilation errors into a reply? Do you still see them for the 0.92 release?
frenk88 wrote:
3)Last. About your suggestion in how to use the two funcions to skip the tx_state_machine to trasmit immediately packets:
Do you think that can be a "safe" place to use them in frame_receive, when a packet of data is correctly received from a station, and reply with an immediate data packet directly at this point with the two functions? In other words do you think the following can works fine without any further thought :
frame_receive() isn't, in general, a safe place. There are two ways into the frame_receive() function:
1) From polling in main()
2) From within frame_transmit()
For the first case, you'd be safe to call the low-level transmit functions. For the second case, frame_transmit() actually calls frame_receive() to deal with the case of receiving a packet during a transmission timeout. This is *not* a safe time to call the low-level transmit functions. One idea is that you could add an argument to frame_receive so that code inside frame_receive knows how that function was called. For example, in the main() loop, you could call frame_receive(0) and in frame_transmit(), you could call frame_receive(1). Then you could execute the low-level transmit functions only when the argument is 0.
Offline
Dear chunter,
thank you.
Regard the antenna, you are totally right about the kind of connector. The antennas I was currently using have a reverse-polarity SMA connector. It is not an SMA male connector, it has not the pin to mates with the SMA connector in the board. At the moment I don't was able to find any right antennas. I should buy them.
Now, I have tried with other 3 wifi antennas (I don't know the model of the latter but they are more bigger and for sure with higher gain), also these with reverse-polarity SMA connector and in this case I can see from Putty that, even with the boards more distanciated (respect the classical 40 cm distance), the rx_power is around - 20 dbm.
I don't understand how this is possible if the two connectors don't match between them.
I have not yet run any throughput experiments with these antennas. If these antennas can guarantee such a rx_power even if the SMA connector is not the correct one , do you think that I can work with them as if I was using
right antennas or should I not definitely trust working with them?
About the new reference design. I have tried also to do the procedure with the 802.11 v0.92 but I get the same compilation errors. I specify that I use the Xilinx SDK 14.4, because I read another discussion with a user getting a compilation xparameters.h compilation errors, but with version 14.7. I did the build and clean of the project but nothing change.
The compilation errors for the 3 projects (AP,STA,DCF) are saying that in the files that recall the header files i mentioned are absent.
e.g: wlan_mac_high_framework/wlan_mac_eth_util.c:16:26: fatal error: xaxiethernet.h: No such file or directory
compilation terminated.
For the two bsp high and low I get:
bsp_cpu_high:
ERROR:EDK:3323 - C:\Users\Francesco\Desktop\universita\tesi\Xilinx\ultimissimo\workspace\SDK_W orkspace\wlan_bsp_cpu_high\system.mss line 153 - Cannot find MDD file w3_userio_axi_v2_1_0.mdd for the driver w3_userio_axi 1.01.a INFO:EDK:1040 - Directories Searched : - C:\Users\Francesco\Desktop\universita\tesi\Xilinx\ultimissimo\workspace\SDK_Work space\wlan_bsp_cpu_high\drivers/w3_userio_axi_v1_01_a/data - C:\Users\Francesco\Desktop\universita\tesi\Xilinx\ultimissimo\workspace\SDK_Work space\wlan_bsp_cpu_high\pcores/w3_userio_axi_v1_01_a/data - C:\Users\Francesco\Desktop\universita\tesi\Xilinx\ultimissimo\workspace\drivers/ w3_userio_axi_v1_01_a/data - C:\Users\Francesco\Desktop\universita\tesi\Xilinx\ultimissimo\workspace\pcores/w 3_userio_axi_v1_01_a/data - C:\WARP_Repository\edk_user_repository\drivers/w3_userio_axi_v1_01_a/data - C:\WARP_Repository\edk_user_repository\pcores/w3_userio_axi_v1_01_a/data - C:\Xilinx14\14.4\ISE_DS\EDK\sw\lib\drivers/w3_userio_axi_v1_01_a/data - C:\Xilinx14\14.4\ISE_DS\EDK\sw\lib\pcores/w3_userio_axi_v1_01_a/data - C:\Xilinx14\14.4\ISE_DS\EDK\sw\XilinxProcessorIPLib\drivers/w3_userio_axi_v1_01_ a/data - C:\Xilinx14\14.4\ISE_DS\EDK\sw\XilinxProcessorIPLib\pcores/w3_userio_axi_v1_01_a /data - C:\Xilinx14\14.4\ISE_DS\EDK\sw\ThirdParty\drivers/w3_userio_axi_v1_01_a/data - C:\Xilinx14\14.4\ISE_DS\EDK\sw\ThirdParty\pcores/w3_userio_axi_v1_01_a/data INFO:EDK:772 - Check the following for possible causes of not finding MDD: - If DRIVER_VER is specified in MSS, it must follow literal form X.YY.Z - There is no driver with given name - Driver exists but not that version - Driver and version (directory) exist but no MDD is available ERROR:EDK:1204 - Errors occured while creating Software System. make: *** [mb_high/lib/libxil.a] Error 2 make: Target `all' not remade because of errors.
bsp_cpu_low:
ERROR:EDK:3323 - C:\Users\Francesco\Desktop\universita\tesi\Xilinx\ultimissimo\workspace\SDK_W orkspace\wlan_bsp_cpu_low\system.mss line 93 - Cannot find MDD file w3_userio_axi_v2_1_0.mdd for the driver w3_userio_axi 1.01.a INFO:EDK:1040 - Directories Searched : - C:\Users\Francesco\Desktop\universita\tesi\Xilinx\ultimissimo\workspace\SDK_Work space\wlan_bsp_cpu_low\drivers/w3_userio_axi_v1_01_a/data - C:\Users\Francesco\Desktop\universita\tesi\Xilinx\ultimissimo\workspace\SDK_Work space\wlan_bsp_cpu_low\pcores/w3_userio_axi_v1_01_a/data - C:\Users\Francesco\Desktop\universita\tesi\Xilinx\ultimissimo\workspace\drivers/ w3_userio_axi_v1_01_a/data - C:\Users\Francesco\Desktop\universita\tesi\Xilinx\ultimissimo\workspace\pcores/w 3_userio_axi_v1_01_a/data - C:\WARP_Repository\edk_user_repository\drivers/w3_userio_axi_v1_01_a/data - C:\WARP_Repository\edk_user_repository\pcores/w3_userio_axi_v1_01_a/data - C:\Xilinx14\14.4\ISE_DS\EDK\sw\lib\drivers/w3_userio_axi_v1_01_a/data - C:\Xilinx14\14.4\ISE_DS\EDK\sw\lib\pcores/w3_userio_axi_v1_01_a/data - C:\Xilinx14\14.4\ISE_DS\EDK\sw\XilinxProcessorIPLib\drivers/w3_userio_axi_v1_01_ a/data - C:\Xilinx14\14.4\ISE_DS\EDK\sw\XilinxProcessorIPLib\pcores/w3_userio_axi_v1_01_a /data - C:\Xilinx14\14.4\ISE_DS\EDK\sw\ThirdParty\drivers/w3_userio_axi_v1_01_a/data - C:\Xilinx14\14.4\ISE_DS\EDK\sw\ThirdParty\pcores/w3_userio_axi_v1_01_a/data INFO:EDK:772 - Check the following for possible causes of not finding MDD: - If DRIVER_VER is specified in MSS, it must follow literal form X.YY.Z - There is no driver with given name - Driver exists but not that version - Driver and version (directory) exist but no MDD is available ERROR:EDK:1204 - Errors occured while creating Software System. make: *** [mb_low/lib/libxil.a] Error 2 make: Target `all' not remade because of errors.
Hope I posted enough info.
Last edited by frenk88 (2014-Apr-28 16:20:13)
Offline
ERROR:EDK:3323 -
C:\Users\Francesco\Desktop\universita\tesi\Xilinx\ultimissimo\workspace\SDK_W
orkspace\wlan_bsp_cpu_high\system.mss line 153 - Cannot find MDD file
w3_userio_axi_v2_1_0.mdd for the driver w3_userio_axi 1.01.a
INFO:EDK:1040 - Directories Searched :
This is the actual error- the tools cannot find the driver for the w3_userio_axi v1.01.a core. Is your local copy of the WARP edk_user_repository up to date? The 1.01.a core was new before the v0.9 release.
Offline
Regard the antenna, you are totally right about the kind of connector. The antennas I was currently using have a reverse-polarity SMA connector. It is not an SMA male connector, it has not the pin to mates with the SMA connector in the board. At the moment I don't was able to find any right antennas. I should buy them.
Now, I have tried with other 3 wifi antennas (I don't know the model of the latter but they are more bigger and for sure with higher gain), also these with reverse-polarity SMA connector and in this case I can see from Putty that, even with the boards more distanciated (respect the classical 40 cm distance), the rx_power is around - 20 dbm.
I don't understand how this is possible if the two connectors don't match between them.
I have not yet run any throughput experiments with these antennas. If these antennas can guarantee such a rx_power even if the SMA connector is not the correct one , do you think that I can work with them as if I was using
right antennas or should I not definitely trust working with them?
You should definitely use antennas with standard SMA plugs. Using a reverse-polarity plug on a standard-polarity jack results in no electrical connection between the PCB and the antenna element. The results of this will be unpredictable (i.e. if you screw the plug on well, you might get sufficient coupling to operate at short-to-medium ranges, but this cannot be relied on).
Offline
Hi, as your suggestion doing an "update" of the edk_user_repository was exactly the solution to solve the compilation errors in the reference design. All what remain is the following:
08:59:41 ERROR : Unable to read in MSS file C:\..\SDK_Workspace\wlan_bsp_cpu_low\system.mss.
but this is "marked" as a message in the console and not as error.
Again, last i hope about the antenna question. I have tried to look around in my university department but I'm not able to find any available right antenna of this kind i need with standard polarity and male SMA connector.
Do you think that, instead buying antennas, should be good as well , buying adaptors RP-SMA-Female to RP-SMA-Female (e.g http://www.ebay.it/itm/RP-SMA-Female-to … 43c8217f7b) and apply them directly on the antenna i have to match correctly with the WARP SMA connector and work correctly as well?
since looking on the web i get more confused if i have a male SMA, attached to the board, it's all what I need? Reverse polarity means that on the antenna I have a female termination right? Standard polarity is the same of male SMA right?
Last edited by frenk88 (2014-Apr-29 07:32:24)
Offline
Reverse polarity means that on the antenna I have a female termination right? Standard polarity is the same of male SMA right?
The images on this page are a good guide.
Some manufacturers use "Plug" and "Jack", where Plug == Male, Jack == Female.
The connectors on the WARP v3 board are standard-polarity SMA jacks (female). The mated cable, adapter or antenna must have standard-polarity SMA plugs (male).
RP-SMA to SMA adapters work fine in our experience.
Offline
chunter wrote:
I think the error in the calculation is in the use of T_ACK = 50µs, which is the duration of an ACK at 6Mbps including the 6µs of signal extension. ACK durations are a function of the rate being used. At the 54Mbps rate for DATA packets, ACKs are sent back at 24Mbps. The duration of an ACK at 24Mbps is only 28µs (not counting signal extension, which we lump into the SIFS calculation of 16µs instead of 10µs). I think that reduction in time for each packet accounts for the throughput difference.
Hi, I remember ACK size is 14bytes, the duration is 14*8/24=4.6us. I did not understand the 28us.
Offline
The MAC payload for an ACK is 14 bytes (FRAME_CTRL[0:1] DURATION_ID[0:1] ADDR1[0:5] FCS[0:3]). The total waveform duration includes the preamble, PHY header, and MAC payload. Refer to the wlan_ofdm_calc_txtime() helper function for details.
Offline
frenk88 wrote:
I took a look of the graph here: http://warpproject.org/trac/wiki/802.11 … Throughput
In particular I have noticed that the value at a rate of 54 Mbps with a payload of 1500 byte is 29.6 Mbps.
I tried to calculate this value and what I get is 29.3 Mbps (ideal one). What surprise to me is that your value is above the one calculated by me.
In order to calculate this value I used the following step:
throghput = (L_PAYLOAD*8)/(T_DIFS+T_BACKOFF+T_DATA+T_SIFS+T_ACK)
with L_payload=1500 bytes, T_DIFS=34 usec, T_BACKOFF=(CWmin -1)*Tslot/2=67.5 usec , Tslot= 9 usec, CWmin=16 usec
T_DATA = T_PREAMBLE+T_SIGNAL+T_SYMB*CEILING(L_SERVICE+L_TAIL+(L_MAC+L_PAYLOAD))/N_dbps + T_EX =254 usec con
T_SIFS=16 usec T_ACK=50 usec, N_DBPS=216 (x data rate 54Mbps)
Which is the formula implemented in your code to calculate T_ACK and T_DATA that are respectively the time to trasmit the a data packet and an ACK packet? did you try also to verify your obtained throughput data through this formula?
Hi，murphpo:
1.N_DBPS is N_DATA_BITS_PER_SYM, why is it 216 (x data rate 54MBps). This means a symbol with 216 bits?
2.T_SIGNAL not exist in your script, so what is this value?
Thank you!
Last edited by TIM (2018-Aug-15 06:41:01)
Offline
murphpo wrote:
The MAC payload for an ACK is 14 bytes (FRAME_CTRL[0:1] DURATION_ID[0:1] ADDR1[0:5] FCS[0:3]). The total waveform duration includes the preamble, PHY header, and MAC payload. Refer to the wlan_ofdm_calc_txtime() helper function for details.
Another question is that:
How to choose PHY_rate from (10,20,40) at 54Mbps?
Offline
PHY_rate is 20 (20 MSps) for normal 802.11 waveforms. Our design also supports (non-standard) 10 and 40 MSps sampling rates.
Offline
TIM wrote:
frenk88 wrote:
I took a look of the graph here: http://warpproject.org/trac/wiki/802.11 … Throughput
In particular I have noticed that the value at a rate of 54 Mbps with a payload of 1500 byte is 29.6 Mbps.
I tried to calculate this value and what I get is 29.3 Mbps (ideal one). What surprise to me is that your value is above the one calculated by me.
In order to calculate this value I used the following step:
throghput = (L_PAYLOAD*8)/(T_DIFS+T_BACKOFF+T_DATA+T_SIFS+T_ACK)
with L_payload=1500 bytes, T_DIFS=34 usec, T_BACKOFF=(CWmin -1)*Tslot/2=67.5 usec , Tslot= 9 usec, CWmin=16 usec
T_DATA = T_PREAMBLE+T_SIGNAL+T_SYMB*CEILING(L_SERVICE+L_TAIL+(L_MAC+L_PAYLOAD))/N_dbps + T_EX =254 usec con
T_SIFS=16 usec T_ACK=50 usec, N_DBPS=216 (x data rate 54Mbps)
Which is the formula implemented in your code to calculate T_ACK and T_DATA that are respectively the time to trasmit the a data packet and an ACK packet? did you try also to verify your obtained throughput data through this formula?Hi，murphpo:
1.N_DBPS is N_DATA_BITS_PER_SYM, why is it 216 (x data rate 54MBps). This means a symbol with 216 bits?
2.T_SIGNAL not exist in your script, so what is this value?
Thank you!
Could you help me about this question? Thank you!
Offline