Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Affichage des résultats 1 à 9 sur 9
  1. #1
    Bonjour
    J'aimerais savoir s'il est normal que mon overclocking de mon chipset Ati rs480M, soit limité à 229 de fsb avec clockgen? Le seul PLL qui autorise l'augmentation du FSB est le 951412, les autres me donnent les bonnes fréquences mais ne me permet pas de les modifier( les 9514XX). J'ajoute que je n'ai pas de reboot, pas de feeze mais juste un overclock limité. J'aimerais juste pousser le FSB à 240, histoire de booster la mémoire que j'ai désynchronisée. De plus, même en baissant le HT à 600 cela n'a rien changé.
    Ma config/
    Chipset Ati rs 480M
    RAM c 2700 1Go( désynchro mais repassé à 166mhz)
    Processeur: Turion ML 28 poussé à 1,83 GHz 1,1 volts( 1,6 ghz d'origine et 1,4v)
    C'est un portable donc j'ai baissé le voltage pour perdre en température et il chauffe moins qu'a l'origine.

  2. #2
    Quel est le modèle du portable? Le GPU est intégré ou pas?

    De mémoire l'ICS 951412 ne permet pas de désynchroniser les horloges reférence ("FSB"), PCI et PCIe, donc tu es peut-être limité par un périphérique PCI. Ou alors c'est simplement la tension du RS480M qui n'est pas suffisante pour un overclock supérieur.

    En tout cas tu t'en sors déjà mieux que moi :
    http://forum.x86-secret.com/showthread.php?t=4324

  3. #3
    Oui en effet mon GPU est intégré à la CM, mais je peux enlever l'overclock du PCI et de l'AGP, pas de problème. Mais j'ai essayé aussi en laissant le voltage d'origine mais je reste limité même dans ce cas de figure. J'avais cru lire qu'au dessus de 230 de FSB le système devenait instable, peut-être est-ce un garde-fou de clockgen?
    En revanche je suis allé sur ton topic précédent, je ne comprends pas grand chose au liens IDT!!

  4. #4
    Citation Envoyé par krajlevic
    Oui en effet mon GPU est intégré à la CM, mais je peux enlever l'overclock du PCI et de l'AGP, pas de problème. Mais j'ai essayé aussi en laissant le voltage d'origine mais je reste limité même dans ce cas de figure. J'avais cru lire qu'au dessus de 230 de FSB le système devenait instable, peut-être est-ce un garde-fou de clockgen?
    En revanche je suis allé sur ton topic précédent, je ne comprends pas grand chose au liens IDT!!
    Faut dire que dans mon cas il fallait en plus que je programme un Clockgen pour Linux en même temps :D

    Sinon ICS a été racheté par IDT depuis, donc les liens sont devenus http://www.idt.com/products/getDoc.cfm?docID=11435786
    pour la 951412 et http://www.idt.com/products/getDoc.cfm?docID=2537808 pour la 951416.

    La partie intéressante dans la doc de la 951412 est les tableaux page 6 et 7. On voit que la PLL ne supporte qu'un nombre limité de modes prédéfinis. Et que à part pour les modes d'underclock, la fréquence PCI est liée à la fréquence CPU.
    Et surtout que, oh tiens, la fréquence maxi est 229,43MHz.

    Donc oui, c'est normal que tu ne puisse pas overclocker plus, c'est la PLL qui limite (si c'est une ICS 951412).

    Sinon la 951416, tout en restant compatible avec la 951412, permet de programmer à la main les multiplicateurs et diviseurs, donc n'a pas ces limitations-là.

    Tout espoir n'est pas perdu, il reste à déterminer le modèle exact de ta PLL.
    Tu peux poster ici un dump de ses registres (dans Clockgen, PLL Setup, mettre "Non specified" et faire Read Clocks)?
    Chez ICS, les 2 derniers chiffres du modèle (12, 16...) sont stockés dans l'octet 06.

  5. #5
    Bon et bien déjà merci pour les infos. Par contre changer le coeff multiplicateur est impossible sur mon turion je crois bien donc mon aventure d'oc s'arrête là. Je te mets le dump de clockgen et en effet c'est bien le 941512( le seul fonctionnant de toutes façons)
    Code:
    00 01 02 03 04 05 06 07 08 09 0A
    00 D1 FF 00 FC 00 10 12 01 15 07 80
    0B CD B7 FA 36 CD 3C EB 2F 49 88
    Bon c'est décalé et je n'arrive pas à remettre les colonnes alignées.
    En revanche quand tu parles de programmer à la main c'est les valeurs du dump?

  6. #6
    Citation Envoyé par krajlevic
    Bon et bien déjà merci pour les infos. Par contre changer le coeff multiplicateur est impossible sur mon turion je crois bien donc mon aventure d'oc s'arrête là. Je te mets le dump de clockgen et en effet c'est bien le 941512( le seul fonctionnant de toutes façons)
    Effectivement. Bon, 229MHz c'est toujours ça. Ne te plains pas, moi je suis toujours à 200

    Bon c'est décalé et je n'arrive pas à remettre les colonnes alignées.
    Merci Lissyx, on dit :jap:

    En revanche quand tu parles de programmer à la main c'est les valeurs du dump?
    Non, j'aurais du dire programmer tout court. C'est juste que sur la 951416 on a le choix entre soit choisir un mode prédéfini, soit définir chaque diviseur indépendamment. J'imagine que c'est ce que ferait ClockGen, mais il détecte d'une manière ou d'une autre que ce n'est pas la bonne PLL et t'empêche de changer les réglages plutôt que de risquer un crash.

  7. #7
    Moi ça m'intéresse un ClockGen pour linux

  8. #8
    Ok, en tout cas merci bien, cela m'évitera de me creuser les méninges pour grappiller quelques Mhz que je n'aurais pas de toutes façons...Mais c'est vrai que c'est déjà pas mal, en plus je monte le chip graphique à 380 Mhz...mais je ne vois pas grande différence à part dans les benchs synthétiques mais pas dans les jeux.
    Oui des fois je boot sous ubuntu et un logiciel d'oc serait le bienvenu.
    Et merci Lissyx...

  9. #9
    Citation Envoyé par Lissyx
    Moi ça m'intéresse un ClockGen pour linux
    En fait ça serait nettement plus simple à faire qu'un ClockGen pour Windows. Grâce à lm-sensors, toute l'infrastructure permettant d'accéder au bus I²C est déjà en place. Reste le plus facile, écrire dans les registres des PLL.
    Je vois 2 façons de faire :

    - crade : écrire un petit programme en userlevel comme ClockGen qui fasse appel directement à la couche I²C (en s'inspirant de i2cdump et i2cset par exemple).

    - moins crade : écrire un module noyau par PLL ou famille de PLL, qui crée une entrée dans /sys/bus/i2c/devices/0-0069. Écrire ensuite les outils en userlevel pour détecter les PLL et y accéder (comme sensors-detect, sensors et compagnie).
    D'ailleurs autrefois il y avait un module nommé icspll dans lm-sensors avec une ébauche d'implémentation, mais il a été éliminé vers le début des kernels 2.6 parce que plus maintenu et vaguement dangereux.

    Mais ce que je ne comprenais pas il y a un an et que je ne comprends toujours pas, c'est qu'est-ce qu'il faut faire de plus que d'écrire la nouvelle fréquence dans le registre kivabien pour que ça ne plante pas.
    J'imagine qu'il faut laisser le temps à la PLL de se stabiliser, ou qu'il faut prévenir le chipset d'un changement de fréquence?

    En tout cas quand j'utilise juste i2cset pour programmer la PLL, la machine crashe. Même chose quand je change les timings/fréquence du contrôleur mémoire en écrivant directement dans les registres PCI, d'ailleurs. J'ai l'impression que j'oublie quelque chose mais je ne sais pas quoi...

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
  •