Qualche anno fa ho avuto a che fare con un computer altrui, con sistema operativo Windows XP, che si spegneva casualmente da solo in continuazione. Era il trentotto luglio, e faceva molto caldo, sospettavo quindi uno shutdown termico di emergenza, ma mi trovavo in difficoltà nel verificare l’ipotesi: ero solo di passaggio e invece del mio solito zaino con “gli strumenti”, avevo con me il borsone con pinne e maschera; nell’ufficio in questione non c’erano cacciaviti; la linea Internet era fuori servizio causa manutenzione estiva (classico cavo tranciato per errore da un bulldozer).
Ho dovuto improvvisare.
Attenzione: se il vostro computer è già danneggiato o progettato male, fare quanto illustrato in seguito potrebbe infliggergli il colpo di grazia; procedete a vostro rischio e pericolo e soprattutto con cautela.
Ho fatto ricorso a uno dei trucchi più vecchi del mondo: il loop infinito.
Ho preparato un piccolo script in Visual Basic Scripting Edition chiamato “CPU stresser.vbs” con le seguenti due righe:
while 1
wend
Eseguendolo, l’interprete VBScript entra in loop infinito, vuoto e incontrollato, e “consuma” risorse CPU, facendo passare più corrente elettrica nei circuiti nell’unità di tempo e quindi aumentando la dissipazione termica: in altre parole fa scaldare il processore.
Certo, non è Prime95, non è nemmeno assembly ottimizzato a mano, è banalissimo VBScript (che non mi fa impazzire, ma ha i suoi pregi), non attiva tutti i circuiti del chip ma solo alcuni, quindi ha dei limiti, ma il suo lavoro lo fa.
Per scaldare come si deve, bisogna lanciare questo script almeno una volta per ogni thread gestibile dal processore. Quindi, per esempio, per il mio vecchio portatile monoprocessore monocore senza Hyperthreading basta una sola esecuzione; per un Phenom II X3 (monoprocessore tricore non-HT) serviranno tre di questi script in esecuzione contemporanea; per un server quad-socket attrezzato con certi Beckton (quadriprocessore hexacore HT) ne serviranno 48. Naturalmente, in quest’ultimo caso c’è la possibilità di generare accidentalmente del plasma da fusione. Una volta avviati tutti questi processi, il grafico dell’utilizzo della CPU del Task Manager di Windows dovrebbe riportare un utilizzo del 100%. Se così non fosse, aggiungere processi quanto basta.
Il lettore attento avrà notato che lo scriptino, proprio per essere -ino, manca totalmente di controllo degli errori, della temperatura, e soprattutto del flusso, e in particolare non può essere normalmente interrotto. È per questo che si chiama loop infinito. Per interromperlo, io utilizzo il suddetto Task Manager per terminare le varie istanze del processo chiamato wscript o cscript (oppure riavvio il computer).
Il vantaggio di questo scriptino (che mi è tornato utile varie volte in altri casi limite del genere) è che è facilmente riproducibile a memoria: lo porto sempre con me e lo rimetto in produzione in trenta secondi anche con il più anemico dei text editor.
Una volta avviato il test, un comportamento normale e non preoccupante in un computer moderno sarebbe l’aumento della velocità (e quindi della rumorosità) della ventola del dissipatore termico della CPU per controbattere l’aumento di temperatura nella CPU e portarla a un nuovo equilibrio termico a una temperatura superiore ma ancora accettabile, senza conseguenze nefaste; al termine dell’esecuzione delle varie istanze dello script, la CPU scalderà di meno e ci si aspetta un conseguente ritorno alla normale velocità (e rumorosità) della ventola. Alcune ventole, tuttavia, girano a velocità fissa e non seguono tale comportamento.
Ora, se il computer cavia è danneggiato (processore difettoso, ventola del dissipatore bloccata, prese d’aria occluse) o mal progettato (aerazione insufficiente, dissipatore sottodimensionato, ventola troppo lenta, chip notoriamente “bollente”) o maltrattato (libri addosso alle feritoie d’aerazione, coperta o cuscino sotto al portatile), o se l’ambiente è ostile (temperatura elevata della stanza, polverosità eccessiva, illuminazione solare diretta), c’è la possibilità che la CPU si surriscaldi e (sperabilmente) il computer si spenga improvvisamente per evitare danni fisici. In casi limite, patologici, questo meccanismo di autodifesa malfunziona, e il processore frigge terminalmente, magari portandosi appresso i componenti con cui è a contatto. Personalmente non mi è mai capitato, ma conosco persone che per questo motivo hanno buttato via processore fuso e scheda madre bruciata.
Avviso per i principianti: io ho tagliato con l’accetta; Internet mette a disposizione informazioni molto più dettagliate sull’argomento.
Per tentare di placare i puristi del VBScript, vorrei citare un’altra versione dello script, che ho utilizzato in passato:
do while 1
loop
Ai fini del risultato finale, ci sono poche differenze pratiche tra le due versioni: entrambe svolgono lo stesso lavoro con pressoché la stessa efficienza. Questa seconda versione però è per me svantaggiosa per due precisi motivi. Uno, mi è molto più facile ricordare la sintassi del ciclo while/wend che quella del ciclo do/loop del VBScript. Due, la prima versione consuma 15 byte, la seconda 18 byte; si tratta di un incremento nel consumo di memoria (centrale e storage di massa) di ben il 20%: decisamente inaccettabile.
Per concludere la storia del computer con cui ho aperto questo pezzo, circa cinque secondi dopo aver fatto partire lo scriptino il computer si è spento brutalmente; ripetuto il test altre due volte con identici risultati, siamo andati al mare e il giorno dopo siamo tornati con gli strumenti. La ventola del dissipatore era guasta. Sostituita la ventola, terminati i problemi. YMMV.
Lascia un commento