Jean-Francois Dive wrote:
de toute facon les grosses caisses avec pleins de CPU c'est pas
interessant, ca coute chers et ca crashe tout le temps.
Un petit exemple ?
Une machine 64 CPUs de 3 ans; pas possible de se passer du contrat de maintenance car il est utilis� r�guli�rement...
La valeur annuelle de ce contrat de maintenance �tait suffisante pour acheter CHAQUE ANNEE plus de deux fois la puissance CPU, l'espace RAM, l'espace HD sous forme de calculateurs dual-XEONS standards (32 bits), facilement r�parables, rempla�ables en cas de panne (ou additionnables d'ann�e en ann�e) ou min une fois avec des Opterons (64 bits).
Ok, pour interconnecter les noeuds � plus de 1Gb/s c'est plus cher mais quand m�me c'est bien plus souple, robuste et extensible comme solution !
A la limite, pas de contrat de maintenance : avec cet argent on ach�te du nouveau mat�riel chaque ann�e (et on colle � la loi de Moore au lieu d'entretenir un vieux trigu) et on peut m�me se permettre de jeter froidement ce qui ne va plus, sans y regarder ;-)
Bonne journ�e,
Alain
Rien ne vaut un bon cluster de PC et ca dois marcher pour toutes les applications si elle est bien developee.
On Tue, Nov 16, 2004 at 07:00:27AM +0100, Pascal Bleser wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Vincent Jamart wrote: | Je suis d'accord avec Pascal sur le fait de laisser le scheduler organiser | les process. J'avais fait quelques benchs sur un pSeries (Power4+) avec | DLPAR et le fameux "CPU affinity" et ca donnait de moins obn resultats | pour des databases. Par compte, c'est possible qu'en HPC ca change la | donne mais la machine n'avait que 4CPU et 2 lpar. Seule celle en AIX 5.2 | pouvait supporter cette option, l'autre en SLES8/Pseries ne m'offrait | aucune option.
Oui, normal, SLES8 est sur kernel 2.4.
A mon avis, ?a n'a de sens (et encore) que quand on a un tr?s grand nombre de CPUs, c?d une douzaine
au minimum. Jusqu'? 8 CPUs le scheduler devrait faire un excellent boulot par lui-m?me (en tout cas
pour le kernel 2.6 - pour 2.4, c'est sans doute un peu moins bon pour 8 que pour 4).
- -- ~ -o) Pascal Bleser http://guru.unixtech.be ~ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ~ _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQFBmZd7r3NMWliFcXcRAvnhAJ9xiC4/6JstFP6AowHTVcJiC+RMtgCgrV56 bRXllixBVpOsP2gVnEaWfWk= =F96M -----END PGP SIGNATURE----- _______________________________________________________ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/[email protected] IRC: chat.unixtech.be:6667 - #unixtech
-- ------------------------------------------------------------ Dr Alain EMPAIN <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Bioinformatics, Molecular Genetics, Fac. Med. Vet., University of Li�ge, Belgium Bd de Colonster, B43 B-4000 Li�ge (Sart-Tilman) WORK: +32 4 366 3821 FAX: +32 4 366 4122 HOME: rue des Martyrs,7 B- 4550 Nandrin +32 85 51 23 41 GSM: +32 497 70 17 64 ------------------------------------------------------------------------------- [ Creative Commons ] Ne pas confondre 'Piraterie' et 'Partage des connaissances' : Faire circuler la connaissance est au coeur m�me de l'activit� de cr�ation et d'invention. La connaissance scientifique est bas�e sur des si�cles de partage cr�atif. 'Du bon usage de la piraterie' F. Latrive (PDF) http://www.freescape.eu.org/piraterie/complet.html ------------------------------------------------------------------------------- _______________________________________________________ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/[email protected] IRC: chat.unixtech.be:6667 - #unixtech
