This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

USB1.1 OHCI driver performance on OMAPL138

Other Parts Discussed in Thread: OMAPL138

Hi,

We have designed OMAPL138 based custom product. We need to use USB1.1 OHCI driver, since USB2.0 is used for other application.

We are using linux kernel from DaVinci-PSP-SDK-03.20.00.12, core is running at 372 MHz.

We are facing performance issue with USB1.1 OHCI.

Can someone give me exact performance figure for USB 1.1 OHCI driver ?

We'll be transferring data in small chunks and will use USB1.1 for data xfer.

Is there a way to tune the performance of USB 1.1? Is there any scope of improvement in performance ?

Thanks in advance,

Sweta

  • Sweta,

    OHCI is a full speed controller and theoretical maximum throughput is 12Mbits/sec. What performance are you getting and whats your expected throughput?

    Regards,
    Ajay

  • Hi Ajay,


    Thanks for the prompt reply.

    We haven't measured the throughput straight away in numbers.
    What we have done is, if we connect single USB based card reader, then the authetication operation (set of few USB commands) takes 64 msec, expected is 30 msec.

    Instead of connecting single card reader, if we connect USB hub and connect 4 USB card readers to hub and make more bus operations on USB, then the authentication time reduces to 40 msec.

    So, the interesting fact is that if the USB bus is active with some operation, then the single card reader authentication time improves.

    I am curious if this can be a tuning issue of driver ?

    Do you have USB1.1 performance benchmark figure? 

    Let me know if you need more details.

    Thanks a bunch,
    Sweta

  • I think this has already been discussed at http://e2e.ti.com/support/embedded/f/354/p/100289/352051.aspx#352051

    Can you capture the bus trace as suggested in above thread.

    Ajay

     

  • Hi Ajay,

    I have attached Cardreader_logs.rar.

    I have used ellisys USB analyzer. I hope you are able to open .ufo file to view trace.

    1Cardreader.ufo - 1 card reader was attached

    2Cardreaders.ufo - 2 card readers were attached but operation was on one card reader only, a pcsc deamon scans two readers but application performs authentication on only one reader.

    Please let me know your observations.

    Thanks,
    Sweta

    Cardreader_logs.rar
  • Sweta,

    I can see different transfers OUT = 17,18,19, 44, 14, 20, 25, IN=12, 11, bytes. Can you explain how the authentication transfers completes? I need to look at start and end of authentication transfers and then compare between the two traces.

    Regards,
    Ajay

  • Hi Ajay,

    I understand your point. But the issue is, we don't have source code of authentication library, so we are not able to differentiate which operation is authentec.

    The problem is that, PCSC daemon keeps on polling for USB based card readers on continuous basis.

    So USB analyzer will capture this data as well. So it is very difficult to differentiate which of the frame is authentication operation and which one is scanning of PCSC.

    Still let me figure out if I can provide you deeper detail on this somehow.

    Meanwhile can you analyze something out of the behaviour when two cards are connected vs/ one card is connected ?

    The only thing that will differ in case of two cards connected to hub :- bus transactions will get increased, which result in better performance, even if it sounds strange.

    What I conclude as of now is, less number of bus transcations result in lower performance.

    Thanks,
    Sweta

     

  • Hi Ajay,

    I did following experiment to find the root cause of the issue.

    - Connect USB hub to OHCI 1.1 port

    - Connected one card reader and one USB pen drive

    Exp.1

    - Don't run application in background which performs R/W in USB pen drive.

    - Authenticate the card via card reader. Authentication time = 64 msec

    Exp. 2

    - Run application in background which performs R/W in USB pen drive

    - Authenticate the card via card reader. Authentication time = 32 msec

    Conclusion:

    In both experiments, there wasn't any change in setup. Same BSP firmware was used and after power on, I performed both experiments.

     

    What I understand from above is, when OHCI controller gets less requests from applications, the latency time rises.

    Is it the case that when the USB's queue is empty, the performance decreases, but when continuous data xfer is happening on the bus, the performance improves ?

    Is there a way to resolve this ? We would be supporting only one reader at a time so we need to handle this case to get better result.

    Thanks,
    Sweta

  • Sweta,

    As you mentioned this seems to be latency issue which is more in case, there is only one card reader connected. Do you see simiar performance difference when you connect only one USB pen drive or more than one? Do you know the endpoint type used with card reader ? Please provide us the descriptor set of the smart card reader.

    You can send us the output of "cat /proc/bus/usb/devices" which would need CONFIG_USB_DEVICEFS to be enabled.

    Regards,
    Ajay

  • Hi Ajay,

    I tried with 1 USB pen drive and 1 reader where I significant improvement in performance of card reader.

    I also tried with 2 USB pen drives connected via hub and did run the same application on both drives simultaneously, but in this case I don't see significant difference in performance whether I run application on one USB drive or both together.

    Endpoint type is bulk transfer in case of pen drive as well as card reader.

    Please find attached log of /proc/bus/usb/devices.

    1) devices_log_reader_only.txt -Card reader and pen drive connected but application runs on card reader only (authentication time = 62 msec)

    2) devices_log_reader_plus_pendrive.txt - Card reader and pen drive connected, application runs on card reader as well as in pen drive (authentication time = 32 msec)

    I don't have descriptor set of card reader. What exact information are you looking for ?

    Please let me know if you need more details.

     

    Thanks,

    Sweta

    proc_bus_usb_devices.rar
  • Hi Ajay,

    After debugging the driver, I noticed that the EDs were not getting scheduled very frequently in case there was less data traffic.

    When call from application comes, it calls ohci_urb_enqueue(). But if ed->state != ED_IDLE, then it will not schedule it, rather it will store the data in queue.

    So, to make it schedule faster for better performance, I did following change in driver file "drivers/usb/host/ohci-q.c"

    Function: finish_unlinks() which is called very frequently. It de-schedules the EDs.

    See below code:

                    ed->state = ED_IDLE;
                   if (quirk_zfmicro(ohci) && ed->type == PIPE_INTERRUPT)
                       ohci->eds_scheduled--;

                    ed->hwHeadP &= ~cpu_to_hc32(ohci, ED_H);
                    ed->hwNextED = 0;
                    wmb ();
                    ed->hwINFO &= ~cpu_to_hc32 (ohci, ED_SKIP | ED_DEQUEUE);

    I added a line here to schedule the ed again to ensure that this is scheduling latency issue of driver.

    After above code, I added this line.

    ed_schedule (ohci, ed);

    With this scheduling, the authentication time gets improved to 46-47 msec from 64 msec, which says around 50% improvement.  Targeted time is 33-34 msec, which I am achieving if I connect pen-drive, so the driver and OHCI has potential to achieve this figure but there is some issue in driver.

    One more interesting observation is, now I don't need to run application in pen drive, just by adding ed_schedule() and connecting pen-drive (not even mounted to fs), I am getting best authentication time - 33 msec. If I just connect and disconnect the pen drive, then also till next reboot, I get best authentication time of 33 msec, evenif it is very strange.

    I hope this will give you some hints on what can be exact root cause, why increasing frequency of ed_schedule() improves performance and what can be done further to achieve better performance than this.

    I'll highly appreciate your attention in this direction.

    Thanks,
    Sweta

  • Sweta,

    The finding are very interesting and looks like some bug inside OHCI controller driver. OHCI controller driver is coming from Linux kernel and TI has not changed it.I would recommend to post these findings in linux-usb list also (http://marc.info/?l=linux-usb) to get the correct fix from OHCI driver writers.

    Furtehr looking at descriptor I saw that the card reader having one INTERRUPT IN endpoint with polling interval as 24ms.

    T:  Bus=02 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
    D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
    P:  Vendor=076b ProdID=6320 Rev= 5.10
    S:  Manufacturer=OMNIKEY
    S:  Product=Smart Card Reader USB
    S:  SerialNumber=OKCM0030312100617205175124215286
    C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=250mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=usbfs
    E:  Ad=83(I) Atr=03(Int.) MxPS=   8 Ivl=24ms   <================== see here
    E:  Ad=84(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=05(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

    Any idea why INTERRUPT IN endpoint is used and if it has any relation with the authetication data being sent to host?

    Regards,
    Ajay