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/linux@lists.unixtech.be 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/linux@lists.unixtech.be IRC: chat.unixtech.be:6667 - #unixtech
