Hi Bastian, Thanks for reply. I know they are two different values. 5M is for the physical layer and 115K bits/s is for the application layer. The application layer's upper bound should be the physical layer. So the value of application layer should always be less than the physical layer' s. However, I think my program is right which can take as much as the physical layer bandwidth can support. You can see my program's result. The 802.11 average speed is 22Mb/s and I can get 15Mb/s. So I think, as the bandwidth is 5M, then the coding rate should be 5/3 = 1.67M bits/s. So I expect a throughput around 1M b/s. But the result is just 1/10 of my expection. Too far away. I'm new to the communication. Not sure if I'm right. Please correct me if I'm wrong.
My professor wants me to use it in his prototype, please help me. And could you tell me if there is any software which can correctly measure the physical layer bit rate? Best regards. Siyu 2017-06-10 1:08 GMT+08:00 Bastian Bloessl <m...@bastibl.net>: > Hi, > > On 06/09/2017 05:14 PM, zhan siyu wrote: > >> Then how to explain the relationship between the 5M and the 115K bits/s >> throughput? >> > > I cannot since I see absolutely no relationship. Maybe you want to explain > (in detail) why you think these numbers should match. > > > Best, > Bastian > > > > >> Best regards. >> >> Siyu >> >> >> 2017-06-08 21:41 GMT+08:00 Bastian Bloessl <m...@bastibl.net <mailto: >> m...@bastibl.net>>: >> >> >> Hi, >> >> On 06/07/2017 02:32 PM, zhan siyu wrote: >> >> Thanks for your reply. Let me explain what I 'm doing. >> >> I have two B210s connected with two computers. I want to measure >> the throughput between the two computers over the usrp >> connection over gr-ieee802-11. But no matter how hard I try, >> like tuning the parameters and turning off my own wifi card and >> AP, I can only get 150K B/s, which should be around 300K B/s if >> my theoretical calculation is right. There are no underrun or >> overrun errors. The throughput measurement tool I'm using is >> iperf, which is an application to measure the end to end >> throughput. >> >> Could you give me some hints? >> >> >> I'm afraid I can't help a lot, since I have no idea what iperf is >> doing. I guess it floods the network stack with UDP packets. The GNU >> Radio transceiver, however, has no back pressure mechanism, so it >> will just drop the frames when they are injected into the GNU Radio >> flow graph. >> >> Also, I don't understand what exact analytical number you are trying >> to reproduce here. In fact, I have no idea what this experiment is >> supposed to show/prove or what part of the transceiver you are >> trying to profile. If, at all, this experiment will tell you how >> fast the TX-side can produce frames. >> >> This was investigated in >> >> Gonzalo Arcos, Rodrigo Ferreri, Matías Richart, Pablo Ezzatti and >> Eduardo Grampín, "Accelerating an IEEE 802.11 a/g/p Transceiver in >> GNU Radio," Proceedings of 9th Latin America Networking Conference >> (LANC'16), Valparaíso, Chile, October 2016, pp. 13-19. >> >> Turns out, you can improve the TX-side by improving the OFDM Carrier >> Allocator. >> >> Best, >> Bastian >> >> >> >> Best regards. >> >> Siyu >> >> 2017-06-07 14:02 GMT+08:00 Bastian Bloessl <m...@bastibl.net >> <mailto:m...@bastibl.net> <mailto:m...@bastibl.net >> <mailto:m...@bastibl.net>>>: >> >> >> Hi, >> >> On 06/07/2017 03:04 AM, zhan siyu wrote: >> >> Thanks. I just wonder why. Because I meet some >> performance >> problem. I thought it maybe caused by my >> misconfiguration of the >> gr-ieee802-11 code. Now, it seems not. >> >> >> I'm a bit confused why the fact that the transceiver is not >> configured through iwconfig ruled out any configuration >> issues, but >> great that all seems to be set up now. >> >> >> However, theoretically, as my current sample rate is >> 10M and >> BPSK. So the coding rate should be 10M/2 = 5M b/s. The >> throughtput should be around 5M/8 = 625K B/s. Assuming >> the 12% >> head cost, so the data throughput should be 625 * 88 % >> = 550K >> B/s. But as my experiment shows, the throughput is >> only 150K B/s. >> >> I'm new to the communication. Is my calculation right ? >> >> >> BPSK 1/3 is 3Mbit/s gross at 10MHz. The overhead per packet >> has to >> be subtracted, i.e. the actual maximum rate depends on the >> frame size. >> >> >> If it were right, then what might cause the gap? >> >> >> Since you don't explain what you are doing, this is very >> hard to >> tell. You would reach this theoretical throughput only if >> you send >> frames back-to-back (which probably only works if you >> pregenerate >> the sample stream). But also a WiFi card will insert >> inter-frame >> space, so that the actual throughput will not match the >> theoretical >> maximum physical layer throughput. >> >> Best, >> Bastian >> >> >> >> One more question, I didn't run the volk_profile. Does >> it matter? >> >> Best regards. >> >> Siyu >> >> >> 2017-06-07 4:23 GMT+08:00 Bastian Bloessl >> <m...@bastibl.net <mailto:m...@bastibl.net> >> <mailto:m...@bastibl.net <mailto:m...@bastibl.net>> >> <mailto:m...@bastibl.net <mailto:m...@bastibl.net> >> >> <mailto:m...@bastibl.net <mailto:m...@bastibl.net>>>>: >> >> >> Hi, >> >> On 06/06/2017 03:55 PM, zhan siyu wrote: >> >> Hi all, >> >> I just found I can't use the iwconfig tap0 >> rate 20M to >> setup the >> bandwidth of the tap0. The error message is : >> >> Error for wireless request "Set Bit Rate" >> (8B20) : >> SET failed on device tap0 ; >> Operation not >> supported. >> >> But in their video , it can be set in this >> way. May I >> know how >> to solve it ? >> >> >> The WiFi transceiver is attached to the tun/tap >> interface, >> which is >> a virtual Ethernet device. This device doesn't >> support >> WiFi-specific >> configuration through iwconfig. >> >> If you wanted this level of integration, you would >> have to >> write a >> kernel module that attaches the transceiver to a >> virtual >> WiFi card. >> >> Some group already did that, but they didn't >> release the >> source code. >> >> Best, >> Bastian >> >> >>
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
