Jump to content

As of July 17, 2015, the LabJack forums here at forums.labjack.com are shut down. New registrations, topics, and replies are disabled. All forums are in a read-only state for archive purposes.

Please visit our current forums at labjack.com/forums to view and make new posts. To post on the current forums, use your labjack.com login account. Your old LabJack forums login credentials have been retired. There are no longer separate logins for labjack.com and LabJack forums.


Photo

Command/response execution times


  • Please log in to reply
7 replies to this topic

#1 brian6091

brian6091
  • Members
  • 13 posts

Posted 13 October 2012 - 10:06 AM

I was trying to replicate the command/response times in section 3.1 of the User guide, which indicates that using a USB hub will improve performance. I noticed two things: 1) Using a powered hub makes no obvious difference in timing. This was true on a Windows 7 desktop as well as a Macbook pro running 10.7.4. I tested using two different powered hubs and didn't see any difference whether I used the hub or not. 2) The Windows machine was noticeably faster than the Mac. Here are some examples using u6allio.py Windows 7 machine (direct connection to host) >python u6allio.py 0 Time difference: 0:00:00.490000 Time per iteration: 0:00:00.000490 Time per iteration in millis: 0.49 >python u6allio.py 8 Time difference: 0:00:00.996000 Time per iteration: 0:00:00.000996 Time per iteration in millis: 0.996 Windows 7 machine (powered hub) >python u6allio.py 0 Time difference: 0:00:00.471000 Time per iteration: 0:00:00.000471 Time per iteration in millis: 0.471 >python u6allio.py 8 Time difference: 0:00:00.986000 Time per iteration: 0:00:00.000986 Time per iteration in millis: 0.986 Macbook Pro (direct connection to host) >python u6allio.py 0 Time difference: 0:00:01.14782 Time per iteration: 0:00:00.001147 Time per iteration in millis: 1.147 >python u6allio.py 8 Time difference: 0:00:01.369947 Time per iteration: 0:00:00.001369 Time per iteration in millis: 1.369 Macbook Pro (powered hub) >python u6allio.py 0 Time difference: 0:00:01.187222 Time per iteration: 0:00:00.001187 Time per iteration in millis: 1.187 >python u6allio.py 8 Time difference: 0:00:01.360845 Time per iteration: 0:00:00.001360 Time per iteration in millis: 1.36 Why is the Mac slower? I thought the exodriver was supposed to be as fast as the windows driver. And why doesn't the powered hub speed things up for me?

#2 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 15 October 2012 - 03:44 PM

I would not expect any speed difference with a bus-powered hub versus a self-powered hub. As for Windows speed versus Mac speed, someone else here will have to comment on that. Tomorrow most likely.

#3 brian6091

brian6091
  • Members
  • 13 posts

Posted 15 October 2012 - 11:11 PM

I would not expect any speed difference with a bus-powered hub versus a self-powered hub.

As for Windows speed versus Mac speed, someone else here will have to comment on that. Tomorrow most likely.

In the U6 manual, table 3.1-1 that indicates the expected timing difference when the U6 is connected directly to the host or through a high-speed USB2 hub:

"A “USB high-high” configuration means the U6 is connected to a high-speed USB2 hub which is then connected to a high-speed USB2 host. Even though the U6 is not a high-speed USB device, such a configuration does
provide improved performance. Typical examples of "USB other" would be a U6 connected to an old full-speed hub (hard to find) or more likely a U6 connected directly to the USB host (even if the host supports high-speed)."

This thread also indicates that I should see the difference on a Macbook Pro:

https://forums.labja...?showtopic=4604

Has this changed?

#4 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 16 October 2012 - 08:00 AM

Yes, that documentation is correct. If you put a high-speed (or super-speed) hub between the U6 and the host, you will see faster speeds than if the U6 is connected directly to the host. This is true whether the hub is self-powered or bus-powered. Someone else will comment on Win/Mac.

#5 Iandol

Iandol
  • Members
  • 46 posts

Posted 16 October 2012 - 10:06 AM

Hi, just to say that I see response times consistent with the documentation (results here with a U3, but our U6s are the same) on a Mac Pro 10.8.2 with exodriver 2.5.1 & ibusb 1.0.9 (installed via homebrew):

High-speed hub:
╒═ian @ vis32 in ~/Code/LabJackPython/Examples (master)
╘═◎ python u3allio.py 0
Time difference:  0:00:00.451183
Time per iteration:  0:00:00.000451
Time per iteration in millis:  0.451
Latest readings:  []

Directly plugged into front of machine:
╒═ian @ vis32 in ~/Code/LabJackPython/Examples (master)
╘═◎ python u3allio.py 0
Time difference:  0:00:03.950373
Time per iteration:  0:00:00.003950
Time per iteration in millis:  3.95
Latest readings:  []

I will try my MBP tonight...

#6 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 16 October 2012 - 03:45 PM

For "python u6allio.py 0" I would expect times close to 0.6 (hub) and 4.0 (direct) ms as we document if not better. Some PCs/Macs may be faster or slower, but fairly modern machines should keep around those times. Here are some things to consider/try:

Make sure that your hubs support high-speed or better. Just because the hub supports USB 2.0 doesn't mean it supports high speed. The same applies to the host, but I expect Mac Pros to support high-speed.

Make sure you are using the latest Exodriver and libusb software. Exodriver is version 2.5.1 and libusb is 1.0.9. The latest Exodriver version can be found on github and in the Mac installer we updated a couple of weeks ago. The installer also provides libusb 1.0.9.

If you have have XCode/gcc installed, try using the u6allio.c example for speed tests. Python can add a little extra overhead, and documentation times were gathered by C programs.

#7 brian6091

brian6091
  • Members
  • 13 posts

Posted 30 October 2012 - 04:54 AM

For "python u6allio.py 0" I would expect times close to 0.6 (hub) and 4.0 (direct) ms as we document if not better. Some PCs/Macs may be faster or slower, but fairly modern machines should keep around those times. Here are some things to consider/try:

Make sure that your hubs support high-speed or better. Just because the hub supports USB 2.0 doesn't mean it supports high speed. The same applies to the host, but I expect Mac Pros to support high-speed.

Make sure you are using the latest Exodriver and libusb software. Exodriver is version 2.5.1 and libusb is 1.0.9. The latest Exodriver version can be found on github and in the Mac installer we updated a couple of weeks ago. The installer also provides libusb 1.0.9.

If you have have XCode/gcc installed, try using the u6allio.c example for speed tests. Python can add a little extra overhead, and documentation times were gathered by C programs.

The hubs indeed enumerate as high-speed devices. The tests above were run using Exodriver 2.5.0 and libusb 1.0.8. Updating to libusb 1.0.9 did not change anything. That is, I was still seeing about 1.2-1.3 ms per iteration from u6allio.c (also reading 8 analog channels), regardless of whether I was connected through a high-speed hub between the u6 and a macbook pro, or if the u6 was connected directly to the computer.

Upgrading to Exodriver 2.5.1 did speed things up, dropping times to ~0.9-1 ms per iteration from u6allio.c (reading 8 analog channels). If I don't read analog channels (u6allio.py 0), I get times just under 0.6 milliseconds, regardless of whether I was connected through a high-speed hub between the u6 and a macbook pro, or if the u6 was connected directly to the computer.

I replicated the timing, and its lack of dependence on connecting through a high-speed hub on a MacMini (mid 2011). Both macs are running 10.7.5. And then there is the lack of dependence as noted in my first post for a Windows 7 machine.

I'm happy now that the Mac and Windows speeds are quite close, although I have no better understanding of why, particularly since diffing the exodriver code doesn't reveal anything that explains the change...

#8 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 30 October 2012 - 10:55 AM

This commit/change for the Exodriver was the one that helped performance:

https://github.com/l...e0b004a2ea13953

In older versions to check if the handle was valid a write/read call would try to perform a quick test communication first, then perform the write/read. The test communication was removed since it caused unnecessary delays and on certain computers communication failures.

Usually around here we need a hub for the 0.6 ms speeds, but I have seen speeds approaching 0.6 ms without a hub on one of our computers (our Raspberry Pi).


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users