API update and new performance measures

API update and new performance measures

After several days of testing, we published this week a new version of the programming libraries (API) for all the languages, as well as a new version of the VirtualHub software, allowing you to reach our USB modules through the network. New or improved features are:
- improved ARM support (MK802, MK805, and Raspberry Pi)
- access control on network connections
- HTTP callback in the VirtualHub
- improved performances with all the languages

Improved ARM support

The presence of the Raspberry Pi and the MK802 on the market has democratized the use of ARM machines among the public. These cheap machines hide nevertheless a few difficulties, because of processor and convention variations.

Cheap ARM based computers are now widely available
Cheap ARM based computers are now widely available

The two main families currently used are armel (standing for ARM EABI Little-endian) and armhf (for ARM Hard-Floats). These two families are entirely incompatible because they use distinct conventions for register use: a program compiled in armel doesn't function on a system for which system libraries use the armhf conventions, and inversely. Most common images for Mele A1000, MK802, MK805, and QNAP work in armel. Debian images for recent processors, and the Raspian distribution for Raspberry Pi, work in armhf.

To help you out, from now on we provide two versions of all our ARM binaries, the armel version and the armhf version. armhf binaries don't use the ARMv7 optimizations, which allow them to run on ARMv6 machines, such as the Raspberry Pi.

Access control

You can now setup access control in the VirtualHub to prevent undesired access to your modules through the network. You can block all accesses, by setting a password for global use, or block separately read and write access to the modules (distinct passwords). The access control uses the standard HTTP Digest protocol, in its most secure variant which doesn't circulate the password on the network and which prevents request replication.

HTTP callback

If you have tried to publish on a public site measures taken by a sensor located at home, you probably had had to code a short program which read the sensor at a regular interval and then posted the values on your public site. The VirtualHub is now able to perform this task on its own: at a regular interval, taking into account values that have been modified, it can post on the URL of your choice the current value of all the sensors, identifying itself though a standard HTTP method. In the long run, this functionality should enable a direct connection with services such as Zapier.

New features for the VirtualHub
New features for the VirtualHub

Improved performances

At the beginning of the year, we had realized some performance measures for the languages that we supported then. Today, we redo these tests on all the languages and on some more platforms, after having partly optimized the code.

The speed test device comeback
The speed test device comeback

We measure the following durations: sending a unique command (such as commuting a relay), repeated sending on the same module (requiring to wait until the end of the preceding command), total latency between sending a commutation command and the detection of the commutation (by another module), and the total waiting time for the first synchronous reading of all the sensors of a module (the following readings are almost instantaneous because they use values in cache).

Let's start by performance measures in Direct USB on desktop machines.

OSLanguageCommand sendingRepeated sendingLatency1st reading
Windows C++ 1.0 [ms]4.6 [ms]7.1 [ms]35 [ms]
Windows C# .NET 1.5 [ms]4.7 [ms]6.5 [ms]35 [ms]
Windows VB .NET 1.0 [ms]4.5 [ms]6.0 [ms]35 [ms]
Windows Delphi 1.3 [ms]4.3 [ms]6.3 [ms]32 [ms]
Windows Python 1.7 [ms]4.6 [ms]7.0 [ms]36 [ms]
Linux C++ 1.2 [ms]3.9 [ms]7.0 [ms]32 [ms]
Linux Python 1.8 [ms]3.9 [ms]6.0 [ms]34 [ms]
Mac OS XC++/ObjC0.7 [ms]3.0 [ms]7.1 [ms]32 [ms]
Mac OS XPython 1.2 [ms]3.0 [ms]6.0 [ms]33 [ms]

Performances of the machine itself are of little account. It's mainly the architecture of the USB stack which makes a difference between Windows, Linux, and Mac OS X. However, when we add ARM machines to the comparison, we start to feel the difference caused by CPU power. Here is a test on USB, using C++ on different machines under Linux:

Machine Command sendingRepeated sendingLatency1st reading
Portable Core i31.2 [ms]3.9 [ms]7.0 [ms]32 [ms]
MK802, MK805 1.7 [ms]5.0 [ms]6.5 [ms]41 [ms]
Raspberry Pi 2.0 [ms]5.0 [ms]7.9 [ms]80 [ms]

Let's now look at access through the VirtualHub, which allows us to add other languages. To prevent adding external parameters, the VirtualHub runs on the same machine as the test program, but you can deduce the latency of a remote access by simply adding the latency of your network.

OSLanguageCommand sendingRepeated sendingLatency1st reading
Windows C++ 0.1 [ms]6.0 [ms]8.4 [ms]36 [ms]
Windows C# .NET 0.1 [ms]6.0 [ms]6.9 [ms]36 [ms]
Windows VB .NET 0.1 [ms]6.0 [ms]7.0 [ms]36 [ms]
Windows Delphi 0.1 [ms]6.0 [ms]8.0 [ms]35 [ms]
Linux C++ 0.1 [ms]4.0 [ms]7.0 [ms]32 [ms]
Linux Python 0.1 [ms]4.3 [ms]6.0 [ms]32 [ms]
Mac OS XC++/ObjC0.2 [ms]4.5 [ms]7.0 [ms]32 [ms]
Mac OS XPHP 0.2 [ms]3.5 [ms]6.0 [ms]32 [ms]
Mac OS XJavaScript0.8 [ms]n/a7.3 [ms]32 [ms]
Mac OS XJava 0.4 [ms]n/a7.5 [ms]44 [ms]

If you compare this with our preceding tests, you'll see that the most visible improvements are:
- an important decrease in the latency for network access (by a factor 2)
- a noticeable improvement for all accesses in JavaScript
We have also improved by a factor 2 the performance of the repeated commands, in USB as well as through the VirtualHub (but this value was not measured in our first tests).

In the same idea, we have been asked for the possibility to read the raw value of a sensor as fast as possible, without using the cache. This should be possible in a future update of the firmwares and of the libraries, a priori in 5[ms] which should allow sampling at close to 200[Hz]. If you need to test this feature, send us an email with the name of the module used and the programming language you'd like to use.

Add a comment No comment yet Back to blog

Yoctopuce, get your stuff connected.