locked
Question regarding sdr_mac_cs.c and Loops contained therein RRS feed

  • Question

  • Hi there;

     

    Currently working on an expansion of my previous RTS/CTS design; again, loosely based on existing 802.11b code (haven't ported all my code over to the new SDK yet).

     

    In SDR_MAC_CS.C, there are some functions I'd like some clarification on. Specifically:

     

    //expect an ACK is in the RX stream.
    __inline 
    HRESULT __ExpectAck(PPHY pPhy)
    {
      int i = 5;
      HRESULT hRes;
      KIRQL OldIrql = KeRaiseIrqlToDpcLevel();  
      do
      {
        hRes = PhyDot11BCs(pPhy, RADIO_SEND);
        i--;
      }while(hRes != BB11B_OK_POWER_DETECTED && i > 0 );
      KeLowerIrql(OldIrql);
      return hRes;
    }
    

    What made you choose 5 for the number of times this loop iterates?

    I'm currently designing some very similar code for waiting for CTS replies (if the CTS isn't received within (variable) amount of time, assume it won't ever arrive, and increment an error number). I could (and might have to) design a timer based off of how long it takes my custom CTS packets to modulate and an assumption of how long the time spent in-the-air before reception is (this as best I know could be done with the help of the KeQueryPerformanceCounter routine), but I'd love to know what you guys had in mind when you designed this much simpler for-loop.

     

    I've toyed with using similar loops but currently experience time-outs far too often, and would like a more efficient/reliable algorithm in order to compute overall expended times (say, between the start of a transmission, including RTS/CTS's, all the way to the end (final ACK reception)). These timings are kind of neccesary to the rest of our implementation, so I need to get these as accurate as possible (there are some questions with regards to if KeQueryPerformanceCounter is the best way to do this, but as for now, it works moderately well).

     

    Thanks!

    -Cory

    Tuesday, March 1, 2011 1:41 AM

All replies

  • Hi, Cory:

    This is just an approximate of the ACK time window. 5 is only an experience value.

    I think KeQueryPerformanceCounter is OK for accurate timing. But make sure all of the callings happen in one core.

    Thanks.


    Sen Xiang (项森)
    Tuesday, March 1, 2011 3:07 AM