[Thread Ufficiale] Aspettando Bulldozer *leggere prima pagina con attenzione*

[paolo.oliva2]

Originariamente inviato da bjt2

Interessante post di JF-AMD su semiaccurate...

http://www.semiaccurate.com/forums/s...0&postcount=37



Cosa vuol dire? In sostanza il nuovo turbo core aumenta deterministicamente la frequenza in base alla potenza stimata, perchè tanto c'è il CoolSpeed a guardia della temperatura... Questo mette un po' ordine alle varie ipotesi che avevamo fatto in passato... Ovviamente il Turbo alla INTEL è meglio per le prestazioni, ma 1) JF-AMD non lo ammetterà mai e 2) in ogni caso più sali di clock, meno è il rapporto prestazioni/watt perchè i consumi salgono con il cubo della frequenza mentre le prestazioni un po' meno che con la frequenza, dunque non è poi tanto campato per aria il turbo alla AMD...

Il Turbo2 di BD, sarebbe una logica ed automatismo in simbiosi con il bios o una logica interna al procio?

Cioè, quello che vorrei capire è se AMD, a seguito pure dei proci venduti come X2-X3 e poi fatti rinascere come X4 da parte dell'utente, abbia optato su una logica che un BD o lo prendi come B.E./FX, o ti accontenti del Turbo2 e basta, ed a questo punto penso abbia per così dire "limitato" il Turbo2.

E poi questo, potrebbe influire sull'OC? Nel senso, io occo, se la logica del Turbo2 si basasse sui consumi, il Turbo2 andrebbe ad influire pure nell'OC.

Se invece fosse un qualche cosa a livello di bios, come ad esempio che il B.E. offre più possibilità di modificare parametri a piacere, chiaramente un 125W o un B.E. dovrebbe permettere che so... di modificare l'assorbimento max o addirittura disabilitarlo addirittura lasciando attivo unicamente il controllo sulle temp.
Cioè... ora come ora un Thuban ad esempio gli disattivi il Turbo e vai su di Vcore e molti, ma se il procio arrivasse a 75°, il sistema prima obbliga il procio ad attivare il P-State più basso qualunque sia il carico (800MHz e Vcore più basso), dopodiché ti spegne il sistema nel caso le temp aumentino ugualmente.

[bjt2]

Originariamente inviato da paolo.oliva2

Il Turbo2 di BD, sarebbe una logica ed automatismo in simbiosi con il bios o una logica interna al procio?

Cioè, quello che vorrei capire è se AMD, a seguito pure dei proci venduti come X2-X3 e poi fatti rinascere come X4 da parte dell'utente, abbia optato su una logica che un BD o lo prendi come B.E./FX, o ti accontenti del Turbo2 e basta, ed a questo punto penso abbia per così dire "limitato" il Turbo2.

E poi questo, potrebbe influire sull'OC? Nel senso, io occo, se la logica del Turbo2 si basasse sui consumi, il Turbo2 andrebbe ad influire pure nell'OC.

Se invece fosse un qualche cosa a livello di bios, come ad esempio che il B.E. offre più possibilità di modificare parametri a piacere, chiaramente un 125W o un B.E. dovrebbe permettere che so... di modificare l'assorbimento max o addirittura disabilitarlo addirittura lasciando attivo unicamente il controllo sulle temp.
Cioè... ora come ora un Thuban ad esempio gli disattivi il Turbo e vai su di Vcore e molti, ma se il procio arrivasse a 75°, il sistema prima obbliga il procio ad attivare il P-State più basso qualunque sia il carico (800MHz e Vcore più basso), dopodiché ti spegne il sistema nel caso le temp aumentino ugualmente.

E' chiaro che ci sono cose regolabili da BIOS. Il CoolCore e il PowerTune sono cose pubblicizzate in ambito server ma penso a questo punto che le metteranno anche in ambito desktop, magari modificabile da AOD...
Io penso che si potrà regolare sia il target TDP, limitato a 95/125W per le CPU non BE/FX e libero per le BE/FX, sia la temperatura limite di intervento del coolcore (e disattivarlo a tuo rischio e pericolo)...

[Pat77]

mi iscrivo.

[checo]

ma in oc il turbo non si disattiva scusa?

[gi0v3]

Originariamente inviato da checo

ma in oc il turbo non si disattiva scusa?

non in automatico... di solito lo si disabilita, ma se te lo dimentichi a 300x14 di suo cercherà di andare a 300x16,5

[checo]

Originariamente inviato da gi0v3

non in automatico... di solito lo si disabilita, ma se te lo dimentichi a 300x14 di suo cercherà di andare a 300x16,5

a ok, e son ignoratnte, l'ultimo turbo che ho visto su un pc era su un 486

[gi0v3]

per chi si chiedeva se zacate può essere overclockato, ecco una potenziale chicca dal thread sul hp dm1z di notebookreviews

This is an initial report since I have had the system less than a couple of hours, and I will be confirming later with other tools, but the ROG version of CPUz reports the APU speed @ 2Ghz when in high performance mode.

The multiplier is dynamic seeming to range between 5 and 10 at a 200Mhz bus. According to CPUz power saving mode runs the APU @ 1Ghz and high performance mode yields 2Ghz.

Like I said, I haven't had a chance to confirm this with any other tools, and I've heard the stories of these APU's not pushing past 1.7Ghz in a mini-itx solution, so this may be an erroneous report. Either way I'm very curious and I'll report back later.

vediamo se e cosa posterà

[Gigamez]

Originariamente inviato da bjt2

Interessante post di JF-AMD su semiaccurate...

http://www.semiaccurate.com/forums/s...0&postcount=37



Cosa vuol dire? In sostanza il nuovo turbo core aumenta deterministicamente la frequenza in base alla potenza stimata, perchè tanto c'è il CoolSpeed a guardia della temperatura... Questo mette un po' ordine alle varie ipotesi che avevamo fatto in passato... Ovviamente il Turbo alla INTEL è meglio per le prestazioni, ma 1) JF-AMD non lo ammetterà mai e 2) in ogni caso più sali di clock, meno è il rapporto prestazioni/watt perchè i consumi salgono con il cubo della frequenza mentre le prestazioni un po' meno che con la frequenza, dunque non è poi tanto campato per aria il turbo alla AMD...

ciao bjt2, posso farti qualche domanda?

- Prima di tutto secondo te che meccanismo attuano o potrebbero attuare per avere una stima della potenza da dissipare, tenendo conto non solo dei cores utilizzati, ma anche della loro % di utilizzo?

- I base alla tipologia di sensori (o a calcoli basati non su sensori ma su dati astratti e puramente teorici presi come assiomi per il calcolo) non sarebbe molto piu' semplice oltre che sicuramente più preciso partire dalle temperature invece che dal TDP per il calcolo delle frequenze del turbo? Onestamente: dal mio punto di vista non vedo NESSUN vantaggio in un approccio del genere!

- In una mia ipotesi (penso realistica) il turbo alla Intel agirebbe per mezzo di un algoritmo in relazione ai threads gestiti ed a dei sensori di temperatura. Teoricamente se si riuscisse a dissipare una quantita' di calore infinita si potrebbe quindi portare il procio ad una frequenza infinita (e' teoria: so bene che ci sono limiti esistenti ed imposti dall'architettura e/o da protezioni varie). Questo sistema pur fornendo delle prestazioni non calcolabili deterministicamente, spreme il procio al meglio in base anche alle situazioni ambientali disponibili.
In base a cio' che ha detto AMD al riguardo è possibile che il suo turbo agisca in base ad una sorta di "tabella di corrispondenze" (es. a tot valore di TDP in relazione a tot. threads da gestire setto una determinata frequenza per i cores affini ai threads)?

-Sarebbe formalmente corretto ammettere che in questo caso (tabella deterministica per il calcolo del turbo, magari che parte pure da assiomi e non da valori rilevati da sensori veri e propri) il numero di entries sarebbe tanto deterministico quanto FINITO, riducendo il turbo appunto ad una sorta di "steps" gestiti a livello hardware, ma del tutto simili a quelli gestiti via software da programmi come k10-stats? (per questo qualche post fa dicevo che se cosi' fosse il turbo AMD sarebbe a mio parere un po' deludente!)

- Nel caso l'ipotesi sopra sia verosimile torno a chiedere: In che modo il turbo AMD (pur tenendo in considerazione il fatto che il rapporto prestazioni/watts scenda tanto piu' si alzino le frequenze) potrebbe avere una sorta di giustificazione rispetto a quello Intel, oltre appunto al fatto che JF-AMD non potra' mai dire che il loro sia peggio?

infine: non ho capito appunto il discorso che fai sul rapporto prestazioni/potenza che servirebbe a giustificare in parte il lavoro di AMD. Lo intendi come una sorta di "controllo qualità dei consumi", non assicurato dagli algoritmi aggressivi, ma anche molto dispendiosi di Intel?

[cionci]

Originariamente inviato da Gigamez

- Prima di tutto secondo te che meccanismo attuano o potrebbero attuare per avere una stima della potenza da dissipare, tenendo conto non solo dei cores utilizzati, ma anche della loro % di utilizzo?

Probabilmente non usano nessun sensore, ma partono dallo stato dei registri che controllano il clock e pawer gating. Questi registri identificano le aree accese e le aree spente del modulo. Non hanno nemmeno la necessita di conoscere la % di utilizzo. Perché è un controllo in tempo reale, mentre il valore della % è mediato sul tempo.

Originariamente inviato da Gigamez

- I base alla tipologia di sensori (o a calcoli basati non su sensori ma su dati astratti e puramente teorici presi come assiomi per il calcolo) non sarebbe molto piu' semplice oltre che sicuramente più preciso partire dalle temperature invece che dal TDP per il calcolo delle frequenze del turbo? Onestamente: dal mio punto di vista non vedo NESSUN vantaggio in un approccio del genere!

Imho in realtà non usano il TDP, ma una stima del TDP in base alle aree accese e spente dei core. Partire da questa stima è più semplice e più efficacie che partire dalla temperatura:
- la temperatura non varia così velocemente: la stima può variare in teoria anche 100 volte in un secondo, la variazione di temperatura in un centesimo di secondo non può variare significativamente per poter modificare il comportamento della CPU.
- il delay fra il cambiamento di stato della CPU e l'aumento della temperature è tutt'altro che trascurabile, senza contare una certa inerzia termica necessaria prima di far scendere nuovamente la temperatura

Originariamente inviato da Gigamez

- In una mia ipotesi (penso realistica) il turbo alla Intel agirebbe per mezzo di un algoritmo in relazione ai threads gestiti ed a dei sensori di temperatura. Teoricamente se si riuscisse a dissipare una quantita' di calore infinita si potrebbe quindi portare il procio ad una frequenza infinita (e' teoria: so bene che ci sono limiti esistenti ed imposti dall'architettura e/o da protezioni varie). Questo sistema pur fornendo delle prestazioni non calcolabili deterministicamente, spreme il procio al meglio in base anche alle situazioni ambientali disponibili.

D'ora in poi si dovranno conoscere anche le temperature ambientali e del case prima di fare un test ?

Originariamente inviato da Gigamez

In base a cio' che ha detto AMD al riguardo è possibile che il suo turbo agisca in base ad una sorta di "tabella di corrispondenze" (es. a tot valore di TDP in relazione a tot. threads da gestire setto una determinata frequenza per i cores affini ai threads)?

E' chiaro che ci sarà una tabella e la frequenza sarà calcolata in base allo stato dei registri che descrivono le aree accese e spente dei core.

Originariamente inviato da Gigamez

-Sarebbe formalmente corretto ammettere che in questo caso (tabella deterministica per il calcolo del turbo, magari che parte pure da assiomi e non da valori rilevati da sensori veri e propri) il numero di entries sarebbe tanto deterministico quanto FINITO, riducendo il turbo appunto ad una sorta di "steps" gestiti a livello hardware, ma del tutto simili a quelli gestiti via software da programmi come k10-stats? (per questo qualche post fa dicevo che se cosi' fosse il turbo AMD sarebbe a mio parere un po' deludente!)

Non è assolutamente la stessa cosa, K10stats si basa sulla percentuale di uso. Turbo core 2 può variare la frequenza anche se la percentuale di uso si mantiene costante.

[bjt2]

Originariamente inviato da Gigamez

ciao bjt2, posso farti qualche domanda?

- Prima di tutto secondo te che meccanismo attuano o potrebbero attuare per avere una stima della potenza da dissipare, tenendo conto non solo dei cores utilizzati, ma anche della loro % di utilizzo?

- I base alla tipologia di sensori (o a calcoli basati non su sensori ma su dati astratti e puramente teorici presi come assiomi per il calcolo) non sarebbe molto piu' semplice oltre che sicuramente più preciso partire dalle temperature invece che dal TDP per il calcolo delle frequenze del turbo? Onestamente: dal mio punto di vista non vedo NESSUN vantaggio in un approccio del genere!

- In una mia ipotesi (penso realistica) il turbo alla Intel agirebbe per mezzo di un algoritmo in relazione ai threads gestiti ed a dei sensori di temperatura. Teoricamente se si riuscisse a dissipare una quantita' di calore infinita si potrebbe quindi portare il procio ad una frequenza infinita (e' teoria: so bene che ci sono limiti esistenti ed imposti dall'architettura e/o da protezioni varie). Questo sistema pur fornendo delle prestazioni non calcolabili deterministicamente, spreme il procio al meglio in base anche alle situazioni ambientali disponibili.
In base a cio' che ha detto AMD al riguardo è possibile che il suo turbo agisca in base ad una sorta di "tabella di corrispondenze" (es. a tot valore di TDP in relazione a tot. threads da gestire setto una determinata frequenza per i cores affini ai threads)?

-Sarebbe formalmente corretto ammettere che in questo caso (tabella deterministica per il calcolo del turbo, magari che parte pure da assiomi e non da valori rilevati da sensori veri e propri) il numero di entries sarebbe tanto deterministico quanto FINITO, riducendo il turbo appunto ad una sorta di "steps" gestiti a livello hardware, ma del tutto simili a quelli gestiti via software da programmi come k10-stats? (per questo qualche post fa dicevo che se cosi' fosse il turbo AMD sarebbe a mio parere un po' deludente!)

- Nel caso l'ipotesi sopra sia verosimile torno a chiedere: In che modo il turbo AMD (pur tenendo in considerazione il fatto che il rapporto prestazioni/watts scenda tanto piu' si alzino le frequenze) potrebbe avere una sorta di giustificazione rispetto a quello Intel, oltre appunto al fatto che JF-AMD non potra' mai dire che il loro sia peggio?

infine: non ho capito appunto il discorso che fai sul rapporto prestazioni/potenza che servirebbe a giustificare in parte il lavoro di AMD. Lo intendi come una sorta di "controllo qualità dei consumi", non assicurato dagli algoritmi aggressivi, ma anche molto dispendiosi di Intel?

Come anche tu ipotizzi, ci sono vari modi per implementare questo e dal post del BLOG non si capisce quale. Ora elencherò, in ordine crescente di efficacia (prestazionale) e conseguentemente in ordine decrescente di consumo/potenza, le varie strategie di clocking dei processori.

1) Clock fisso tale che in tutte le condizioni possibili di Vcore e temperatura non si superi il TDP indicato. La più conservativa e quella usata fino a qualche anno fa da tutti, in particolare sui Phenom X4 C3. Garantisce il maggior rapporto consumo/potenza ed è il più semplice da implementare. Per risparmiare energia il clock è abbassato a bassi carichi.
2) Clock incrementato DETERMINISTICAMENTE quando un certo numero di cores sono in IDLE, sempre fatto in modo da non sforare il TDP in tutte le condizioni di Vcore e temperatura. Prima implementazione del turbo sul Thuban. A fronte di un leggero incremento di consumo, garantisce un leggero incremento di prestazioni DETERMINISTICO su tutti i cores attivi.
3) Clock fisso a un valore tale da non sforare il TDP nel caso medio e tecnologia CoolCore per downcloccare il chip nel caso di superamento TDP o temperatura... E' la tecnica usata nel MagnyCours (almeno nell'X12) per ottenere un clock a default di 2.4GHz con 12 cores, nonostante l'enorme numero di transistors. E' una tecnica DETERMINISTICA finchè il carico, il Vcore e la dissipazione rimangono nei parametri di progetto. Non è escluso che carichi patologici possano far downcloccare la CPU.
4) Base clock e turbo con vari livelli (attualmente almeno 2: tutti i cores occupati e 50% dei cores occupati) e transizione tra i vari livelli deterministica e basata su modellizzazione a tavolino del comportamento della CPU e verifica in condizioni sfavorevoli in fase di test in fabbrica. Tecnologia CoolCore che downclocca la CPU nel caso di sovratemperatura. E' l'ipotesi più conservativa possibile per il TurboCore 2.0. Ha il vantaggio di non richiedere logica complessa e misure complesse e di avere le stesse performance per tutti gli esemplari della CPU (ossia tutte le CPU vanno alla stassa frequenza e prestazione media dato un carico fissato e posto che la dissipazione sia sufficiente). Ha lo svantaggio che non dà le prestazioni massime ottenibili da metodi di turbo più sofisticati. IMHO è l'ipotesi meno probabile di implementazione del turbocore 2.0 per quanto detto nel punto 5) successivo.
5) Base clock e turbo con vari livelli (attualmente almeno 2: tutti i cores occupati e 50% dei cores occupati) e transizione tra i vari livelli determinata in base a misure di corrente assorbita e tensione erogata alla CPU. Tecnologia CoolCore che downclocca la CPU nel caso di sovratemperatura. E' la implementazione del turboCore 2.0 in Llano così come rilevabile dal paper dell'ISSCC 2010. Lì si asseriva che nel core Llano era stata implementata una logica di misura in tempo reale con una accuratezza del 95-98% delle correnti e tensioni del core, presumibilmente al fine di calcolare il TDP istantaneo al fine di regolare la frequenza di clock. E' ipotizzabile che tale meccanismo sia applicato anche in BullDozer. Ha il vantaggio di prestazioni medie superiori al punto 4, svincolandosi dal caso peggiore. Ha lo svantaggio che ogni esemplare di CPU fa storia a se e quindi le prestazioni non sono perfettamente identiche tra tutti gli esemplari e addirittura in dipendenza della MB su cui è installata la CPU (in particolare la tolleranza sul Vcore). E' possibile che downvoltando la CPU la logica interna, posto che la CPU regga con il downvolt, spinga la CPU a una frequenza media superiore. Questo se la logica basa le decisioni sul TDP (I*V) e non solo sulla corrente. Da verificare. Questa è l'ipotesi più probabile di Turbocore 2.0 dai paper su Llano. E' possibile che la versione desktop adotti il metodo 5 e quella server il metodo 4, viste le dichiarazioni di JF-AMD sul suo blog sul funzionamento deterministico del TurboCore 2.0. Il punto 5 non è in contrasto con quanto dichiarato da JF-AMD in quanto il tutto è ancora deterministico, fissato MB, dissipatore e Vcore, ma ovviamente ancora variabile tra esemplare e esemplare. Questo punto non è stato chiarito nel BLOG, quindi non possiamo ancora sapere quale delle 2 (4 o 5) strategie saranno applicate.
6) E' il Turbo Boost alla INTEL versione Nehalem/Bloomfield. Il clock è incrementato a passi di 133 MHz (quindi almeno 4 stati) a seconda di quanti cores sono occupati e la temperatura del DIE, rimanendo entro limiti di consumo. E' simile al 5, ma avendo più scalini è potenzialmente più efficace.
7) E' il Turbo Boost alla INTEL versione sandy bridge. Il clock è incrementato a passi di 100MHz e viene monitorato il TDP istantaneo e la temperatura, ma anche la storia recente del TDP. In caso di periodi di IDLE si può sforare fino a 25 secondi il TDP nominale per sfruttare la capacità termica dei vari componenti (CPU, dissipatore). Oltre a una granularità più fine c'è una maggiore aggressività.

Ovviamente le prestazioni medie, fissata l'architettura e il TDP massimo, aumentano passando dalla strategia 1 alla 7. Ritengo che i due turbo alla INTEL siano i migliori in assoluto. La scusa del determinismo, IMHO è solo per giustificare il fatto che AMD non ha copiato pedissequamente INTEL... Considerando l'ottimo processo produttivo di GF, il turbo alla INTEL sarebeb proprio cascato a fagiolo...

[bjt2]

Originariamente inviato da cionci

Probabilmente non usano nessun sensore, ma partono dallo stato dei registri che controllano il clock e pawer gating. Questi registri identificano le aree accese e le aree spente del modulo. Non hanno nemmeno la necessita di conoscere la % di utilizzo. Perché è un controllo in tempo reale, mentre il valore della % è mediato sul tempo.

Imho in realtà non usano il TDP, ma una stima del TDP in base alle aree accese e spente dei core. Partire da questa stima è più semplice e più efficacie che partire dalla temperatura:
- la temperatura non varia così velocemente: la stima può variare in teoria anche 100 volte in un secondo, la variazione di temperatura in un centesimo di secondo non può variare significativamente per poter modificare il comportamento della CPU.
- il delay fra il cambiamento di stato della CPU e l'aumento della temperature è tutt'altro che trascurabile, senza contare una certa inerzia termica necessaria prima di far scendere nuovamente la temperatura

D'ora in poi si dovranno conoscere anche le temperature ambientali e del case prima di fare un test ?

E' chiaro che ci sarà una tabella e la frequenza sarà calcolata in base allo stato dei registri che descrivono le aree accese e spente dei core.

Non è assolutamente la stessa cosa, K10stats si basa sulla percentuale di uso. Turbo core 2 può variare la frequenza anche se la percentuale di uso si mantiene costante.

Ci avevo pensato anche io a una modellizzazione della CPU e una decisione "a catena aperta" del clock istantaneo. Ma poi mi sono posto la domanda: "e allora a che cavolo serve l'unità in Llano di misura accurata con errore entro il 2% della potenza istantanea assorbita?"

[cionci]

Originariamente inviato da bjt2

Ci avevo pensato anche io a una modellizzazione della CPU e una decisione "a catena aperta" del clock istantaneo. Ma poi mi sono posto la domanda: "e allora a che cavolo serve l'unità in Llano di misura accurata con errore entro il 2% della potenza istantanea assorbita?"

Allora però non è deterministico Visto che il TDP dipende dalla temperatura della CPU.

[Gigamez]

Originariamente inviato da cionci

Probabilmente non usano nessun sensore, ma partono dallo stato dei registri che controllano il clock e pawer gating. Questi registri identificano le aree accese e le aree spente del modulo. Non hanno nemmeno la necessita di conoscere la % di utilizzo. Perché è un controllo in tempo reale, mentre il valore della % è mediato sul tempo.

Imho in realtà non usano il TDP, ma una stima del TDP in base alle aree accese e spente dei core. Partire da questa stima è più semplice e più efficacie che partire dalla temperatura:
- la temperatura non varia così velocemente: la stima può variare in teoria anche 100 volte in un secondo, la variazione di temperatura in un centesimo di secondo non può variare significativamente per poter modificare il comportamento della CPU.
- il delay fra il cambiamento di stato della CPU e l'aumento della temperature è tutt'altro che trascurabile, senza contare una certa inerzia termica necessaria prima di far scendere nuovamente la temperatura

D'ora in poi si dovranno conoscere anche le temperature ambientali e del case prima di fare un test ?

E' chiaro che ci sarà una tabella e la frequenza sarà calcolata in base allo stato dei registri che descrivono le aree accese e spente dei core.

Non è assolutamente la stessa cosa, K10stats si basa sulla percentuale di uso. Turbo core 2 può variare la frequenza anche se la percentuale di uso si mantiene costante.

innanzitutto grazie per le risposte come sempre molto tecniche ed accurate!

Fammi pero' capire una cosa: da quello che dici il valore stimato di TDP viene appunto stimato in base ai registri che in tempo reale visualizzano "cosa" sta esattamente lavorando all'interno del core. Perfettamente d'accordo e comprensibile quindi il fatto che come giustamente dici le "tracce" dei registri risultino essere molto piu' reattive alle variazioni di quanto lo sia la temperatura, specialmente in intervalli relativamente ridotti di tempo.

L'ottica che stai propopnendo in effetti non la avevo minimamente considerata: sbaglio o mi stai dicendo che il turbo potrebbe agire costantemente con un "polling" anche di varie decine di volte al secondo (per Intel sarebbe ovviamente impossibile visto che si basa su temperature) massimizzando non tanto le prestazioni teoriche assolute, quanto piuttosto quelle "medie e reali" con grossi carichi di lavoro?
Effettivamente se cosi' fosse i vantaggi ci sarebbero, eccome!
Si avrebbe un uso massimale dei cores in maniera appunto deterministica! (ora inizio a capire cosa forse intendeva JF-AMD)
Senza contare che con tutta probabilita' sarebbe anche molto piu' efficiente dal punto di vista energetico, visto che calcolando la cosa in base all'ipotetico TDP istantaneo si massimizzerebbe anche la perdita' dovuta al leackage (come mi sembrava di capire dicesse appunto bjt2)

..era questo quello che intendevi?

[cionci]

Originariamente inviato da Gigamez

..era questo quello che intendevi?

E' quello che intendevo, quante volte venga effettuato il poilling al secondo lo ignoro, ma in teoria potrebbero studiare interventi diversi dal polling, potrebbe essere guidato da eventi. Mi spiego: l'albero di diramazione del clock è controllato da alcuni registri, il calcolo della nuova frequenza potrebbe avvenire quando c'è una variazione di un bit che controlla la trasmissione o meno del clock ad una certa profondità prefissata dell'albero.
Si prende lo stato complessivo, lo si buttta, nel migliore dei casi, in una tabella e si ottiene la nuova frequenza.

Comunque io non sono sicuro che sia così, ma mi sembra la situazione che possa descrivere nel migliore dei modi la parola "deterministico" detta da JF.

[Gigamez]

Originariamente inviato da bjt2

cut...

7) E' il Turbo Boost alla INTEL versione sandy bridge. Il clock è incrementato a passi di 100MHz e viene monitorato il TDP istantaneo e la temperatura, ma anche la storia recente del TDP. In caso di periodi di IDLE si può sforare fino a 25 secondi il TDP nominale per sfruttare la capacità termica dei vari componenti (CPU, dissipatore). Oltre a una granularità più fine c'è una maggiore aggressività.

Ovviamente le prestazioni medie, fissata l'architettura e il TDP massimo, aumentano passando dalla strategia 1 alla 7. Ritengo che i due turbo alla INTEL siano i migliori in assoluto. La scusa del determinismo, IMHO è solo per giustificare il fatto che AMD non ha copiato pedissequamente INTEL... Considerando l'ottimo processo produttivo di GF, il turbo alla INTEL sarebeb proprio cascato a fagiolo...

Interessantissimo il punto 7!
Davvero ingegnoso utilizzare la capacita' termica dei componenti per sforare temporaneamente il TDP!
Fammi capire: mi stai dicendo che anche Intel utilizza un metodo deterministico basato sulla stima del TDP (a parte situazioni particolari limitate a quelche sencondo)?

Non sono sicuro di aver capito bene: mi stai dicendo che Intel gestendo anche il "sovrappiu'" teorico dato dalla capacità termica (controllato costantemente dalla temperatura reale) di fatto teoricamente permetterebbe anche una sorta di OC automatico semplicemente cambiando sistema di dissipazione in modo da "ingannare il procesore" facengli vedere come "maggiore capacità termica" quello che in effetti e' a tutti gli effetti una maggiore dissipazione di watts termici?

sarebbe effettivamente ancora piu' evoluto!
lol, sto imparando un bel po' di cose oggi!

[cionci]

Sinceramente io non ci vedo niente di deterministico E' deterministico se a passando gli stessi carichi si ottengono esattamente gli stessi risultati.
Se c'è dipendenza dalla temperatura allora è chiaro che non sarà mai deterministico.

[bjt2]

Originariamente inviato da cionci

Allora però non è deterministico Visto che il TDP dipende dalla temperatura della CPU.

Eh, lo so... E' questa ambiguità nelle parole del post di JF che mi fa essere indeciso tra il 4 e il 5... Ma considerando che ha detto che quel post è passato nel reparto di engineering prima di essere pubblicato... Again o hanno semplificato troppo, oppure vale il punto 4...

[bjt2]

Originariamente inviato da Gigamez

Interessantissimo il punto 7!
Davvero ingegnoso utilizzare la capacita' termica dei componenti per sforare temporaneamente il TDP!
Fammi capire: mi stai dicendo che anche Intel utilizza un metodo deterministico basato sulla stima del TDP (a parte situazioni particolari limitate a quelche sencondo)?

Non sono sicuro di aver capito bene: mi stai dicendo che Intel gestendo anche il "sovrappiu'" teorico dato dalla capacità termica (controllato costantemente dalla temperatura reale) di fatto teoricamente permetterebbe anche una sorta di OC automatico semplicemente cambiando sistema di dissipazione in modo da "ingannare il procesore" facengli vedere come "maggiore capacità termica" quello che in effetti e' a tutti gli effetti una maggiore dissipazione di watts termici?

sarebbe effettivamente ancora piu' evoluto!
lol, sto imparando un bel po' di cose oggi!

Esatto... Il sistema interno misura temperatura, corrente e tensione del core, calcola il TDP istantaneo e nel SB mantiene anche una storia per poter calcolare per quanto tempo può usare il TDP maggiorato dopo uno stato prolungato di IDLE... In SB ci sono due TDP che di default sono 95W e 120W. Il primo è quello mantenuto a tempo indeterminato, il secondo è mantenuto per un tempo massimo di 25 secondi a seconda della storia passata di assorbimento. Il tutto tenendo sotto controllo la temperatura. Considerando che il leakage in INTEL è molto alto, il TDP dipende FORTEMENTE dalla temperatura, molto di più che per AMD. Quindi usando il clock massimo possibile compatibilmente con il TDP fissato, si ottiene un comportamento non deterministico dipendente anche dal sistema di dissipazione: più è efficiente, più la temperatura è bassa, più è basso il leakage, più è basso il TDP a una data freuquenza, più può salire la CPU.

[bjt2]

Originariamente inviato da cionci

Sinceramente io non ci vedo niente di deterministico E' deterministico se a passando gli stessi carichi si ottengono esattamente gli stessi risultati.
Se c'è dipendenza dalla temperatura allora è chiaro che non sarà mai deterministico.

Esatto... Quindi o JF-AMD ha barato, oppure quelli dell'engineering hanno trascurato la variazione di leakage con la temperatura.

[Gigamez]

Originariamente inviato da cionci

E' quello che intendevo, quante volte venga effettuato il poilling al secondo lo ignoro, ma in teoria potrebbero studiare interventi diversi dal polling, potrebbe essere guidato da eventi. Mi spiego: l'albero di diramazione del clock è controllato da alcuni registri, il calcolo della nuova frequenza potrebbe avvenire quando c'è una variazione di un bit che controlla la trasmissione o meno del clock ad una certa profondità prefissata dell'albero.
Si prende lo stato complessivo, lo si buttta, nel migliore dei casi, in una tabella e si ottiene la nuova frequenza.

Comunque io non sono sicuro che sia così, ma mi sembra la situazione che possa descrivere nel migliore dei modi la parola "deterministico" detta da JF.

Non penso che un sistema basato unicamente sugli eventi possa funzionare..

Per massimizzare all'estremo (seguendo al tua ipotesi) probabilmente bisognerebbe utilizzare sia il polling che gli eventi:
Magari sbaglio, ma in una gestione ad eventi prima di variare il clock secondo me si dovrebbero comunque confrontare tutti gli altri registri relativi ai diversi livelli di profondita' dell'albero di distribuzione del clock, pena la perdita di sincronia!
Magari dico cavolate, ma poni il caso che ad un livello X il registro relativo ti dica che hai un utilizzo della logica del 5% ed ad un altro livello il registro Y ti dica che hai un uso del 100%: il livello del 5% manderebbe un interrupt di richiesta clock aggiuntivo. bisognerebbe controllare anche gli altri stati, compreso quello del 100% prima di adottare ISTANTANEAMENTE nuove politiche di clock, sbaglio?
Per poter garantire la sincronia del clock bisognerebbe quindi fare una sorta di "polling distribuito" sui livelli dell'albero.. onestamente molto difficile da gestire..

Se si facesse invece un semplice polling, ad ogni ciclo di clock si potrebbero facilmente "sommare" gli stati dei registri stimando di fatto il TDP istantaneo e totale su tutti i livelli dell'albero e variando quindi di conseguenza la frequenza in base ad una media calcolata su n cicli (e' un esempio implementativo magari pure impossibile da attuare). Penso sarebbe tuttavia infinitamente piu' semplice e di sicuro impatto, anche se sicuramente meno efficente a livello teorico.

ho detto cavolate?