Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 21 sur 26 PremièrePremière ... 111314151617181920212223242526 DernièreDernière
Affichage des résultats 601 à 630 sur 764
  1. #601
    Fuck !!

    Il y a un outil qui devrait m'aider, mais je n'y ai pas accès, il fait parti du Windows Driver Kit. Il s'agit de Pwrtest.exe.

    Plus d'infos dans ce document.

    Fin de mon HS.

  2. #602
    Je quote la partie sur le Power control Unit du dossier de Pcinpact
    Enfin, Intel mettra à disposition des utilisateurs un logiciel de surveillance et de gestion des différentes valeurs du processeur et de son contrôleur mémoire, un peu à la manière de l'overdrive d'AMD, que nous étudierons lors de nos tests.
    Quelqu'un a vu ça quelque part ?

  3. #603
    Tu peux essayer avec ProcessMonitor (si tu penses que la cause est logicielle).
    Par contre, si le PC est chargé, tu risques d'avoir pas mal d'événements, mais si tu sais ce que tu cherches, ca peut être jouable.

  4. #604
    Citation Envoyé par Stéphane.P Voir le message
    Fuck !!

    Il y a un outil qui devrait m'aider, mais je n'y ai pas accès, il fait parti du Windows Driver Kit. Il s'agit de Pwrtest.exe.

    Plus d'infos dans ce document.

    Fin de mon HS.
    Pourquoi tu n'y a pas accès ? Il faut un abo MSDN ?

    edit: j'viens de regarder et la version de novembre 2008 de Windows Driver Kit fait 632Mo
    A la limite je peux l'installer et de mettre à dispo juste l'exe (et les éventuelles DLL) mais j'ai peur que ça soit pas aussi simple.

    edit2: Pwrtest.zip (attention il faut minimum Vista)
    Dernière modification par Foudge ; 09/03/2009 à 15h31.

  5. #605
    Merci beaucoup Foudge, ça va m'être très utile...mais pas pour le cas présent. Je vais m'en servir lorsque modifier le comportement des changement d'état dans Vista...afin d'éviter d'être obligé de laisser les machines en C0 en permanence.

    En fait, je viens de trouver d'où viens mon problème, et ça n'a rien à voir avec le nehalem ou les fonctions d'éco d'énergie :
    J'avais donc des pics de DPC de manière un peu aléatoire, et en fait, c'était lié à la vitesse de rotation d'un des ventilo qui en fonction de la charge cpu avait tendance à ralentir un peu pour osciller autour de 715tr/mn.... qui est justement considérée par le bios comme la limite en dessous de laquelle il y a un problème.

    - Allo ? Le support technique Supermicro ?
    - Oui ?
    - Bordel !! Votre Bios viens de me faire perdre 4 jours de taff !

    edit pour foudge : oui, il faut un abo msdn

  6. #606
    Joli ! Cela me surprenait que ca soit lie aux changements de C state etant donne la latence typique de ceux-ci (faible au regard de la taille du probleme que tu mentionnais).

    Si tu trouves des scenarios RT ou le changement de C/P-state affecte ta latence de maniere visible je suis interresse (sur Nehalem).
    fefe - Dillon Y'Bon

  7. #607
    Citation Envoyé par Stéphane.P Voir le message
    Merci beaucoup Foudge, ça va m'être très utile...mais pas pour le cas présent. Je vais m'en servir lorsque modifier le comportement des changement d'état dans Vista...afin d'éviter d'être obligé de laisser les machines en C0 en permanence.

    En fait, je viens de trouver d'où viens mon problème, et ça n'a rien à voir avec le nehalem ou les fonctions d'éco d'énergie :
    J'avais donc des pics de DPC de manière un peu aléatoire, et en fait, c'était lié à la vitesse de rotation d'un des ventilo qui en fonction de la charge cpu avait tendance à ralentir un peu pour osciller autour de 715tr/mn.... qui est justement considérée par le bios comme la limite en dessous de laquelle il y a un problème.

    - Allo ? Le support technique Supermicro ?
    - Oui ?
    - Bordel !! Votre Bios viens de me faire perdre 4 jours de taff !

    edit pour foudge : oui, il faut un abo msdn
    Putain, comment t'as trouvé ? T'as vraiment pas de bol, quand même...

  8. #608
    Citation Envoyé par fefe Voir le message
    Joli ! Cela me surprenait que ca soit lie aux changements de C state etant donne la latence typique de ceux-ci (faible au regard de la taille du probleme que tu mentionnais).
    Ouaip, j'ai galèré pour trouver d'où ça venait, et ça n'explique pas pourquoi passer dessous le seuil de 715rpm génère ce genre de pics :


    Si tu trouves des scenarios RT ou le changement de C/P-state affecte ta latence de maniere visible je suis interresse (sur Nehalem).
    En fait, c'est déjà le cas depuis longtemps. Quoique ce n'est pas tout à fait ça : Les changements de state ne modifient pas la latence audio mais mettent le bronx dans les buffers et ont se retrouve avec des craquements. De visu, la jauge "cpu" (1) du soft audio peut se balader tranquillement à 50% et sauter régulièrement à 100% l'espace d'une milliseconde.

    Pour recoller un peu au topic, jusqu'il y a quelques heures, j'étais parti sur l'idée que le mode turbo se désactivait lorsque les 8 coeurs logiques arrivaient à 100% d'utilisation.
    De un, il semble que ce ne soit pas le cas, mon i7 920 reste à 2.78Ghz (curieux d'ailleurs), ou bien le coeff redescend à x20 de manière trop rapide pour être visible et c'est pour cette raison que je cherchais ce soit disant logiciel d'intel qui permettrait de "voir" le comportement du PCU.
    De deux, cela ne collait pas avec les pics de DPC.

    Au passage, Franck si tu passes par là, sur quoi se base réellement l'indication "Power" qu'on trouve dans HwMonitor ? Dans mon cas, elle reste à 145W, ce qui contredis ce qu'on lit au sujet du PCU.

    (1) cpu entre guillement car elle n'a pas toujours en rapport avec l'utilisation réelle du processeur. Elle tient compte de l'ensemble de la chaine audio. C'est la raison pour laquelle les configs audio ont leurs fonctions d'économie d'énergie désactivées..... et ça me plait de moins en moins. Je n'ai plus qu'à coder un p'tit soft qui les modifieraient à la volée lorsqu'un soft audio est en fonctionnement.

    : parsacheterleC++pourlesnuls:

  9. #609
    Citation Envoyé par Alexko Voir le message
    Putain, comment t'as trouvé ? T'as vraiment pas de bol, quand même...
    J'ai fini par m'orienter vers un éventuel problème de throttle/température. Donc, j'ouvre le boitier, et je colle un ventilo de 220mm à souffler sur la config. Les pics dispairaissent. Ha ! Je suis sur la voie. Pour vérifier, je referme tout et je coupe un ventilo pour faire monter en température. Au bout de plusieurs heures ...toujours pas de pics. Merde, c'est pas la température.

    Et là, d'un seul coup, j'ai lu la matrice

    1)En idle, le ventilo cpu tourne à environ 725tr/mn
    2)Avec une grosse charge Cpu, les ventilos ont toujours tendance à ralentir légèrement, ce qui expliquait pourquoi j'avais ces pics uniquement à ce moment là.
    3) En ouvrant le boitier (résistance de l'air moins importante) et avec un ventilo dessus (push-pull), celui du cpu tournait forcément un peu plus vite -> il restait donc au dessus de 715.
    4) Boitier fermé, mais avec un ventilo en moins à pomper du jus, celui du cpu gagnait aussi forcément quelques tr/mn et c'était suffisant pour rester au dessus de 715.
    5)Je me souvenais de ce seuil de 715tr/mn qui m'avait posé problème il y a un an : Sur des configs bi-xeon, dès que l'un des ventilos passait sous la limite, tout le monde repassait en full speed quelques secondes.

  10. #610
    Hé bien un grand bravo à Supermicro, spécialiste des cartes pour serveur

  11. #611

  12. #612
    Ca fait mal...
    http://valid.x86-secret.com/cache/banner/313021.png

  13. #613
    +30% grâce au HT... (si j'ai bien compris la légende du moins - c'est quoi ce (HP) ?)
    C'est impressionnant le gain que l'on peut tirer du SMT sur une µarch à pipeline (relativement) court (et non prévue pour à la base ?) et sur des tâches quand même assez parallèles (je connais pas le bench, mais bon du SAP serveur, ca doit être parallèle).
    Ca veut dire que même sur ce genre d'applis, on a encore au moins 30% de "trous".

  14. #614
    Citation Envoyé par Yasko Voir le message
    +30% grâce au HT... (si j'ai bien compris la légende du moins - c'est quoi ce (HP) ?)
    C'est impressionnant le gain que l'on peut tirer du SMT sur une µarch à pipeline (relativement) court (et non prévue pour à la base ?) et sur des tâches quand même assez parallèles (je connais pas le bench, mais bon du SAP serveur, ca doit être parallèle).
    Ca veut dire que même sur ce genre d'applis, on a encore au moins 30% de "trous".
    Le SMT tire tout aussi bien partie d'un pipeline large que long, puisque les deux génèrent des "trous".

    Finalement, ces résultats ne sont pas très étonnants, comparé à Shanghai, Nehalem :

    - est un cran plus performant en single-thread
    - monte plus haut en fréquence
    - a une plus grosse bande-passante
    - a l'HT

    Les temps vont êtres rudes pour AMD sur les serveurs :-/

  15. #615
    Citation Envoyé par Alexko Voir le message
    Les temps vont êtres rudes pour AMD sur les serveurs :-/
    Surtout vu que dans le monde actuel (francais en tout cas), arriver à 'vendre' un serveur à base d'AMD est quasi impossible :/
    (D'expérience, sur les derniers projets menés, à chaque fois que j'ai mentionné les opterons je me suis fait rire au nez ou presque. Que ca soit de la part des clients ou dans ma boite, qui fait pourtant du conseil en archi et infra )

  16. #616
    Citation Envoyé par Alexko Voir le message
    Le SMT tire tout aussi bien partie d'un pipeline large que long, puisque les deux génèrent des "trous".
    OK, je reformule : ce qui m'étonne, c'est pourquoi ne pas avoir mis le SMT sur Core dès le début si le gain est si important (en limitant aux CPU serveurs éventuellement - gros cache).

    Ils en avaient pas besoin pour être les premiers.

  17. #617
    BP ram ?
    Mes propos n'engagent personne, même pas moi.

  18. #618
    Citation Envoyé par Yasko Voir le message
    OK, je reformule : ce qui m'étonne, c'est pourquoi ne pas avoir mis le SMT sur Core dès le début si le gain est si important (en limitant aux CPU serveurs éventuellement - gros cache).
    Peut-etre parce que c'est le genre de trucs que tu n'ajoutes pas en 5 minutes ?

  19. #619
    Mouais, je vais peut-être / surement dire des conneries, mais je ne pense pas que ce soit très compliqué à implémenter du SMT.
    Faut redonder des registres et en allonger certains pour y indiquer qui vient d'où, et hop ca tourne.

    Bon, en y réfléchissant 5 minutes, c'est vrai que Nehalem est le tick (ou tock, je sais jamais) suivant Core version desktop, c'est donc un peu logique que ca ne vienne que maintenant. Ils auraient peut-être pu le sortir avec Conroe direct, mais au final ce ne fut pas nécessaire (et ca aurait retardé sa sortie ?).

    C'est juste que je m'étais fait à l'idée qu'ils avaient enterré HT avec Netburst, car pour Core, cela n'apportait quasiment rien.
    Dernière modification par Yasko ; 31/03/2009 à 15h08.

  20. #620
    Meme si c'etait si simple (ce dont je doute), l'impact doit etre assez important sur les timings ; donc si c'etait fait a l'arrache les resultats seraient mauvais. Ca reclame d'etre integre dans le design depuis le debut. Enfin c'est juste mon avis.

  21. #621
    J'ai complété mon message précédent, pendant que tu rédigeais le tien.

    Citation Envoyé par newbie06 Voir le message
    Ca reclame d'etre integre dans le design depuis le debut. Enfin c'est juste mon avis.
    Ben, pour Core, j'aurais justement tendance à dire que ce n'était pas le cas.
    Intel a modifié quelques trucs sur la µarch (et la BP RAM effectivement) pour Nehalem, mais je ne sais pas/plus si ca a été fait pour introduire le SMT.

  22. #622
    Core a ete concu comme plan de sauvetage apres le "plantage" du P4. C'etait conceptuellement un Pentium-M et je parie qu'Israel n'a pas eu beaucoup de temps ni de moyens pour le faire.

    Tout ca base sur ma memoire que je sais parfois defaillante

  23. #623
    Citation Envoyé par newbie06 Voir le message
    Meme si c'etait si simple (ce dont je doute), l'impact doit etre assez important sur les timings ; donc si c'etait fait a l'arrache les resultats seraient mauvais. Ca reclame d'etre integre dans le design depuis le debut. Enfin c'est juste mon avis.
    Et plus de BP ram qu'un quad cpu (2*dual par socket) rendu octo thread n'en a...
    Mes propos n'engagent personne, même pas moi.

  24. #624
    Roooooh il a besoin de reconnaissance le Neo_13

    Je n'ai pas repondu parce que je ne sais pas du tout quel est l'impact de la BP. J'aurais plutot dit que la latence est plus importante, mais ca reste mon intuition qui me trompe souvent en design

  25. #625
    Citation Envoyé par Yasko Voir le message
    Mouais, je vais peut-être / surement dire des conneries, mais je ne pense pas que ce soit très compliqué à implémenter du SMT.
    Faut redonder des registres et en allonger certains pour y indiquer qui vient d'où, et hop ca tourne.

    Bon, en y réfléchissant 5 minutes, c'est vrai que Nehalem est le tick (ou tock, je sais jamais) suivant Core version desktop, c'est donc un peu logique que ca ne vienne que maintenant. Ils auraient peut-être pu le sortir avec Conroe direct, mais au final ce ne fut pas nécessaire (et ca aurait retardé sa sortie ?).

    C'est juste que je m'étais fait à l'idée qu'ils avaient enterré HT avec Netburst, car pour Core, cela n'apportait quasiment rien.
    Ça implique quand même pas mal de modifications au niveau du scheduling, du cache L1, etc. D'ailleurs, la "preuve" que c'est pas si simple, c'est qu'AMD ne l'a toujours pas fait. Pourtant ça leur ferait pas de mal, surtout sur les Opteron...

    Sinon, Nehalem c'est un gros changement, donc un tock.
    Penryn était un petit changement, donc un tick.
    Si ma mémoire est bonne, ce moyen mnémotechnique est © fefe.

  26. #626
    Citation Envoyé par Yasko Voir le message
    Mouais, je vais peut-être / surement dire des conneries, mais je ne pense pas que ce soit très compliqué à implémenter du SMT.
    Lol .
    Sur P4 qui avait ete concu a la base pour supporter HT, les 3/4 des bugs et de l'effort de validation ont ete consacres a HT (sachant que a peu pres les 3/4 des ressources d'un projet de microprocesseur sont dans la validation je te laisse tirer la conclusion toi meme. Je n'ai plus les liens vers la presentation, mais Intel avait donne pas mal de details sur la complexite du projet de P4 et le cauchemard que SMT representait.

    Il y a une raison pour laquelle AMD ne l'a pas. Ce ne sont pas les brevets (ils ont les droits de les utiliser) ma la complexite infernale d'une implementation efficace de SMT.

    Il faut aussi noter que l'equipe qui a fait Nehalem chez Intel est l'equipe de l'Oregon qui avait fait P4. Les autres equipes qui ont travaille sur core ont eu plus de 10 ans pour implementer SMT (si on compare a P4) et pourtant ne l'ont pas fait.

    Sinon pour conclure, le SMT est probablement "la" feature la plus complexe presente dans un microprocesseur moderne, et "la" plus difficile a implementer et valider...

    Faut redonder des registres et en allonger certains pour y indiquer qui vient d'où, et hop ca tourne.
    Oui 1 bit et 1 mux ...

    C'est juste que je m'étais fait à l'idée qu'ils avaient enterré HT avec Netburst, car pour Core, cela n'apportait quasiment rien.
    Ou alors que Core etait a l'origine un processeur pour laptops et que l'interet de SMT est assez limite dans ce domaine (et plus complique a power manage qu'un autre core).

    ---------- Post added at 16h35 ---------- Previous post was at 16h33 ----------

    Citation Envoyé par newbie06 Voir le message
    Roooooh il a besoin de reconnaissance le Neo_13

    Je n'ai pas repondu parce que je ne sais pas du tout quel est l'impact de la BP. J'aurais plutot dit que la latence est plus importante, mais ca reste mon intuition qui me trompe souvent en design

    Sur serveur, c'est generalement la BP , mais la latence de snoop des autres socket peut rapidement etre suffisament longue qu'elle te reduit la bande passante (et devient ton principal goulet d'etranglement). Tu recouvres la latence avec des threads sur les applis serveur, par contre la bande passante il n'y a pas moyen de contourner.

    Cf "little's law" pour les effets de la latence sur la bande passante.
    fefe - Dillon Y'Bon

  27. #627
    Citation Envoyé par fefe Voir le message
    Sur serveur, c'est generalement la BP , mais la latence de snoop des autres socket peut rapidement etre suffisament longue qu'elle te reduit la bande passante (et devient ton principal goulet d'etranglement). Tu recouvres la latence avec des threads sur les applis serveur, par contre la bande passante il n'y a pas moyen de contourner.

    Cf "little's law" pour les effets de la latence sur la bande passante.
    Comment je suis trop balaise, tellement c'est ce que j'avais dit, tellement j'ai toujours raison, tellement je pourrais être architecte CPU.

    Oui, je craque... c'est la crise... ya des réductions partout, sauf dans les bugs d'Excel.

    J'ai juste cru que mes 6char au milieu de votre flood* étaient passsé inapercu.

    * : plus de 3message dans le meme thread en 1journée... c'est du flood ici.
    Mes propos n'engagent personne, même pas moi.

  28. #628
    Citation Envoyé par Neo_13 Voir le message
    * : plus de 3message dans le meme thread en 1journée... c'est du flood ici.
    Ben ca faisait un moment que j'etais offline, je me rattrape
    fefe - Dillon Y'Bon

  29. #629
    Nan, mais c'était une blague à la base (et du flood, ouais !)... :se rattrape aux branches:

    Et puis, je me suis dit, boah un vieux truc des années 50, ca doit pas être si compliqué à implémenter. Même DEC et IBM ont réussi.

  30. #630
    Citation Envoyé par fefe Voir le message
    Lol .
    Sur P4 qui avait ete concu a la base pour supporter HT, les 3/4 des bugs et de l'effort de validation ont ete consacres a HT (sachant que a peu pres les 3/4 des ressources d'un projet de microprocesseur sont dans la validation je te laisse tirer la conclusion toi meme. Je n'ai plus les liens vers la presentation, mais Intel avait donne pas mal de details sur la complexite du projet de P4 et le cauchemard que SMT representait.

    Il y a une raison pour laquelle AMD ne l'a pas. Ce ne sont pas les brevets (ils ont les droits de les utiliser) ma la complexite infernale d'une implementation efficace de SMT.

    Il faut aussi noter que l'equipe qui a fait Nehalem chez Intel est l'equipe de l'Oregon qui avait fait P4. Les autres equipes qui ont travaille sur core ont eu plus de 10 ans pour implementer SMT (si on compare a P4) et pourtant ne l'ont pas fait.

    Sinon pour conclure, le SMT est probablement "la" feature la plus complexe presente dans un microprocesseur moderne, et "la" plus difficile a implementer et valider...
    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 )

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
  •