En effet, SGI construit un super-ordinateur de 1024 Itanium 2 avec 3 To de mémoire partagée pour le NCSA (National Center for Supercomputing Applications) qui sera exploité par Linux.
Dans un premier temps il y aura 2 noyaux gérant chacun 512 CPU puis rapidement 1 seul noyau pour gérer les 1024 CPU.
Toutes les améliorations apportées au noyau 2.6 concernant le support des architectures NUMA et multi-processeurs dépassent finalement toutes les espérances et sont adoptées très rapidement par les constructeurs.
Il se pourrait que la virtualisation, le futur chantier planifié pour le noyau 2.8, fasse son apparition bien plus vite que prévu. Le Kernel Summit, le Congrès des développeurs du noyau, qui commence demain devrait nous apporter des réponses et planifier les axes de développement pour l'année à venir...
Aller plus loin
- La news originale (8 clics)
- Naissance d'un mammouth (30 clics)
- Kernel Summit (4 clics)
- NUMA (6 clics)
- Communiqué de presse SGI : "NCSA to Expand its High-Performance Computing Environment" (6 clics)
# Petite question
Posté par xahlexx . Évalué à 2.
[^] # Re: Petite question
Posté par phenix (site web personnel) . Évalué à 5.
Ont t'il un fabriquant qui leur donne accés a une telle machine pour faire leur developement ?
[^] # Re: Petite question
Posté par Jean-Max Reymond (site web personnel) . Évalué à 9.
Maintenant, cas classique, le hardware est toujours en retard ;-) alors tu valides ton code sur une machine qui a beaucoup moins de processeurs, de mémoire et quand le proto devient un petit peu opérationnel, tu testes (et debogues !!!) ton code et aussi le proto !!!
[^] # Re: Petite question
Posté par 007 . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Pas toujours
Posté par o°Oo°Oo°o°O°Oo°Oo°Oo°Oo°o°O°O o° . Évalué à 4.
Côté fonctionnalité, c'est impressionnant de changer une carte alors que le serveur tourne encore, juste en précisant avant au système qu'il faut arrêter de l'alimenter. Tout le reste du système tourne encore, donc il n'est plus nécessaire de procéder à un redémarrage en pleine période d'exploitation pour changer une carte réseau d'un teaming ou autre ! :-)
Pour info, les serveurs Compaq sont remarquablement bien faits côté hot-plug et redondance (ventilos, alims, processeurs, banques mémoires, etc.)
[^] # Re: Petite question
Posté par Guillaume Knispel . Évalué à 2.
Apres y a surrement quelques subtilités à regler, mais j'imagine que l'essentiel est fait très tot.
[^] # Re: Petite question
Posté par Guillaume POIRIER . Évalué à 6.
En effet, le code fonctionne, mais les problèmes d'échelles font qu'il est nécessaire de repenser certains mécanismes, améliorer la granularité, etc... et tout cela demande beaucoup, beaucoup de temps, et des gens très brillants pour trouver des solutions élégantes à ces problèmes de changement d'échelle.
C'est ce qui fait que Solaris se vend encore très bien dans les domaines de serveur de multi-processeur pour applications de types transactionnelles (SGDB typiquement) (cf. http://www.sun.com/servers/highend/(...) )
... enfin, en voyant cette news, je me demande combien de temps tiendront encore les gros Unix... il ne leur restera pour se démarquer les uns des autres d'axer leur offre sur le hard super fiable (et encore!)
[^] # Re: Petite question
Posté par mdlh . Évalué à 2.
L'une des subtilites est de gerer des informations sur des champs de bits. Forcement a 2 bits par processeurs sur un mot de 32 bits, 1024 processeurs, ca tient pas.
Les developeurs de SGI ont ecrit un patch pour lever cette limite.
[^] # Re: Petite question
Posté par Matthieu Moy (site web personnel) . Évalué à 10.
Ouais, quelques subtilités, comme tu dis ;-)
Pour des applications fesant du calcul pur, effectivement, la question est relativement facile à régler au niveau de l'OS. C'est au niveau applicatif qu'il faut paralléliser les algos.
Maintenant, si tu prends une application comme un gros SGBD, ou quelque chose qui utilise beaucoup d'appels systèmes, tu passes facilement 20% du temps dans les couches noyau. Maintenant, tu imagines bien que si deux processeurs executent en parallèle deux bouts de code qui touchent au mêmes données, ou au même périphérique, tu as 99% de chances d'avoir un truc déconnant. Il faut donc placer des verrou pour assurer l'exclusion mutuelle de certaines portions de code dans le noyau. L'approche la plus simple (c'est en gros comme ça que ça se passait dans les premiers Linux SMP), c'est de mettre un gros verrou sur l'ensemble du noyau, ce qui fait que deux processeurs ne peuvent pas executer du code en mode noyau en même temps. Ca marche assez bien sur 2 processeurs, parce que pendant qu'un processeur execute du code dans le noyau, l'autre processeur a en général un processus à executer. Mais évidement, si tu passes 20% du temps dans le noyau, et que tu as plus de 5 processeurs, alors tu as toujours plusieurs processeurs qui n'ont rien à faire. C'est (entre autres) pour ça qu'un Linux 2.2 a du mal sur une machine quadri-proc, et n'arrive vraiment pas à utiliser correctement 8 procs.
Pour utiliser correctement un grand nombre de processeurs, il faut donc que les verroux d'exclusion mutuelle dans le noyau soient le plus fins possibles. Qu'un processeur puisse écrire sur un disque dur pendant qu'un autre écrit sur un autre disque par exemple. Il y a déjà eu beaucoup de progrès dans ce domaine depuis Linux 2.2, mais avant d'exploiter correctement 1024 processeurs, il y a encore du boulot !
Ce n'est bien sur pas le seul problème. Par exemple, quand le noyau doit choisir entre 5 ou 10 processus éligibles (ce qui correspond déjà à une machine très chargée pour un mono ou bi-processeur), tu t'en fout pas mal que l'algo de scheduling soit en O(n), O(log(n)) ou en O(1). Sur une machine 1024 procs, tu as au moins 1024 taches éligibles à chaque instant quand ta machine est chargée, et la, la finesse des algos fait la différence.
Bref, avoir un systeme qui tourne sur 1024 procs, c'est assez facile, mais avoir un des perfs acceptables sur un tel système (avoir un système qui n'est pas trop loin d'être 1024 fois plus rapide qu'un système mono-processeur), c'est une autre paire de manches !
[^] # Re: Petite question
Posté par capicapio . Évalué à 1.
# Scheduling domains
Posté par 007 . Évalué à 10.
Le 2.6.6 (ou 7?) a introduit "scheduling domains" dont il y a ici une excellente présentation :
http://lwn.net/Articles/80911/(...)
La difficulté n'est pas d'avoir plein de CPU mais de les faires travailler en même temps.
[^] # Re: Scheduling domains
Posté par phenix (site web personnel) . Évalué à 2.
Donc pour les faire travailler en même temps, je pense qu'il faut qu'il y est autant de procesus ouvert que de CPU.
Peut etre que je me trompe, je pense que c'est pour ca que la commande "ps aux " donne par exemple apache ouvert plusieurs fois
[^] # Re: Scheduling domains
Posté par 007 . Évalué à 2.
Ou thread (du moins avec NPTL, linuxthread fesait des équivalents de fork()).
[^] # Re: Scheduling domains
Posté par Florian Fainelli . Évalué à 6.
[^] # Re: Scheduling domains
Posté par 007 . Évalué à 2.
Apache 2 mixe les threads et les processus. Du moins lorsqu'il est compilé avec les bonnes options.
Puis le mode "processus" ne manque pas d'intérêt (typiquement lorqu'un module plante).
btw : apache augmente le nombre de processus/thread en fonction de la demande. C'est configurable via httpd.conf.
[^] # Re: Scheduling domains
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
[^] # Re: Scheduling domains
Posté par ham . Évalué à 1.
memoire, threads, processus, etc...
Les caches memoire sant dans la ligne des pools:
tu rapatrie plus que necessaire, en te basant sur le fait que tu as de forte probabilite d'en avoir besoin.
[^] # Re: Scheduling domains
Posté par 007 . Évalué à -2.
Ooops. Je viens de comprendre (rapport au début du thread).
Quoiqu'il en soit une connexion est faite avec ip:port:processus (si mes souvenirs sont bons car c'est vieux). Donc par moment que les thread (même pid) ça peut être insuffisant (rien à voir avec le nombre de processeurs).
[^] # Re: Scheduling domains
Posté par David . Évalué à 2.
[^] # Re: Scheduling domains
Posté par KiKouN . Évalué à 1.
[^] # Re: Scheduling domains
Posté par capicapio . Évalué à 1.
Ou alors il faudra qu'on m'explique comment il peut y avoir plus de processus qui tournent que de processeurs à un instant T.
[^] # Re: Scheduling domains
Posté par briaeros007 . Évalué à 1.
en utilisant des processeurs vectoriel et faires des calculs lineaires avec une surcouche?
pas la peine de m'indiquer la sortie ---> [-]
# virtualisation
Posté par Calvin0c7 . Évalué à 5.
Encore que.
Quand j'y pense, une entreprise ayant des besoins en environnement de travail possède déjà les machines ad hoc (et donc les progs qui viennent avec + compétences etc...).
Alors quel marché pour de telle machines ?
Quelle complexité d'administration ? quel seront les outils qui viendront avec ?
[^] # Re: virtualisation
Posté par Christophe Merlet (site web personnel) . Évalué à 10.
http://www.solucorp.qc.ca/miscprj/s_context.hc(...)
http://www.linux-vserver.org/(...)
Cette solution de virtualisation surpasse tous ce qui se fait par ailleurs. Elle est super facile à administrer et nul doute que meme les serveurs de base l'utiliseront.
Il suffit d'assister à une présentation de vserver pour être définitivement convaincu de l'utilité du concept.
Il y a plein de serveurs en prod qui utilise déjà cette technologie dont...... linuxfr !
[^] # Re: virtualisation
Posté par Ludovic . Évalué à 10.
De plus, le gain de sécurité est impressionant. Un apache qui se fait avoir, seul le vserver pourra être rootkiter.
En plus, j'ai des potes qui se connecte à ma machine (IRC and co), bah genre, en cas de quelconque problème, seul ce vserver pourra se être utilisé. L'intégrité de la machine est toujours préservé.
En plus, dans le cadre de développement de logiciel (libre de préférence ;) ), on peut avoir des machines dans différentes versions. Exemple avec Debian : on peut avoir une machine hôte stable, et avoir une station de développement unstable. On a accès à la dernière version de toutes les librairies et on ne risque pas de mettre en péril l'intégrité de la machine hôte.
Bref, le pied ;)
++
Ludo
[^] # Re: virtualisation
Posté par Ludovic . Évalué à 4.
Ceci étant dit, dans le cadre du recyclage, il est évident que tu choisiras la solution la plus adaptée à ton problème.
Or, lorsque tu regardes à l'heure actuelle les évolutions, tu te rends compte, que certes le mainframe présente des avantages en termes d'administration. Mais dès lors que tu veux des performances supérieurs et [surtout] de l'évolutivité pour ton matériel/ton OS, la virtualisation est pour toi une/LA solution. Il faut évidemment une structure adaptée à ce changement (la machine citée dans l'article est d'ailleurs l'ancêtre de ces solutions).
Je crois que la virtualisation pourra et sera adoptée par les entreprises, dans le but de gagner en performance et en évolutivité.
Ceci étant dit, le principal problème que tu as cité sera bien évidemment, de faire comprendre aux entreprises, lors du renouvellement, que c'est ce genre de machine (enfin, peut-être pas non plus, celle là, car là c'est du spécifique), qui sera l'avenir.
Enfin bon, c'est mon avis.
[^] # Re: virtualisation
Posté par Calvin0c7 . Évalué à 8.
Il me semble que ce n'est pas tout à fait la même chose. Dessous, c'est toujours le même kernel qui tourne, avec le même espace mémoire etc...
Mais est ce qu'on peut avoir 2 kernels qui tournent en même temps (et de version différentes) comme cela est permis sur mainframe ? Est ce qu'on peut arrêter (rebooter) un des environnements sans toucher à l'autre ?
Sinon, à mon sens ce qu'il manque encore à linux (valable pour tout les unix à mon sens) c'est encore la stabilité. En 6 ans de boulot sur mainframe, j'ai du connaitre 3 ipl (redémarrage) et à chaque fois pour une monté en version de certaines parties de l'OS. Tout le reste est upgradé à chaud, en arrêtant seulement la partie concernée. Et puis il y a le pb des compétences. Quand tu as une armée de dev, d 'ingé système et pupitreur formé au mainframe, pas facile de prendre un virage technologique trop brusque pour une entreprise.
Ca marche, ça a couté cher et on connait bien. Quel décideur prendrai le risque de tout foutre en l'air ? Pour mémoire, les superdôme n'ont pas fait un malheur vu leur prix (3 Millions d'euro la bêbete, je parle pour des systèmes de puissance équivalente à un gros mainframe).
[^] # Re: virtualisation
Posté par rarcel . Évalué à 3.
[^] # Re: virtualisation
Posté par Christophe Lucas (site web personnel) . Évalué à 5.
--
Christophe
[^] # Re: virtualisation
Posté par mdlh . Évalué à 3.
Il y a plusieurs niveaux de privilege mais l'espace d'adressage est bien le meme.
[^] # Re: virtualisation
Posté par Christophe Lucas (site web personnel) . Évalué à 1.
Mais sinon en effet, mais nous n'avions pas trop spécifié de quoi nous parlions :-)
--
Christophe
[^] # Re: virtualisation
Posté par ckyl . Évalué à 2.
Genre sur un noyau fedora tu as 4:4 d'activé (oui c'est tres con)
[root@loutre]~# cat /proc/self/maps ~
002c7000-002dc000 r-xp 00000000 fd:00 1441971 /lib/ld-2.3.3.so
002dc000-002dd000 r--p 00014000 fd:00 1441971 /lib/ld-2.3.3.so
002dd000-002de000 rw-p 00015000 fd:00 1441971 /lib/ld-2.3.3.so
002e0000-003f5000 r-xp 00000000 fd:00 1441973 /lib/tls/libc-2.3.3.so
003f5000-003f7000 r--p 00115000 fd:00 1441973 /lib/tls/libc-2.3.3.so
003f7000-003f9000 rw-p 00117000 fd:00 1441973 /lib/tls/libc-2.3.3.so
003f9000-003fb000 rw-p 003f9000 00:00 0
0079f000-007a0000 r-xp 0079f000 00:00 0
08048000-0804c000 r-xp 00000000 fd:00 950317 /bin/cat
0804c000-0804d000 rw-p 00003000 fd:00 950317 /bin/cat
08f34000-08f55000 rw-p 08f34000 00:00 0
f6e42000-f6e7f000 r--p 00aa5000 fd:00 200223 /usr/lib/locale/locale-archive
f6e7f000-f707f000 r--p 00000000 fd:00 200223 /usr/lib/locale/locale-archive
f707f000-f7080000 rw-p f707f000 00:00 0
fef77000-ff000000 rw-p fef77000 00:00 0
ffffd000-ffffe000 ---p 00000000 00:00 0
Tu peux aussi couper de pas mal d'autres manières et sur les archis 64 bits ca serait tres con de limiter l'espace d'adressage d'un processus a 3Go...
http://fxr.watson.org/fxr/source/include/asm-alpha/page.h?v=linux-2(...) 82 ou par exemple
[^] # Re: virtualisation
Posté par Christophe Lucas (site web personnel) . Évalué à 1.
Pour ceux que cela intéresse :
http://kerneltrap.org/node/view/2450?PHPSESSID=64f7f951d3e846fc9388(...)
Bonne journée.
--
Christophe
[^] # Re: virtualisation
Posté par Christophe Lucas (site web personnel) . Évalué à 1.
--
Christophe
[^] # Re: virtualisation
Posté par Ludovic . Évalué à 2.
J'en ai, mais bon, c'est de la triche, y'a pas souvent d'upgrade, mais, j'en ai avec plus de 2 ans d'uptime. Bref, mo'j'dis, honorable.
Bref, tout ça pour dire, que les seuls reboot qui sont effectués sont pour des changement de version. Dans le cas présents, je te parle d'OS genre : Digital UNIX, Sun et Linux (entre autres, ...).
Non, vraiment, je ne comprends pas ce que tu reproches en matière de stabilité aux machines UNIX.
[^] # Re: virtualisation
Posté par Calvin0c7 . Évalué à 3.
Je te crois tout à fait quand tu me parle d'uptime de 2 ans. Mais ça c'est un peu l'exception. J'ai travaillé sur des 10-proc sous HP-UX (des espèce de grosse machine à laver) et ça arrivait tout les 6 mois que la machine plante. Mais bon, faut voir l'utilisation qui en était faite. Cette machine servait de serveur de tests pour une multitudes d'appli en dev, de test avec des 10aines d'utilisateurs etc... 6 Mois d'uptime dans ces conditions c'est tout à fait honorable. Et sur une machine peu sollicité (tout est relatif, peu utilisé pour un serveur unix j'entend), 2 ans c'est tout à fait plausible et même plus. Mais sur mainframe, tu as un environnement de dev, d'integ et de prod (ou plus) sur une seule CPU (voire 2) avec des milliers d'utilisateurs 24h/24h (il ya l'exploitation la nuit qui mouline), et un uptime de 2 ans n'a rien, mais alors rien du tout d'exceptionnel.
Alors si la disponibilité d'un serveur unix est de 99%, celle d'un mainframe est 99.99% (dans mes souvenirs, IBM garantissait moins de 2 heures d'indisponiblité par an sur ses machines).
[^] # Re: virtualisation
Posté par 007 . Évalué à 3.
Le type d'utilisation est très important. Le hard aussi :-)
J'ai utilisé du Digital Unix avec 8 proc et la fiabilité était impressionnante alors que l'utilisation était "massive" (développeurs/utilisateurs/serveurs).
Dernier uptime connu (avant de quitter la boite) : 450 jours. Plusieur disques dures ont été changés durant cette période (merci raid5).
upload en journée était de 6 à 15 !
Un serveur Web qui tient 2 ans n'est vraiment pas impressionnant pour moi maintenant. Et c'est souvent le signe d'une machine peu entretenue (genre mise à jour noyau non appliquée).
[^] # Re: virtualisation
Posté par GP Le (site web personnel) . Évalué à 10.
Donc, y'a encore un peu de temps avant qu'un simple noyau concurrence une machine completement pense pour faire ca.
Pour info, la virtualisation interesse directement IBM, car les regatta sont livrable en AIX ou en Linux. Sauf que sous Linux, tu peux pas attribuer les elements a chaud...
[^] # Re: virtualisation
Posté par Temsa (site web personnel) . Évalué à 1.
ça permet de faire tourner plusieurs serveurs dans des sortes d'environnements chrooté (mais en mieu je suppose)c'est ça?
est-ce qu'on peux faire tourner 2 noyaux en même temps (avec usemod linux en plus peut-être ?)
Si oui, est-ce possible de changer un noyau a chaud (on lance un noyau, on en compile plus tard un autre, on le démarre et on coupe l'ancien...)? Ca permettrais de faire des jolis uptime :)
[^] # Re: virtualisation
Posté par Florian Fainelli . Évalué à 2.
Le but est sécuritaire, mais pas uniquement. On peut par exemple créer un jail pour apache, puis le chrooter dans sa prison. Ainsi il n'est pas possible d'attaquer l'OS lui même.
Linux ne possède pas d'équivalent aussi souple / flexible et facile à manipuler de jail qui n'existe que sur les BSD.
[^] # Re: virtualisation
Posté par ckyl . Évalué à 10.
chroot : changement de la racine pour un processus (et donc tout ses fils). Ca ne fait rien d'autre. Avantage en sécurité si le chroot est bien pensé et avec un noyau prévu pour (grsec au hasard pour linux).
jail : concept de chroot plus poussé. la on ne touche plus uniquement au FS mais aussi aussi au pas mal de structures du noyau. Notament avec des restriction au niveau du reseau, process etc. Ainsi autant un processus dans un chroot peu faire n'importe quoi du point de vue syscall, FreeBSDverifie non pas l'uid 0 mais l'uid 0 et si le process est dans une jail. Avantage : sécurité, et souplesse d'administration (on peut laisser une jail a un client qui a un root sur la machine). Inconveniant : ce n'est pas de la virtualisation, le DoS est tres facile etc.
user mode linux: permet de faire tourner un linux dans un linux dans un linux. En gros ceci permet a un noyau d'utiliser comme architecture non pas le hardware mais un noyau. Tres couteux en performance et utile uniquement pour le debug. Ca n'apporte rien dans la virtualisation ou tres peu pratique. Aucun controle, impossibilite de toucher au noyau qui s'addresse au materiel. Bref ce n'est pas sont but.
vserver : je connais mal, mais le principe est dans l'idee des jails. Un seul noyau, que plusieurs sous environements utilisent. Par contre le controle des ressources a l'air d'etre plus abouti (inexistant avec les jails actuelles) avec notament des limites sur les processus, la memoire, le disque, le temps CPU. Reste a voir si c'est correctement implémenté on a souvent des surprises :-)
On reste bien loin des UNIX proprio avec toutes ces solutions. Mais c'est un axe de developpement interessant. D'ailleur FreeBSD a toujours la network stack virtualization de marco Zec dans les cartons qui ne demande qu'a etre developpe :-)
Note : Ainsi il n'est pas possible d'attaquer l'OS lui même.
Tout ne repose que sur un seul noyau (comme toutes les solutions presentés ici) donc une faille dans le noyau compromet la machine en entier. Vu le nombre de faille locale trouvées et trouvables... De plus les jails ne sont pas faciles a manipuler il s'agit d'ailleur d'un axe de developpement et de reecriture. Dans l'etat actuel des choses c'est trop ou trop peu. Avec une meilleure integration de MAC la dedans on pourrait faire de jolies choses amha.
[^] # Re: virtualisation
Posté par Antoine J. . Évalué à 1.
[^] # Re: virtualisation
Posté par gebura . Évalué à 1.
Ca kexec permet de le faire, ou du moins de s en approcher, par contre pour ton uptime...
- article d ibm developerWorks: http://www-106.ibm.com/developerworks/linux/library/l-kexec.html(...)
- depeche (assez recente) sur linuxfr: http://linuxfr.org/2004/05/18/16263.html(...)
voila voila...
[^] # Re: virtualisation
Posté par ckyl . Évalué à 4.
Dans un article sur DTrace les mecs de SUN parlent de 2h pour booter un SunFire 15k y'aurait un gain appreciable.
[^] # Re: virtualisation
Posté par gebura . Évalué à 5.
pour ca que j avais dit "ou de s en approcher"
>> Tout l'executif lui est perdu
je n ai pas testé kexec, je donais juste ces liens a titre informatifs,en d autre termes j essayais juste de donner des pistes pour un truc que je connais a peine donc fallait s attendre a quelques coquilles :) Peut etre qu une utilisation couplé au suspend to RAM permettrait conserver cet executif, theoriquement ca a l air fesable (avec peut etre quelques bidouilles), apres je peux pas t en dir plus...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
# Documentations ?
Posté par xahlexx . Évalué à 3.
# Oui bon....
Posté par Vincent (site web personnel) . Évalué à 6.
[^] # Re: Oui bon....
Posté par Olivier Serve (site web personnel) . Évalué à -2.
Quoique, non, c'est SGI donc C pas du nVidia
Lynchez-moi lynchez-moi lynchez-moi ....
[^] # Re: Oui bon....
Posté par Bobyl . Évalué à 1.
Vous m'arrêtez si je me trompe mais il me semblait qu'aux premières heures, SGI et nVidia avaient travaillé ensemble sur les drivers Linux (à l'époque des GeForce). Il me semble que c'était parce que SGI voulait utiliser des GeForce à la place de leurs cartes (plus chères et finalement aussi puissantes).
Mais bon, je dis ptet une ânerie là...
[^] # Re: Oui bon....
Posté par let antibarbie = xp <- xp - 1 . Évalué à 2.
# 2 noyaux !?
Posté par Pinaraf . Évalué à 2.
[^] # Re: 2 noyaux !?
Posté par Dalton joe . Évalué à 4.
[^] # Re: 2 noyaux !?
Posté par Ben A. . Évalué à 1.
En gros, tu peux jouer au lego virtuel et créer plusieurs machines plus petites qui seront vues comme des machines autonomes (meme si, physiquement, elles sont dans le meme boitier)
Par exemple, les grosses SUN (style E6500 & co) font ca depuis des temps immemoriaux.
Evidemment, l'archi hardware est developpé spécifiquement pour ca.
[^] # Re: 2 noyaux !?
Posté par Jérôme F. . Évalué à 1.
Ce qui existe effectivement sur les gros Sun (E10k, SF15k et petits frères), mais aussi HP (Superdome), Alpha (Galaxy), IBM (p690 Regatta et p670), IBM zSeries (virtualisation matérielle et logicielle), etc.
Tu peux même le faire sur ton PC (virtualisation logicielle) avec VMWare ou les Vserver (http://www.linux-vserver.org/(...)).
Et mon petit doigt me dit que ça va arriver en matériel sur les serveurs PC d'ici peu de temps.
# ça tombe bien
Posté par titititi . Évalué à 0.
[^] # Re: ça tombe bien
Posté par earxtacy . Évalué à 4.
# Plus d'infos sur Altix
Posté par Christophe Merlet (site web personnel) . Évalué à 8.
Entre autres elle aura une capacité de stockage de masse de 370 To.
Ce monstre devrait servir à faire des simulations sur l'évolution de l'univers. Moi qui pensais naïvement que tout le monde connaissait déjà la réponse...
[^] # Re: Plus d'infos sur Altix
Posté par Gart Algar . Évalué à 4.
[^] # Re: Plus d'infos sur Altix
Posté par Simon Huet . Évalué à 2.
# et le cpu MIPS ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: et le cpu MIPS ?
Posté par mdlh . Évalué à 2.
Apres il me semble qu'effectivement que l'Itanium se debrouille assez bien dans un environment multi-proc.
[^] # Re: et le cpu MIPS ?
Posté par gallenza . Évalué à 3.
Le meilleur MIPS est actuellement 4 fois moins performant que le meilleur Itanium, et toute la statégie de SGI, qui est en situation financière relativement difficile et n'a pas les moyens de supporter les frais astronomique de R&D pour un CPU performant, est de lentement mais sûrement switcher sa gamme des MIPS aux Itanium....et de Irix à Linux !!!
# CPU dans les Mainframes
Posté par gallenza . Évalué à 0.
[^] # Re: CPU dans les Mainframes
Posté par Calvin0c7 . Évalué à 3.
Grand système IBM :
http://solutions.journaldunet.com/0403/040330_mainframe.shtml(...)
MVS :
http://fr.wikipedia.org/wiki/MVS(...)
Plus technique :
http://www-1.ibm.com/servers/eserver/zseries/library/literature/ref(...)
Qques photos :
http://www.ericom.com/images/wbt5.gif(...)
http://images.google.fr/imgres?imgurl=http://www.sfrisch.com/images(...)
3270 powaaa
http://www.bomara.com/FTP/products/hostlink97/3270.gif(...)
http://www.dn-computing.com/images/Screen2.JPG(...)
[^] # Re: CPU dans les Mainframes
Posté par gallenza . Évalué à 0.
[^] # Re: CPU dans les Mainframes
Posté par KDYY4RF . Évalué à 1.
http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/sg246(...)
[^] # Re: CPU dans les Mainframes
Posté par gallenza . Évalué à 0.
# Du plus petit au plus gros
Posté par Jérôme F. . Évalué à 2.
# Petite erreur
Posté par bill236 . Évalué à 1.
De toutes façons, ça me parait plus réaliste.
Quoique 10240, ça le ferait surement! :)
A+
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.