Overclock stabile del Raspberry PI 3

Overclock stabile del 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.

Avviso di sicurezza: l'overclock del Raspberry Pi 3 non è ufficialmente supportato dalla Foundation. La configurazione force_turbo=1 con over_voltage > 0 attiva il warranty bit nel firmware in modo permanente, invalidando la garanzia. Procedete a vostro rischio. Senza dissipazione adeguata il SoC raggiunge gli 85°C e va in shutdown automatico.

L'overclock stabile del Raspberry Pi 3 con force_turbo=1 è una configurazione specifica per scenari always-on, dove la board lavora continuativamente sotto carico e ha senso che giri sempre al massimo della frequenza senza dynamic scaling. Tipicamente: media center Kodi acceso 24h/24, server domestico LAMP che serve continuamente, dashboard di monitoring sempre attiva su display industriale. È un approccio diverso rispetto all'overclock ottimizzato con scaling dinamico che ho documentato in un articolo separato per scenari ad uso intermittente.

Prima di entrare nel merito tecnico, però, la domanda che vale la pena fare nel 2026 è preliminare: stai overcloccando un Pi 3 perché ne hai uno e vuoi spremerlo, oppure stai pianificando un setup nuovo? La risposta cambia radicalmente la strategia ottimale, e in molti casi convince a saltare l'overclock e passare direttamente al Pi 5.

Conviene overcloccare un Pi 3 nel 2026 o passare al Pi 5?

Risposta secca: se non hai già un Pi 3 e devi acquistare hardware nuovo, prendi direttamente un Pi 5. Un Pi 5 stock (Cortex-A76 quad 2,4 GHz) supera nettamente un Pi 3 spinto al massimo (Cortex-A53 quad 1,4 GHz) in tutti i benchmark applicativi reali, di un fattore 5-6× sulla CPU e 2,8× sulla GPU. La differenza di prezzo fra un Pi 3B+ nuovo e un Pi 5 4GB sui listini italiani correnti è di poche decine di euro: non è una scelta che si gioca sul costo, è una scelta che si gioca sul valore.

I bundle Pi 5 attualmente più sensati sono il Raspberry Pi 5 8GB con Active Cooler ufficiale, Case, alimentatore 27W e cavi dual 4K Micro HDMI per chi vuole tutto pronto, o il bundle Pi 5 4GB con Case, Alimentatore 27W e Active Cooler se 4 GB di RAM ti bastano. Per chi vuole solo la board e ha già accessori, Pi 5 4GB board-only o Pi 5 16GB board-only sono le opzioni asciutte. Ho dedicato una guida estesa al confronto Pi 3/Pi 4/Pi 5 e ai bundle disponibili in commercio con tabelle comparative dettagliate sull'hardware e benchmark applicativi reali (Kodi 4K, Docker, NVMe, AI inference, kernel build).

Sulla MicroSD, indipendentemente dal modello scelto, vale una regola che ho consolidato 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, entrambe A2-rated con TBW dichiarato sostanziale. Costano il doppio di una MicroSD generica e durano cinque-sei volte di più.

Se per qualche ragione specifica devi prendere un Pi 4 (compatibilità HAT precisi, consumo minimo per applicazioni a batteria, budget rigido), le opzioni sono Pi 4 8GB Modello B board-only, Pi 4 4GB board-only, o il bundle Pi 4 8GB con Case, Alimentatore 15W, dissipatori passivi e cavo Micro HDMI 4K. Il Pi 4 2GB board-only è sconsigliato per qualunque uso non triviale nel 2026.

Per chi resta sul Pi 3 perché ha già la board e vuole spremerla, la guida tecnica che segue resta valida e produce un overclock stabile a 1350 MHz adatto a scenari 24/7 sempre attivi.

Perché serve davvero la dissipazione prima di overcloccare?

Il SoC Broadcom BCM2837 del Pi 3 Model B (rispettivamente BCM2837B0 sul Pi 3 Model B+) ha due soglie firmware-impostate. La prima è a 80°C, dove il sistema riduce proattivamente le frequenze per evitare di salire ulteriormente. La seconda è a 85°C, dove il throttling diventa aggressivo e in casi estremi il sistema si spegne per autoprotezione.

Provando a impostare questo overclock su un Pi 3 senza alcun sistema di dissipazione, il sistema raggiunge gli 85°C in pochi minuti sotto carico Kodi o RetroPie e va in shutdown automatico. Non è un'opzione: la dissipazione attiva (o almeno passiva ben fatta) è prerequisito non negoziabile per qualunque overclock stabile. Ho documentato il setup di dissipatori attivi DIY o commerciali per Raspberry Pi 3 in una guida separata, dove copro il pattern del ponte termico stratificato con materiali recuperati e le alternative commerciali correnti (ICE Tower, dissipatori Argon, soluzioni passive Flirc).

Il secondo prerequisito è l'alimentazione adeguata. Il Pi 3B richiede ufficialmente 2,5 A a 5 V (12,5 W). Sotto overclock con periferiche USB collegate la richiesta sale facilmente a 13-14 W di picco. Alimentatori sotto specifica producono brownout silenziosi che si manifestano come reboot apparentemente casuali, corruption del filesystem, o instabilità intermittente. Per scenari 24/7 con force_turbo=1 uso esclusivamente alimentatori da almeno 3 A a 5 V con cavo dedicato non condiviso.

Configurazione di overclock stabile a 1350 MHz

Modificare il file di configurazione boot del Raspberry Pi (sul Raspberry Pi OS Bookworm il path è /boot/firmware/config.txt, sui sistemi pre-Bookworm è /boot/config.txt):

sudo nano /boot/firmware/config.txt

Aggiungere queste righe in fondo al file:

# Pi 3 - overclock stabile 1350 MHz per scenari 24/7 sempre attivi
arm_freq=1350                # frequenza ARM (default 1200 Pi 3, 1400 Pi 3B+)
core_freq=500                # frequenza GPU core (default 400)
sdram_freq=500               # frequenza SDRAM (default 450)
over_voltage=5               # voltage adjust (sopra 6 attiva warranty bit; 5 è il limite "sicuro")
gpu_freq=400                 # frequenza GPU (lascia il default sotto la CPU)

# Allocazione memoria GPU (se la usi per Kodi/decoding video)
gpu_mem=256                  # MB dedicati alla GPU (256 sufficiente per Kodi 1080p)

# Modalità always-on
force_turbo=1                # CPU sempre alla frequenza max, no dynamic scaling
                             # Attiva warranty bit se over_voltage > 0
boot_delay=1                 # Riduce errori di corruzione SD con force_turbo

# Protezione termica
temp_limit=80                # default 85, sotto questa soglia mantiene il clock
disable_splash=1             # boot più rapido per scenari kiosk/media center

Le scelte specifiche di questa configurazione, con la motivazione tecnica.

arm_freq=1350: il Pi 3 Model B di default gira a 1200 MHz, il Pi 3 Model B+ a 1400 MHz. La soglia di 1350 MHz è un compromesso che funziona bene su entrambi i modelli per il pattern always-on. Sul Pi 3B originale è un overclock del 12,5%; sul Pi 3B+ è un leggero downclock dal 1400 di default per maggiore margine termico in scenari sempre attivi.

force_turbo=1: questa è la differenza chiave rispetto all'overclock ottimizzato con scaling dinamico. Con force_turbo=1, il governor cpufreq viene disabilitato e la CPU resta sempre alla frequenza massima (arm_freq), anche in idle. Per scenari intermittenti è uno spreco energetico (il Pi consuma di più anche quando non sta facendo niente), ma per scenari sempre sotto carico ha tre vantaggi concreti: latenza prevedibile (no spike di scaling), zero throttle gaps fra idle e load, vita batteria irrilevante (siamo alimentati da rete).

over_voltage=5: è il valore più alto che si può impostare senza scivolare in territorio "rischio danneggiamento". Sopra 6 il firmware attiva flag aggressive che la Foundation considera "out of warranty even at your own risk". A 5 si ottiene il voltaggio aggiuntivo necessario per stabilità a 1350 MHz senza danneggiare il SoC nel medio periodo. Il warranty bit è comunque attivato perché force_turbo=1 con over_voltage > 0 lo triggera; se la garanzia ti interessa, ridimensiona over_voltage=4 e accetta possibile instabilità.

temp_limit=80: il default è 85°C, ma settarlo a 80°C lascia 5 gradi di buffer prima del throttling automatico. La VideoCore monitora la temperatura ogni qualche millisecondo, e quando supera la soglia abbassa automaticamente le frequenze fino al ripristino delle condizioni di sicurezza. È protezione attiva integrata, non si può bypassare in modo sano.

gpu_mem=256: alloca 256 MB di RAM alla GPU per accelerazione hardware video. È il valore consigliato per scenari Kodi 1080p; per scenari server pure (no video) puoi ridurre a 64 o 128 MB recuperando RAM per le applicazioni.

Salvare il file (Ctrl+O, Enter, Ctrl+X in nano) e riavviare:

sudo reboot

Come verificare che l'overclock sia attivo e stabile

Dopo il reboot, prima cosa: verificare che il sistema sia effettivamente partito alla frequenza configurata. Con vcgencmd:

vcgencmd measure_clock arm
# Output atteso: frequency(48)=1350000000 (= 1350 MHz)

vcgencmd measure_volts core
# Output atteso: volt=1.3750V (valore tipico con over_voltage=5)

Per il monitoraggio termico continuo, lo script che uso è documentato nella mia guida al controllo temperatura e benchmark del Raspberry Pi 3, che include la versione completa con colori, alerting, logging CSV per analisi storica.

Il benchmark sintetico per validare il guadagno prestazionale è sysbench:

sudo apt-get install -y sysbench
sysbench cpu --cpu-max-prime=20000 --threads=4 --time=60 run

Su un Pi 3 Model B stock (1200 MHz), sysbench --cpu-max-prime=20000 con 4 thread completa intorno ai 1100-1300 events/sec. Con questa configurazione di overclock a 1350 MHz e dissipazione adeguata, il throughput sale di circa il 12-15%, in linea con l'incremento di clock. Non aspettatevi miracoli: stiamo parlando di un overclock incrementale, non di una rivoluzione architetturale come quella che porta il salto a Pi 5.

Per il test di stabilità reale, dopo il sysbench iniziale fate girare uno stress test prolungato:

sudo apt-get install -y stress-ng
stress-ng --cpu 4 --cpu-method matrixprod --timeout 30m --metrics-brief

In parallelo, in un'altra shell, monitorate temperatura e throttle status:

watch -n 2 'vcgencmd measure_temp; vcgencmd get_throttled'

Il pattern di temperatura che cerchi è: rampa iniziale di 3-5 minuti fino a stabilizzazione, poi plateau termico per il resto del test sotto la soglia di throttling (80°C nella nostra configurazione). Il valore di get_throttled dovrebbe restare a 0x0. Se sale a valori che includono il bit 16 (0x10000) o superiori, hai avuto throttling: la dissipazione è insufficiente per questo overclock e il sistema sta lavorando a frequenze ridotte.

Il test che separa overclock teorico da overclock reale

Una nota di metodologia che ho consolidato: il segnale più affidabile di overclock instabile non è il crash sotto stress sintetico, è il silent data corruption che emerge solo dopo ore di operatività in carico realistico. Pi 3 che superano stress-ng per 30 minuti senza errori possono comunque produrre corruzioni del filesystem dopo otto-dieci ore di Kodi che decodifica video e scrive cache su MicroSD. Il test che applico oggi è duplice: stress-ng sintetico per identificare il floor di stabilità immediata, seguito da 24 ore di workload realistico prima di considerare la configurazione production-ready.

Per scenari 24/7 dove il pattern è esattamente quello dell'esempio originale di questo articolo (Pi 3 con Kodi sempre acceso, biblioteca media accessibile da smartphone e tablet di casa), il workload realistico è semplice da generare: lasci il Pi acceso con Kodi attivo, processi una libreria con cover art che scarica miniature in continuo, fai partire qualche video in background per stress sulla GPU. A fine 24 ore controlli il dmesg per errori del filesystem, controlli la suite di test della libreria Kodi (i video aperti partono o no?), confronti l'hash delle cache prima/dopo. Se nulla è corrotto, la configurazione è stabile.

Quando ha ancora senso un Pi 3 overcloccato a 1350 MHz nel 2026?

Tre scenari precisi. Primo: hai un Pi 3 dedicato a media center Kodi sempre acceso e vuoi un boost del 12-15% di prestazioni a costo zero. Configurazione perfettamente sensata, e il pattern always-on force_turbo=1 è quello giusto per questo caso d'uso. Secondo: hai un Pi 3 dedicato a RetroPie con emulazione PSX/N64 dove il margine di clock fa la differenza fra emulation a 60fps stabili e drops percettibili. Terzo: hai un'installazione embedded long-term con consumo energetico ancora accettabile (~7-9 W medi sotto carico) e durata target oltre i 5 anni, dove la conferma di produzione del Pi 3B+ fino al 2030 garantisce ricambi disponibili.

Per tutti gli altri casi, il Pi 5 non overcloccato supera nettamente questo setup. Un Pi 5 stock fa girare Kodi 4K HEVC hardware-decoded (cosa che il Pi 3 non riesce a fare nemmeno a 1500 MHz), Plex direct play in dual-stream, container Docker concorrenti, AI inference leggera. La differenza non si paga in numeri di benchmark, si paga in giornate di lavoro risparmiato e in feature che semplicemente non sono disponibili sull'hardware del 2016.

Se hai un progetto Raspberry Pi che vuoi strutturare in modo professionale fin dall'inizio, dalla scelta del modello giusto al provisioning, dal monitoring termico alla disaster recovery, il mio profilo professionale include esperienze concrete di setup di flotte di Pi in scenari embedded di produzione, con disciplina di provisioning automatizzato, monitoring centralizzato e disaster recovery.

Per chi gestisce installazioni Pi su scala (digital signage, totem informativi, sensoristica IoT distribuita, dashboard di monitoring), la differenza tra una flotta che funziona affidabilmente per cinque anni e una che genera ticket ogni mese è quasi tutta nelle prime ore di setup: scelta della MicroSD (SanDisk Extreme PRO 64GB o Samsung PRO Plus sono le uniche che uso), alimentazione correttamente dimensionata, dissipazione adeguata al carico atteso, monitoring termico continuo, hardening del filesystem per ridurre wear sulla SD. Se vuoi inquadrare il setup giusto per il tuo progetto specifico prima di committare hardware, contattami direttamente per una valutazione iniziale. Una review di un'ora identifica spesso scelte che ripagano per anni di operatività affidabile.

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 (D.Lgs. 206/2005) 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.

Ultima modifica: