Iddad Tech Blog

Aller au contenu | Aller au menu | Aller à la recherche

mardi 27 septembre 2016

Routeur A5-V11 et Ralink RT5350

Pour faire de l'IoT, a part l'architecture Arm qui règne en maître dans l'embarqué, on peut aussi utiliser l'architecture MIPS, assez souvent rencontrée sur les routeurs.

Justement, un petit routeur 3G qui a récemment fait parler de lui à cause de son petit prix - moins de 7€ port compris sur ebay, utilise un processeur Ralink avec une architecture MIPS.

A5-V11

Aussi connu sous le nom "A5-V11", ce périphérique est vendu sous la dénomination un peu trompeuse de "routeur 3G/4G" mais n'a en fait aucune capacité 3G, on peut juste y brancher un modem 3G USB et partager ensuite la connexion via Wifi ou via Ethernet. Il existe aussi des versions avec batteries intégrées pour quelques euros de plus.

Caractéristiques

Processeur : Ralink RT5350F @ 360 Mhz
Flash : 4 Mo
Ram : 32 Mo
port USB : Host USB 2.0
Ethernet : 100 Mb
Wifi : 802.11n

Consommation

À titre indicatif, voici des chiffres trouvés sur le forum OpenWrt :

Wi-Fi activé, ethernet désactivé: 194mA
Wi-Fi désactivé, ethernet désactivé: 112mA

La Consommation est raisonable mais la datasheet du RT5350 ne mentionne pas de mode d'économie d'énergie particulier. C'est assez dur de comparer la consommation de 2 systèmes, mais si on s'en tient au comparatif de Adafruit, la consommation de l'A5-V11 se situe entre celle d'une Raspberry Pi A et d'une Arduino Yun.

Système d'exploitation

Livré avec un firmware Made In China qui remplit bien son rôle de routeur, l'A5-V11 peut facilement être reflashé avec OpenWRT , une distribution Linux optimisée pour les routeurs. Il suffit d'uploader un firmware OpenWrt via l'interface web, et c'est fait! Par contre mieux vaut souder un port série et avoir un adaptateur USB-FTDI à portée de main car on a vite fait de se retrouver dans une solution où l'on doit reflasher un firmware via Uboot.

Après avoir installé OpenWrt, on dispose d'un "vrai" Linux basé sur Busybox, Opkg et un noyau 3.18 assez ancien, mais avec beaucoup de drivers backportés. Avec seulement 4 Mo de stockage, on ne va pas trop en demander, d'autant plus que le dépôt de paquets est plutôt bien fourni.

Grâce à Extroot, on peut stocker une partie de l'OS sur une clef USB, mais il faut vraiment choisir les modules noyau un à un : après m'être débarrassé du support IPv6, de PPP et du serveur SSH, je n'avais toujours pas assez de place pour ajouter le support Ext4 nécessaire à ExtRoot. On peut cependant se contenter du support FAT pour lire les clefs USB formatées pour Windows et y stocker ses applications et données.

Entrée/sorties disponibles

Sur le routeur de base, on a accès au port série (soudure nécessaire), à 2 leds et à un bouton .

A5-V11-serie

Pour allumer les leds:

root@(none):/# cd /sys/class/leds/a5-v11\:blue\:system/
root@(none):/sys/devices/gpio-leds/leds/a5-v11:blue:system# echo none > trigger
# on allume le GPIO/ la LED
root@(none):/sys/devices/gpio-leds/leds/a5-v11:blue:system# echo 1 > brightness
# on éteint le GPIO/ la LED
root@(none):/sys/devices/gpio-leds/leds/a5-v11:blue:system# echo 0 > brightness

Pour lire le GPIO associé au bouton reset il suffit d'utiliser le script /etc/rc.button/reset

Les cartes Olimex et VoCore offrent beaucoup plus de possibilités:

-2 Relais 15A/240VAC
-27 GPIOs (dont 24 libres)
-1 port SPI
-1 port I2C
-1 port I2S
-1 port JTAG

Performances

sysbench n'étant pas disponible dans le repository d'OpenWRT, je me suis contenté du benchmark intégré à OpenSSL:

SSL Benchmark

Comparé au Raspberry Pi B+, ce dernier est 2 à 3 fois plus performant que l'A5-V11, et il a beaucoup plus de mémoire.

Quant au Raspberry 3, il est loin devant, surtout si on considère que ce test est monothread et que le Raspberry Pi 3 a 4 coeurs contre seulement 1 pour le Ralink RT5350. Le RT5350 datant de 2010 et coûtant beaucoup moins cher, ils ne jouent pas dans la même cour.

Pour ce qui est de la rapidité du démarrage, avec un temps de boot + établissement de la connexion Wifi de presque 30 secondes, l'A5-V11 démarre assez lentement. On doit sans doute pouvoir accélerer un peu les choses en retirant certains modules de routage IP et de firewall inclus par défaut dans OpenWRT.

Conclusion

Peut on détourner ce routeur pour faire de l'IOT? Oui, mais le point noir se situe au niveau du stockage , 4Mo c'est bien maigre pour un Linux surtout si on tient compte du comportement de JFFS2... Mieux vaut s'orienter sur des cartes dédiées Olimex ou VoCore qui ont 8 Mo de stockage, ce qui permettra de se sentir plus à l'aise et d'inclure tous les drivers nécessaires sans sacrifier le port USB ou le bus SPI pour une carte SD.

L'intérêt de solutions à base de RT5350 réside dans leur petit prix et dans le support d'OpenWRT. Par exemple, si on a besoin de relier une machine industrielle, ou un dispositif médical au réseau via ethernet/wifi et en plus d'offrir un port USB pour un l'import/export de fichiers, c'est un solution quasi clef en main.

Par contre pour les utilisations type capteurs connectés où l'on doit avoir une consommation minimale et une grande autonomie, mieux vaut choisir une autre architecture.

jeudi 23 juin 2011

SSD performances for C/C++ development

Solid State Disks may seem like a luxury reserved to high end or noise free PCs, but can they improve your productivity? Let's find out!

Test configuration:

  • - Intel Core i7 2500k
  • - AsusP8P67 Rev 3.0
  • - 4Gb ram PC12800
  • - SATA3 Western Digital Caviar blue 1 Tb hard disk
  • - SATA3 Crucial M4 64Gb SSD
  • - Ubuntu 11.04 64bits


The 2 disks are partitioned roughly the same :

  • - a 250 Mb /boot partition
  • - a 8Gb swap
  • - a 50+ GB Ext4 root partition

Apparently the way you partition your disk can affect performance. Just in case, I followed the instructions I found here.
I copied the Western Digital HDD root partition to the Crucial root partition and updated /etc/fstab and grub. This way I'm sure I have the exact same operating system on both hard disks.
I also added the discard option to the /etc/fstab SSD entries to ensure the TRIM will happen correctly on my SSD.

Raw performances

With the hdparm -tT command, we can measure the absolute speed of each disk:

Western Digital HDD

Timing cached reads: = 11092.48 MB/sec
Timing buffered disk reads= 129.09 MB/sec

Crucial SSD

Timing cached reads: 23146 MB in 2.00 seconds = 11584.70 MB/sec
Timing buffered disk reads: 1046 MB in 3.00 seconds = 348.37 MB/sec

So The SSD is nearly 3 times as fast as the HDD! That's a good start, what does it change for real life applications?

Boot time

The first obvious performance impact should be the boot time. In order to get accurate results, we will use bootchart. Bootchart checks loading and execution times of various processes involved in the boot sequence. It draws nice graphics and is a bit more reliable than just timing the boot process.

Booting on the HDD

HDD boot time

Booting on the SSD

SSD boot time

Bootchart clearly shows when that with a regular hard disk, the system spends a lot of time waiting for I/Os.
And the reported boot time is 8.21 seconds with the SSD and 21.26 seconds with the HDD! In practice, it takes less than 10 seconds between the time I press enter in Grub and the time when Gnome is up and running, it's less than the BIOS takes to start Grub from a cold boot!

Compilation

Booting quickly is nice, but a lot of people only boot their machine once a day. Let's take the case of a C/C++ developer and see how a SSD improves compilation time.
I used the time command to measure the compilation time, and the compilation tests were launched just after a boot, to minimise all the "caching" that could happen involuntarily. Compilation was set up to use 4 simultaneous jobs (make -j 4). The latest Kernel (2.6.39.1) and Qt examples (4.7) were used for this test.

SSD impact on compilation time The performance boost is not as obvious as for the boot time, but still, your code should compile 10% faster if you use a SSD.
Although it is not in this graphic, I did some tests with Git, it involved adding the kernel source to a git repository and committing all the files. Maybe this task was not intensive enough because I couldn't see any improvement when using the SSD rather then the HDD.

Conclusion

So a SSD can give you a good 10% performance boost when compiling C/C++ projects and make you boot twice as fast.
SSD are still expensive, but if you already have the best CPU your motherboard can take, it is the easiest way to increase the reactivity of your PC.
Also, SSD are supposed to be good at multiple simultaneous random accesses, and this exactly what happens when you have multiple cores doing different tasks. This test was done with a 4 cores CPU, if we repeated it on a core i7 2600k (8 cores), I would expect the SSD to bring an even bigger performance boost.