locked
About throughput using Sora user mode RRS feed

  • Question

  • Hi, everyone. I'm using UMXDOT11 to test throughput under user mode. The test result is that, the total throughput is just 0.488Mbps under 6M rate in protocol 802.11a. On the other hand,  the total throughput can be 3.8M under kernel mode using iperf as the tool to tx/rx. Why is it so different under user mode and kernel mode? What causes this difference? How can I improve throughput under user mode?

    Thanks.

    Friday, July 27, 2012 7:39 AM

Answers

  • Hi, Qi Luo,

    I read again the source code. The transferring operation is done by the following statement,

      hr = SoraURadioTransfer(TARGET_RADIO, Packet.Reserved3, &TxID);

    In this statement, Packet.Reserved3 doesn't store buffer size but signal length. I'm not sure where you wrongly use the buffer size as signal length. Could you point it out?

     Thanks.

    I double checked the code in Sora SDK ver 1.6. Please ignore my last email. I found the bug is indeed 'Sleep(1);' statement in the function 'DoDot11ATx', which cause long time interval between sent frames.

    Wednesday, August 15, 2012 2:32 AM
    Answerer

All replies

  • Hi ychm,

    TCP or UDP (broadcast) throughput? It should be almost the same as kernel mode.

    -Jiansong

    Thursday, August 2, 2012 7:56 AM
  • Hi ychm,
    Sorry for the problem. It is indeed a bug in UMXDot11. The TX part modulates one frame, stores the signal samples in buffer in PC memory, and then transfer them to RCB memory. During the transferring step, we wrongly use the buffer size as signal length. The result is that there is large interval between frames, and you observe low throughput.

    We will fix the bug in next release. Or you may check dot11atx.cpp and dot11btx.cpp to fixed it yourself.
    • Proposed as answer by Qi LuoEditor Monday, August 6, 2012 9:20 AM
    • Marked as answer by Jiansong zhangMicrosoft employee Friday, August 10, 2012 6:16 AM
    • Unmarked as answer by ychm Wednesday, August 15, 2012 2:15 AM
    • Unproposed as answer by ychm Wednesday, August 15, 2012 2:15 AM
    Monday, August 6, 2012 9:19 AM
    Answerer
  • Hi, Qi Luo,

    I read again the source code. The transferring operation is done by the following statement,

      hr = SoraURadioTransfer(TARGET_RADIO, Packet.Reserved3, &TxID);

    In this statement, Packet.Reserved3 doesn't store buffer size but signal length. I'm not sure where you wrongly use the buffer size as signal length. Could you point it out?

     Thanks.

    Wednesday, August 15, 2012 2:12 AM
  • Hi, Qi Luo,

    I read again the source code. The transferring operation is done by the following statement,

      hr = SoraURadioTransfer(TARGET_RADIO, Packet.Reserved3, &TxID);

    In this statement, Packet.Reserved3 doesn't store buffer size but signal length. I'm not sure where you wrongly use the buffer size as signal length. Could you point it out?

     Thanks.

    I double checked the code in Sora SDK ver 1.6. Please ignore my last email. I found the bug is indeed 'Sleep(1);' statement in the function 'DoDot11ATx', which cause long time interval between sent frames.

    Wednesday, August 15, 2012 2:32 AM
    Answerer