Spostamento server

Ho dovuto di nuovo spostare il sito su un altro server cambiando sistema operativo. Sono rimasto piuttosto perplesso nei confronti delle instabilità mostrate dalla Raspbian Wheezy sul Raspberry: prima ha cominciato a funzionare male la ZenCache poi addirittura a fronte dell’aggiornamento del Kernel alla versione 4.1 dopo poche ore il sito diventava irraggiungibile e addirittura il Raspberry non era più accessibile via SSH. Unica soluzione il reboot. La cosa brutta è che a differenza del primo caso i log di sistema non mi hanno permesso di ricostruire la natura del problema. Insomma, ora il blog gira su un Banana Pro dotato della stabilissima Bananian (kernel 3.4.108) e mi sembra che sia migliorato come velocità di accesso non fosse altro perché ora il server ha a disposizione una ethernet Gigabit ( e non fast-ethernet) e un “vero” hard disk collegato alla porta SATA. Ho provato un po’ di tutto su queste schede ma devo dire che l’accoppiata Banana Pi/Pro e Bananian 15.08 headless per questo tipo di attività non si batte.

Sensori: perché e meglio usare Arduino

E’ una problematica ben nota, con cui mi sono scontrato anche io i primi tempi che tentavo di usare svariati tipi di sensori con il Raspberry. Mentre lo stesso sensore su Arduino mostrava una affidabilità praticamente ideale, usato con Linux sia su Raspberry che su Banana Pro mi dava una percentuale piuttosto alta (20 – 25%) di letture fallite. Il motivo è piuttosto semplice: il microcontrollore (di qualsiasi tipo sia) presente su una scheda Arduino dedica totale attenzione al codice che sta girando nello sketch e dal momento che molti sensori richiedono timings piuttosto precisi per funzionare (stiamo parlando di microsecondi) questa alta priorità di esecuzione fa sì che praticamente ogni lettura di un qualsiasi sensore vada a buon fine.

Per un sistema operativo complesso come Linux purtroppo le cose non vanno altrettanto bene. Nonostante i kernel per schede come i Raspberry e via dicendo siano compilati generalmente con delle patch di tipo PREEMPTIVE, per gestire appunto processi di tipo real-time, si tratta comunque di un sistema operativo continuamente impegnato a gestire richieste di processi di sistema per controllare l’hardware collegato, la memoria, schedulazioni di vario genere che chiedono senza pausa l’attenzione della CPU (si chiamano interruzioni o interrupt).  Quindi il microprocessore della scheda non è mai a riposo e quando mandiamo in esecuzione il nostro codice di gestione dei sensori, sia esso scritto in Python o in C, non è assolutamente detto che riesca ad ottenere dalla CPU quella continua “attenzione” che servirebbe per gestire temporizzazioni di millisecondi e addirittura microsecondi.

Il risultato all’atto pratico? Ad esempio un normale sensore DHT11 o DHT22 darà letture fallite su Linux con una percentuale di circa il 20-25%, come ho potuto verificare sperimentalmente. Non oso pensare poi ai fatidici 10 microsecondi necessari all’HC SR04 per inviare il segnale di andata, e a tanti altri casi simili. Basta guardare ad esempio il codice della libreria Adafruit per i sensori DHT: è previsto al loro interno un retry delle letture per ben 15 volte prima di far uscire i dati, e nonostante tutto questo è possibile ancora il fallimento della lettura stessa. Niente del genere sulle stesse librerie per Arduino, lì andiamo praticamente a colpo sicuro. Ho il DHT22 sul prototipo della stazione meteo che ha accumulato più di 20000 letture (1 ogni minuto) senza fallire un colpo, ma è pilotato da un Arduino Nano.

Tutto questo discorso ovviamente non per farne una colpa a Linux. E’ un sistema operativo, ha una moltitudine di cose da fare, e per quanto si sforzi non riesce a fare di meglio nei processi di tipo real-time. Almeno con queste piccole schede e senza un kernel fortemente specializzato. Nei processi di controllo industriale la musica cambia, laddove vengono utilizzati altri tipi di macchine.

Concludendo direi che volendo mantenere un livello di affidabilità molto alto farei pilotare a schede come Raspberry e simili solamente attuatori, lasciando il compito delicato di gestire l’acquisizione di grandezze a schede della famiglia di Arduino, evidentemente in colloquio con le prime. Tutto questo mi ha portato a progettare la mia stazione meteo basandosi su Arduino, delegando al Raspberry la sola scrittura delle informazioni su un database MySql. Fare tutto con il Raspberry avrebbe certamente semplificato l’hardware del progetto ma…….

 

Raspbian Wheezy – Se il firewall non funziona

Scaricata ed installata la Raspbian Wheezy dal sito ufficiale del Raspberry ho avuto la necessità di impostare IPTABLES, ovvero il firewall di Linux. Avevo già effettuato i classici comandi < apt-get update > e < apt-get upgrade > per l’aggiornamento della distro ma quando ho chiesto lo stato delle chain con < iptables -vnL > ho ricevuto in risposta questo errore:

Sintomo di un disallineamento tra kernel e iptables stesso. Va dato quindi un comando ulteriore < rpi-update > per sistemare tutto. Dopo questo ulteriore aggiornamento iptables funzionerà correttamente.

Cambio look

GrepPipeLinux cambia aspetto. Questo nuovo tema è un po’ più pesante del precedente, ma pur rimanendo piuttosto essenziale nella grafica mi sembra migliori la leggibilità del sito, soprattutto negli sketches. Stavolta ho dovuto abilitare ZenCache per alleviare un po’ il carico del web server. Ricordo che questo sito gira su un Raspberry Pi2 dedicato con installata RedSleeve 7.1

RedSleeve 7.1 – Kernel 4.1.6

Tra i vari repository YUM di cui bisogna cambiare i puntamenti nell’immagine originale c’è anche il raspberry.repo, che contiene solamente il Kernel e il firmware specifico per la scheda, nel mio caso il Rasberry Pi2. Dal momento che contiene un Kernel 4 ho voluto aggiornare la distro per provarlo.

Questo è il file /etc/yum.repos.d/raspberry.repo da sostituire all’originale:

Una volta salvato con il comando yum upgrade viene riletto l’elenco dei repository e quindi si può procedere con lo yum update. E’ richiesto un reboot di siatema.

 

RedSleeve 7.1 – Running on GrepPipeLinux :)

Unknown-1

Oggi durante la giornata la “vecchia” Fedora 21 è letteralmente impazzita. Systemd ha cominciato a dare i numeri portando instabilità su MariaDb, Apache (che sono caduti) e perfino l’interprete di comandi. L’ho spazzata via, e ora GrepPipeLinux gira sotto RedSleeve 7.1,

Non sono riuscito a capire cosa sia successo, se un incauto update che è arrivato dai repository ufficiali della distribuzione oppure una interruzione di corrente avvenuta qualche giorno fa. Fatto sta che, data la fretta di rimettere in piedi il sito,  ho colto l’occasione per mettere ulteriormente sotto test la RedSleeve facendogli gestire un sito WordPress. E con questo l’ultima Fedora che utilizzavo se ne va in pensione 🙂

RedSleeve 7.1 – Configurare la scheda wi-fi.

Come primo test ho deciso di togliere il Raspberry con installata la RedSleeve 7.1 dallo switch di rete insieme agli altri server ed installare tramite un classico dongle wifi (solito mini-dongle basato sul chip Ralink 5370) un interfaccia wlan per poterlo portare con comodo sulla scrivania e provare a collegarlo a qualche sensore. Tutto questo senza servirsi del Network Manager ma ripetendo le procedure che ho già indicato in un mio post precedente (http://greppipelinux.synology.me/?p=13). Tutto è andato bene e l’interfaccia wlan0 funziona perfettamente. E’ già un buon inizio, ad esempio la Centos 7-arm allo stato attuale non riesce a gestire le interfacce di rete (come dovrebbe invece fare) senza il NM avviato. Ho scritto già un post sul sito ufficiale da un paio di settimane per chiedere spiegazioni in merito ma nessuna risposta.

Prossimo step le librerie GPIO per Python e C.

Radiatore passivo per la CPU del Raspberry Pi2

Akru_03

Dal momento che i miei 2 Raspberry Pi2 sono destinati ad essere accesi H24 mi sono deciso di dotarli almeno di un radiatore passivo sulla CPU per far scendere la temperatura di esercizio di qualche grado. Ce ne sono di vario tipo ma ho scelto questo kit in rame della Aukru che ne comprende un paio ad un prezzo poco inferiore agli 8 euro. Come si vede in foto sono dotati di un biadesivo costituito da una sorta di pasta conduttiva. Rimossa la protezione bianca rimane esposto uno strato nero e appiccicoso che va messo a contatto della CPU.

Akru_02

Non so quanto tempo ci voglia affinchè questa sorta di pece si stabilizzi, ma dopo circa un’ora dall’applicazione ho notato un calo della temperatura del processore di circa 5 gradi (da 49 gradi a 44 gradi) che mi sembra comunque già buono considerando che si tratta comunque di un radiatore passivo.

Akru_01

La superficie di copertura è buona, siamo appena al di sotto delle dimensioni effettive della CPU, ma è roba di poco conto. Raggiungevo la temperatura di circa 50 gradi con una temperatura ambientale di 27 gradi e con il clock massimo mantenuto ai valori nominali. Quindi quest’inverno mi aspetto ancora qualche grado in meno come temperatura di lavoro, il che non guasta.

pi2

Ho usato per i Raspberry questo tipo di contenitore che tra l’altro è progettato per il B+, quindi come si vede in figura non ha neanche il foro per la CPU perfettamente corrispondente. Per fortuna la plastica di questa copertura non è molto spessa e con un taglierino e qualche minuto di lavoro ho portato allo scoperto buona parte della scheda, il che ha permesso di migliorare la dissipazione del calore in generale e di coprire la CPU con il dissipatore.

Per il Banana Pro dovrò trovare qualcosa di differente, perché a parte il fatto che se non ricordo male la CPU ha dimensioni maggiori, ma è anche situata nella parte inferiore della scheda e quindi richiede altre soluzioni, non ultima quella di montarla “al contrario”, con il processore in alto. Anche il Banana è acceso H24 e le temperature di esercizio della CPU sono grosso modo le stesse del Raspberry.

Raspberry e Banana Pi/Pro – Leggere la temperatura della cpu

Ecco due brevi script utili per leggere la temperatura corrente della CPU rispettivamente sulle schede Rasbberry e Banana Pi/Pro. Sulla prima scheda le ho testate su distribuzioni Fedora e Centos (mi aspetto che funzioni anche sulla Redsleeve). Nel secondo caso è testato sulla Bananian,

Raspberry:

Banana Pi/Pro:

Si può ad esempio copiare il codice in uno script chiamato cpu_temp.sh nella directory /root/scripts (da creare) e dopo aver dato un comando chmod 755 cpu_temp.sh lanciarlo con ./cpu_temp.sh.