A propos des taux de transfert dans l'internet des objets

A propos des taux de transfert dans l'internet des objets

De nos jours, lorsque les médias nous parlent de l'Internet des Objets, plus personne ne se soucie de problèmes de vitesse de transfert. On tient pour acquis que les réseaux sont suffisamment rapides pour avoir relégué ce problème au passé. Mais est-ce vraiment le cas ? Pas si sûr...

Lorsqu'on ne travaille que sur un réseau câblé ou WiFi, il est vrai que les performances actuelles permettent presque n'importe quoi. L'expérience d'utilisation des applications web, conçues pour utiliser de manière optimales les ressources du serveur et de clients web puissants, tend à nous faire oublier les contraintes technologiques sous-jacentes.

Dans le contexte des objets connectés, les choses sont un peu différentes. Pour des raisons d'économie d'énergie, de coût et de dissipation de chaleur, on travaille en général avec des petits processeurs disposant de très peu de mémoire. Le réseau est rarement câblé, et dans certains cas il s'agit d'un réseau avec une forte latence (comme un réseau GSM, par exemple dans les applications liées à l'agriculture). Mais est-ce que ça compte vraiment ? On est tenté de se dire que de les objets connectés ne transmettent que très peu de données, et que de toute manière, tant qu'il ne s'agit que de latence, cela n'a pas vraiment d'effet sur les taux de transfert. Et bien... c'est faux!

En premier lieu, sur la quantité de données à transférer: si l'objet connecté dispose d'une interface web digne de ce nom, elle va certainement exiger le transfert de quelques dizaines de kilobytes au minimum. Et même si il n'en a pas et transmet ses données avec un protocole beaucoup plus léger, il faudra nécessairement qu'il dispose d'un mécanisme de mise à jour du firmware, pour pouvoir appliquer les inévitables correctifs de sécurité, qui lui demandera probablement de transférer plusieurs centaines de kilobytes.

Deuxième piège: 200KB, 500KB, ça ne parait pas grand chose pour un réseau 3G dont le débit théorique se compte en Mbit/s... mais c'est sans tenir compte du fonctionnement de TCP/IP, le protocole utilisé pour la plupart des transferts sur le réseau. En TCP, pour garantir une transmission sans erreur, l'expéditeur ne peut pas envoyer plus de données que la taille de la mémoire de réception du destinataire le permet. De plus, l'expéditeur doit garder ces données en mémoires jusqu'à ce que le destinataire lui en ait quittancé la bonne réception. Donc le débit effectif est limité par la taille de la plus petite des deux fenêtres de transmission, et par le temps nécessaire à recevoir la quittance, donc la latence du réseau. Et c'est là que le bas blesse: faible mémoire, haute latence, ce sont justement les caractéristiques que nous citions précédemment.

Un exemple...


Un capteur est connecté via sur un réseau GSM 3G HSPA+ à 15 Mbit/s mais avec une latence de 300ms. Si il dispose de tampons réseau entrants de 1 KB, combien de temps faut-il pour mettre à jour le firmware qui fait 1 MB ?

Débit effectif = fenêtre / latence = 1 [KB] / 0.3[s] = 3.333 [KB/s]

Temps de transfert = taille / débit effectif = 1024 [KB] / 3.333 [KB/s] = 307 [s], soit plus de 5 minutes !

En soi, ce n'est pas un problème qu'une mise à jour de firmware prenne 5 minutes, si cela a été prévu correctement par le concepteur et ne cause pas un échec de l'upload pour dépassement de temps. Par contre, on ne peut pas se permettre ce genre de délais n'importe où dans une interface web. Donc faire de l'IoT, ce n'est pas aussi simple que de prendre un petit projet construit sur un coin de table qui fonctionne sur un réseau Ethernet, et le mettre derrière un modem GSM :-)

Un YoctoHub-GSM et un téléphone: pas le même usage, pas les même perfs
Un YoctoHub-GSM et un téléphone: pas le même usage, pas les même perfs


Alors comment se fait-il qu'on peut voir une video sur un téléphone 3G ?


Un téléphone portable a bien plus de ressources qu'un objet connecté: les téléphones actuels sont dotés de 4 GB de RAM, soit 40'000 fois plus qu'un YoctoHub-Ethernet par exemple. Cela permet l'utilisation de grands tampons de réception et évite l'effet de congestion décrit ci-dessus. De plus, les protocoles de streaming video utilisent d'autres algorithmes plus rapide, mais qui ne s'appliqueraient pas à une mise à jour de firmware par exemple.

Qu'en est-il des produits Yoctopuce ?


Yoctopuce est dans le cas de figure typique IoT: petits processeurs, petite mémoire. Nos premiers YoctoHubs ont été conçus pour travailler avec des réseaux locaux à faible latence, et n'étaient donc pas très réactifs si on les utilisait à travers une ligne GSM ou satellite. Jusqu'à présent, la mise à jour de firmware devait se faire soit par USB, soit sur le réseau local.

Pour les YoctoHub-GSM, nous avons développé une nouvelle version de l'interface web et un nouveau protocole réseau, basé sur les WebSockets plutôt que sur du simple HTTP, permettant de mieux gérer les canaux à faible débit. Aujourd'hui, nous élargissons cette fonctionnalité aux YoctoHub-Ethernet et au YoctoHub-Wireless-g, pour lesquels nous publions un nouveau firmware équivalent.

Donc si vous mettez à jour votre firmware avec cette nouvelle version, vous pourrez désormais -avec un peu de patience- faire les prochaines mises à jour même à travers une ligne GSM...

Commenter aucun commentaire Retour au blog












Yoctopuce, get your stuff connected.