"Vu qu'on fait varier la fréquence et le voltage a la baisse dans le cas de la conso dynamique, on n'est pas loin d'avoir un f3 pour la consomation en premiere approximation."
Pour la puissance instantané, pas pour la consommation d'une tache, qui est multiplié par le temps pour l’exécuter. Ce temps augmente avec la baisse de la fréquence. Si on baisse une fréquence sans baisser la tension, cela ne sert à rien. Les OMAP sont équipé d'un système de retroaction qui mesure la vitesse de la puce (vitesse d'un anneau d'inverseur) et adapte la tension en fonction.
"Sur un terminal mobile qui passe son temps en veille, oui, la consomation statique est le probleme important."
Non pas du tout. En veille, 99% de la puce est coupé. Il reste juste le domaine de réveil(wakeup domain), qui est alimenté avec une horloge à 32khz. Quand je parle de conso statique, je parle de fuite de courant de bloc allumé (power domain). Ces fuites sont proportionnelles à la surface de la zone et à la tension, indépendamment de la fréquence de l'horloge.
" Pour ca, il est certain qu'il faut baisser la conso statique, mais ca le soft n'y peut rien. C'est du a la techno utilise et tu n'as pas d'optimisation pour."
Si tu peux, avec le "race to idle", et la gestion correct des latences de réveil (cf les arrondis des compteurs de Linux pour grouper les réveils). Il y a aussi la gestion correct des états des périphériques, souvent si un driver est utilisé, son bloc n'est jamais complètement coupé de peur de perdre son état. Le fait d'adapter la fréquence entre bus mémoire et cpu, permet aussi de baisser la tension qui a un effet sur la consommation statique.
Souvent la combinaison des systèmes de gestion d'énergie est tellement compliqué (on parle de >100 blocs dans des power domain différent, avec des clock domain différent, et des dépendances gérés plus ou moins automatiquement), que le plus simple est encore de gérer des "modes" d'usage, pour passer de l'un à l'autre, et optimiser à mort leur configuration. C'est beaucoup plus simple que d'essayer de faire du code intelligent qui s'adapte à tous les cas (en plus un code qui tourne, c'est un cpu allumé, un bus mémoire, une mémoire, etc...).
[^] # Re: Mouais
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Kalray un processeur massivement parallèle très impressionnant : Qu’il est loin le temps de mon ZX81. Évalué à 4.
"Vu qu'on fait varier la fréquence et le voltage a la baisse dans le cas de la conso dynamique, on n'est pas loin d'avoir un f3 pour la consomation en premiere approximation."
Pour la puissance instantané, pas pour la consommation d'une tache, qui est multiplié par le temps pour l’exécuter. Ce temps augmente avec la baisse de la fréquence. Si on baisse une fréquence sans baisser la tension, cela ne sert à rien. Les OMAP sont équipé d'un système de retroaction qui mesure la vitesse de la puce (vitesse d'un anneau d'inverseur) et adapte la tension en fonction.
"Sur un terminal mobile qui passe son temps en veille, oui, la consomation statique est le probleme important."
Non pas du tout. En veille, 99% de la puce est coupé. Il reste juste le domaine de réveil(wakeup domain), qui est alimenté avec une horloge à 32khz. Quand je parle de conso statique, je parle de fuite de courant de bloc allumé (power domain). Ces fuites sont proportionnelles à la surface de la zone et à la tension, indépendamment de la fréquence de l'horloge.
" Pour ca, il est certain qu'il faut baisser la conso statique, mais ca le soft n'y peut rien. C'est du a la techno utilise et tu n'as pas d'optimisation pour."
Si tu peux, avec le "race to idle", et la gestion correct des latences de réveil (cf les arrondis des compteurs de Linux pour grouper les réveils). Il y a aussi la gestion correct des états des périphériques, souvent si un driver est utilisé, son bloc n'est jamais complètement coupé de peur de perdre son état. Le fait d'adapter la fréquence entre bus mémoire et cpu, permet aussi de baisser la tension qui a un effet sur la consommation statique.
Souvent la combinaison des systèmes de gestion d'énergie est tellement compliqué (on parle de >100 blocs dans des power domain différent, avec des clock domain différent, et des dépendances gérés plus ou moins automatiquement), que le plus simple est encore de gérer des "modes" d'usage, pour passer de l'un à l'autre, et optimiser à mort leur configuration. C'est beaucoup plus simple que d'essayer de faire du code intelligent qui s'adapte à tous les cas (en plus un code qui tourne, c'est un cpu allumé, un bus mémoire, une mémoire, etc...).
"La première sécurité est la liberté"