Mise à jour de l'API, nouvelles mesures de performance

Mise à jour de l'API, nouvelles mesures de performance

Après plusieurs jours de tests, nous avons publié cette semaine une nouvelle version des librairies de programmation (API) pour tous les langages, ainsi que du logiciel VirtualHub permettant d'atteindre nos modules USB par le réseau. Les nouveautés sont:
- un support ARM amélioré, (MK802, MK805 et Raspberry Pi)
- le contrôle d'accès sur les connections réseau (authentication)
- callbacks HTTP dans le VirtualHub (du genre webhooks)
- des meilleures performances, avec tests à l'appui


Support ARM amélioré

L'arrivée du Raspberry Pi et du MK802 a démocratisé l'utilisation des machines ARM auprès du grand public. Ces machines bon marché cachent pourtant quelques difficultés, dues aux variantes de processeur et de conventions.

Les machines bon marché, basées sur du ARM, commencent à proliférer
Les machines bon marché, basées sur du ARM, commencent à proliférer


Les deux principales familles utilisées actuellement sont armel (pour ARM EABI Little-endian), et armhf (pour ARM Hard-Floats). Ces deux familles sont entièrement incompatibles car utilisent des conventions d'utilisation des registres différentes: un programme compilé en armel ne fonctionne pas sur un système dont les librairies systèmes utilise les conventions armhf, et inversement. Les images les plus répandues pour Mele A1000, MK802, MK805 et QNAP travaillent en armel. Les images Debian pour les processeurs récents, et la distribution Raspian pour Raspberry Pi travaillent en en armhf.

Pour vous simplifier la tâche, nous fournissons désormais deux versions de tous nos binaires pour ARM, la version armel et la version armhf. Les binaires armhf n'utilisent pas les optimisations ARMv7, ce qui leur permet de tourner sur les machines ARMv6 comme le Raspberry Pi.

Contrôle d'accès

Il est maintenant possible de configurer un contrôle d'accès au VirtualHub pour prévenir les accès non désirés à vos modules par le réseau. Un mot de passe global permet de bloquer indifféremment tout accès. On peut aussi protéger spécifiquement les accès altérant l'état des modules, par un mot de passe séparé. Le contrôle d'accès utilise le protocole standard HTTP Digest dans sa variante la plus sûre, qui ne fait pas circuler le mot de passe sur le réseau, et empêche la réplication de requête.

Callback HTTP

Si vous avez essayé de publier sur un site web des mesures faites pas un capteur situé chez vous, vous avez probablement du écrire un petit programme qui lit le capteur à intervalles réguliers et les poste sur votre site web publique. Le VirtualHub est désormais capable de faire cette tâche tout seul: à intervalle régulier, et en tenant compte des valeurs qui ont changé, il peut aller poster sur l'URL de votre choix la valeur courante de tous les capteurs, en s'identifiant via une méthode HTTP standard. A terme, cette fonctionnalité devrait permettre une connection directe avec des services tels que Zapier.

Le VirtualHub hérite de nouvelles fonctionnalités
Le VirtualHub hérite de nouvelles fonctionnalités



Meilleures performances
En début d'année, nous avions effectué quelques mesures de performance pour les langages que nous supportions alors. Aujourd'hui, nous ré-éditons ces tests sur tous les langages et quelques plate-formes de plus, après avoir apporté quelques optimisations au code.

On a ressorti notre dispositif de test
On a ressorti notre dispositif de test


Nous mesurons les temps suivants: envoi d'une commande unique (comme une commutation de relais),envoi répété sur le même module (exigeant d'attendre la fin de la commande précédente), la latence totale entre l'envoi d'une commande de commutation et la détection (par un autre module) de la commutation, et le temps total pour la première lecture synchrone de tous les capteurs d'un module (les lectures suivantes sont quasi-instantanées car elles utilisent les valeurs en cache).

Commençons par les mesures de performance en USB, sur des machines de bureau.

OSLangageEnvoi commandeEnvoi répétéLatence1e lecture
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]



Les performances de la machine elle-même comptent peu. C'est principalement l'architecture de la pile USB qui fait la différence entre Windows, Linux et Mac OS X. Par contre, si l'on ajoute les machines ARM dans la comparaison, on commence à sentir les différences de puissance des CPU. Voici un test en USB sur différentes machines sous Linux, en C++:

Machine Envoi commandeEnvoi répétéLatence1e lecture
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]



Voyons maintenant les accès à travers le VirtualHub, ce qui permet d'ajouter d'autres langages. Pour ne pas rajouter de paramètre extérieur, le VirtualHub tourne sur le même machine que le programme de test, mais vous pouvez en déduire la latence pour un accès distant en ajoutant simplement la latence de votre réseau.

OSLangageEnvoi commandeEnvoi répétéLatence1e lecture
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]



Si vous comparez avec nos tests précédents, vous verrez que les améliorations les plus notoires sont:
- une forte réduction de la latence pour les accès par le réseau (d'un facteur 2)
- une amélioration sensible pour tous les accès en JavaScript et en PHP
Nous avons aussi amélioré d'un facteur 2 la performance des commandes répétées, aussi bien en USB que via le VirtualHub (mais cette valeur n'était pas mesurée lors de nos premiers tests).

Dans le même registre, on nous a demandé la possibilité de lire la valeur instantanée d'un capteur le plus rapidement possible, sans lissage ni passer par les cache. Cela devrait être possible lors d'une prochaine mise à jour des firmware et de nos librairies, a priori en 5[ms] ce qui devrait permettre du sampling à près de 200[Hz]. Si vous avez besoin de tester cette feature, envoyez-nous un mail avec le nom du module utilisé et du langage de programmation que vous voudriez utiliser.

Commenter aucun commentaire Retour au blog












Yoctopuce, get your stuff connected.