Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 22 sur 26 PremièrePremière ... 1214151617181920212223242526 DernièreDernière
Affichage des résultats 631 à 660 sur 764
  1. #631
    Citation Envoyé par ylyad Voir le message
    Pourtant, j'imagine que l'équipe de l'Oregon a archi-documenté le truc, non? Malgré ça, les autres ne l'ont pas implémenté? Ou avaient?

    Une question, si je suis: chaque tock (et les ticks correspondants) est géré par une équipe dédiée? Du coup, si une feature est implémentée par l'une, elle n'est pas forcément reprise par les autres ou c'est juste une question de latence (compréhensible en fonction de la complexité de ladite feature)?
    Autrement dit: si SMT est maîtrisé seulement par l'Oregon, alors que (j'imagine) il y a des projets en cours chez les autres, est-ce à dire que les futurs tocks ne l'implémenteront pas? Ou Core (et ses dérivés) était un cas à part car venant trop tôt après Netburst?
    (je sais, ça fait plusieurs questions )
    Je vais juste répondre à une seule

    Un processeur doit être équilibré, et comme un truc comme le SMT aura un impact sur tout le design et pas seulement le core, mais aussi le côté Data et Instruction, c'est dur de récupérer quoi que ce soit, même conceptuellement. Je dirais qu'au mieux les autres équipes de design peuvent récupérer les idées des autres équipes et apprendre de leurs erreurs. Mais la réutilisation brute ça n'existe quasiment pas, ou ça donne de mauvais résultats.

    Après tu as le credo de chaque équipe où tu auras la grande gueule qui en impose à tout le monde et qui va expliquer, sans forcément savoir pourquoi, que ça ne sert à rien pour le design particulier que va faire l'équipe... Ca sent le vécu non ?

    Bref tout ça pour dire que même si un centre maîtrise une technique pointue, la dissémination n'est pas facile.

  2. #632
    Citation Envoyé par ylyad Voir le message
    Pourtant, j'imagine que l'équipe de l'Oregon a archi-documenté le truc, non? Malgré ça, les autres ne l'ont pas implémenté? Ou avaient?
    La documentation est une chose l'experience est une autre. Avoir une liste de bug documentee, meme avec la methode pour les trouver et les corriger n'est pas la meme chose qu'etre l'equipe qui a fait face aux problemes.

    Une question, si je suis: chaque tock (et les ticks correspondants) est géré par une équipe dédiée?
    Le Tick n'est pas necessairement fait par la meme quipe que le Tock. Merom vient d'Israel, Penryn de Californie, Nehalem et Westmere d'Oregon.

    Du coup, si une feature est implémentée par l'une, elle n'est pas forcément reprise par les autres ou c'est juste une question de latence (compréhensible en fonction de la complexité de ladite feature)?
    Ce que tu decris est un probleme classique de developpement parallele de projets successifs (en pipeline). Il faut un partage et une reutilisation d'information entre les equipes afin que les features d'un projet ne disparaissent pas dans le suivant. Si tu refais tout a partir de 0 a chaque changement d'equipe ca ne peut pas marcher. Si tu reutilises un maximum il s'agit juste de faire attention a l'interaction de tes nouvelles features avec celles du projet immediatement avant toi (qui est en cours aussi, mais plus avance).

    Autrement dit: si SMT est maîtrisé seulement par l'Oregon, alors que (j'imagine) il y a des projets en cours chez les autres, est-ce à dire que les futurs tocks ne l'implémenteront pas? Ou Core (et ses dérivés) était un cas à part car venant trop tôt après Netburst?
    (je sais, ça fait plusieurs questions )
    Il y a une difference entre ajouter des features sur un processeur deja SMT et l'implementer sur un processeur non SMT. Les seuls bugs que tu dois trouver sont localises aux features que tu viens d'ajouter. Ca limite la complexite.
    C'est un peu comme implementer un x86 a partir de 0 ou alors avoir deja un core x86 et le modifier. La difference de complexite est significative.

    Tu remarqueras que depuis la transition P3->P4 il n'y a pas eu trop de transitions de processeurs chez Intel avec beaucoup de retours en arriere cote performance (le P3 etait meilleur sur pas mal d applis que le P4, meme si le P4 gagnait en moyenne). Cela indique une approche basee sur l'evolution d'un core: tu y ajoutes des choses, mais tu n'enleves rien. L'avantage est que tu construis sur du connu et limite ta validation (l'ecriture de nouveaux tests) a tes nouvelles features. L'inconvenient est que tu ne peux que grossir, et si certaines decisions de projets precedents sont nefastes a certaines de tes features il faudra quand meme gerer les choses comme avant (le poids de la retro compatibilite, mais etendu aux problemes de performance).
    fefe - Dillon Y'Bon

  3. #633
    Citation Envoyé par newbie06 Voir le message
    Je vais juste répondre à une seule

    Un processeur doit être équilibré, et comme un truc comme le SMT aura un impact sur tout le design et pas seulement le core, mais aussi le côté Data et Instruction, c'est dur de récupérer quoi que ce soit, même conceptuellement. Je dirais qu'au mieux les autres équipes de design peuvent récupérer les idées des autres équipes et apprendre de leurs erreurs. Mais la réutilisation brute ça n'existe quasiment pas, ou ça donne de mauvais résultats.
    Si chaque generation de processeur est fait a partir de 0 oui, si tu partages les chaines d'outils de simulation , les bases de donnees RTL, les tests de validation, etc... tu peux travailler dans un mode incremental. Le surcout est important, mais suivant la complexite de l'ensemble ca peut valoir le coup (surtout si tu commences avec un monstre enorme).

    Après tu as le credo de chaque équipe où tu auras la grande gueule qui en impose à tout le monde et qui va expliquer, sans forcément savoir pourquoi, que ça ne sert à rien pour le design particulier que va faire l'équipe... Ca sent le vécu non ?
    Oui il y a des grandes gueules partout, mais a partir du moment ou tu as des review entre les differentes equipes sur leurs choix et que chacun doit justifier de ses choix aux autres projets qui vont en heriter ca ramene souvent a des argumentations nettement plus raisonables et techniques.

    Bref tout ça pour dire que même si un centre maîtrise une technique pointue, la dissémination n'est pas facile.
    Horriblement difficile meme, mais quand la complexite d'un projet depasse la taille d'une equipe, il n'y a plus le choix.
    fefe - Dillon Y'Bon

  4. #634
    Tiens, hors sujet, enfin, hors conversation, les Xeon Nehalem sont là :D

    Trucs marrant, y a des TDP "bizarres" et un peu de tout dans les CPU :

    8 Mo, 4 Mo en cache

    4 cores + HT, 4 cores sans HT, 2 cores sans HT et 2 cores avec HT :D

    Ca change des 3 Core i7 :D

  5. #635
    Et d'ailleurs, les gammes constructeurs sont *déjà* dispo. Y'a des trucs sympa, les DL380G6 ou DL360 sont assez bluffants d'ailleurs (144GB + 16 SFF & 2 55xx dans 2U ou 144GB + 8 SFF & 2 55xx dans 1U)

  6. #636
    Voila une mobo sympa pour les nouveaux Xeon (pour mes besoins) :


    Mais.... Enhanced E-ATX

  7. #637
    Si tu peux te payer cette MB avec les Xeon qui vont dessus, tu peux te payer le reste, non ?

  8. #638
    Oui mais non. Elle n'est pas plus chère que les autres (je l'ai vue entre 500 et 550$ en prix de revente). Mais ensuite, va trouver un boitier pour la faire rentrer, qui soit étudié pour le silence, et qui ait un peu de gueule.

    'Fin bon, je fais dériver le topic à chaque fois, j'arrête

  9. #639
    Citation Envoyé par fefe Voir le message
    La documentation est une chose l'experience est une autre. Avoir une liste de bug documentee, meme avec la methode pour les trouver et les corriger n'est pas la meme chose qu'etre l'equipe qui a fait face aux problemes.
    Je n'ai (malheureusement) aucune illusion à ce sujet, mais c'est rassurant que même dans des boites comme Intel, on se retrouve face aux mêmes problèmes. Ca me servira à expliquer à mes chefs que "monter une base de connaissances" même béton ne rendra pas nos collègues indiens opérationnels du jour au lendemain par la magie de la lecture
    Le Tick n'est pas necessairement fait par la meme quipe que le Tock. Merom vient d'Israel, Penryn de Californie, Nehalem et Westmere d'Oregon.
    Au temps pour moi
    Ce que tu decris est un probleme classique de developpement parallele de projets successifs (en pipeline). Il faut un partage et une reutilisation d'information entre les equipes afin que les features d'un projet ne disparaissent pas dans le suivant. Si tu refais tout a partir de 0 a chaque changement d'equipe ca ne peut pas marcher. Si tu reutilises un maximum il s'agit juste de faire attention a l'interaction de tes nouvelles features avec celles du projet immediatement avant toi (qui est en cours aussi, mais plus avance).

    Il y a une difference entre ajouter des features sur un processeur deja SMT et l'implementer sur un processeur non SMT. Les seuls bugs que tu dois trouver sont localises aux features que tu viens d'ajouter. Ca limite la complexite.
    C'est un peu comme implementer un x86 a partir de 0 ou alors avoir deja un core x86 et le modifier. La difference de complexite est significative.

    Tu remarqueras que depuis la transition P3->P4 il n'y a pas eu trop de transitions de processeurs chez Intel avec beaucoup de retours en arriere cote performance (le P3 etait meilleur sur pas mal d applis que le P4, meme si le P4 gagnait en moyenne). Cela indique une approche basee sur l'evolution d'un core: tu y ajoutes des choses, mais tu n'enleves rien. L'avantage est que tu construis sur du connu et limite ta validation (l'ecriture de nouveaux tests) a tes nouvelles features. L'inconvenient est que tu ne peux que grossir, et si certaines decisions de projets precedents sont nefastes a certaines de tes features il faudra quand meme gerer les choses comme avant (le poids de la retro compatibilite, mais etendu aux problemes de performance).
    Oui, j'avais pas pensé à ça, mon hypothèse était bâtarde (on repart de zéro mais on réutilise ce qui était bien avant): si seulement c'était aussi simple que ça
    Citation Envoyé par newbie06 Voir le message
    Je vais juste répondre à une seule
    Un processeur doit être équilibré, et comme un truc comme le SMT aura un impact sur tout le design et pas seulement le core, mais aussi le côté Data et Instruction, c'est dur de récupérer quoi que ce soit, même conceptuellement. Je dirais qu'au mieux les autres équipes de design peuvent récupérer les idées des autres équipes et apprendre de leurs erreurs. Mais la réutilisation brute ça n'existe quasiment pas, ou ça donne de mauvais résultats.
    Oui, c'est pour ça que je parlais de "latence" (i.e. temps de diffusion des nouvelles features entre les différentes équipes)
    Après tu as le credo de chaque équipe où tu auras la grande gueule qui en impose à tout le monde et qui va expliquer, sans forcément savoir pourquoi, que ça ne sert à rien pour le design particulier que va faire l'équipe... Ca sent le vécu non ?

    Bref tout ça pour dire que même si un centre maîtrise une technique pointue, la dissémination n'est pas facile.
    Yep, même remarque plus haut, Intel est une boite (presque) comme les autres... Mais c'est AUSSI le boulot du management de ne pas se laisser emmerder par des grandes gueules

  10. #640
    Citation Envoyé par fefe Voir le message
    Le Tick n'est pas necessairement fait par la meme equipe que le Tock. Merom vient d'Israel, Penryn de Californie, Nehalem et Westmere d'Oregon.
    C'est d'ailleurs étonnant que ça puisse parfois être le cas (la même équipe qui fait à la fois l'évolution de l'architecture et du process).
    Ou alors, les "équipes" sont pluri-disciplinaires et organisées par projet, et non pas selon leur domaine de compétence.
    Vu que les 2 domaines sont étroitement liés tout au long du projet, je suppose que ca a un sens, même si niveau organisation, ca ne doit pas être évident à gérer.

  11. #641
    Citation Envoyé par Stéphane.P Voir le message
    Oui mais non. Elle n'est pas plus chère que les autres (je l'ai vue entre 500 et 550$ en prix de revente). Mais ensuite, va trouver un boitier pour la faire rentrer, qui soit étudié pour le silence, et qui ait un peu de gueule.

    'Fin bon, je fais dériver le topic à chaque fois, j'arrête
    Les 'gros' lianli et les p180 supportent les e-atx je crois

  12. #642
    Je ne sais pas comment ca se passe chez Intel, mais l'implementation (ou pour simplifier le process) n'est-elle pas assez distincte des phases micro-achitectures/design ?
    Donc en tick on aurait une equipe qui s'occupe du nouveau process avec quelques bonhommes qui tunent la micro-architecture. Et en tock on aurait une equipe qui fait de la micro-arch et du design avec quelques bonhommes qui font l'implementation.
    Ca marche comme ca ?

  13. #643
    Tel que tu le dis, on aurait donc toujours des équipes différentes entre le tick et le tock. C'est aussi ce que je pensais initialement (d'ou ma question), mais contrairement à ce qu'on pourrait interpréter basiquement de ce tick /tock (un coup, c'est les designers qui bossent, un coup ce sont les physiciens), dans la pratique, les 2 doivent travailler étroitement ensemble qu'on soit en tick ou en tock (d'ou l'idée de les mettre dans une même "équipe").
    Peut être plus en tock qu'en tick puisque il faut que le process puisse supporter les ambitions du design, mais en tick, les nouvelles possibilités offertes par le process doivent également conduire à des légers redesigns, afin par exemple de permettre une meilleure montée en fréquence.

  14. #644
    Citation Envoyé par Stéphane.P Voir le message
    Voila une mobo sympa pour les nouveaux Xeon (pour mes besoins) :
    http://tof.canardpc.com/view/8c93f26...c-1908d6ad72ed

    Mais.... Enhanced E-ATX

    Et ça, ça ne va pas? Bon, y a encore du vieux PCI, mais je suppose que ce qui bloque c'est les slots de RAM ( Inuendo si j'ai bonne mémoire )
    http://valid.x86-secret.com/cache/banner/313021.png

  15. #645
    Citation Envoyé par DJ_DaMS Voir le message
    ( Inuendo si j'ai bonne mémoire )
    Nuendo.
    Innuendo, c'est un morceau de Queen (et le titre de leur dernier album avec F. Mercury).

  16. #646
    Citation Envoyé par Oxygen3 Voir le message
    Les 'gros' lianli et les p180 supportent les e-atx je crois
    Et aller ! Un deuxième qui s'est fait avoir
    La carte mère que j'ai montré est une Enhanced E-ATX, c'est encore plus grand.

    Citation Envoyé par DJ_DaMS Voir le message
    http://www.supermicro.com/a_images/p...TL-iF_spec.jpg
    Et ça, ça ne va pas? Bon, y a encore du vieux PCI, mais je suppose que ce qui bloque c'est les slots de RAM ( Inuendo si j'ai bonne mémoire )
    Chez supermicro, la moins mauvaise dans mon cas sera la X8DAi :

    Mais 3 slots Pci-e seulement c'est juste.
    edit : et un foutu ventilo surement bien strident... berk.

    Sinon, pour recoller au topic, il va falloir faire attention au type de barrette de mémoire utilisées sur les plates-forme 5500/5520 :
    Exemple : Registered Quad Rank limité à 800mhz si les deux slots d'un même canal sont utilisés.

    ps : Ce serait peut-être pas mal de créer un topic pour discuter de ce qui sort de l'architecture pure et dure. Mais on met ça où ? Advanced or not ?

  17. #647
    Citation Envoyé par Yasko Voir le message
    Nuendo.
    Innuendo, c'est un morceau de Queen (et le titre de leur dernier album avec F. Mercury).
    Oui, sorry honte sur moi !

    Sinon là on a reçu un server 1U Intel en éval avec 2 X5550 et 12Go dedant.
    C'est pour faire du transcodage on the fly de plusieurs flux HD. Problème, les codecs n'utilisent que 8 cores sur les "16".
    Va falloir creuser.
    http://valid.x86-secret.com/cache/banner/313021.png

  18. #648
    Citation Envoyé par DJ_DaMS Voir le message
    Sinon là on a reçu un server 1U Intel en éval avec 2 X5550 et 12Go dedant.
    C'est pour faire du transcodage on the fly de plusieurs flux HD. Problème, les codecs n'utilisent que 8 cores sur les "16".
    Va falloir creuser.
    J'suis jaloux... si je pouvais avoir du matos en eval, ça me simplifierait vraiment la tâche.

  19. #649
    Citation Envoyé par Yasko Voir le message
    Nuendo.
    Innuendo, c'est un morceau de Queen (et le titre de leur dernier album avec F. Mercury).
    Ouais enfin c'est aussi juste un mot ^^

    Sinon c'est quoi les facteurs limitants sous Nuendo ? Je demande parce que mon paternel s'en sert pas mal sur une vieille config, donc pour son prochain upgrade j'aimerais bien savoir quoi privilégier.

  20. #650
    Citation Envoyé par Yasko Voir le message
    Tel que tu le dis, on aurait donc toujours des équipes différentes entre le tick et le tock. C'est aussi ce que je pensais initialement (d'ou ma question), mais contrairement à ce qu'on pourrait interpréter basiquement de ce tick /tock (un coup, c'est les designers qui bossent, un coup ce sont les physiciens), dans la pratique, les 2 doivent travailler étroitement ensemble qu'on soit en tick ou en tock (d'ou l'idée de les mettre dans une même "équipe").
    Peut être plus en tock qu'en tick puisque il faut que le process puisse supporter les ambitions du design, mais en tick, les nouvelles possibilités offertes par le process doivent également conduire à des légers redesigns, afin par exemple de permettre une meilleure montée en fréquence.
    Il y a beaucoup de monde et beaucoup de competences differentes dans une equipe qui fabrique un microprocesseur. Architectes, RTL design, Circuit design, Layout, Validation de l'architecture, validation des circuits, process, production. Tu pourrais avoir des personnes qui sont pluridisciplinaires, mais il serait impossible d'en avoir suffisament pour gerer des projets de la taille des processeurs x86 modernes (ou alors tu as beaucoup d'argent pour reussir a tous les garder avec toi pendant longtemps). Par contre des personnes peuvent partager leur temps entre 2 projets assez efficacement. Tu peux donc adapter la taille de chaque sous equipe en fonction des projets. Tu n'es pas non plus oblige que toutes tes equipes aient le meme nombre de personnes de chaque competence et tu peux avoir des sites plus "optimises" pour les shrinks que pour l'architecture. Et le jour ou un site de shrink doit faire de l'architecture il peut recevoir l'aide de quelques ingenieur d'un autre site.

    Qui plus est, les tick de Intel ne sont pas des shrinks optiques (ala NV GF285 par ex), en effet tu retrouves toujours une ou deux petites ameliorations d'architecture, une ou deux nouvelles instructions a la con etc... Bien assez pour garder ton architecture et ton design occupe pendant le temps de developpement (plus court qu'un tock) de ton tick.

    Citation Envoyé par Ylyad
    Je n'ai (malheureusement) aucune illusion à ce sujet, mais c'est rassurant que même dans des boites comme Intel, on se retrouve face aux mêmes problèmes. Ca me servira à expliquer à mes chefs que "monter une base de connaissances" même béton ne rendra pas nos collègues indiens opérationnels du jour au lendemain par la magie de la lecture
    Et sinon esperer qu'un site puisse se former en lisant de la doc n'est pas seulement utopique, c'est tout simplement stupide a moins bien sur que les competences necessaires au job soient minimes et tres rependues (meme l'outsource des services techniques perd beaucoup en qualite le temps que la nouvelle equipe acquierre de l'experience, alors si en plus les competences sont pointues...). Les methodes de travail, les relations humaines et l'experience individuelle jouent un role enorme, surtout quand un petit projet prend 3 ou 4 ans et un gros 5 a 7. Tu perds deja bien assez de competences juste a cause de la duree du projet (il y a toujours des gens qui s'en vont) alors ne plus avoir les personnes qui ont complete au moins un projet bosser sur un suivant peut tourner a la cata. Bien entendu il est possible de former une equipe, mais ca ne prend pas du jour au lendemain (pour un petit projet j'ai vu une nouvelle equipe reussir a sortir=vendre son premier projet en 7 ans, apres un ramp up et un echec...).

    Voila, la delocalisation ca marche, mais ce n'est pas si facile et aussi peu couteux que certains peuvent penser.
    fefe - Dillon Y'Bon

  21. #651
    Citation Envoyé par fefe Voir le message
    Et sinon esperer qu'un site puisse se former en lisant de la doc n'est pas seulement utopique, c'est tout simplement stupide a moins bien sur que les competences necessaires au job soient minimes et tres rependues (meme l'outsource des services techniques perd beaucoup en qualite le temps que la nouvelle equipe acquierre de l'experience, alors si en plus les competences sont pointues...). Les methodes de travail, les relations humaines et l'experience individuelle jouent un role enorme, surtout quand un petit projet prend 3 ou 4 ans et un gros 5 a 7. Tu perds deja bien assez de competences juste a cause de la duree du projet (il y a toujours des gens qui s'en vont) alors ne plus avoir les personnes qui ont complete au moins un projet bosser sur un suivant peut tourner a la cata. Bien entendu il est possible de former une equipe, mais ca ne prend pas du jour au lendemain (pour un petit projet j'ai vu une nouvelle equipe reussir a sortir=vendre son premier projet en 7 ans, apres un ramp up et un echec...).

    Voila, la delocalisation ca marche, mais ce n'est pas si facile et aussi peu couteux que certains peuvent penser.
    on est d'accord. Malheureusement, pas ma direction

  22. #652
    Benchmark d'un dual x5570 sous WinServer : http://www.realworldtech.com/page.cf...WT040709042555
    Le test sous un vrai OS devrait arriver plus tard.

    EDIT : certains resultats SPECfp_rate sont un peu etranges : povray se tape un 921 alors que tous les resultats publies sont dans les 300 (meme compilo, sous Linux ou Windows). Y'a un truc foireux la.
    Dernière modification par newbie06 ; 07/04/2009 à 17h45.

  23. #653
    Citation Envoyé par newbie06 Voir le message
    certains resultats SPECfp_rate sont un peu etranges : povray se tape un 921 alors que tous les resultats publies sont dans les 300 (meme compilo, sous Linux ou Windows). Y'a un truc foireux la.
    libquantum des SPECint a aussi un speedup impressionnant (760 contre 200), mais là c'est aussi le cas dans les autres résultats.
    L'hypothèse de la parallélisation automatique n'est pas convaincante, ça profiterait au Harpertown aussi.
    Ça pourrait être dû à la différence de latence mémoire, mais même là ça fait beaucoup, surtout qu'un Dunnington 4x4 arrive péniblement à 200...

  24. #654
    J'avais déjà entendu parlé du "dysfonctionnement" de libquantum. Il faudra que je retrouve où (sans doute sur SPARC, Sun est spécialiste ).

  25. #655
    Tiens pour ceux qui l'auraient loupé, le screen du clarkdale / havendale

    http://www.cpuid.com/pics/05113357.jpg

  26. #656
    Je n'ai pas eu de réponse par rapport à cette question. Peut-être qu'ici....

  27. #657
    Je ne vais pas dire que tu ne peux pas (peut etre qu'il y a des utilitaires permettant de le faire), mais je dirais que de maniere generale c'est une mauvaise idee. En effet l'unite qui gere le power (PCU) dans le processeur contient des tables qui lui permettent de prendre des decisions sur les frequences et voltages a utiliser. Ces tables sont certainement statiques donc si tu changes le mode d'operation par defaut de ton CPU tu risques de te retrouver a utiliser ton budget d'energie d'une maniere sous optimale.

    Sinon il y aura un coeff minimum sous lequel tu ne pourras pas descendre de toutes facons. Je sais je ne reponds pas vraiment a ta question.
    fefe - Dillon Y'Bon

  28. #658
    Si je cherche à diminuer le coeff, c'est uniquement dans le but de faire des tests de performance à différentes fréquences, ce ne sera pas le mode de fonctionnement "normal".

    Pour le moment, voici les résultats de mes tests :

    C2D @ 2.66 = 96
    C2Q @ 2.66 = 158
    I7 920 @ 2.66 = 192
    Dual X5430 @ 2.66 = 200 (environ)
    Dual X5560 @ 2.8 = 316

    Ca va, ils "scalent" pas trop mal ces Xeon

    Par contre, j'ai deux cartes mère, une Intel et une Supermicro. La Intel est très mauvaise en basse latence.

  29. #659
    ASUS Z8NA-D6

    DS LGA 1366
    ATX
    PCI Express x16
    PCIe
    PCI
    PCI-X
    2x3 DDR3 R/DIMM U ECC/Non-ECC
    14 SATA
    http://www.asus.com/product.aspx?P_ID=JoOxbkv8HgVqHLrz

    Dispo. En Allemagne à 260 € Moins chère que certaine carte pour i7 et deux fois moins que ce que valait une mobo Skulltrail.

  30. #660
    Ha du ATX et y'a même un port série

    Je vois deux soucis : seulement 3 sockets RAM / CPU et en plus un de ces sockets me paraît trop proche du slot PIC-E à côté (alors si en plus ce PCI-E est le 16x c'est encore pire).

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •