Cluster ARM

arm-cluster
Cluster arm, cubox im cubieboard, rpi, odroid

Salut,

Je souhaite revenir sur quelque mois d’utilisation intensive de mon cluster ARM. L’image n’est pas celle actuel mais donne une idee de mon portable datacenter.

Je trouve dommage que pour avoir java 8, il faille utiliser le java de oracle et que ce dernier n’est pas actualisé et donc potentiellement avec des failles. Java est une technologie qui permet de faire fonctionner une application que vous soyez sur ARMv6, v7, x86. Mais cela ajoute une abstraction assez casse pieds qui bloque l’accès a certain truc spécifique de l’OS et ne permet de de descendre aussi bas dans le optimisation que en c/c++.

Nagios est performant, munin est pourri cote performance et plombe ces propres mesures (Surtout a cause du spawn de processus). Le backup sur une node en btrfs, le but étant d’avoir des backups différentiel.

Il faut faire très attention à la bande passante inter processus/thread qui est très réduite, sans même parler des communication externe. Donc il vaut mieux privilégier plusieurs processus mono thread qui travaille en local sur leur données locales que du multi-thread qui passe plus de temps à faire tourner les données entre plusieurs threads et se coordonner le travail que à travailler. L’ordonnanceur cpu vas naturellement repartir chaque processus par cpu (base de donnée, noyau, serveur authentification serveur de jeu). Le multi-thread peu être simpa si vous avec qu’un service sur un matos multi coeur (votre base donnée sur un quadcore, bien que dans ce cas l’ordonnanceur disk, le FS et le disque en lui même auront plus d’influence). Mon programme est plus simple est bien plus rapide sur ARM vu que je n’utilise pas de verrou, et je fait juste tourner plusieurs serveur en parallèle. Le joueur n’as plus qu’as jouer sur le même serveur que ces amis, ce qui déporte le problème du multi-thread sur l’humain. Cela permet que le serveur consomme 10-50x moins de cpu que le noyau linux pour gérer les packet tcp.

Grsec combiné à certain manque d’optimisation sur ARM (hardware comme software) fonds que certaines fonction sont bien plus lente (memcpy() vs accès non aligné, presque aucune différence de performance sur x86, ARM + grsec 7x plus performant sur les accès non aligné). Une taille fix en mémoire de l’application aide à ne pas faire de pression sur le code de gestion de la mémoire.

La consommation et prix de la puce est défini par le nombre de transistor dans la puce. Si vous avec une puce trop généraliste vous perdez sur cela, par exemple j’ai pas besoin du GPU ni du FPU pour mes serveur. Par contre j’ai besoin de l’ALU et des unités SIMD. J’aurai aussi besoin d’ASIC AES et SHA224, un générateur de nombre aléatoire pour optimiser la partie cryptographique des applications (connexion des utilisateurs, des serveurs aux bases de données, des serveurs entre eux). La communication chiffré est de nos jours obligatoire, donc le volume transmit via une connexion chiffré même établis en permanence a un impacte sur les performances, les accélérateur hardware se rapporte à un système de chiffré qui hélas se font brisé de plus en plus rapidement). Je n’est presque jamais vu d’accélération sur la compression, si cela est possible. Pas mal de puce ont démontré un meilleur ratio GFLOPS/W car leur circuit sont fix et optimisé. (GPU passage de statique, partiellement programmable, totalement programmable)

Finalement les performances son bien meilleur que un gros serveur x86 (15x la vitesse de la DDR3), plus de sécurité car il y as beaucoup moins de vm par hardware car il y as plus de hardware pour le même prix/consommation énergétique. Je suis très content de mon cluster MMORPG sur ce cluster qui peu tenir d’apres mes testes en gardant beaucoup de marge 30 hardware*4 cpu*100k utilisateur=12 millions de joueur pour moins de 100W.

Longueur idéal de token (jeton)

Bonjour,

Je vais couvrir une partie peu couverte sur le web: quel est la longueur idéal d’un token (jeton)?

Pour qu’il soit réutilisé (piraté) il faut qu’il y ai une collision, c’est à dire que le nombre aléatoire corresponde à celui que l’ont est de notre coté. Cela ne sert à rien d’avoir une grosse longueur si les nombres aléatoires générés sont de mauvaise qualités, car il pourrons être prédit.

Calcule

Avec 32 octets, soit 256Bits, il y as 1.15792089237e+77 possibilité, considérons que l’ont vas tomber par chance sur le bon token dés les 1er 0.01%, il faut donc tester: 1.15792089237e+77/10000=1.15792089237e+73, sachant que un token fait 32 octets et qu’il y as 1.15792089237e+73, cela fait: 1.15792089237e+73*32 donc 3.70534685559e+74 octets à tester. Soit 3.36999333339e+62To à tester. Ce qui corresponds à 1.17495778018e+59 années (oui 59 zeros) avec un réseau 1000Mbps. Les tokens plus grands que 32Bytes me semble inutile.

Plus petit?

Ne connaissant pas les futures innovations technologique (memristor, remplacement du silicium par quelque chose sans vrai limite de fréquence, loi de moore, …), sachant que la courbe est exponentiel (division par 2 réduit fortement la sécurité), sachant que un protocole est difficile à changer, que les futures matériel auront tous les générateurs de nombres aléatoires (voir wikipedia)… Je pense qu’il ne faut pas tomber en dessous de 16 octets, soit 128Bits. Si vous l’envoyé par le réseau en binaire, comptez 60 d’entête (header) tcp donc même avec 32 octets c’est votre entête tcp qui prendra tout la place (inutile donc de diminuer plus pour économiser du réseau).

Plus grands?

Après un certain moments cela n’est plus utile, les temps explose, les risques de collision sont presque null. Ne pas oublier que après 64 octets la taille ce fait sentir sur des packets réseau ne transportant que le token. Si vous n’avez pas de générateurs de nombres aléatoires (voir wikipedia) hardware comme sur les vieux matériel ou bas de gammes et que vous être sur un serveur, il y aura peu d’entropie (voir wikipedia). Donc dépasser 64 octet me semble inutile.

Conclusion

32 octets me semble un bonne taille en générale pour un bonne sécurité. Si la duré de vie du token est limité, si la sécurité n’est pas trés importante, si c’est juste utilisé pour switcher d’un serveur à l’autre dans un temps imparti vous pouvez utilisé 16 octets. Si la sécurité est critique et que le token est stoker et pas généré dynamiquement jusqu’as 64 octets peuvent être utilisé. Je met à part les clef privé (128-512 octets ou +) car les implications sont pas les mêmes et que je suis pas sur de maîtriser le sujet. J’utilise /dev/random pour les clefs/tokens stockés, et /dev/urandom pour les tokens dynamiques.

Je m’en sert pour ajouter un salt dynamique avec le mot de passe et comparer les hash coté server (envoie du token serveur -> client, hash, résultat client -> serveur). Le token n’étant jamais le mêmes la personne ne peu répété les packets réseau, cela permet d’authentifier la personne sans que le mot de passe puisse être intercepté ou répété.

Lien sympa:

CatchChallenger 2 et cluster

CatchChallenger 2 introduit l’infrastructure de cluster. Ce qui implique des changements coté datapack (base commune pour faire tourner les avatars entre les serveurs, et partie spécifique), les changements sont principalement fait. Des changements coté base de données, qui en plus d’avoir les obligations du datapack se doit d’être performante et de marcher sans les auto increment pour les index (pour les bases ne le supportant pas), il y aura encore des changements.

Pour les serveurs, je tiens à garder le serveur Qt (avec une interface et de beaux boutons) pour faciliter la mise en place de petit serveur perso, et le serveur epoll linux simple en CLI pour des serveurs moyens. Le faite de n’avoir qu’un exécutable, une base de donnée et un port à ouvrir rends simple l’utilisation du serveur mais cela permet aussi de ce passer d’une surcouche de communication inter-serveur qui peu être coûteuse en performance.
Le mode cluster ce compose de 2 types de base de données distante (login et common) qui vont être accédé par plusieurs serveurs. Et une base de données spécifique par serveur (qui peu être distante ou non). Il y a des serveurs de login pour gérer l’authentification, le changements de la liste des avatars, création d’avatars et de l’envoie de la base du datapack. Il peuvent servir de proxy pour que le joueur ne doivent pas se reconnecté sur le game serveur (meilleur anonymisation car les ip des games serveurs ne sont pas connu, mais à cause des connexions maintenu ouverte cela à un coût). Un serveur master qui est responsable d’unifier les configs qui ne doivent pas varier en fonction du serveur, d’avoir une base datapack unifié et d’avoir un point de centralisation pour poser les verrous sur les avatars. Il n’est connu que des serveurs login et game. Les games serveurs sont la où joue les joueurs. Si les joueurs sont directement connecté sur les games serveur, les logins serveurs peuvent être coulé par une attaque DDOS sans que les joueurs déjà connecté soit affecté.
Status map du portable datacenter avec nagios pour CatchChallenger 2
Status map du portable datacenter avec nagios pour CatchChallenger 2
La communication inter-serveur n’est pas facile sachant qu’il faille tenir compte des RTT car les serveurs au quatre coin du monde vont avoir des latences de communications. La bande passante peu être limité dans un pays en voie de développement ce qui rends la compression obligatoire. La cryptographie l’est pour certifier que les serveurs autorisé peuvent bien ce connecter entre eux et que les données ne puisse être intercepté (idem pour les bases de données). La modification dynamique de l’infrastructure doit être pris en charge pour ajouter ou retirer à la demande des logins ou games serveurs sans rien redémarrer. Les serveurs doivent se comporter comme un cluster. Il faut prendre en compte aussi les possibles déconnexion temporaire avec le master serveur. C’est la ou l’asynchronisme surtout coté base de données prends tout sont sens.
Pour idéalement une bonne portabilité sur tout les environnements mais aussi de bonne performance (le QDataStream + QByteArray de Qt à beau être sécurisé et très commode, il est extrêmement peu performant), le passage d’un maximum de code en C++11 et surtout les sérialiseurs (avec des buffers pré-allouer pour éviter des pressions sur la mémoire à cause de new/malloc trop fréquent) est en cour. Mais je ne pense pas pouvoir tout bouclé pour la version 2 donc la dépendance avec Qt sera toujours de mise. Le passage en C++11 me permet un certain nombre de chose via la norme même, et me force à faire du code souple Qt <-> C++. Cela permet aussi d’exploiter les parties spécifiques à l’OS qui est totalement abstraite en Qt et donc qui n’est pas accessible. Je pense aussi à libOS qui veux être dans la branche principale de linux, j’ai un peu peur de cela car certain dev newbies ont tendance à vouloir le contrôle sur tout, soit car il ont entendu que ça augmenterai les performances (ce qui est vrai seulement si ont sais s’en servir) ou simplement pour se sentir aux commandes (en oubliant la sécurité, et l’isolation des taches). Sans parler que refaire un ordonnanceur, un driver, … et le maintenir est une grosses charge supplémentaire qui fait exploser le développement à faire. Idéalement si le master serveur et les logins serveur font 10Mo et utilise 1Mo de mémoire ou max <10Mo ça me vas.
Un support de NoSQL ne me semble pas réaliste ainsi que les requêtes préparé pour cette version. Par contre vu que MySQL 5.5+ ce généralise je verrai si j’ai le temps de faire le support de MySQL en asynchrone.
Le portable datacenter continue à grandir, ayant changé ma connexion pour 2M en download et upload, cela me permet de faire un peu d’hébergement (site + 200 joueurs). Peu de services sont visibles mais pas mal de service en background sont la. Il continue à être un mix de machine légère (rpi 1, cubieboard2, ordoid u3, cubox-i, fit pc 1…, donc Geode LX800, Cortex A9, ARM1176JZF-S, Cortex A7, de 1 à 4 coeur par config). Le tout monitoré sous nagios + munin. Avec un peu de btrfs, beaucoup d’ext4. Lxc + grsec comme système de virtualisation, et gentoo en -march=native pour les hôtes et -march=native pour les hardwares où j’ai de multiple exemplaire et -march=generic pour les autres. Cela me fait un bon parque pour faire de l’auto benchmarking.

 

 

btrfs vs overlayfs

Bonjour,

Btrfs est un systéme de fichier avec des fonctions évolué telque la compression, le support du raid, la déduplication, la gestion de multiple volume (pour booster le FS avec un SSD), les snapshots pour faire les backups et ne garder sur le hdd que les différence entre 2 snapshots…. ZFS est une alternative, mais ce n’est pas dans la branche principale de linux.

Overlayfs est une virtualisation du FS qui permet d’avoir un dossier de base, et une multitude variation de ce dernier. Cela est surtout utilisé dans les livecd, cela permet d’avoir une image fix (le cd), et une zone d’écriture (ramdisque, tmpfs), ce qui permet à l’utilisateur d’avoir l’impression d’avoir une version installé car il peu tout modifié (et donc les changements sont gardé en mémoire RAM grace à overlayfs). Il existe comme alternative aufs, unionfs, … mais seul overlayfs est dans la branche principale de linux.

Les machines virtuelles sont souvent trés similaire. J’ai donc testé ces 2 solutions pour monté des machines virtuelles:

  • Btrfs ne permet pas la déduplication de dossier (il vous avec 10000 fichiers identique dans un dossier, la liste de 10000 sera stocker 2x). La déduplication ne s’applique pas aux fichiers inline (petit fichier surtout). Il m’as fait perdre des vm pour ces divers bugs (vm de teste donc pas de backup). La réparation peu bloquer pourtant le FS est montable, … il faut donc le backuper, reformater et restaurer: un comble que la réparation ne marche pas. Par contre la compression est utile sur les petits espaces ou pour augmenter virtuellement la vitesse du média sur le fichiers compressible (carte SD 😉 mais en échange de latence un peu plus grande surtout sur les petits fichiers). Les backups temps réél avec juste sauvegarde des différences et la déduplication (même si elle est partiel) sont un plus.
  • Overlayfs ne déduplique pas, cela veux dire que 2 fichiers changés au dessus du dossier de base vont être stocké 2x sur le hdd. Donc si vous mettez à jour vos vm, la différence des mise à jour est stocker X fois. Mais c’est trés stable sur du ext4. La variation stocker est vraiment minime et permet de gagné vraiment beaucoup de place (c’est presque comme si vous stockiez les sites que vous y mettais).

Au final, quelle solution j’utilise? Aucune, les défauts de chaque solution sont trop grandes pour être utilisé en production. Donc ext4 pour les serveurs de prod, et btrfs + snapshot pour les serveurs de backups.

Nextcoin market, i2p et CatchChallenger

Salut,

Je viens vous donner quelques nouvelles. J’ai mit en place un système de vente de software sur le nextcoin market. Le nextcoin market est un système de vente en ligne parfait pour l’ecommerce mais décentralisé et peu chére. J’y ai donc mit CatchChallenger, et j’y mettrai Ultracopier 2. Le tout via l’envoie de clef. J’ai aussi mit en ligne d’autre moyen de paiments.

CatchChallenger avance bien, il rentre en RC. Il marche super bien au travers d’une connexion lente et d’i2p. Il deviens de plus en plus stable et as une meilleure base chaque jour. Version 0.7 en ligne, version final pour la fin de l’année.

Le site CatchChallenger et Ultracopier à été réécrit rapidement en responsive design pour marcher sur téléphone et tablette.

Bye,

Socket Tcp vs Socket Unix

Bonjour,

Quel est la différence entre un socket unix et un socket tcp?
Un socket Tcp est fait pour communiquer sur l’exterieur via le protocol ip, avec une possible perte de packet, corruption et j’en passe. Il faut donc pas mal de code pour remettre ça en forme, les données transportés doivent être indépendante de la platforme logiciel et materiel utilisé.
Un socket unix est un socket local, donc pas de perte de packet, pas de routage, et  dans la même machine. Cela implique pas de changement endianness, cela reviens à juste écrire en mémoire d’un coté et lire de l’autre ce qui permet une grosse augmentation de performance.
Chaqu’un a donc son utilisation, mettre les données d’un socket unix sur un réseau tcp/ip perdrai ces performances et ne serai pas fonctionnel à cause de l’endianness par exemple. Mettre un socket tcp dans un socket unix n’as pas le moindre sens non plus. Pour communiquer exclusivement en local utilisez un socket unix, pour une communication distante un socket tcp (encrypté, et peu être compressé) sera plus adapté.
Bye

Path finding du plus droits chemin

Bonjour,

Je viens de finir une version préliminaire du path finding pour le plus droits chemin.
Mais pourquoi le plus droits et non pas le plus court?
  • Car cela permet de minimiser le volume réseau
  • Minimiser le changement de contexte coté OS à cause de multiple trame réseau
  • Minimiser le changement de contexte coté application car il doit géré un client, puis un autre, puis revenir sur le 1er
C’est loin d’être optimal coté implémentation (ont ne peu pas changer de map, intérragir avec les objets, …), mais c’est fait. C’est assez complexe car il y as 4 informations par tile, au lieux de une dans un path finding avec le plus cour chemin.
Cela permettra de reduire les couts de fonctionnement du projet.
1er post fait avec blogilo car chrome bug pour les accents depuis quelques versions.
Bye,

 

Odroid u3

Hello,

How to

Cut one wire of power source, connect your 2 wire of you ampermetter to the 2 part of one wire, take care to be in 10A mode to don’t burn the fuse.

Result

Here you have the power consumption on 5V line (then without the adaptador power, I have used an DT-830B):

ODROID-GameStation-Turbo-0.10_20140525-X
4 thread: 1.42A, 7.1W
1 thread: 0.75A, 3.75W
0 thread: 0.58A, 2.9W
99°C max temp

USB not work, then my usb joystick not work, 100% at all time.

It’s just crazy in fonction of ubuntu server:

4 thread: 1.20A->1.46A, grow slowly and after is random: 6-7.3W
1 thread: 0.48A, 2.4W
0 thread: 0.29A, 1.45W
85°C max temp

Only use micro SD card, network (1000Mbps), no thing more. No HDMI, no sound, …

Cheers,

Kernel 3.10 ipv4 performance

Hello,

You have here for 3.10 kernel the performance on lo (127.0.0.1) via iperf of different hardware:

  • Fit pc1 Geode lx800 @500Mhz: 828Mbits/sec, 1.6Mbits/sec/MHz
  • Cubox-i4 pro, iMX6 quad @1000MHz: 2.16Gbits/sec, 2.16Mbits/sec/MHz
  • Fit pc2, Intel Atom z530 @1600MHz: 3.05Gbits/sec, 1.9Mbits/sec/MHz
  • Intel Haswell Core i5-4670 @3400MHz: 36.7Gbits/sec, 10.8Mbits/sec/MHz
  • Intel Core2Duo P8600 @2400MHz: 3.79Gbits/sec, 1.6Mbits/sec/MHz

Note: ARM need of of optimisation in kernel and in compiler to be exploited.

Have good day.

Technologie utilisé dans CatchCallenger

Manipulation du buffer réseau

0 copy

La technologie 0 copy technologie est un moyen pour ne jamais copier un buffer dans un autre (bien sur qu’en interne ont ne peu y échapper, par exemple pour transférer le buffer de la carte réseau jusqu’au programme). Vous déplacez seulement le curseur sur les données et vous controlez les données. Aprés vous pouvez:

  • Isolez le code principal et retournez les données comme une structure
  • Directement tout passer comme une structure

La structure de donnée est exclusivement de taille fixe car les tailles dynamique exige pointer et copie mémoire. (Et vous ne pouvez pas envoyé un pointeur au travers du réseau)

Si une donnée est supérieur à 8Bits, alors vous devez corrigez l’endianness, cela coute principalement des petites transactions mémoire.
Cela est pour envoyer des commandes avec des arguments temporaires. Les données persistantes ont besoin d’être stocker et donc n’autorise pas le 0 copy. Vous devez les garder quelque part car le buffer vas être purger.

SIMD

Sur Arm c’est neon, sur x86 c’est SSE-X, AVX-X. Pour en savoir plus, voir: http://en.wikipedia.org/wiki/SIMD
Ils permettent de copier un block mémoire avec une seuls instruction, c’est plus puissant qu’une boucle car cela exploite mieux le hardware sans avoir besoin d’utiliser les capacités de Vectorization du compilateur, voir: http://en.wikipedia.org/wiki/Vectorization_(parallel_computing)
Si une plage d’octet est valide, vous pouvez avoir un structure similaire as: 99x8Bits dans le buffer,  »’vous pouvez utiliser memcpy() pour transférer une plage d’octet directement depuis le buffer sur la structure »’.
Si une donnée est supérieur à 8Bits, alors vous devez corriger l’endianness, cela coute principalement des petites transactions mémoire. Voir le déserialiseur.
Cela est plus orienté pour le stockages des données mais peu être utilisé avec des données temporaire dans certains circonstances..

Déserialiseur

Cela est plus lent que le SIMD, mais cela est adapté pour les stockages d’informations qui doit être traités. Par exemple en chaine qui doit être transformer en pointeur + taille (mix avec les SIMD arrive souvent), vous devez changer l’Endianness pour la plus part des entiers, …
Priviligez de démarrer avec les adresses basses (buffer[0]) jusqu’au adresses haute (buffer[99]) pour améliorer les performances.

0 Allocation mémoire

La plus par du temps, n’ayez pas d’allocation mémoire, ou dans le pire des cas sur la stack. Grace à un protocole binaire, une taille fixe, un buffer permanent pour déserialiser les données est une bonne solution.
Toutes les opérations réseau lourdes comme le chargement du datapack peuvent être externalisé. Sur des serveurs hautes performances seul le trafic utile est envoyé et reçu, il y as donc de meilleur latences et un serveur plus légé, …

Binaire

Le texte peu être utile pour débugger, mais il utilise beaucoup de réseau et ressources.
Moins d’un accès sur un millards sur http est lu directement depuis le dump réseau (par des hackers, admin réseau, développeur -> vous devez avoir le niveau pour travailler avec, au même titre que manipuler des images/videos), cela veux dire que le reste du temps les ressources sont consommés sans raison, un protocole http binaire serai afficher de la même manière que le protocole http text dans un navigateur.
Pour utiliser les données « Data: 654654″‘ vous devez extraire « 654654 » (vérifier la longueur, faire une allocation dynamique) puis  »’le convertir en nombre »’. En binaire faite juste une copie (a=b;) et corriger l’endianness si besoin. ce qui est beaucoup plus puissant en binaire. La negociation du protocol en binaire été de 66 octets, en binaire elle est seulement de 5, avec un gain de 50x d’utilisation du cpu sur les opérations de lecture et comparaison.

Anti DDOS et cout de l’infrastructure

Toutes ces technologies et un bon usage du compilateur comme -march=XXX, permette d’être anti-DDOS par nature car cela permet de supporter un grand nombre de requêtes par seconde. Cela minimise le cout de l’infrastructure, autorise un jeu moins chère, plus de serveur pour les joueurs. Cela est donc plus dur à DDOS, C’est aussi plus facile à administré.

Epoll

Epoll est utilisé pour résoudre le problème C10K. Le serveur peu facilement supporter beaucoup de joueur sur un ordinateur de 25ans. Il ne saute pas la couche tcp du noyau pour fonctionner correctement en para-visualization, mais un bonne optimisation permet de résoudre le problème C10M sur un bon hardware.

Plugin

La plus par des parties standard comme la visibilité sur la map, base de données sont dans des classes et géré comme des plugin pour être changé, testé et benchmarké facilement.
Les plugins des bases de données en mode texte demande beaucoup de conversion du text vers des entiers (utilisation du cpu sur le serveur), la manipulation des chaines due à SQL prends aussi beaucoup de cpu/memoire/allocation mémoire aussi, et finalement la base de données sur le même serveur consomme aussi des ressources.
Inclut avec index et optimisé, la base de données est largement la partie la plus lente du serveur (tant coté cpu, memoire que IO disk), c’est pourquoi les requêtes sont asynchronisés.

Traduit de: http://catchchallenger.first-world.info/wiki/Technologies_used

Note: le protocole ftp en plus d’être text oblige de supprimer le contenu des dossiers pour supprimer ces dossiers. Vous passez donc de l’envoie de quelque octet et quelque ms 0 des Mo et des minutes heures pour supprimer les gros dossiers… Et vous contourner toutes les optimisations des FS sur la suppression des dossiers…