Newsgroup: it.comp.hardware.cpu
Titolo: Ridurre % utilizzo processore

Ciao a tutti,
sapete se esiste qualche modo x ridurre l'utilizzo del processore?
ad es. sui portatili c'è una modalità x cui quando si usa la batteria
l'utilizzo del processore viene automaticamente ridotto x ridurre i
consumi.
Conoscete qualche programma che fa la stessa operazione?
ho visto Hmonitor, ma non mi rileva la temperatura e credo che quello
si basi sulla temperatura...
Grazie, Revenge

 si basi sulla temperatura...
non lo so e , comunque , la cosa NON HA SENSO
se riduci l'uso del processore, fai durare di più il processo (  CHE TU 
UTENTE  ) hai chiesto al pc di eseguire
e , quindi , richiedi al pc di rimanere ancor più tempo acceso ...
in pratica tu vorresti "la botte piena e la moglie ubriaca"
se spieghi meglio le tue necessità , forse, ti si riesce a dare una mano 
  ...
sicuramente in un altro modo ...
ciao :-)

sapete se esiste qualche modo x ridurre l'utilizzo del processore?
Ma tutto a ciň a che scopo e con quale CPU?
-- 
Saluti
Alec (28,72+,CT)
Powered by AMD Athlon64 X2 5200+
Fueled by ATi - Sapphire X1800XT-OC
OnLine by Tiscali 12Mega 

 --
lo scopo è di poter utilizzare un processo (un gioco ^^) per un tot di
ore senza che il processore vada al 100%.
anche riducendo al 70-80% non dovrei avere grosse perdite di
prestazioni (è ottimizzato male il gioco)
Non mi piace l'idea di far girare il processore al 100% per parecchie
ore al giorno.....(non è salutare ^^)
Ciao

 Ciao
Questo lo dici tu.... I produttori non sfruttano mai l'hardware al 100% 
delle possibilitŕ proprio per garantirne una buona durata e 
funzionamento costantemente conforme alle specifiche. Usa il tuo pc come 
vuoi, ci mancherebbe che dopo aver speso tutti quei soldi non lo sfrutti 
nemmeno :-P.

 nemmeno :-P.
beh, si.....
il 100% reale si verificherebbe in una situazione di overclock che
porterebbe il processore realmente ad un utilizzo del 100%...e senza
overclock il processore è già "limitato" rispetto al max
possibile....(scusa il gioco di parole, eh, eh)
però resto sempre col dubbio che non sia salutare tenerlo attivo x
parecchie ore così......(sul portatile posso tenere d'occhio la
temperatura....che in effetti rimane entro dei buoni limiti, ma sul
fisso no....)

*Revenge* scrisse:

Prova a cambiare la priorità del processo.
Ciao
-- 
Lo Zio Fizzy ©
       /)/)
     (  '.')
   o(_('')('')

 nemmeno :-P.
mi dici una cosa :-)
MA
è corretto dire che "il processore funziona al tot% "  ???
non è forse vero che il processore 'macina' **sempre** al 100% !?!?!
che poi esegua sempre una piccolissima porzione di codice giusto per 
verificare la pressione di un tasto oppure il movimento del mouse per 
migliaia di volte al secondo , oppure , al contrario solo poche volte in 
un secondo , è una cosa che dipende da s.o.
MA
di per sè il processore , comunque , gira 'sempre al 100%' ?!?!?!
che , poi , nello specifico dei sistemi windows , dove , mi sembra , che 
il sistema ancora non sfrutti il vero multitasking preemptive a 32 bt e 
, quindi , un applicazione prende il controllo del processore per 
parecchi tempo , tanto da dare la possibilità al s.o. di cedere il 
controllo ad un altra applicazione molto in ritardo , non significa che 
il processore lavora  " di più " rispetto a quando c'è un solo 
applicativo !!!!!
o c'è qualcosa di base che mi sfugge ?!?!?!?
in definitiva, l'indicazione di "percentuale di utilizzo del processore" 
in realtà , è , più che altro , una indicazione del s.o. di quanto tempo 
passi perchè una applicazione riprenda il controllo la prossima volta ...
ciao e grazie di ogni lume che vorrai darmi :-)

@Zio Fizzy II° ha scritto:
cambiare la priorità può servirmi giusto x permettere ad altre
applicazioni di poter "lavorare" con priorità maggiore (normal
rispetto ad infnormal) ma il processore continua cmq a lavorare al 100%
@tony pedi
si, il processore lavora cmq al 100%......
ma x un tempo generalmente limitato (a tratti o tempi non
esageratamente lunghi......parlo di 7-8 ore di fila ogni volta nel mio
caso...)
più che evitare che il processore vada al 100%, volevo evitare che il
processore non andasse al 100% x 8 ore di fila....e gli unici due modi
che vedevo erano:
- ridurre i tempi di utilizzo del processo (usare meno il gioco o
programma "incriminato")
- forzare la riduzione dell'utilizzo del processore durante questo
lasso di tempo
tutto qui...
cmq la risposta è stata abbastanza chiara....e quindi mi pare di aver
capito che non devo preoccuparmi.....
Ciao

*Revenge* scrisse:
| @Zio Fizzy II° ha scritto:
|
| cambiare la priorità può servirmi giusto x permettere ad altre
| applicazioni di poter "lavorare" con priorità maggiore (normal
| rispetto ad infnormal) ma il processore continua cmq a lavorare al 100%
[...]
Conosco CPU Idle,[PRO] ma non credo faccia al caso tuo, ad ogni modo sul mio 
portatile abbassa la temp del procio quando faccio codifica  (Centrino 2 
Ghz) e il procio sta parecchio tempo a palla.
Ciao.


 passi perchè una applicazione riprenda il controllo la prossima volta ...
No, la percentuale di utilizzo del processore è basata su quanto detto 
prima. Il kernel sa benissimo quanto tempo di cpu ha dato ai vari 
thread/processi, quindi può fare una stima valida di chi ha consumato 
quanto.
Ciao!

allora se tu riduci la velocita' della cpu la % di carico cresce... pensaci 
un po'!
se hai una cpu che varia i mhz da 1000 a 2000 ad esempio, e stai ascoltando 
un mp3 e usando excel, se a 2ghz la cpu e' usata al 5%... a 1ghz la devi 
usare al 10% (circa).
l'utilizzo % della cpu lo puoi ridurre solo diminuendo i task. Per ridurre i 
consumi devi ridurre i mhz (agendo su fbb e moltiplicatore se puoi). Inoltre 
per ridurre bene i consumi devi poter ridurre il vcore al scendere dei mhz.
in base all cpu e mainboard-chipset che hai devi cercare il software giusto. 
su mobo nforce 2 va benino speedfan ad es. 

ore al giorno.....(non è salutare ^^)
Non è salutare per cosa??? :-O


 Un processore gira sempre ad una velocità fissa, data da un clock.
Non oggi. :-P


 Non oggi. :-P
Eheh, lo sapevo che ci sarebbe stato un commento così! :)
Ok, non ho messo in campo speedstep/powernow/c&q ma era solo per non 
complicare ulteriormente il discorso!
Pignolone che non sei altro!

 Ciao!
grazie di aver precisato
MA
già le sapevo queste cose
SOLO che avevo letto ( forse qualche annetto fa ... ^___^ )
che , di fatto , la maggior parte delle applicazioni erano programmate 
in modo da non sfruttare il vero multitasking preemptive
e che , quindi , di fatto , il 99% degli applicativi funzionava 
condividendo lo stesso 'spazio memoria' ( con tutte le conseguenze del 
caso ... ) e funzionando in "non-preemptive" *fra di loro*
insomma, mi stai dicendo che , adesso , non è più così e che il s.o. 
gestisce , comunque , tutte le operazioni, tutti gli applicativi , 
creando un 'ambiente x86' specifico per ognuno ; ognuno con il suo 
spazio di indirizzamento di memoria privato che le altre applicazioni , 
e, quindi, anche se 'impazziscono', non possono danneggiarsi a vicenda ????
forse quanto io ipotizzavo essere ancora realtà , è una riminescenza dei 
sistemi fino al ME ?!?!?!?!?!
in effetti empiricamente/praticamente negli ultimi 4 anni di utilizzo 
del win2000 ho potuto constatare la solidità del sistema !!!!
processi impazziti non mi hanno mai fatto perdere la possibilità ( 
imperterrito io ... lol ) di far apparire il task manager , magari dopo 
svariati minuti , ed interrompere l'eventuale singolo processo bloccato
ciao e grazie delle delucidazioni/conferme datemi :-)

 -- 
Sempre a rovinare tutto tu eh? ;D

 sistemi fino al ME ?!?!?!?!?!
Già... gli OS della serie Win9x usavano ancora in gran parte un multitasking
di tipo cooperativo.

 caso ... ) e funzionando in "non-preemptive" *fra di loro*
Non so cosa tu abbia letto e a quanto risalisse. Quello di cui parli 
risale a Windows pre-95. In Windows 95 il preempting già esisteva, e 
ogni processo aveva il suo spazio di indirizzamento.
Purtroppo il fatto che avesse un proprio spazio di indirizzamento non 
significava che questo fosse isolato... infatti, se ricordo bene, gli 
indirizzi inferiori tra 2GB e 3GB erano memoria comune a tutti i 
processi (read-write), e quelli superiori a 3GB (rabbrividisco) erano 
memoria del *sistema*, accessibile in read-write ad ogni processo.
Fortunatamente i sistemi operativi moderni (nel caso di Windows, la 
modernità è arrivata con NT) hanno eliminato del tutto questi problemi, 
per cui puoi stare tranquillo. ;)
Ciao
Davide

 ogni processo aveva il suo spazio di indirizzamento.
In teoria si... peccato però in pratica le famose bsod erano quasi
all'ordine del giorno con quegli OS :))

 all'ordine del giorno con quegli OS :))
Beh, ma quello l'ho spiegato dopo. Tutti i processi potevano sia leggere 
che scrivere sia nello spazio condiviso (in cui erano caricate anche le 
DLL comuni) sia nello spazio di memoria del sistema operativo (brrr).
Il problema non ha molto a che fare con l'utilizzo del processore, comunque.
Ciao
Davide

 ha scritto nel messaggio
news:450db60f$0$17455$4faf...@reader4.news.tin.it...

Si infatti... volevo solo essere ironico se non si è capito ;))

 ciao e grazie delle delucidazioni/conferme datemi :-)
Di nulla!


La MMU comunque gestisce anche la memoria virtuale stessa se non erro...in
pratica traduce gli indirizzi logici (appartenenti appunto alla memoria
virtuale ricavata sul disco rigido del sistema) in indirizzi fisici
(relativi alla memoria centrale, alias RAM, dove queste informazioni devono
essere riportate prima di essere utilizzate nell'elaborazione).

 e basta.
E' la seconda volta che leggo questa idea sul fatto che Windows 95 non 
implementasse il preemptive multitasking e mi viene qualche dubbio. Io 
ho sempre saputo che Windows 95, per quanto pieno di difetti (che 
abbiamo già citato), almeno fosse in grado di suddividere il tempo della 
CPU tra i processi. Quali sono gli aspetti di Win95 ancora "cooperative"?
Ciao
Davide

 
il fatto è che
anche se le applicazioni NON potevano impossessarsi del processore per 
tutto il tempo che volevano , proprio perchè il sistema implementava un 
vero multitasking preemptive
era anche vero che la gestione della memoria era unica
tutte le applicazioni condividevano lo stesso 'spazio di indirizzamento'
facendo diventare possibilissimo ( ed accadeva sovente ) che 
applicazioni mal scritte , che andavano in tilt per un qualsivoglia 
motivo , finivano per andare a scrivere nella memoria di altre 
applicazioni e/o del s.o. facendo andare TUTTO in tilt
finale : il sistema della gestione dei processi era sì di tipo preemptive
ma a causa della gestione memoria inefficace ( inesistente ?!??? ...) il 
sistema nel suo complesso risultava comunque molto 'instabile'
ciao :-)


Anche la documentazione stessa di Microsoft parla di "conseguenze 
catastrofiche", come č facile comprendere per chiunque abbia un minimo 
di esperienza e abbia mai lavorato su un sistema piů serio, ma non era 
questo il punto centrale dei post originari.
Il dettaglio che invece veniva fuori confusamente nella discussione era 
quello del multitasking cooperativo, visto che piů di una persona 
sosteneva che in Win95 fosse possibile per un'applicazione prendersi 
tutto il tempo della CPU, e chiedevo se non ci fosse qualcosa che io non 
sapevo.
Ciao
Davide

 essere riportate prima di essere utilizzate nell'elaborazione).
Si, infatti MMU sta per Memory Management Unit (per i non addetti ai 
lavori), e si occupa appunto di tradurre da virtuale a fisico 
supportando opportunamente il sistema operativo.

 sapevo.
Con Windows kernel 9x per compatibilità con il passato sono state 
mantenute molte cose disgraziate.
In primis le applicazioni a 16 bit di windows 3/dos: un applicazione a 
16 bit (ma anche a 32 bit sotto dos extender) aveva la possibilità di 
richiedere IRQ senza problemi. Avere la possibilità di richiedere IRQ 
rende tutto molto più difficile perché l'applicazione sfugge ad ogni 
controllo del sistema operativo, può anche bloccare tutte le altre 
applicazioni e andare in esecuzione per fatti suoi!
Immagina che ci siano una catena di processi che devono gestire un IRQ, 
in mezzo c'è un'applicazione a 16 bit e pensa all'IRQ è come se fosse un 
testimone che ogni applicazione passa a quella successiva. Pensa cosa 
accadrebbe se l'app crasha... il testimone non passa più al successivo! 
Quello che ne può conseguire è solo frutto della fantasia.
Oppure, sempre per compatibilità con il passato, erano permesse molte 
interazioni pericolose con l'hardware, di cui la più importante era la 
possibilità di ricevere o inviare dati verso le porte hardware (cioè 
chiaccherare con disco, scheda video/audio, controller IRQ e DMA, e chi 
più ne ha più ne metta) senza interpellare il sistema operativo! Un 
semplice bit sbagliato al posto sbagliato può mandare in crash tutto il 
computer.
C'era anche un testo che diceva che win95 non fosse preemptive perché 
alla base c'era qualcosa che non andava, ma purtroppo a suo tempo non lo 
finì di leggere :(

 richiedere IRQ senza problemi. [...]
Capito, grazie.
In effetti se ricordo bene era la ragione per cui fino a poco tempo fa 
gli utenti home erano tanto restii a passare ai Windows derivati da 
NT... ad esempio tutto il funzionamento di vecchi videogiochi per DOS 
che avevano bisogno di qualche trucchetto in più per sfruttare le 
risorse della macchina, e che su Windows 9x continuavano ad andare più o 
meno bene (per le ragioni che hai spiegato tu, e compromettendo buona 
parte della stabilità del sistema) e su NT non andavano.
In conclusione, sono contento di non usare Windows 9x da 7-8 anni ormai. ;)
Ciao
Davide

Il ratto ha scritto:

Esatto, hai colto nel segno.
NT (così come 2000 e XP) sono 32 bit puri, con uno strato di 
*emulazione* per i 16 bit (non tutte le app a 16 bit funzionano 
infatti), infatti migrare le directX (nate su win9x) su NT è stato un 
grosso grosso problema e ci sono voluti dei service pack appositi. In 
particolare l'audio, che su win9x era in buona parte a 16 bit, aveva 
molti problemi su NT ed era emulato tramite il classico waveout di 
sistema... Altri tempi!

 grosso grosso problema e ci sono voluti dei service pack appositi.
NT di default non supportava manco le periferiche USB comunque...è anche
quello è proprio d'altri tempi ;))