none
Miniport driver - Throughput RRS feed

  • Question

  • HI

    I am writing miniport driver.

    Basic functionality is working fine for my driver. In throughput validation Downlink Upto 40Mbps my driver is working fine ..no datagram is missing.

    When increase speed in downlink 50mbps ,60mbps,  70mbps, 80mbps.. datagram packet is missing. What is the reason?
    I didn't tested in uplink....if i go to more than 100mbps system will be hang..

    My design is......While receiving Bulkin packet....using Usb continuous reader... In usbread_completion request....adding memory object into collection then releasing semaphore and return from that function.... from another thread waiting for semaphore and get memory object from collection then process the read packet and send to Ndis using "NdisMIndicateReceiveNetBufferLists".

    1. Is My design is correct for higher throughput?

    2.usb continuous reader if I set "TransferLength" is more than what I am receiving ..it will affect ?

    3.Is workitem better way in collection after receiving packet from framework?

    4.Please give me solution what is best design for datagram loss ?



    • Edited by Avata_ Monday, July 24, 2017 5:43 AM
    Monday, July 24, 2017 5:43 AM

All replies

  • USB transfers via bulk pipes are reliable. If you don't see any problem with USB reader on the Windows side, look at the device side. It can drop data there. 

    -- pa

    Monday, July 24, 2017 2:38 PM
  • why are you deferring to a workitem or a thread to process the incoming IO? why not process the read in the completion routine and indicate the received packet directly?  Have you tried increasing the number of readers? Your TransferLength should be the maximum possible size buffer you can receive.

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Monday, July 24, 2017 7:42 PM
  • Another possible reason (after Doron's reply) - when you relay received data to yet another intermediate storage - make sure that packets are indicated to NDIS in the original order. Even if TCP layer supports out-of-order packet arrival, NDIS test may require that packets arrive in correct order.

    --pa


    • Edited by Pavel A Monday, July 24, 2017 8:59 PM
    Monday, July 24, 2017 8:57 PM
  • From ur answer please clarify the following doubts
    1.Completion routine  is (IRQL =) DISPATCH_LEVEL.  Is it possible to indicate 'NdisMIndicateReceiveNetBufferLists" inside completion routine
    2.If I get multiple calls in completion routine before completing previous request. how to handle this situation?
    3.I am doing .. whenever the data comes in completion routine, using WDFCOLLECTION queue it (after taking a Memory hanle reference ).
    then process Memory object from the the queue in waiting thread. In this situation any possiblity to missing packet ( out-of-order)?


    • Edited by Avata_ Wednesday, July 26, 2017 9:52 AM
    Wednesday, July 26, 2017 9:51 AM
  • TransferLength  is 32768.

    If I do intermediate storage inside the completion routine, following parameters will affect or not?

    the memory size ,

    time take to copy the bytes and

    Throughput speed




    • Edited by Avata_ Wednesday, July 26, 2017 9:58 AM
    Wednesday, July 26, 2017 9:57 AM
  • Is it possible to indicate 'NdisMIndicateReceiveNetBufferLists" inside completion routine

    Yes. Have you seen the documentation? sometimes it is correct ;)

    If I get multiple calls in completion routine before completing previous request. how to handle this situation?

    This is complicated. The simple way (got a callback, call NdisMIndicateReceiveNetBufferLists immediately) may work, but if you get a lot of data, there's a risk of staying at DISPATCH for too long time. Try to keep it simple and see what happens.

    > 3 ... In this situation any possiblity to missing packet ( out-of-order)?

    Without seeing the code it's hard to tell, but generally: missing - no, out of order - yes.

    Regards,

    -- pa


    • Edited by Pavel A Wednesday, July 26, 2017 10:28 AM
    Wednesday, July 26, 2017 10:26 AM