Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Affichage des résultats 1 à 30 sur 30
  1. #1
    Bon, je vais surement gueuler dans le vent parceque la vitesse d'incrementation du TSC, ca n'interesse personne, mais tant pis. Bon, pour rappel : http://www.x86-secret.com/index.php?...=newsd&nid=845 c'etait il y a 3 ans et maintenant, c'est un état de fait partout.

    Donc en codant Memtest86+ V2.00 qui sortira bientot, d'un coup, j'ai tilté sur les douzemilles rdtsc un peu partout dans le code ASM. Ben oui, mais le probleme, c'est que l'incrementation du TSC d'un Core 2 en mode EIST (qui ne fonctionne donc pas a son ratio d'origine) n'est pas conforme à sa fréquence. Donc je me retrouve avec un CPU à 2 GHz doté d'un TSC qui tourne à 3 GHz. Pour les calculs de bande passante ou de temps écoulés, ca fout tout en l'air. Pour le moment, je comble en rajoutant un ratio (coef_actuel / coef_boot) pour retomber sur les bonnes valeurs.

    Reste qu'Intel aurait tout de même pu doté ses CPU d'un cheat comme chez AMD : Sur Phenom, un MSR permet de configurer la vitesse d'incrémentation du TSC (MSRC001_0015[24]), soit variable, soit invariable, ce qui régle le problème.

    Donc, amis codeurs amateurs de précisions et de determinisme en FP, je vous pose une question simple : Connaissez-vous un MSR caché pour rentre le TSC variable ou un compteur auxilliaire chez Intel dont l'incrémentation suive réellement les cycles d'horloges du CPU ?

  2. #2
    Pas que je sache...

    A mon avis, tu vas deja devoir te taper l'abstraction du mécanisme de lecture du compteur partout dans le code, et péter la supposition sur les fréquences, mais tu seras sans doute content de l'avoir fait après.
    Si c'est de l'asm, ça sera facile de grep/replacer "RDTSC" par une macro qui fait un call qui fait ce que tu veux (ie un rescaling).
    Si c'est de l'asm inline ça risque d'être plus casse-burnes.
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  3. #3
    Citation Envoyé par Tramb Voir le message
    Pas que je sache...

    A mon avis, tu vas deja devoir te taper l'abstraction du mécanisme de lecture du compteur partout dans le code, et péter la supposition sur les fréquences, mais tu seras sans doute content de l'avoir fait après.
    Si c'est de l'asm, ça sera facile de grep/replacer "RDTSC" par une macro qui fait un call qui fait ce que tu veux (ie un rescaling).
    Si c'est de l'asm inline ça risque d'être plus casse-burnes.
    C'est de l' ASM inline... Mais en fait, je n'ai pas besoin pour le moment de trouver un autre compteur (en ASM, tout devient d'un coup nettement plus compliqué) tant que je connaitrais la vitesse d'incrémentation du TSC. Ce qui m'etonne principalement, c'est qu'Intel change le comportement d'une instruction x86 fondamentale sans donner d'autre solution de remplacement que "Utilisez les compteurs de Windows à la place" (véridique). Une solution Hardware comme l'a fait AMD serait la bienvenue. Mais je doute que ce soit prévu dans les futurs CPU

  4. #4
    D'après la réponse d'Intel mis dans ta news, il faut utiliser les compteurs PMON, pas TSC

    "To count processor core clocks or to calculate the average processor frequency Intel recommends using the PMON counters Monitoring data from the event counters over the period of time for which the average frequency is required. See PRM Volume 3 Chapter 15 Debugging and Performance Measuring,Section 15.10.9 and Appendix A Performance Monitoring Events for details on the Global_Power_Events, event. "

    Edit :
    C'est les compteurs Windows dont tu parles, les PMON ?

  5. #5
    Citation Envoyé par Yasko Voir le message
    D'après la réponse d'Intel mis dans ta news, il faut utiliser les compteurs PMON, pas TSC

    "To count processor core clocks or to calculate the average processor frequency Intel recommends using the PMON counters Monitoring data from the event counters over the period of time for which the average frequency is required. See PRM Volume 3 Chapter 15 Debugging and Performance Measuring,Section 15.10.9 and Appendix A Performance Monitoring Events for details on the Global_Power_Events, event. "
    Ouai mais alors les PMON, c'est bien beau, mais chaque instruction doit mettre 1000x plus de cycles à s'executer qu'un simple rdtsc, de quoi fausser la mesure du temps

  6. #6
    Je te trouves ca demain. Dans mes souvenirs depuis Yonah c'est core_clock_unhalted ou qq chose comme ca qu'il faut utiliser dans ces conditions.
    fefe - Dillon Y'Bon

  7. #7
    Citation Envoyé par fefe Voir le message
    Je te trouves ca demain. Dans mes souvenirs depuis Yonah c'est core_clock_unhalted ou qq chose comme ca qu'il faut utiliser dans ces conditions.
    CPU_CLK_UNHALTED.CORE
    C'est de ce compteur que se sert VTune en tout cas.
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  8. #8
    Ben oui, mais reste que c'est un PMON et que c'est super lent à poller.

    Comparez le nombre de cycles d'un rdtsc par rapport à un rdmsr, vous allez rire

  9. #9
    Citation Envoyé par Doc TB Voir le message
    Ben oui, mais reste que c'est un PMON et que c'est super lent à poller.

    Comparez le nombre de cycles d'un rdtsc par rapport à un rdmsr, vous allez rire
    Yep yep je sais bien, mais à part:
    1) passer en PMON et changer la granularité de tes appels...
    2) corriger tous tes RDTSC

    Je vois pas trop de solution madgique...
    Sleeping all day, sitting up all night
    Poncing fags that's all right
    We're on the dole and we're proud of it
    We're ready for 5 More Years

  10. #10
    Citation Envoyé par Doc TB Voir le message
    Pour le moment, je comble en rajoutant un ratio (coef_actuel / coef_boot) pour retomber sur les bonnes valeurs.
    Et ça marche bien ? Comment tu détectes le coef de boot ?
    J'ai déjà eu des pb de mesure de fréquence sur des CPU en coef 9 qui étaient OC en 8*400 mais mesurés à 3.6GHz (en utilisant le RDTSC), comme s'ils étaient en coef 9.
    Le ratio ne devrait-il pas être (coef_actuel / coef_origine) ?

  11. #11
    coef_boot ou coef_origine, c'est pareil.

    Sinon, ben je detecte avec de l'extreme MSR trick

    Code:
    ulong correct_tsc(ulong el_org)
    {
        
        float coef_now, coef_max;
        int msr_lo, msr_hi, is_xe;
        
        rdmsr(0x198, msr_lo, msr_hi);
        is_xe = (msr_lo >> 31) & 0x1;        
        
        if(is_xe){
            rdmsr(0x198, msr_lo, msr_hi);
            coef_max = ((msr_hi >> 8) & 0x1F);    
            if ((msr_hi >> 14) & 0x1) { coef_max = coef_max + 0.5f; }
        } else {
            rdmsr(0x17, msr_lo, msr_hi);
            coef_max = ((msr_lo >> 8) & 0x1F);
            if ((msr_lo >> 14) & 0x1) { coef_max = coef_max + 0.5f; }
        }
        
        if((cpu_id.feature_flag >> 7) & 1) {
            rdmsr(0x198, msr_lo, msr_hi);
            coef_now = ((msr_lo >> 8) & 0x1F);
            if ((msr_lo >> 14) & 0x1) { coef_now = coef_now + 0.5f; }
        } else {
            rdmsr(0x2A, msr_lo, msr_hi);
            coef_now = (msr_lo >> 22) & 0x1F;
        }
            
        if(coef_max && coef_now) { el_org = (ulong)(el_org * coef_now / coef_max); }
        
        return el_org;
    
    }

  12. #12
    Et sinon il n'y pas moyen de désactiver SpeedStep pendant le test ? J'ai lu qu'on pouvait régler ça dans les options d'alimentation de Windows, c'est vrai ?
    Citation Envoyé par Wanou Voir le message
    Je t'aime...
    :wq

  13. #13
    pmon c'est pas immédiat, faut configurer un compteur (enfin c'est pas non plus ULTRA compliqué).

    Pourquoi ne pas utiliser le MSR APERF (0xE8) ?

    Citation Envoyé par DaP Voir le message
    Et sinon il n'y pas moyen de désactiver SpeedStep pendant le test ? J'ai lu qu'on pouvait régler ça dans les options d'alimentation de Windows, c'est vrai ?
    y'a un bit lock sur les derniers processeurs intel, càd que le bit qui permet d'activer/désactiver l'EIST est protégé par un bit WO.
    C1E reste débrayable à chaud cependant, mais ça résoud que partiellement le pb
    Dernière modification par Franck@x86 ; 29/01/2008 à 19h53. Motif: Fusion automatique

  14. #14
    Citation Envoyé par Franck@x86 Voir le message
    pmon c'est pas immédiat, faut configurer un compteur (enfin c'est pas non plus ULTRA compliqué).

    Pourquoi ne pas utiliser le MSR APERF (0xE8) ?
    Parceque rdmsr, c'est 1000 cycles et que ca fout la merde sur un compteur précis :-/

  15. #15
    Citation Envoyé par Doc TB Voir le message
    coef_boot ou coef_origine, c'est pareil.

    Sinon, ben je detecte avec de l'extreme MSR trick
    Ha ok, c'est le coef_max, je comprend mieux. Et cette méthode ne te convient pas ? Pas fiable à 100% ?

  16. #16
    Citation Envoyé par Doc TB Voir le message
    Parceque rdmsr, c'est 1000 cycles et que ca fout la merde sur un compteur précis :-/
    Ca déconne si tu bases ta mesure sur un temps d'attente donné, mais c'est pas la bonne méthode. Faut te servir d'une méthode différentielle :

    - Mesure MSR #1
    - Mesure ref timer #1
    - wait some ms
    - Mesure MSR #2
    - Mesure ref timer #2

    Même si la mesure MSR prend une plombe, la mesure du ref timer est toujours effectuée juste après que la mesure MSR sorte son résultat, tu as donc une lecture pratiquement simultanée des deux compteurs (et même si elle ne l'est pas, l'écart est le même entre les mesures #1 et #2, et il s'annule donc lors de la différence ref2-ref1). Tu t'affranchis donc complètement du temps de mesure du compteur.
    Dernière modification par Franck@x86 ; 29/01/2008 à 21h10.

  17. #17
    Citation Envoyé par Doc TB Voir le message
    Parceque rdmsr, c'est 1000 cycles et que ca fout la merde sur un compteur précis :-/
    Ben, tu peux déja virer celui là
    if(is_xe){rdmsr(0x198, msr_lo, msr_hi);

    Tu as déja dans msr_lo et msr_hi le contenu du MSR#0x198.

  18. #18
    RDPMC et RDTSC ont une latence similaire (meme ordre de grandeur) sur Merom (Yonah aussi dans mes souvenirs, mais pas garanti), et tu peux acceder le compteur en question avec rdpmc une fois que tu as programme tes compteurs. Ca evite d'avoir a faire des rdmsr et en theorie tes perfs devraient rester similaires.

    RDPMC contrairement a RDMSR ne force pas de serialisation et devrait prendre une 20aine de cycles. Et sinon pour lire un MSR c'est plus de l'ordre de la 100 aine de cycles sur Merom que du millier, mais je ne retrouve plus mes sources exactes.
    Dernière modification par fefe ; 30/01/2008 à 15h49.
    fefe - Dillon Y'Bon

  19. #19
    Alors Doc, ca donne quoi ?
    fefe - Dillon Y'Bon

  20. #20
    Citation Envoyé par fefe Voir le message
    Alors Doc, ca donne quoi ?
    Ca donne que pour utiliser autre chose que rdtsc, je dois coder de l'ASM pour detecter si pmon est dispo sur le CPU avant puis configurer et que ca complique grave les choses face à un rdtsc supporté par tout les procs depuis la nuit des temps :x Je vais faire le vieux qui radote, mais ce serait qd meme NETTEMENT plus simple qu'un MSR permette de spécifier le mode d'incrémentation du TSC comme chez AMD. Pourquoi Intel fait pas ça pour les pauvres developeurs low-level ?

  21. #21
    Sauf que RDPM est 2 a 3x plus rapide qu'un RDTSC, donc ta mesure de temps n'en est que plus precise. Sinon je comprends que ca demande du code en plus et que ca ne vaille pas necessairement le coup.

    Pour le MSR, vu qu'il est possible de mesurer le temps des 2 manieres (1 avec PM et l'autre avec TSC) , ce n'est pas la peine d'esperer . Mais tu as le droit de raler .
    fefe - Dillon Y'Bon

  22. #22
    Je me permet de remonter ce topic pour demander au Doc à quoi correspond le :
    if((cpu_id.feature_flag >> 7) & 1)
    Merci

  23. #23
    Je suis joueur, alors je parie que c'est le bit EST (Table 3-5 http://www.intel.com/Assets/PDF/appnote/241618.pdf)

  24. #24
    Pas bête

    edit: d'ailleurs la version de novembre 2008 est dispo :
    http://download.intel.com/design/pro.../241618033.pdf
    Dernière modification par Foudge ; 22/11/2008 à 23h18.

  25. #25
    Citation Envoyé par Foudge Voir le message
    edit: d'ailleurs la version de novembre 2008 est dispo :
    http://download.intel.com/design/pro.../241618033.pdf
    Il est vraiment pourri le site Intel : la réf que j'avais donnée était issue d'une recherche avec leur moteur

  26. #26
    Citation Envoyé par Foudge Voir le message
    Je me permet de remonter ce topic pour demander au Doc à quoi correspond le :
    if((cpu_id.feature_flag >> 7) & 1)
    Merci
    Faut qd meme donner un peu plus de code et/ou dire de quel fichier ca vient pour que je puisse te répondre

  27. #27
    Dans un post à toi, publié sur ce topic le 29/01/2008 à 18h16

  28. #28
    Citation Envoyé par Doc TB Voir le message
    Sur Phenom, un MSR permet de configurer la vitesse d'incrémentation du TSC (MSRC001_0015[24]), soit variable, soit invariable, ce qui régle le problème.
    J'ai un cas où le Phenom boot à 3GHz (15*200) et passe, sous Windows grâce à un logiciel d'OC, à 3.1GHz (15.5*200). C'est un Phenom 9950 BE (donc coef débloqué). Mais malgré cette manip, je mesure toujours la fréquence à 3GHz.
    J'ai bien vérifié après relecture, le bit 24 (TscFreqSel) est bien passé à 1, donc mon wrmsr a apparemment bien fonctionné. Il y a quelque chose à faire juste après ça, pour que ce soit effectif ?
    La doc d'AMD n'en dit pas plus.

  29. #29
    Normal, c'est un bit Write-Once. Une fois que tu l'a positionné (et ton BIOS l'a fait), tu ne peux plus le changer aprés.

    "Changing the state of this bit after setting it results in undefined behaviour from the TSC."

  30. #30
    Ok, donc pour mesurer la fréquence d'un Phenom avec le TSC, c'est mort. Là je regarde comment on peut faire pour "corriger" la mesure (de la même manière que sur les C2D/C2Q) mais je n'arrive qu'à récupérer le coef réel (MSRC001_0071), mais pas le coef de boot.
    En plus de ça, avec les versions BE, je me demande si je suis pas tombé sur un fonctionnement un peu particulier (pour l'histoire des coef). Faut que je trouve un gars avec un Phenom classique pour voir comment ça se passe.

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
  •