Controllo temperatura e benchmark Raspberry PI 3

Stai ancora usando un Raspberry Pi 3 nel 2026? Se sì, è il momento di chiedersi se conviene ancora raffreddarlo o se è meglio fare il salto generazionale al Pi 5. Ne parlo in maniera estensiva su Perché passare a Raspberry Pi 5: guida all'upgrade da Pi 3 e Pi 4, che include tabelle comparative dettagliate, benchmark applicativi reali, e i bundle attualmente disponibili in commercio. Se invece hai già un Pi 3 e vuoi raffreddarlo, la guida tecnica che segue resta valida per estrarre il massimo dall'hardware esistente.

Monitorare temperatura e prestazioni di un Raspberry Pi è un'attività che ha senso in tre scenari distinti: setup di un Pi 3 in fase di overclock, validazione di un sistema di dissipazione, monitoring continuo di installazioni embedded in produzione. La domanda preliminare che vale la pena fare prima di tutto, però, è se stai monitorando un hardware che vale la pena tenere o uno che potresti rimpiazzare con un upgrade che cambia categoria di workload. Nel 2026 il quadro è chiaro: un Pi 5 non overcloccato fa quello che un Pi 3 overcloccato e raffreddato fatica a fare, e benchmark applicativi reali confermano un fattore 5-6× sulla CPU e capacità che il Pi 3 semplicemente non ha (4K HEVC hardware, NVMe storage, Gigabit Ethernet vera).

Conviene monitorare un Pi 3 o passare al Pi 5?

Risposta secca: se hai già un Pi 3 in casa, il monitoraggio termico e prestazionale che descrivo in questa guida è la disciplina giusta per estrarre il massimo dall'hardware. Se invece stai valutando un setup nuovo o stai pianificando un upgrade dell'hardware embedded esistente, nel 2026 il Pi 5 è la scelta razionale. Il delta di prezzo è di poche decine di euro, e il salto applicativo è di un'intera generazione.

Nei progetti che gestisco per piccole aziende italiane che devono sostituire installazioni Pi 3 invecchiate, la raccomandazione tipica è il bundle Raspberry Pi 5 8GB con Active Cooler, Case, alimentatore 27W e cavi dual 4K Micro HDMI: tutto quello che serve in una scatola, alimentazione corretta dimensionata (i 27W del Pi 5 contro i 12,5W del Pi 3), case con canalizzazione termica integrata. Per progetti più snelli o per chi è autonomo sugli accessori, Pi 5 4GB board-only o Pi 5 16GB board-only sono le opzioni asciutte. Il modello 16GB diventa rilevante solo per workload di container Docker multipli o AI/ML inference locale; per uso media center, retro gaming, server domestico, 4GB sono sufficienti. Una via di mezzo è il bundle Pi 5 4GB con Case, Alimentatore 27W e Active Cooler.

Sulla MicroSD vale una regola che ho imparato a forza di chiamate di assistenza: nessuna scheda economica regge un Pi acceso H24 oltre i sei-otto mesi prima di iniziare a corrompere il filesystem. Le uniche due MicroSD che uso nei miei Pi e che raccomando ai clienti sono SanDisk Extreme PRO 64GB e Samsung PRO Plus 128GB, entrambe A2-rated con TBW dichiarato sostanziale. Costano il doppio di una scheda generica e durano cinque-sei volte di più, e il valore vero non è il prezzo della scheda, è non doverti rifare il setup ogni sei mesi.

I numeri di benchmark che leggi più sotto in questa guida sono raccolti in modo più sistematico, con tabelle comparative cross-modello (Pi 3B+, Pi 4B, Pi 5) e con il confronto applicativo completo (Kodi 4K, Docker NGINX, NVMe, AI inference, kernel build), nella mia guida dedicata all'upgrade verso il Pi 5, che include anche timeline di lancio dei vari modelli e bundle attualmente disponibili in commercio.

Pi 4 nel 2026: alternativa quasi sempre sconveniente

Il Pi 4 ha attualmente un prezzo solo leggermente inferiore al Pi 5, e il delta non giustifica un upgrade verso una piattaforma di una generazione precedente. Se hai vincoli specifici (compatibilità HAT, consumo energetico minimo per scenari batteria, budget rigido), le opzioni Pi 4 sono Pi 4 8GB board-only, Pi 4 4GB board-only, Pi 4 2GB board-only per setup minimali, o il bundle Pi 4 8GB con Case, Alimentatore 15W, dissipatori passivi e cavo Micro HDMI 4K. Per qualunque caso non vincolato, il Pi 5 è la scelta migliore.

Cosa cambia davvero in pratica fra Pi 3 e Pi 5 sui workload più frequenti?

Il quadro applicativo, basato su benchmark di workload reale e non su numeri sintetici astratti, è chiaro:

Kodi e media center: Pi 3 limitato a 1080p hardware-decoded, Pi 5 supporta dual 4Kp60 con HEVC hardware accelerato e ha eliminato il vecchio H.264 IP block del Pi 3/4 (che limitava la decodifica H.264 a 8-bit 1080p). Sul Pi 5 il 4K H.264 e HEVC funzionano fluidi out of the box.

RetroPie ed emulazione: Pi 3 copre fino a N64 e PSX decentemente; Pi 5 fa partire fluidi PSP, GameCube, Nintendo DS, con enhancement 1080p sui sistemi più vecchi. RetroPie ufficiale richiede compilazione manuale sul Pi 5 (~2 ore), ma Recalbox e Batocera hanno immagini precompilate Pi 5 ready.

Server domestico LAMP/PHP: Pi 3 limitato a 1 GB RAM ed Ethernet via USB 2.0 (massimo ~300 Mbps reali); Pi 5 ha 4-8-16 GB e Gigabit Ethernet vera (~941 Mbps reali misurati), supporta NVMe via PCIe 3.0 portando lo storage a 1500-3000 MB/s rispetto ai 30-50 MB/s di MicroSD su Pi 3.

Container Docker e self-hosting: Pi 5 con 8 o 16 GB regge una decina di container concorrenti senza fatica; Pi 3 si arrende a tre per limiti di RAM. Compilare il kernel Linux 6.6 sul Pi 5 prende 42 minuti su NVMe contro 1h 58min su MicroSD: 2,8× di speedup solo cambiando storage layer.

AI/ML inference locale: Pi 5 fa girare modelli leggeri (TensorFlow Lite, ONNX Runtime, piccoli LLM ottimizzati); Pi 3 è strutturalmente fuori dal gioco.

Per chi resta sul Pi 3 perché ha vincoli specifici (consumo energetico minimo, hardware esistente che vale la pena monitorare), il workflow di osservabilità che segue è quello giusto.

Come si misura davvero la temperatura del Raspberry Pi nel 2026?

Il comando di base è rimasto invariato dal 2018: vcgencmd measure_temp restituisce la temperatura del SoC in gradi Celsius con precisione di un decimale. Il SoC è il chip Broadcom (BCM2837 sul Pi 3, BCM2837B0 sul Pi 3B+, BCM2711 sul Pi 4, BCM2712 sul Pi 5), e contiene sia la CPU ARM sia la GPU VideoCore. La temperatura riportata è quella di giunzione del SoC, e per il Pi 3 i valori operativi accettabili sono sotto i 70°C in continuo, idealmente sotto i 60°C. Sopra gli 80°C il firmware inizia il throttling automatico, sopra gli 85°C interviene la protezione hardware aggressiva.

Lo script di monitoraggio continuo che pubblicavo nel 2018 è ricostruibile in versione corrente come segue. Il file da creare è pi-temp.sh, eseguibile, con il seguente contenuto:

#!/bin/bash
# pi-temp.sh - monitor SoC temp, ARM frequency, throttle state
# Compatibile con Raspberry Pi 2, 3, 3B+, 4 e 5
LRED='\033[1;31m'
LCYAN='\033[1;36m'
LGREEN='\033[1;32m'
NC='\033[0m'

while true; do
    cpu_temp=$(vcgencmd measure_temp | sed 's/[^0-9.]//g')
    arm_freq=$(($(vcgencmd measure_clock arm | cut -d= -f2) / 1000000))
    core_volt=$(vcgencmd measure_volts core | sed 's/[^0-9.]//g')
    throttled=$(vcgencmd get_throttled | cut -d= -f2)

    # Color logic: green sotto 60, cyan sotto 70, red sopra
    if (( $(echo "$cpu_temp < 60.0" | bc -l) )); then
        color=$LGREEN
    elif (( $(echo "$cpu_temp < 70.0" | bc -l) )); then
        color=$LCYAN
    else
        color=$LRED
    fi

    clear
    echo -e "${color}=== Raspberry Pi monitor ===${NC}"
    echo -e "Temperature SoC : ${color}${cpu_temp}°C${NC}"
    echo -e "Frequenza ARM   : ${arm_freq} MHz"
    echo -e "Core voltage    : ${core_volt} V"
    echo -e "Throttle status : ${throttled}"
    echo ""
    echo "Premi Ctrl+C per uscire. Refresh ogni 2 secondi."
    sleep 2
done

Lo script cattura quattro metriche fondamentali a ogni ciclo: temperatura SoC, frequenza ARM corrente, voltaggio core, stato di throttling. Il valore di get_throttled è un bitmask in hex che codifica lo stato: 0x0 = tutto ok, bit 0 (0x1) = under-voltage attiva, bit 1 (0x2) = ARM frequency throttling attivo, bit 2 (0x4) = throttling attivo, bit 3 (0x8) = soft temp limit attivo. I bit 16-19 sono i corrispondenti "occurred since boot" (eventi storicizzati). Per esempio 0x50000 significa che under-voltage e throttling si sono verificati in passato ma sono ora rientrati, mentre 0x50005 significa che si stanno verificando ora.

Per uso quotidiano la sintassi colorata sopra è sufficiente. Per logging permanente vale la pena scrivere su file CSV con timestamp, che permette analisi a posteriori. Una variante minimale per cron a intervalli regolari (ogni minuto) è:

#!/bin/bash
# pi-temp-log.sh - append CSV row to /var/log/pi-temp.csv
ts=$(date -u +%Y-%m-%dT%H:%M:%SZ)
temp=$(vcgencmd measure_temp | sed 's/[^0-9.]//g')
freq=$(($(vcgencmd measure_clock arm | cut -d= -f2) / 1000000))
throttle=$(vcgencmd get_throttled | cut -d= -f2)
echo "${ts},${temp},${freq},${throttle}" >> /var/log/pi-temp.csv

Inserito in crontab con * * * * * /usr/local/bin/pi-temp-log.sh, produce un dataset minuto-per-minuto che si interroga con qualunque tool di analisi (semplice awk, importazione in Grafana via tail di file, push a Prometheus via node_exporter custom).

Come si fa benchmark prestazionale corretto su Raspberry Pi?

Il benchmark serve a quattro scopi distinti che vale la pena tenere separati. Primo: validare la stabilità di un overclock. Secondo: confrontare prestazioni prima e dopo modifiche hardware (aggiunta dissipatore, ventola, alimentatore migliore). Terzo: verificare comportamento sotto carico reale prolungato. Quarto: identificare degradi nel tempo (un Pi che dopo sei mesi ha throughput ridotto del 15% sotto stesso benchmark è un campanello di allarme su accumulo polvere o invecchiamento componenti).

Il tool che uso come standard è sysbench, disponibile via apt: sudo apt install -y sysbench. La sua API è cambiata fra le versioni 0.4 (storica, ancora in alcune guide del 2018) e 1.0+ (corrente, sintassi diversa). La sintassi 2026 corretta per CPU benchmark è:

sysbench cpu --cpu-max-prime=20000 --threads=4 --time=60 run

Il parametro --cpu-max-prime=20000 definisce la complessità: il test calcola tutti i numeri primi fino a 20.000, ed è una metrica computazionalmente intensa che stressa la ALU del SoC. --threads=4 saturate i quattro core del Pi 3/3B+/4 (sul Pi 5 è ancora 4 ma con architettura più moderna). --time=60 esegue per 60 secondi. L'output riporta "events per second" e "events per second per thread", e questi sono i numeri da confrontare prima/dopo per valutare incrementi prestazionali.

Per stress test continuo che verifica la stabilità termica oltre alle prestazioni, il tool è stress-ng: sudo apt install -y stress-ng. Il comando standard che uso è:

stress-ng --cpu 4 --cpu-method matrixprod --timeout 30m --metrics-brief

Questo lavora i 4 core con il metodo matrixprod (moltiplicazione matriciale, computazionalmente pesante e termicamente impegnativa) per 30 minuti. Durante l'esecuzione, lo script pi-temp.sh in una shell parallela mostra l'evoluzione termica in tempo reale. Il pattern di temperatura che cerco è: rampa iniziale di 3-5 minuti fino a stabilizzazione, poi plateau termico per il resto del test sotto la soglia di throttling. Se la temperatura continua a crescere oltre i 5 minuti, il sistema di dissipazione è insufficiente. Se entra in throttling (la frequenza ARM scende sotto il valore overcloccato), l'overclock che hai impostato è teorico, non reale.

Per benchmark del filesystem (importante per Pi che girano server LAMP, database, applicazioni I/O-intensive), hdparm per la lettura sequenziale dalla MicroSD:

sudo hdparm -tT --direct /dev/mmcblk0

Restituisce due valori: cached reads (memoria, irrilevante) e buffered disk reads (lettura sequenziale dalla SD, questo è il numero che conta). MicroSD economiche stanno tipicamente sui 20-40 MB/s, MicroSD A1/A2 di qualità (come la SanDisk Extreme PRO o la Samsung PRO Plus 128GB che raccomando) sui 60-90 MB/s. Per scritture sequenziali, dd è il classico:

dd if=/dev/zero of=/tmp/test.bin bs=1M count=1024 conv=fsync

Scrive 1 GB sulla MicroSD e riporta il throughput. Il flag conv=fsync è essenziale perché forza il flush finale e include il tempo di sync, senza il quale i numeri sono ottimisticamente sopravvalutati per via della buffer cache del kernel.

Per benchmark di rete, iperf3 è lo standard. Su un altro device della rete (PC, server) si lancia iperf3 -s, sul Raspberry iperf3 -c <ip-server> -t 30. Il throughput misurato è quello effettivo della rete + USB stack. Sul Pi 3B+ con Ethernet "Gigabit" via USB 2.0, ti aspetti circa 200-300 Mbps reali, ben sotto al teorico Gigabit. Sul Pi 4/5, la Gigabit reale arriva (~940 Mbps).

Cosa cambia fra Pi 3, Pi 4 e Pi 5 dal punto di vista del benchmark?

Il workflow di benchmark è identico cross-modello, ma i numeri di riferimento cambiano significativamente e vale la pena conoscerli per non confondere risultati che dipendono dal modello con risultati che dipendono dal tuo setup. Sul Raspberry Pi 3 Model B stock (1,2 GHz), il benchmark sysbench CPU con --cpu-max-prime=20000 e 4 thread restituisce tipicamente intorno ai 1100-1300 events/sec. Con overclock a 1,3 GHz e dissipazione adeguata sale a 1300-1500. Il Pi 3 Model B+ (1,4 GHz stock) parte da 1500-1700 senza overclock. Il Pi 4 (1,5 GHz, architettura BCM2711 più moderna con A72 invece di A53) salta nettamente sopra: 4500-6000 events/sec stock, fino a 7000+ con overclock a 1,8 GHz e dissipazione attiva. Il Pi 5 (BCM2712, A76, 2,4 GHz stock) raddoppia ancora: 11000-14000 events/sec stock, un fattore 8-10× rispetto al Pi 3 Model B di partenza.

Su benchmark del filesystem MicroSD, le differenze sono meno marcate perché dipendono più dalla SD usata che dal SoC. Il Pi 4 ha portato il bus MicroSD a SDR104 (UHS-I) raddoppiando il throughput teorico rispetto al Pi 3. Il Pi 5 ha mantenuto SDR104 ma aggiunto NVMe via PCIe Gen 2 attraverso il connettore HAT dedicato, che porta storage performance su un livello completamente diverso (1500-3000 MB/s con NVMe Gen 3 supportato in modalità degraded). Per un'installazione embedded che richiede I/O storage seri, il Pi 5 con SSD NVMe è strutturalmente diverso dalle generazioni precedenti.

Sui benchmark di rete, il Pi 4 ha sbloccato il vincolo USB 2.0 dei modelli precedenti: la Gigabit Ethernet del Pi 4 e del Pi 5 viaggia su bus dedicato e raggiunge i 940 Mbps reali, contro i 200-300 Mbps reali del Pi 3B+. Per applicazioni server o NAS la differenza è enorme.

Come si interpreta il get_throttled per troubleshooting?

Il bitmask di vcgencmd get_throttled è la diagnostica più importante per capire perché un Raspberry Pi non sta andando come dovrebbe. La codifica completa è documentata nei forum ufficiali Raspberry Pi e nella documentazione del firmware. I bit rilevanti sono:

• 0x1 - under-voltage detected: l'alimentatore non sta fornendo abbastanza corrente. Sintomi: reboot apparentemente casuali, instabilità sotto carico USB. Soluzione: alimentatore da almeno 2,5 A a 5 V (3 A consigliato per overclock) con cavo dedicato non condiviso. Per Pi 5 serve l'alimentatore ufficiale 27W incluso nei bundle.
• 0x2 - ARM frequency capped: il SoC sta limitando la frequenza ARM. Quasi sempre triggered da under-voltage o da temperatura.
• 0x4 - currently throttled: throttling termico attivo ora. Soluzione: dissipazione migliore.
• 0x8 - soft temp limit active: stai sopra la soglia temp_limit impostata in config.txt. Comportamento volontario, non un errore. Se non lo vuoi, alza la soglia (a tuo rischio).
• 0x10000-0x80000 - bit "occurred since boot" delle quattro condizioni precedenti, storicizzati.

Il pattern operativo che applico nelle installazioni che monitoro è leggere get_throttled ogni minuto via lo script CSV, e flaggare automaticamente eventi sopra 0x10000. Pattern frequenti che catturo: under-voltage transienti che si manifestano sotto carico USB intenso (chiavette, hard disk esterni alimentati dal Pi) e che indicano necessità di alimentatore migliore; throttle termico che si manifesta solo nei mesi caldi e indica sotto-dimensionamento del cooling per il caso peggiore d'estate; under-voltage durante boot che indica BootROM lento per via di MicroSD economica.

Come si automatizza l'alerting per non doverlo guardare manualmente?

Per installazioni con più di un Pi o per Pi che girano in scenari embedded dove non sei fisicamente vicino al dispositivo, il logging CSV su file è il punto di partenza ma non basta. Serve alerting che ti notifica quando una soglia critica viene superata. Tre approcci, in ordine di sofisticazione crescente.

Primo approccio: cron + script + email. Lo script pi-temp-log.sh mostrato sopra può essere esteso con una verifica di soglia che, se superata, invoca mail o curl verso un webhook (es. Slack, Telegram, Discord). È sufficiente per scenari semplici e singolo Pi, costo zero, niente infrastruttura aggiuntiva.

Secondo approccio: Prometheus + node_exporter + Alertmanager. Per flotte di 5+ Pi gestite in modo professionale, il pattern standard è esporre le metriche di vcgencmd via un piccolo exporter custom (Python o Bash che scrive su un file /var/lib/prometheus/node-exporter/pi-temp.prom formato textfile collector) e lasciare che node_exporter ufficiale lo serva su porta 9100. Un Prometheus centrale fa scrape ogni 30 secondi, Grafana visualizza dashboards, Alertmanager invia notifiche su Slack/email quando le soglie vengono superate. Setup iniziale di un'ora, poi gira da solo.

Terzo approccio: agente con autoremediation. Per scenari embedded distribuiti dove l'intervento manuale è costoso, lo script di monitoring può anche prendere azioni automatiche: ridurre frequenza arm via vcgencmd cache_flush, attivare la ventola PWM al massimo, eseguire un reboot pianificato se il throttle persiste. È un livello di operatività che richiede design accurato (un agente che fa reboot automatico può causare reboot loop se il problema è hardware), ma per certi scenari è la differenza fra una flotta che si auto-recupera e una flotta che genera ticket di intervento.

Le risorse autorevoli che continuo a consultare sono la documentazione ufficiale di vcgencmd su raspberrypi.com e la documentazione di config.txt per i parametri termici. Per benchmark approfonditi e confronti cross-modello, i thread dei forum ufficiali Raspberry Pi restano la fonte più ricca di dati comparativi reali, perché aggregano centinaia di misurazioni da setup differenti.

Per chi gestisce flotte di Raspberry Pi in scenari embedded di produzione (digital signage, totem informativi, sensoristica IoT distribuita, dashboard di monitoring) e vuole strutturare un workflow di osservabilità termica e prestazionale che permetta manutenzione predittiva invece che reattiva, il mio profilo professionale include esperienze concrete di setup di telemetria centralizzata su Pi (push di metriche a Prometheus via node_exporter, dashboard Grafana, alerting su soglie configurabili). La differenza tra una flotta che richiede interventi mensili e una flotta che gira affidabile per cinque anni è quasi tutta nel layer di osservabilità: senza monitoring continuo, ogni Pi è una scatola opaca che si rompe senza preavviso. Con monitoring continuo, i degradi si vedono settimane prima del fallimento e si interviene proattivamente. Se hai un progetto di scala con Raspberry Pi che merita questo livello di disciplina operativa, contattami direttamente per inquadrare il setup di telemetria appropriato fin dall'inizio. Le guide complementari su questo blog includono l'overclock ottimizzato del Pi 3 e i dissipatori attivi DIY o commerciali per Pi 3, che insieme a questa pagina formano la trilogia operativa per chi vuole spremere il massimo da hardware Pi 3 esistente prima di valutare un upgrade.

Disclosure affiliazione

Questo articolo contiene link di affiliazione al programma Amazon Associates (Affiliato Amazon). Quando clicchi su un link e completi un acquisto idoneo, ricevo una piccola commissione dal venditore senza alcun costo aggiuntivo per te. Questa pratica è regolata dalle linee guida AGCOM 2026 sulla trasparenza pubblicitaria, dal Codice del Consumo italiano e dall'Operating Agreement del programma Amazon Associates. I prodotti che linko sono esclusivamente quelli che uso personalmente o che raccomando con convinzione nei progetti embedded e di consulenza che gestisco. Non promuovo prodotti che non userei in prima persona.