Articles précédents : Articles
- [10] Linux-mag US : Journaling File Systems
- [15] Rétrospective 2002 des logiciels Libres
- [103] Radio France cherche du monde pour faire un passage sous Linux
- [18] Derivative Works
- [2] Longue intro à PostgreSQL
- [34] Trucs et astuces pour la Mandrake 9
- [19] Accès publics gratuits à des machines sous Linux
- [25] Jon Johansen acquitté dans le cas DeCSS
- [6] Les robots de papier
- [14] Lettre ouverte sur la copie privée
Liens connexes
- La page SGI (858 hits)
- Descriptions (524 hits)
- Article ZDNet (569 hits)
- Le Monde Informatique (901 hits)
- Réseaux & Télécoms (404 hits)
Dépêche modérée par
Articles : Nouveau server SGI : Altix 3000 sous Linux
Posté par gege (page perso, ). Modéré le 09 janvier 2003.
Les upgrade processeurs se font par briques de 4 procs...
Le tout fonctionne avec un linux 64bit, of course.
... raaahhh j'en veux un !
Note du modérateur : merci aussi à 'tuiu pol' et Mathieu Malaterre pour les liens supplémentaires
![[en]](../../../images/en.png)
La page SGI (858 hits)-
Descriptions (524 hits)
![[fr]](../../../images/fr.png)
Article ZDNet (569 hits)-
Le Monde Informatique (901 hits)
-
Réseaux & Télécoms (404 hits)
> Lire les commentaires (13 commentaires, moyenne: 2,8).
Kernel patché ?
D'après NewsForge, ils utilisent un noyo patché maison ...
http://newsforge.com/newsforge/03/01/07/1712243.shtml?tid=23(...)
... car le kernel Linux ne supporte pas de SMP a plus de 8 procs.
Vraiment ? Auquel cas, ce patch risque d'interesser beaucoup de monde. Gageons qu'il soit rendu public.
-
[^]Re: Kernel patché ?
-
[^]Re: Kernel patché ?
Posté par Strass (page perso, ) le 10/01/2003 à 09:58. (lien). Évalué à 1.Oui enfin comme dit ici http://www.linuxplanet.com/linuxplanet/reports/4619/1/(...)
C'est Nec qui a été la première boîte a dépassé la limite de 8 proc en SMP dans une machine commercialisée.
"The technology that SGI used, he said, was a direct result of work done by NEC and other companies through OSDL and the Atlas Project, which is now a part of the Linux on Large Systems (LoLS) Foundry."
-
[^]Re: Kernel patché ?
Posté par Nicolas Boulay () le 10/01/2003 à 16:17. (lien). Évalué à 0.Je crois que la limite était 32 ou 64 (nombre de bit dans un mot). En pratique, les perf de linux sur quadri/octo sont assez pourris parait-il.
-
[^]Re: Kernel patché ?
Posté par Olivier Jeannet () le 10/01/2003 à 18:41. (lien). Évalué à 1.En pratique, les perf de linux sur quadri/octo sont assez pourris parait-il.
De ce que j'ai compris, le noyau 2.2 gérait correctement 2 processeurs, mais beaucoup moins bien à partir de 4, étant donné la granularité grossière des verrous (le big kernel lock), quasiment un seul processus seulement pouvant être dans le noyau à la fois.
Avec le noyau 2.4 est arrivée une granularité beaucoup plus fine et je crois que le big kernel lock n'est presque plus utilisé. La granularité plus fine permet aussi de faciliter le développement de patch "low-latency" ou "preempt". Je ne sais pas jusqu'à combien de processeurs le noyau 2.4 est censé être performant.
Le noyau 2.5/2.6 a quant à lui été retravaillé pour une meilleure granularité pour les entrées/sorties. Ca concernera surtout les serveurs qui seront chargés en E/S, sans doute pas beaucoup nous sur nos machines de bureau.-
[^]Re: Kernel patché ?
Posté par matiasf () le 10/01/2003 à 21:22. (lien). Évalué à 0.Si j'ai bon souvenir, le 2.0 était déjà SMP. C'est le 2.2 qui a viré le "big lock" dans le kernel et qu'il avait déjà de bonne performance SMP (surtout par rapport au 2.0).
> Je ne sais pas jusqu'à combien de processeurs le noyau 2.4 est censé être performant.
Pour des programmes "simples" (sans accès disques etc...) comme les clients distributed.net il n'y a pas de problème. C'est dont très dépendant des applications.
> Le noyau 2.5/2.6 a quant à lui été retravaillé pour une meilleure granularité pour les entrées/sorties.
Ouais mais les développeurs ont calmé le jeux en estimant que les performances gagnées ne justifiaient pas la complexité ajoutée pour les développeurs.
-
-
un peu cher quand même
Prix du ticket dentrée : plus de 70 000 $ pour lAltix 3300 quadri-processeur avec 32 Go de mémoire vive. LAltix 3700 est commercialisé à partir de plus de 1 M$ dans sa version 64 processeurs.
Mais mon anniversaire est pour bientôt, merci de vous cotiser. Je me contenterai de la version quadri-cpu (-:
The only thing necessary for the triumph of evil is for good men to do nothing.
Re: Nouveau server SGI : Altix 3000 sous Linux
Côté matériel, ça laisse rêveur : cluster sur bus spécific hyper rapide
je veux pas faire le puriste, mais il y a pas de "bus" ici. la machine est cc::numa (le temps pour acceder à une adresse mémoire dépend de la position physique de celle-ci est n'est pas uniforme, les caches sont coherents.
En plus elle est présentée comme un cluster alors que c'est vraiment un gros serveur non SMP.
-
[^]Re: Nouveau server SGI : Altix 3000 sous Linux
Posté par gege (page perso, ) le 10/01/2003 à 12:16. (lien). Évalué à 2.bon, c'est sûr, ça n'est pas un bus...
Par contre chaque serveur est SMP (jusqu'à 64 procs), et ils sont prêts à être intégrés dans un cluster numa (jusqu'à 8 machines de 64 procs donc 512 procs). La spécificité de numa étant que toute la mémoire de chaque cluster est accessible directement aux autres cluster.
D'où les temps d'accès mémoire différents (accès à sa RAM locale très rapide, accès à une RAM sur un cluster distant plus long).
Donc c'est un gros serveur SMP pouvant être mit en cluster (et c'en est un point essentiel).-
[^]Re: Nouveau server SGI : Altix 3000 sous Linux
Posté par Paul Andre () le 10/01/2003 à 13:27. (lien). Évalué à 2.Par contre chaque serveur est SMP (jusqu'à 64 procs),
Ben justement, non.
Chaque serveur est composé de carte de CPU (C-Brick) de 4 Itanium2 et de slots mémoire. Les composants dans ces cartes sont reliés par un Bus (archi SMP)
Ensuite ces cartes sont reliées entre elles par un routeur NumaLink 4 (il me semble, et la on passe en cc:numa) jusqu'a avoir au maxi 64 CPU connectés.
Si on en veux plus, on relie tous ca avec un routeur NumaLink 3 (deux fois moins rapide) jusqu'a la limite de 512 CPU.
Ce machin, est "strictement SMP" uniquement si t'a une seule C-Brick peuplée de 4 CPU et pas de M-Brick (carte mémoire connecté via le routeur). si t'as plus que ca, c'est du cc:numa.
j'ai pas trop le temps de verifier, mais il me semble que ca doit etre a peu pres ca ...-
[^]Re: Nouveau server SGI : Altix 3000 sous Linux
Posté par gege (page perso, ) le 10/01/2003 à 15:02. (lien). Évalué à 1.Non plus...
modèle Altix 3300
NumaLink 4: débit de 6.4GB/s bidirectionnel. Utilisé sur le modèle 3300 en topologie mono-plan, anneau.
modèle Altix 3700
NumaLink 3: débit de "seulement" 3.2GB/s bidirectionnel, mais utilisé en topologie bi-plan, "fat tree".-
[^]Re: Nouveau server SGI : Altix 3000 sous Linux
Posté par Nicolas Boulay () le 10/01/2003 à 16:20. (lien). Évalué à 2.bah si, tu site seulement les topology de connexion des routeurs cela colle avec ce qui est dis plus haut.
-
-
-
[^]Re: Nouveau server SGI : Altix 3000 sous Linux
Posté par Serge Rossi (page perso, ) le 11/01/2003 à 14:45. (lien). Évalué à 1.Etant donné l'architecture, ils pourraient très bien faire un "single image" Linux de 512 CPU si le noyau Linux dans sa version actuelle le supportait. Ils le font avec les Origin 3000 MIPS/Irix :
http://www.sgi.com/origin/3000/overview.html(...)
"With our unique SGI NUMAflex memory, you can combine up to 512 CPUs and 1TB of memory in a shared-memory image"
Dans la version actuelle de Linux, ils n'utilisent le bus mémoire global que comme un canal de communication ultra rapide et à faible latence entre les différents noeuds du cluster.
Parions qu'avec les versions futures du noyau, plus de CPU seront supportés par machine. Maintenant, le hardware est là !
-
Cette page a été générée par Templeet en 0.1879s (dont 0.0965 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.