Sommaire
Il y a quelques jours, nous avons été invité à tester la futur offre de serveur basé sur des processeurs ARM sur le site cloud.online.net. Ces serveurs disposent de 2 Gio de ram, 20 Gio d’espace disque sur SSD, ils ne sont pas virtualisés, et disposent d'un SoC ARM V7 a 4 coeurs (ARMv7 Processor rev 2 (v7l) / Marvell Armada 370/XP pour les intimes).
Les applications que nous avons testées sont des applications d'entreprise classique, c.a.d. ayant peu d'utilisateur, mais faisant des choses plutôt lourd et très diverses.
Nous utilisons le framework grails, en version 2.4.3 et 2.5.0. Nous avons constaté un gains de 10 pour cent au démarrage avec la version 2.5.0, par rapport à la précédente, rien qu’avec le passage à Groovy 2.4.1 et la version 3 devrait apporter d'importants gains supplémentaires.
Grails, c'est RoR (Rubis on Rails), mais basé sur Spring. Spring va gérer la durée de vie des objets de votre application (contrôleur, services, beans), en les injectants par inversion de dépendance. Spring va également offrir de nombreux composants. Grails va ajouter un ORM basé sur Hibernate, ainsi qu'une grande facilité d'utilisation grâce à Groovy, et a un ensemble de conventions pour simplifier la configuration (convention over configuration).
Les plugins/composants que nous utilisons:
- Spring security,
- Spring webflow,
- BiRT Projet Eclipse Business Intelligence Reporting Tool, permet de générer du xls, ods et de très simplement faire des rapports
- Solr et Tika pour l’indexation des fichiers / objets métiers
- LibreOffice et ImageMagick pour la génération des thumbnail pour les fichiers uploadés.
- postgres extention pour pouvoir utiliser les maps, les tableaux, jsond, nativement dans postgres
- Quartz pour la planification des jobs “applicatifs” (mailing, tâches de synchronisation).
- Protobuff pour la communication avec CRM Android
Nous utilisons Postgres, avec un plugin de datamining Madlib. Il y a 2 instances de base de données, l'une pour les applications, l'autre pour les statistiques/datamining. Les stats sont synchronisées avec les différents ERP des filiales tous les jours, via l'ETL Kettle (une merveille, libre en plus). Sans rentrer dans les détails, tous les ERP sont évidemment différents, et ne sont pas tous basée sur une base SQL…
Pour planifier le tout, on utilise Rundeck / ssh. ça fonctionne un peu comme Ansible, c.a.d. qu’il n y a aucune dépendance ou d'agent installée sur les serveurs où les tâches son planifiée, hormis ssh.
Les applications que nous développons: CRM, EDI, Qualité, BI, plus la gestion d’utilisateur, de projet et l’upload des données sur les sites web (FR, US, CN, DE)…
Voila pour l’aspect applicatif, ce que l’on peut dire, c’est que nous avons pas mal de composant lourds, de plus, si nous utilisons une architecture en plugin pour ranger ce qu’il y a de commun entre les applications, chaque instance d’application utilise son propre espace (mémoire, poll de connexion, cache), l’occupation mémoire est importante, mais on peut faire ce que l’on veut, presque simplement, et le tout tourne bien sur un serveur moyen gamme, avec une grande souplesse et robustesse pour une soixantaine d'utilisateur dans le monde.
Les résultats des essais
L’interface d’administration est très simple, les machines s’installe en une poignée de secondes, ça pourra gêner les bidouilleurs, mais il est possible de gérer sa propre image. En un ou 2 cliques, l’on peut instancier une nouvelle machine avec l’image de son choix, accéder au données et l’administrer.
La plate-forme semble très réactive, j’ai utilisé une Ubuntu sans SystemD (j’aurais aimé une Fedora ou autres avec SystemD). On ne sent pas que l’on est sur un CPU de téléphone portable à l’usage, je suis persuadé que les applications PHP vont très bien tourné, Ubuntu/Debian semble avoir fait du bon boulot pour l’optimisation de leur distribution sur cette architecture, mais comment mon application va t-elle fonctionner?
Après avoir fait de nombreux tests sur Raspberry Pi, je m’attendais à ce que le tout fonctionne, mais vraiment très lentement, avec de nombreux blocage, mais le Raspberry Pi avec ces 512 Mo est vraiment trop juste.
Ce qu’il faut savoir avant de lancer son Tomcat, c’est que l’on doit impérativement utiliser la version Java d’Oracle, car elle dispose du c2 compiler sur ARM v7, ce qui n’est pas le cas de l’OpenJDK. OpenJDK disposera du C2 compiler avec le jeu d’instruction ARM v8 (64-bit). Ça fonctionne avec l’OpenJDK, mais c’est vraiment hyper lent.
Concrètement, on démarre tomcat très simplement ainsi
export JAVA_OPTS=" -Xms512m -Xmx1512m -server "
et c’est tout.. En gros on dispose de 1,5 Gio pour les allocations.
Comme il ne reste plus grand chose pour postgres et solr, je les démarre avec les options par défaut.
Conclusion
Que dire? c’est a peu près 3 ou 4 fois plus lent que mon serveur Xeon à dd non SSD. C’est un exploit! Les applications sont largement utilisables (hors des stats si trop grosse requête). Alors que ces CPU sont réfléchis pour supporter un type de charge horizontal (peu de traitement par requête avec plein de requête), j’ai pu faire fonctionner ma stack logiciel complète, sur une sur une seul machine, sans aucune difficulté.
Pourquoi est-ce un exploit alors que c’est 4 fois plus lent? parce que les développeurs de compilateur, de java et autres optimisent leur code pour Intel depuis des décennies, en réalisant toutes sortes de micro optimisation favorisant Intel, il y a une personne qui travaille sur le C2 compiler pour ARM v7 chez Oracle…
De plus, Linux sur ARM est très agréable à l’usage, autant que sur Intel, il y a quasiment tout ce qu’il y a sur Intel, et le potentiel d’ARM me semble plus prometteur que celui d’Intel à long terme.
# Manque l'essentiel
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 07 avril 2015 à 13:54.
Le concept de serveur ARM, ça fait des lustres que c'est connu (Raspberry Pi et compagnie), on sait que ça marche plutôt pas mal (ben oui, on a des téléphones) en mobilité (l'énergie coûte "cher"), il manque donc l'essentiel : le prix.
C'est la seule chose qui permettra de dire si c'est plus prometteur.
(pour le moment, si je suis bien, c'est 10€/mois, donc il serait plutôt intéressant d'avoir un bench en concurrence avec par exemple une offre au même prix à peu prêt en x86).
Et ne pas oublier que ce n'est pas la première fois qu'on enterre Intel (ha les annonces tonitruantes d'un PPC tueur de x86 dans les années 2000…)
Bref, désolé mais ça me laisse un peu sur ma faim, il manque surtout un comparatif avec la concurrence comme démonstration de quelque chose de prometteur (surtout qu'on a déjà eu le droit à quelques faillites du côté de ceux qui croient en ARM pour les serveurs).
systemd
[^] # Re: Manque l'essentiel
Posté par karteum59 . Évalué à 4. Dernière modification le 07 avril 2015 à 17:26.
Mouais, sur ARM, on n'a pas de couche d'abstraction/introspection comme BIOS/ACPI/EFI/…
Donc on n'a pas "one kernel to rule them all" (alors que sur mes vieux PC d'il y a 15 ans, je peux encore booter un CD d'une distro linux quelconque). Donc c'est autrement plus complexe à maintenir (le device-tree améliore la donne, mais ça reste imparfait) et la pérennité de tes machines est largement discutable lorsque le constructeur en cesse le support.
N.B. 10$/mois, je trouve que c'est cher pour du ARM alors qu'un Odroid C1 (nettement plus puissant qu'un RPi) coûte 35$ ! Et comparé à du cloud : personnellement j'ai une VM OpenVZ pour 10$/an avec 768 MB RAM, 20GB disque et 2TB trafic/mois ! (évidemment ce n'est pas comparable, mais je trouve que le tarif de cette offre ARM reste disproportionné. Autre exemple : Kimsufi est moins cher…)
[^] # Re: Manque l'essentiel
Posté par navaati . Évalué à 3.
Où ? Parle ! :)
[^] # Re: Manque l'essentiel
Posté par Zenitram (site web personnel) . Évalué à 2.
$KVM (plus de possibilités) RAM 1 GB, SSD 24 GB, Transfer 2 TB, USA https://www.linode.com/pricing 10
OpenVZ RAM 2 Go, HDD 24 GB, Transfert "illimité" France http://www.ovh.com/fr/vps/vps-classic.xml 5€
OpenVZ RAM 2 GB, SSD 50 GB, Transfer 1 TB, Audtralie (zut, ils ont viré l'offre 2x moins à $10, je dois prendre un plus gros) http://www.exigent.com.au/budget-virtual-servers $15
etc… voir aussi http://lowendbox.com/ avec plein de VM à moins de $7/mois
Je ne vois pas en quoi OpenVZ pour 10$/an avec 768 MB RAM, 20GB disque et 2TB trafic/mois est étonnant.
le problème est la perf, difficile de comparer les "vCore" entre eux, faut tester.
Mais sérieusement, si on fait un test d'ARM, il faut un minimum bencher, car ça marche sinon ils ne vendraient pas, tiens, et ce n'est pas le prix qui attire (pour le moment) car lors des discussions informelles, la tendance pour le moment est à dire que ben le CPU ARM il ne casse pas grand chose et que le reste ben c'est le même prix.
J'attends toujours une argumentation qui dit qu'ARM a du potentiel, pour le moment on ne voit pas grand chose venir, et personne à ma connaissance n'ose faire de bench (peur de jouer la comparaison?), j'ai plus entendu de faillites dans le milieu des entreprises ayant misé sur de l'ARM serveur.
Bon, à quand un "use case" montrant une supériorité (prix pour la perf, perf pour le prix, qu'importe) d'ARM par rapport à une offre x86?
[^] # Re: Manque l'essentiel
Posté par flan (site web personnel) . Évalué à 4.
À ce que j'ai entendu (par des gens dans le milieu du CHP), certains s'attendent à ce que l'ARM puisse concurrencer le x86 dans 5 ans environ (s'il n'y a pas de grosse surprise). Mais naturellement, si l'ARM obtient les mêmes perfs que le x86, ça sera au détriment de la consommation (qui sera équivalente à celle du x86).
Après, il n'y a pas de mystère : ce sont (globalement) les mêmes technos, qui veulent répondre aux mêmes problèmes, donc on peut s'attendre à avoir des résultats équivalents (sachant que finalement, la surcouche historique due au x86 n'est pas si coûteuse).
L'intérêt de l'ARM reste quand même d'avoir un vrai concurrent à Intel : depuis qu'Intel est le seul « vrai » fournisseur dans le CHP, le prix des processeurs a bien augmenté.
[^] # Re: Manque l'essentiel
Posté par YBoy360 (site web personnel) . Évalué à 0.
L'intérêt d'ARM c'est que tout le monde peut en faire et qu'a procédé de fabrication identique, ça consomme moins qu'intel. Google, Facebook ne sont jamais passé à SPARC ou PowerPC, pourtant il se mettent a utiliser de l'ARM.
C'est pas miraculeux, mais ça n'empêche pas de tester ces applications en conditions réelles pour voir. Pour avoir travaillé 5 ans sur des bench CPU constructeur, les benchs des autres ont trop d'intérêt marketing pour être significatif et partial bien souvent. Ça se regarde avec prudence.
[^] # Re: Manque l'essentiel
Posté par Zenitram (site web personnel) . Évalué à 1.
Ca consomme moins qu'Intel à performance identique? A quel prix? (identique ou pas?)
Ca ne sert à rien d'avoir 1000 fabriquants possibles si aucun ne fait mieux qu'Intel.
Prenons n'importe quel exemple réel : essayer d'optimiser un cas donné (genre une base de donnée donnée, un test de montée en charge etc…)
Je suis preneur de n'importe quel exemple d'utilisation avec un bench sur des plate-formes d’hébergeurs en "vente libre" pour voir si il y en a qui partent sur un processus industriel (pas un beta test, un prix à long terme).
Et oui, je pourrai faire moi-même, mais bon, je dirai que c'est à ceux qui proposer de l'ARM de montrer que ça va servir à quelque chose, ça sert à rien de tester 36 solutions sans avoir l'espoir que ce soit utile.
Oui, oui, Google dit aussi qu'il passe (après l'avoir acheté) à VP9 plutôt que H264 (et qu'il supprimait H264 de la prochaine version de Chrome, celle d'il y a quelques… années), j'attends des preuves que des effets d'annonce.
Pour le moment, je constate que beaucoup disent "ça va marcher", mais qu'un gros paquet de gens ayant dit que ça allait marcher ont mis clé sous la porte, reporté leur déploiement etc… désolé, mais ça pose quelques doutes. J'ai l'impression que c'est plus un lièvre à filer à Intel qu'autre chose.
[^] # Re: Manque l'essentiel
Posté par Yakulu . Évalué à 2.
Bon alors on va me reprocher avec raison la méthodologie, l'aspect micro-bench etc… mais j'ai vu passé quelques comparatifs ARM/x86 chez Phoronix. Par exemple dans le cas du Tegra K1 1 & 2. Le K1 semble compétitif face à des Atom (ici âgés mais dont les performances semblent avoir peu augmenté au fil des années, sauf à ajouter des cœurs et à davantage consommer) ou des APU AMD d'entrée de gamme pour une consommation plus faible.
Le K1 n'est cela dit sans doute pas dans la même gamme que les processeurs utilisés par Free dans son offre. En revanche, pour cette puce-là, il y a un UnixBench qui a été fait pendant la phase bêta.
[^] # Re: Manque l'essentiel
Posté par Zenitram (site web personnel) . Évalué à 2.
Pas du tout, il faut bien commencer quelque part.
Mais je cherche plutôt à avoir des benchs de 2 offres financières comparables, car ici on parle de taper dans la compétition en hébergement, et en hébergement il faut comparer le tout (électricité, place, etc…) et il y a rien de mieux pour la partie financière que des hébergeurs qui se lancent dans un offre réelle.
Par exemple, j'aurai aimé avoir un UnixBench sur les CPU de chez Online des Dedibox (C2750 Avoton) pour avoir un ordre d'idée mais trouve pas :(.
[^] # Re: Manque l'essentiel
Posté par Zenitram (site web personnel) . Évalué à 2. Dernière modification le 07 avril 2015 à 20:23.
Oui, je me répond à moi-même :
UnixBench scores
Ca me fait peur, j'espère me tromper, tu parles de UnixBench à 460 pour le serveur ARM qui semble être à 10€/mois, le moindre VPS à $2-$10/mois tape dans les 1000 (ne parlons pas des IO), voire http://serverbear.com/benchmark/2015/03/21/wi0rPhl0JTETqPQc et cliquer sur "comparison" et cliquer ensuite sur "Cost".
J'espère grandement qu'il y a d'autres bench dans lequel leur offre est meilleure… Parce que la, je ne comprend pas du tout l’intérêt pour le moment.
[^] # Re: Manque l'essentiel
Posté par Yakulu . Évalué à 3.
À vrai dire, cela ne me surprendrait pas tant que ça. Je pense qu'il faut aussi se méfier de ces bench sur des VPS, car selon les technologies sous-jacentes, il est possible qu'il y ait une sur-allocation de CPU - burst au delà des ressources garanties - si l'ensemble du serveur hôte n'est pas trop sollicité. Je crains que la seule comparaison valable serait face à un dédié Atom dans la même gamme de prix.
Il y a deux choses que je trouve intéressantes dans l'offre d'Online :
En revanche :
[^] # Re: Manque l'essentiel
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 07 avril 2015 à 22:38.
Je n'aurai pas dû passer sur les VPS.
Passons donc à un dédié.
Ca tombe bien, j'en ai un pas cher, j'avais oublié.
Et… Même entreprise que le sujet du journal. Donc la comparaison se fait de manière très proche (j'imagine : même réseau, même SLA, même support…)
Dedibox SC Gen2, 6€/mois, 2 GB de RAM (2x plus que le sujet du journal), SSHD de 512 GB (pas cherché combien de SSD dessus, mais je parie que ça s'approche du sujet du journal, et c'est en local) : UnixBench de 340 pour un CPU Via U2250. L'ARM fait donc 35% de plus pour 67% de prix en plus, sachant qu'on a 2x moins de RAM (donc si on a besoin de RAM, hic encore plus cher).
Il serait interessant de tester la Dedibox XC 2015 à 16€/mois mais j'en n'ai pas sous la main, mais vu que Via est réputé pour être un processeur vraiment inférieur aux Atom (surtout ceux de 2014), j'ai peur pour ARM (parce que la, je le compare quand même à un CPU qui date de 2008, 7 ans d'âge! Parait qu'ARM consomme moins, mais alors ça devrait être moins cher hors ça ne l'est pas.).
indépendant du CPU, faisable pareil avec x86
indépendant du CPU, faisable pareil avec x86
Concentrons nous sur l'apport d'un CPU ARM face à l'hégémonie d'Intel… j'avoue avoir du mal à comprendre ce qu'on peut trouver à ARM, du moins en 2014/2015. J'aimerai vraiment un cas d'usage qui fait qu'ARM est plus rentable d'Intel sur les serveur (pas un "processus de fabrication", mais en capacité de proposer une offre globale).
Pour l'instant, j'ai l'impression que c'est plus pour faire parler que quelque chose de viable économiquement (comme le Concorde, mais bon, le Concorde avait le plaisir d'avoir la "perf", la le plaisir est juste d'être différent?)
[^] # Re: Manque l'essentiel
Posté par Yakulu . Évalué à 2.
Oui et comme tu le dis, le Via Nano U2250, qui consomme 8W, est tout sauf un foudre de guerre. CPUBenchmark publie un grand test de processeurs x86, ça permet de le situer par rapport à d'autres. La différence vient surtout du nombre de cœurs, mais ici pour une consommation semblable (10W pour le D2700). En somme, le processeur ARM employé chez Online ne semble pas très efficace mais peut tenir la comparaison face à des serveurs dotés d'Atom (du moins lorsque ceux-ci n'ont qu'un seul cœur).
Restent que les autres défauts relevés rendent l'offre, pour moi, moyennement attractive.
[^] # Re: Manque l'essentiel
Posté par YBoy360 (site web personnel) . Évalué à 1.
Les serveurs disposent de 2 Gio de RAM et d'un ssd local, sur le pcb du serveur, de 20 Gio.
Je ne dis pas que l'offre est intéressante, elle est pas la moins cher, je dis juste avoir été surpris des performances d'un ARM v7 a 1.3 GHz.
Une application d'entreprise typique peut être utilisable. C'est tout. Et je trouve que c'est rassurant pour notre liberté de choix dans le future, concernant les CPU.
[^] # Re: Manque l'essentiel
Posté par Zenitram (site web personnel) . Évalué à 3.
La liberté de choix, on l'a qu'à partir du moment où l'offre est viable (pour pouvoir durer dans le temps).
On l'a vu avec AMD, à partir du moment où ils se sont mis à ne plus savoir faire de bon produit, Intel a repris ses habitudes (ne pas trop se "donner"), dans les négociations ben… euh, non, pas de négociations, Intel sait qu'il est seul, un hébergeur qui va dire "si tu n'es pas gentil, je prend AMD" va plutôt faire rire Intel.
Donc il faut une offre intéressante, sinon l'offre sera assez vite abandonnée faute d'acheteurs (ça ne sera pas la première fois) et tu n'auras pas de libertés.
Et pour que l'offre soit intéressante, il faut qu'elle soit bien meilleure que le concurrent en place (prime à l'ancienneté à casser), du coup ben… je suis déçu plutôt de mon côté, j'espérais bien mieux comme offre (soit plus performant, soit moins cher).
Note : ne te méprend pas, oh que j'aimerai de la compétition mais pour le moment force est de constater que l'offre ARM ne laisse pas trop espérer, comme déjà dit on voit plutôt des faillites dans le milieu des serveurs ARM, et si faillite, ben pas de liberté pour l'acheteur.
[^] # Re: Manque l'essentiel
Posté par Nitchevo (site web personnel) . Évalué à 2.
[^] # Re: Manque l'essentiel
Posté par Prosper . Évalué à 6.
Anandtech qui a fai un article de l'Armv8 (x-gene) face aux solutions intel ( atom , x2750, xeon-d … ) , l'Arm se fait un peu piétiner sur tous les plans par les solutions intel:
http://www.anandtech.com/show/8357/exploring-the-low-end-and-micro-server-platforms
[^] # Re: Manque l'essentiel
Posté par Ph Husson (site web personnel) . Évalué à 2.
Le X-gene n'est pas un coeur ARM, il n'a que les instructions ARM.
C'est comme dire que intel c'est pourri, parce que un via en x86 est nul. (sauf que les instructions ARM sont à ARM et les x86 pas à intel, soit)
[^] # Re: Manque l'essentiel
Posté par Prosper . Évalué à 3.
Ca serait quand même bien ballot d'acheter une licence architecture et faire moins bien que la licence "basique" .
[^] # Re: Manque l'essentiel
Posté par Ph Husson (site web personnel) . Évalué à 2.
Ils datent d'avant la première release des coeurs ARM armv8.
Wikipedia me dit qu'il est même basé sur un cortex-a50, qui n'a jamais existé publiquement.
[^] # Re: Manque l'essentiel
Posté par X345 . Évalué à 3.
Attention la performance des Atom basés sur l'architecture Silvermont est très supérieure à celle des Atom basés sur les architectures précédentes. En particulier, les Atom Silvermont (modèles commençant par C, e.g. C2750) ne sont pas des processeurs in-order, ce qui amène de très gros gains de performance.
Pour se donner une idée: Benchmark CPU - Atom N2800 vs Atom C2750
[^] # Re: Manque l'essentiel
Posté par Ph Husson (site web personnel) . Évalué à 2. Dernière modification le 08 avril 2015 à 15:05.
(pour ceux qui auraient la flemme de faire le calcul, à fréquence et nombre de coeurs égaux, en supposant que les tests sont en turbo speed, ça fait 15%, sinon, 25%)
[^] # Re: Manque l'essentiel
Posté par YBoy360 (site web personnel) . Évalué à 0. Dernière modification le 07 avril 2015 à 21:14.
A procédé de fabrication égale, ARM a un rapport consommation sur performance plus faible. Ce qui sauve Intel, ce sont les 500 ingénieurs qui optimisent Android pour que ce soit pas trop ridicule fasse a ARM, et leurs usines.
Apple voulait faire d'Intel un fondeur, car ils ont les meilleurs usines. ARM sont des gignoles a côté en terme de moyen, pourtant ils y arrivent aisément. On site le K1 de Nvidia, mais la conception de ce CPU a coûté une fraction de ce qu'Intel dépense pour concevoir un CPU.
[^] # Re: Manque l'essentiel
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 07 avril 2015 à 21:20.
Je ne comprend pas pourquoi la répétition de cet élément : on s'en fout de cet élément.
quand on regarde un CPU, on regarde la perf par rapport au coût, la consommation par rapport au coût etc… Suivant le besoin.
Le procédé de fabrication est un moyen, pas un résultat.
Parce qu'Android n'est pas optimisé pour ARM?
Bref, tu parles de théorie quand je parle de pratique : parle-moi de rentabilité, de ratio de performance par rapport au coût, de gain financier lié à consommation plus faible etc… Quel usage? Je vois l'usage pour les smartphone, mais la on ne parle pas de smartphones.
Pourquoi parler théorie plutôt que de regarder le résultat? Des théories, des gens on font tous les jours, mais ça reste de la théorie pour bon nombre de théorie, faute de réalité pratique.
[^] # Re: Manque l'essentiel
Posté par YBoy360 (site web personnel) . Évalué à 1.
En pratique un Snapdragon 801 explose tout ce que fait Intel en rapport prix performance, avec un procédé de fabrication moins performant.
[^] # Re: Manque l'essentiel
Posté par Zenitram (site web personnel) . Évalué à 4.
Pourquoi diable alors personne n'a eu l'idée de faire une offre de serveurs avec, surtout si ça "explose"?
Je pousse, oui je sais, mais c'est seulement parce que je cherche à virer le côté "marketing" et théorie, pour voir la réalité.
Je sais que ce CPU "déchire" beaucoup en mobilité, mais les règles sont différentes (le "coût" de l'énergie est bien plus élevé que dans un DC, on peut donc se permettre de mettre plus de fric dans l'achat du CPU)
[^] # Re: Manque l'essentiel
Posté par karteum59 . Évalué à 2.
Dans mon cas, c'était une promo temporaire à Noël chez HostUS trouvée grâce à Lowendbox.
[^] # Re: Manque l'essentiel
Posté par YBoy360 (site web personnel) . Évalué à 1.
Xgene2 un processeur armv8 dispose de l'ACPI et de l'UEFI. Mais éviter d'avoir un BIOS qui sert à rien sous linux, c'est pas un avantage? J'avais jamais entendu parlé du BIOS comme un argument de pérennité.. Si c'est ton seul argument à l'encontre d'ARM, ça me rassure.
De plus il y a coreboot qui supporte ARM.
[^] # Re: Manque l'essentiel
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
PC est une plateforme. Il existe un moyen standard d'avoir accès au clavier/souris, de booter et de détecter les périphériques.
Sur ARM, chacun fait comme il veut, c'est un peu comme si chaque fabricant de PC devait sortir un driver Linux par modèle de machine qui sort, et pas seulement un drivers par périphérique nouveau.
"La première sécurité est la liberté"
[^] # Re: Manque l'essentiel
Posté par Tangi Colin . Évalué à 1.
Les choses bougent dans se domaine, il y a de plus en plus de board arm qui sont compatible avec un seul kernel (via devicetree). Et y a plusieurs travaux en cours au niveau du développement du kernel. L'un est de rendre le decivetree dynamique (pour gérer les capes à la beaglebone) et un autre qui vise à unifier ACPI et devicetree (par la j'entends avoir une API commune niveau kernel qui dispose d'un backend ACPI pour X86 et devicetree pour ARM ou POWERPC).
http://events.linuxfoundation.org/sites/events/files/slides/unified_properties_API_0.pdf
Après contenant les critères qui feront décolle ARM sur le marché du serveur le prix est un facteur important oui mais l'écosystème n'est pas à négliger non plus. J'ai beau avoir une stack Java (que je peux donc faire tourner sur ARM facilement) j'ai sans doute autour des outils de monitoring, de log, d'agent de déploiement etc… qui ne sont pas forcément disponible sur ARM. Et on va pas demander à un admin sys de faire de la cross compilation.
# horizontal ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je ne vois pas du tout pourquoi dire ça ? Si encore le cpu avait plein de thread ou plein de core par rapport à la bande passante mémoire, je pourrais comprendre. Mais 4 cores, c'est rien de spécial.
"La première sécurité est la liberté"
[^] # Re: horizontal ?
Posté par YBoy360 (site web personnel) . Évalué à 3.
pour une même consommation électrique, on a plein de core pas trop puissant (avec plein de contrôleur mémoire indépendant, donc en absolue une bonne grosse bande passante). En cela, ça favorise plutôt la "scalability horizontal", avec peu de corrélation entre les traitements.
[^] # Re: horizontal ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Un truc horizontal avec peu de corrélations entre les traitements a un mauvais usage du cache. Les XEON ont des caches énormes pour gérer ses cas. L'hyperthreading permet de changer de tread pour virer les attentes, mais cela augmente encore les défauts de cache.
Pour pallier à ses problèmes, le moyen radical est de sacrifier du cache pour mettre un contrôleur mémoire plus large (cf la PS4 par rapport à la xbox).
Il y avait un sparc conçu de cette façon, "l'optimisation" consistait en l'usage d'une seul fpu pour 4 cores. On sacrifiait du silicum en virant 3 fpu pour mettre plus d'unité de calcul entier et plus de cores.
"La première sécurité est la liberté"
# Différence de puissance entre ARM64 et Intel Xeon
Posté par Sébastien Douche . Évalué à 0.
De ce que j'ai pu lire à droite et à gauche, la puissance des Xeon est bien supérieure aux ARM et POWER (IBM) quand on est entre 1 et 8 cœurs. C'est seulement après que ces derniers se rattrapent, ce qui de nos jours n'est pas le plus commun (normal on sort de plusieurs décennies de conception mono-cœur).
Bref, à court terme, et de ce que j'ai compris, ARM est surtout un avantage pour les hébergeurs, pas encore pour les développeurs.
[^] # Re: Différence de puissance entre ARM64 et Intel Xeon
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
On peut imaginer aussi des serveurs qui soit simplement une pile de die, composée d'un SoC, de 2 Go de DRAM et de 16 Go de mémoire flash et d'une connexion réseau. Ainsi l'ordinateur ferait 1 cm de coté tout compris, et consommerait 5W maximum. Tu peux ensuite mettre des centaines de se genre d'ordinateur sur la surface d'une carte mère 1U.
"La première sécurité est la liberté"
[^] # Re: Différence de puissance entre ARM64 et Intel Xeon
Posté par Poulpatine (site web personnel) . Évalué à 1.
On se retrouve alors dans une situation où le port du switch coûte plus cher que ce que l'on y branche. Ce n'est pas vraiment intéressant pour les hébergeurs :-/.
[^] # Re: Différence de puissance entre ARM64 et Intel Xeon
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je ne vois pas pourquoi le switch peut aussi être sur la carte mère. Cela serait logique pour connecter les machines à l'extérieur : 100 ports gigabits relié à un port externe giga ou 10 gigabits.
"La première sécurité est la liberté"
[^] # Re: Différence de puissance entre ARM64 et Intel Xeon
Posté par YBoy360 (site web personnel) . Évalué à 1.
il y a une photo du serveur que j'utilise, il y a plein de modules indépendants
https://www.scaleway.com/features
photo d'un module (en milieu de page
https://www.scaleway.com/
[^] # Re: Différence de puissance entre ARM64 et Intel Xeon
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 07 avril 2015 à 15:14.
?
Il suffit d'intégrer le switch, vu la tête de l'équipement je doute qu'il y a un port Ethernet par machine en sortie, à tous les coups l'hébergeur récupère un port 1 Gpbs (ou 10 Gpbs suivant le dimensionnement cible, et le nombre de module ARM par grappe, sur la photo il y a 18 module allez je parie pour le fun sur un port 1 Gpbs pas cher en visant le fait que les gens ne débittent pas beaucoup par module) par grappe de serveurs et donc pas de switch (de premier niveau) en plus à acheter.
[^] # Re: Différence de puissance entre ARM64 et Intel Xeon
Posté par X345 . Évalué à 3.
Oui, d'ailleurs, c'est exactement ce que Online a fait : https://www.scaleway.com/features. Ils sont pas a des centaines, mais l'idée est la.
Par contre, la dernière fois que j'avais testé, le stockage était accédé via la réseau, chaque SoC n'a donc pas son stockage dédié.
[^] # Re: Différence de puissance entre ARM64 et Intel Xeon
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Un SSD serait plus gros que l'ordinateur, mais un peu de flash rapide, c'est possible. Sans stockage du tout, c'est mettre une pression dingue sur le réseau.
"La première sécurité est la liberté"
[^] # Re: Différence de puissance entre ARM64 et Intel Xeon
Posté par X345 . Évalué à 3.
Apparemment, c'est ce que online a fait. Quand j'avais testé (pendant la phase bêta), le stockage était accédé via un network block device. La latence était d'environ 1 ms et le débit de 50 Mo/s.
Je suis d'accord avec ta remarqué sur la pression réseau. D'ailleurs ceux qui se souviennent des RPS de chez OVH et deux leur stockage iSCSI le savent bien. À voir donc si la performance de la plateforme se dégrade avec beaucoup d'utilisateurs.
Autre hypothèse, je crois que les SoC Marvell Armada disposent de deux interfaces ethernet chacun, peut-être qu'ils on un lien réseau dédié stockage.
[^] # Re: Différence de puissance entre ARM64 et Intel Xeon
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Cela reste très lent, comparé, à quelque puces flash locales.
Le ratio perf/whatt n'est pas si en désavantages de Intel, vu le niveau de perf des puces à 100w.
"La première sécurité est la liberté"
[^] # Re: Différence de puissance entre ARM64 et Intel Xeon
Posté par X345 . Évalué à 3.
Complètement d'accord avec ça. En prenant tout en compte (mémoire, stockage, alimentation, réseau etc.), je suis pas du tout convaincu que de l'ARM soit plus efficace énergétiquement que du Intel.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.