Translate In English / Traduire en Anglais

L'histoire dont nous allons vous parler ici a demandé plusieurs semaines, si ce n'est mois, d'investigations et est extrêmement importante du point de vue de l'architecture interne d'un microprocesseur. Pour mieux comprendre de quoi il s'agit ainsi que les conséquences directes et indirectes, nous allons tenter de vous expliquer toutes les données d'une manière simple. Pour commencer, voyons exactement en quoi consiste le principal intéressé, c'est à dire le TSC, ou Time Stamp Counter.

Introduit par Intel dans le Pentium, première édition, le Time Stamp Counter répondait directement à une problématique de l'époque : Mesurer le nombre de cycle CPU à un moment t. Pour ce faire, Intel a donc créé le TSC qui est, comme son nom l'indique, un compteur de cycles permettant de mesure la frequence du CPU. C'est d'ailleurs la méthode préconisée par Intel comme on peut le lire ici. Accessible par le biais d'un simple registre ou lisible par le biais d'une instruction, RDTSC (ReaD Time Stamp Counter), son fonctionnement est très simple : Réinitialisé à 0 au démarrage, le compteur s'incrémente de 1 à chaque cycle du processeur. Ainsi, vous l'aurez compris, un Pentium 200 MHz incrémentera son TSC de 200 millions à chaque seconde alors qu'un Pentium 4 3.8 GHz l'incrémentera de 3.8 milliards par secondes. Grâce à la taille de son registre de 64 bits, il faudrait quasiment 150 ans pour qu'un Pentium 4 4 GHz reviennent à 0. Bref, le Time Stamp Counter est un compteur de cycle CPU.

Utilisé par énormément de programmes, le TSC sert à plusieurs choses. Premièrement, à mesurer la fréquence d'un microprocesseur. Pour la connaître, rien de plus simple, il suffit de faire un RDTSC, de noter la valeur, d'attendre 1 seconde, de refaire un RDTSC, de d'effectuer la soustraction entre la seconde valeur et la première pour obtenir le nombre de cycle écoulé en une seconde, donc, la fréquence du CPU. On peut ainsi mesurer le TSC d'un CPU Mobile, par exemple, en mode EIST pour savoir a quelle fréquence il est actuellement. Ensuite, le Time Stamp Counter sert pour des tests de performances. Il peut servir à connaître le nombre de cycle nécessaire pour effectuer tel ou tel calcul, mais aussi, et c'est le principal, pour une bonne partie des benchmarks que nous connaissons. En effet, la mesure de base consiste en l'opération suivante : FLOPS = (Nombre d'opérations effectuées) / (Temps mis pour les effectuer). Le dividende étant logiquement fourni par le TSC et le diviseur par l'horloge du PC. C'est généralement ainsi qu'on mesure une performance.

Bref, tout allait pour le mieux dans le meilleur des mondes puisque cette règle immuable est utilisée par beaucoup de développeurs et est, au fil du temps, devenue une fonction indispensable et capitale de tous les CPUs du marché. Or voila, Intel vient de contrarier gravement cet équilibre, et ce, dans le plus total secret puisque le géant de Santa Clara a non seulement profondément modifié le fonctionnement du TSC dans les derniers steppings du Pentium 4, mais pire, n'a pas daigné modifier ces datasheets pour refléter ces changements profonds. Or, la modification du comportement du Time Stamp Counter est tellement importante qu'elle risque de tout simplement FAUSSER les logiciels qui l'utilisent.

Expliquons nous. Depuis le Stepping F41 du Prescott, les Pentium 4 se sont dotés d'un mode de fonctionnement visant à réduire l'énergie consommée, le mode C1E. Ce mode, très pratique, permet de diminuer dynamiquement le coefficient multiplicateur à 14x lorsque le CPU est en idle. Ensuite, la série 6xx, lancée récemment, a introduit l'EIST, qui permet lui, toujours de faire baisser dynamiquement le coefficient multiplicateur, mais cette fois par palier et en incluant également une diminution du voltage. C'est a ce moment que les ennuis ont commencés pour tout les programmes utilisant le Time Stamp Counter. En effet, on a commencé à voir des aberrations inconnues sur les programmes de détections comme celles-ci :

Voici, par exemple, un Pentium 4 630 fonctionnant en mode BIOS par défaut, sur un OS fraîchement installé. Nous avons utilisé une ancienne version de CPU-Z, la 1.26.3, ainsi que Sandra 2005 et la dernière version de Crystal CPUID, la 4.3.8.240. Etrangement, tous ces logiciels semblent détecter correctement la fréquence (3.0 GHz), mais affiche un FSB de 215 MHz et un coefficient de 14x alors que ceux-ci fonctionnent a 200 MHz et 15x. Un bug très étrange. Pour ces trois logiciels, ces valeurs (Fréquence CPU, Cœfficient multiplicateur et FSB) sont calculées de la manière suivante :

• La fréquence CPU est mesurée via le TSC
• Le coefficient multiplicateur se trouve dans un registre du processeur
• Le FSB est calculé avec fréquence / coeff.

Pourtant, les valeurs obtenues ici sont manifestement fausses. Le problème vient donc soit du calcul par TSC, soit du multiplicateur, qui peut difficilement être faux puisque la valeur est lue directement dans un MSR. Franck a donc cherché une autre méthode pour mesurer la fréquence du CPU sans passer par le TSC et y est parvenu. Ainsi, voyons le résultat sous cette même configuration, mais sous CPU-Z 1.27 :

Miracle ! La fréquence n'est cette fois plus que 2.8 GHz et le FSB correspond bien à la réalité, les valeurs relevées sont bien celles de fonctionnement du CPU, en effet, le Pentium 4 630 était ici en mode C1E (ou en mode EIST 14x) et sa fréquence n'était que de 2.8 GHz. La question est donc : Pourquoi tous les logiciels de détection basé sur TSC renvoyaient-ils 3.0 GHz, comme si le CPU fonctionnait à sa fréquence maximale alors que ce n'était pas le cas ? Pour une raison simple, et c'est la que le pot au rose est découvert : Parce qu'Intel a gravement modifié le comportement du TSC dans ces CPUs et que celui-ci est maintenant désynchronisé de la fréquence réelle de fonctionnement ! Dans notre exemple, alors que le CPU ne tournait qu'a 2.8 GHz, le TSC continuait de s'incrémenter à la fréquence de 3 milliards par seconde, comme si il tournait à 3 GHz. Afin de mettre en évidence ce "problème", qui survient lorsque un P4J 5xx est en mode C1E ou d'un P4 6xx est en mode C1E ou EIST, Franck nous a écrit une petite application qui indique simultanément le calcul effectué par les deux méthodes :

On le voit ici très bien, le TSC continue de tourner à sa fréquence maximale alors que le CPU ne tourne plus a cette fréquence, ceci faussant les logiciels de détection qui récupèrent une valeur via TSC qui ne correspond pas à la réalité. Problème majeur, comme nous le disions plus haut, certains benchmarks utilisent le TSC pour fonctionner et sont donc susceptible d'être faussé lorsque le CPU est en mode C1E ou EIST, mode qui n'est pas toujours sous contrôle direct de l'utilisateur. Un exemple représentatif est le résultat du test de Latence du cache L2 inclus dans ScienceMark 2 :

Ce test, en toute logique, ne devrait pas évoluer avec la fréquence puisque la latence du cache est une donnée architecturelle indépendant de la fréquence. Ainsi, un P4 6xx à 2.8 GHz et un P4 6xx 3.6 GHz obtiennent une latence identique. Par contre, lorsque le TSC tourne à 3.6 GHz avec un CPU à 2.8 GHz (EIST minimum), le benchmark perd les pédales et affiche une erreur. Un cas susceptible de se reproduire dans de nombreux autres tests.

Bref, il apparaît donc que, sur les Prescott F4x, le TSC utilise toujours le coefficient multiplicateur défini au boot de la machine, et reste ensuite désynchronisé de la fréquence réelle du CPU, affectée par C1E ou EIST. Vu ce changement important et inédit que cette modification architecturale apporte, nous avons tenté d'en savoir plus. Malheureusement, comme souvent chez Intel, nous nous sommes heurtés, dans un premier temps, à un mur. Insistant sur le fait que le comportement du TSC, tel qu'il était constaté, dérivait gravement des spécifications du processeurs tels qu'on pouvait les trouver dans la documentations, nous pouvons donc qualifié ce trouble d'Errata ou de bug. Que ce "bug" soit voulu ne fait toutefois aucun doute. Le TSC est trop important pour que son fonctionnement ne soit pas soigneusement vérifié.

Bref, nous avons décidé de poster sur un des forums dédiés au support des développeurs d'Intel. En effet, ce problème consiste un processeur en vente actuellement, qui ne respecte pas les spécifications définies. Bref, à la question, toujours visible sur ce thread du site d'Intel, Intel s'est borné à répondre : "The answer to this includes Intel confidential information, so we are unable to post the resolution to this board.". Il est ainsi totalement inadmissible qu'Intel ne daigne par répondre à un problème concernant une fonctionnalité documentée d'un processeur en vente depuis plusieurs mois ! Cette réponse montre clairement qu'Intel ne souhaite pas communiquer sur cet errata et a donc, visiblement, quelque chose de non avouable à cacher.

Pour cette raison, nous avons tenté d'émettre des hypothèses sur le pourquoi d'une telle modification qui, mettre si ce n'est pas son but, semble bien apte à cacher la fréquence réelle de fonctionnement d'un CPU.

1. Influencer volontairement les benchmarks : C'est peu probable. En effet, bien que le P4J soit en vente depuis plusieurs mois, le pot au rose aurait bien finit être découvert un jour ou l'autre. Et l'intérêt d'Intel n'est clairement pas qu'un scandale éclate sur un tel point. De plus, le problème n'apparaît que lorsque le mode EIST est forcé. Le bug en mode C1E n'apparaît qu'en idle, c'est a dire, hors charge CPU, dont hors benchmarks.
   
   
2. Cacher la fréquence réelle du CPU : Beaucoup plus plausible. En effet, il est assez peu élogieux d'un point de vue "marketing" qu'un utilisateur venant d'acheter un P4 570J à 3.8 GHz lance CPU-Z et trouve 2.8 GHz parce que CPU-Z n'a pas une charge CPU assez importante pour que le mode C1E passe de idle (14x) à full-load (19x). De même, Intel ayant depuis peu opéré un revirement à 180 degré concernant la fréquence CPU, il est assez commode qu'on ne puisse plus la définir clairement.
   
   
3. Limitation de l'overclocking : Intel dispose maintenant d'une horloge et d'un compteur qui peut fonctionner de manière totalement désynchronisée de la fréquence réelle du CPU. Il est donc maintenant très simple de comparer la fréquence réelle avec celle-ci et de bloquer le CPU si un écart de plus de x % est détecté.
   
   
4. Adaptation technique pour le Dual Core : On le sait déjà, les deux cores du futur Smithfield pourront fonctionner à des fréquences différentes. Dans ce cas, l'utilisation du TSC pourrait poser problème puisqu'un même CPU physique pourrait renvoyer deux compteurs fonctionnant à des fréquences différentes. Intel aurait ainsi pu choisir de fixer le TSC pour les deux. Toutefois, pourquoi l'avoir activé sur un single core ?

Quoi qu'il en soit, aucune de ces hypothèses ne peut expliquer pour quelle raison Intel n'a pas souhaité s'exprimer plus tôt ni mettre à jour ses datasheets sur une différence d'une telle ampleur. Le sentiment qu'Intel a quelque chose à cacher semble ici de plus en plus plausible. Il n'est en effet pas concevable qu'une modification d'une telle ampleur pour les développeurs ne soit pas documentée.

Voici donc nos impressions, que nous avons écrites sans avoir eu de réponse d’Intel. Ces derniers, après nous avoir promis une explication, ont finalement répondu partiellement :

---------------
The current PRM does not include a complete description for the latest Intel(r) Pentium(r) 4 Processor TSC operation. Intel is currently working on a clarification of the Programmers Reference Manual (PRM) in relation to, but not inclusive of, the following points.

For Intel(r) Pentium(r) 4 Processors with CPUID (Family, Model, Stepping) greater than 0xF30 the designed implementation of the TSC is for the counter to operate at a constant rate. This was implemented due to a request from Operating System Software vendor(s). That rate may be set by the maximum core-clock to bus-clock ratio of the processor or may be set by the frequency at which the processor is booted. The specific processor configuration will determine the exact behavior.

This constant TSC behavior ensures that the duration of each clock tick is uniform and supports the use of the TSC as a high resolution wall clock timer even while the processor core may change frequency. The use of the TSC as a wall clock timer has effectively been prioritized over other uses of the TSC. This is the architectural behavior for the TSC moving forward.

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.
---------------

Bref, Intel admet la modification du TSC sur toute la gamme Prescott et va maintenant modifier la documentation, qui ne reflète pas actuellement le comportement du TSC. Il est toutefois plus qu'étrange qu'une société comme Intel ne s'y prenne qu'un an après la sortie du CPU pour modifier sa documentation, surtout vu l'ampleur du changement. Intel rejette également la responsabilité de cette modification sur les vendeurs d'OS (Comprenez Microsoft, on voit mal qui d'autre aurait un droit de regard sur les CPUs Intel). C'est commode et impossible à vérifier. Le pourquoi reste encore totalement dans l'ombre...