none
some question about ack RRS feed

  • Question

  • In my experiment ,I use two sora stations,just marked as A and B.

    A sends 100 frames to B, and A waits for ACK without time limitation. RESULT:B receives 100 frames ,A receives 100 ACK,but the ACK timer(from end of a frame sent out to the beginning of the ACK long preamble) is much longer than 9us,which is sugessted by 802.11a. I analyse the phennomenon.

    I think it's caused by CCA .Maybe there is too many blocks in the RCB before the ACK. And the CCA needs to analyse every block to judge whether the channel is busy or idle. Am I right?

    If so , could you please kindly help me with a way to do with the problem? Thus we can make it be real time.

    Monday, April 22, 2013 1:08 AM

Answers

  • Hi buptboy,

    Thank you for your information, could you also post your detailed results here?

    CCA is not the reason, because the sender does not go through CCA before receiving ACK.

    The additional delay is actually a tradeoff we made for programmability. When Sora was implemented in pure kernal mode at the beginning, all the timing is correct. But when it was moved to user mode, several additional delays were added, so the interval between a packet and the ack may exceed SIFS. However, commercial devices usually tolerate more latency than SIFS so user-mode Sora is still able to talk with commercial devices.

    -Jiansong

    • Marked as answer by buptboy Monday, April 22, 2013 10:55 AM
    Monday, April 22, 2013 3:16 AM
  • Thank you!
    • Marked as answer by buptboy Monday, April 22, 2013 3:42 PM
    Monday, April 22, 2013 3:42 PM

All replies

  • Hi buptboy,

    Thank you for your information, could you also post your detailed results here?

    CCA is not the reason, because the sender does not go through CCA before receiving ACK.

    The additional delay is actually a tradeoff we made for programmability. When Sora was implemented in pure kernal mode at the beginning, all the timing is correct. But when it was moved to user mode, several additional delays were added, so the interval between a packet and the ack may exceed SIFS. However, commercial devices usually tolerate more latency than SIFS so user-mode Sora is still able to talk with commercial devices.

    -Jiansong

    • Marked as answer by buptboy Monday, April 22, 2013 10:55 AM
    Monday, April 22, 2013 3:16 AM
  • Recently I am working on it. Now the time between is about 2000us .I think it should be wrong. So the results will be posted here not now but later. Thank you! Any question, and I'll be hornored to seek help from you.
    Monday, April 22, 2013 10:55 AM
  • Just a guess, did you only measure the first ACK response time?

    If this case, all later ACK frames will be much faster because it is cached in RCB on-board memory. You can find related code in DataFrameAck11() in mac.cpp in umxsdrbrick project.

    Monday, April 22, 2013 11:43 AM
    Answerer
  • Thank you!
    • Marked as answer by buptboy Monday, April 22, 2013 3:42 PM
    Monday, April 22, 2013 3:42 PM