Pagine

Translate

venerdì 12 agosto 2011

HowTo - Compilazione Kernel Real Time - Parte 1

Perchè ricolpilare un kernel?

Ricompilare un Kernel vuol dire affrontare un battesimo del fuoco che prima o poi tutti gli utenti linux dovrebbero affrontare.

Un kernel ricompilato non porta molti vantaggi rispetto ai kernel così detti vanilla, ossia quelli rilasciati ufficalmente, allora perchè ricompilarlo?

La ricompilazione è spesso utile in casi di Hardware particolari non implementati nei kernel, oppure se il nostro obiettivo è creare dei kernel particolarissimi che implementano particolari specifiche non di default applicate, ad esempio: Hard real-time, server, editing Audio/Video professionale, Real Time.

Questo HowTo si riferisce a distribuzione Linux Debian, in particolare partendo da una distro UBUNTU 9.04 Kernel 2.6.28.11 è stato ricompilato in formato RealTime il kernel 2.6.33.2.

Patch dei sorgenti.

Cominciamo scaricando dal sito http://www.eu.kernel.org/pub/linux/kernel/v2.6/ l'ultima patch RealTime disponibile, quindi scaricare la versione corrispondente del kernel vanilla(estensione .bz2), nel nostro caso abbiamo scaricato i due file linux-2.6.33.2.tar.bz2 (kernel vanilla) e patch-2.6.33.2-rt13.gz (patch realtime). Salviamo questi file nella nostra home. Scarichiamo ora alcune dipendenze necessarie per la compilazione lanciando il comando.

sudo apt-get install build-essential bin86 kernel-package libncurses5 libncurses5-dev

Al termine dell'installazione scompattiamo l'archivio contenente il kernel:

tar -xvjf linux-2.6.33.2.tar.bz2

Nella directory Home sarà stata creata una cartella ./linux-2.6.33.2 con tutti i sorgenti, dopo aver scompattato la patch realtime copiamola nella stessa directory del nostro kernel sorgente. Spostiamoci nella cartella del kernel e applichiamo la patch RT:

sudo cat patch-2.6.33.2-rt13.patch|patch -p1

Al termine della procedura la patch sarà correttamente stata applicata ai sorgenti del nostro nuovo kernel. Ricordiamoci che dovrà ancora essere configurato, ricompilato installato.

Nella seconda parte, parleremo della comfigurazione.

Enjoy
Antonio


giovedì 11 agosto 2011

Sistemi Operativi Real Time (RTOS)

Un sistema operativo real-time o in tempo reale (abbreviato in RTOS) è un sistema operativo specializzato per il supporto di applicazioni software real-time. Questi sistemi vengono utilizzati tipicamente in ambito industriale (controllo di processo, pilotaggio di robot, trasferimento dati nelle telecomunicazioni) o comunque dove sia necessario ottenere una risposta dal sistema entro un tempo prefissato.

Un sistema operativo real-time non deve essere necessariamente veloce: non è importante l'intervallo di tempo in cui il sistema operativo/applicativo deve reagire; l'importante è che risponda entro un tempo massimo pre-determinato. In altre parole il sistema deve essere prevedibile.

In pratica un sistema real-time deve garantire che una elaborazione (o task) termini entro un dato vincolo temporale o scadenza (detta in gergo deadline). Per garantire questo è richiesto che la schedulazione delle operazioni sia fattibile. Il concetto di fattibilità di schedulazione è alla base della teoria dei sistemi real-time ed è quello che ci permette di dire se un insieme di task sia eseguibile o meno in funzione dei vincoli temporali dati. Solitamente i processi che si presentano in un sistema in tempo reale vengono suddivisi in due categorie:


PROCESSI HARD REALTIME:

Processi in cui il mancato rispetto dei vincoli temporali (sforamento delle deadline) comporta un effetto catastrofico sul sistema.

In generale tra gli esempi di processi hard realtime possiamo annoverare tutti quelli che hanno a che fare strettamente con l’ambiente reale circostante(sensoristica, sistemi di attuazione, controllo di dispositivi automatici)

PROCESSI SOFT REALTIME:

Processi in cui lo sforamento dei vincoli temporali comporta un degrado delle prestazioni, ma non viene compromesso il comportamento complessivo del sistema. Pensiamo per esempio al motore di rendering di un videgame, che in alcune situazioni potrebbe rallentare per via di carichi più alti del previsto con l’effetto di vedere il flusso di immagini scattare.

Nei sistemi complessi molto spesso le due categorie di processi convivono e vanno gestite contemporaneamente.


Per dare una idea generale di quello che deve essere un sistema operativo in tempo reale possiamo elencarne le caratteristiche attese:


- Gestione esplicita dei vincoli temporali:
La correttezza dei risultati è valutata non solo riguardo ai valori ma anche rispetto al parametro tempo. Un risultato che arriva in ritardo in alcuni ambiti può significare la vita o la morte di una persona.

- Prevedibilità
Il sistema deve essere sempre in grado di prevedere le conseguenze delle decisioni che si troverà a prendere.

- Tolleranza ai sovraccarichi
Bisogna prevedere l’eventualità di sovraccarichi e prendere decisioni a riguardo senza compromettere il corretto funzionamento del sistema.

- Monitorabilità
Deve conoscere se qualcosa sta andando storto al suo interno e essere in grado di segnalarlo.

- Flessibilità
Deve essere modulare per adattarsi il più possibile alle esigenze delle applicazioni che ci gireranno sopra.

Ad esempio problemi che vanno affrontati nell’ottica del “tempo reale” sono ovviamente ampiamente presenti nella società moderna. Basti pensare ai sistemi ABS delle automobili, o ai sistemi di controllo e stabilizzazione degli aeroplani.

Prossimamente inserirò un How To per la compilazione di un kernel Linux RealTime.

Enjoy
Antonio

mercoledì 1 giugno 2011

Installare Tomcat come servizio windows

In questi giorni ho avuto difficoltà ad installare Tomcat come servizio windows, poiché la versione installata era una 7.xx standalone, e quindi non installata come applicazione windows.
Per far sì che Tomcat si avvii in automatico all'avvio di windows ci sono due soluzioni:

1) Reinstallare nuovamente il pacchetto Apache Tomcat utilizzando questo link 32-bit/64-bit Windows Service Installer, questo comporta riconfigurare la piattaforma.

2) Copiare questi 4 file (Tomcat_service.rar) nella directory /TOMCAT/BIN, e quindi eseguire questo comanda da shell dos:
C:\> service.bat install

in questo modo verrà installato il servizio Tomcat7.
Per rimuoverlo basterà eseguire
C:\> tomcat7 //DS//Tomcat7
Enjoy!

giovedì 21 aprile 2011

Il protocollo SPDY di goole

Ipotizzando uno scenario in cui la navigazione web è istantanea, come sfogliare le pagine di un giornale, Google ha cominciato a lavorare al progetto di un nuovo protocollo che opera a livello applicativo, in grado di minimizzare i tempi di latenza nella visualizzazione delle pagine web e di rendere più veloce la navigazione. SPDY, questo il nome del protocollo che si legge “speedy” non andrà a sostituire l’Http che è la “lingua” con cui finora si sono parlati i server web e i browser, ma dovrebbe contribuire a migliorarlo.

Fino a oggi il web è stato dominato da due protocolli l’Http e il Tcp, quest’ultimo opera a livello di trasporto, mentre l’Http opera a livello applicativo.

Ciò che Google intende fare con questo progetto è qualcosa di molto ambizioso, si tratta di estendere e migliorare alcune funzioni che l’Http per sua natura non è in grado di supportare, vedi ad esempio le richieste multiple all’interno di una sola connessione e l’inizializzazione delle richieste solo lato client.

Il protocollo SPDY incorpora funzioni di streaming multiplexed, richieste di priorizzazione del traffico web e compressione degli header Http. Google ha già sviluppato un prototipo di server web e una versione del browser Chrome che integra il supporto a SPDY. Presto dovrebbe essere disponibile anche la versione open source del web server abilitato a SPDY.

Dai test effettuati su 25 tra i più importanti siti web, si è riscontrato un aumento del 55% nella velocità di download delle pagine web. Il prototipo di SPDY sviluppato, sebbene sia stato testato solo nei laboratori di ricerca, è ora pronto per aprirsi alla community degli utenti.

Una caratteristica del protocollo TCP è la prevenzione della congestione di rete utilizzando il il metodo di Slow Start. Questo metodo tende ad evitare l’insorgere di congestione durante la fase di avvio di una connessione , esso regola l’emissione dei segmenti all’inizio di una connessione e ha lo scopo di raggiungere il ritmo di emissione a regime senza causare congestione . Lo slow Start utilizza la Congestion Window (cwdn) (misurata in segmenti) che tende ad aumentare progressivamente , fino ad arrivare ad un valore massimo che consente la comunicazione alla velocità ottimale senza causare la congestione. La congestion window limita il valore della finestra fino a che questo non sia fissato dalla ricezione degli ACK .

Come dicevamo Spdy è un protocollo a livello applicazione per il trasporto di contenuti sul web, progettato specificamente per la latenza minima, le pagine web sviluppate in questi anni sono notevolmente più “pesanti” di quelle sviluppate 10 anni fa pertanto l'implementazione di un nuovo protocollo protrebbe giovare ai nuovi sviluppi web.

Le caratteristiche principali di questo protocollo sono:

Flussi di connessione Multiplexed

SPDY permette connessioni simultanei illimitate su un singolo webserver.

Richiesta di priorità

Quando effettua una richiesta ad un webserver può specificarne la priorità di invio.

Compressione HTTP header

SPDY comprime le intestazioni di richiesta e risposta HTTP, con conseguente minor numero di pacchetti e un minor numero di byte trasmessi.

Server Push

Effettuare il push dei dati senza che il cliente lo richiedà


Sito di riferimento:

http://www.chromium.org/spdy

venerdì 15 aprile 2011

Degrado della rete su server Windows 2003 SP1 e SP2.

In questi giorni ho dovuto affrontare un problema che affligge sistematicamente noi sistemisti e amministratori di rete, ossi le Disconnessioni di rete.
Bene a seguito di numerose riscerche sono venuto a conoscenza dell'ennesimo bug microsoft che causa un degrado delle prestazioni di rete utilizzando dei programmi che trasmettono pacchetti TCP/IP di piccole dimensioni, 50 byte o meno.
Questo bug si verifica su sistemi operativi Windows 2003 SP1 e SP2.
I sintomi sono questi:
In un computer che esegue Windows Server 2003 con Service Pack 1 (SP1) o Windows Server 2003 con Service Pack 2 (SP2), possibile prestazioni ridotte quando si utilizzano alcuni programmi che trasmettono dati su connessioni TCP/IP.

Questo problema si verifica se le seguenti condizioni sono true:
  • Il programma trasmette i pacchetti di dati di piccole dimensioni. In genere, questi sono i pacchetti che sono di 50 byte o meno.
  • I pacchetti di dati trasmessi si verifichino un tempo di andata e ritorno di oltre 100 millisecondi (ms).
  • Alcuni dei pacchetti TCP trasmessi vengono eliminati da una periferica di rete, ad esempio un router o un'opzione.
In questa situazione, in Windows Server 2003 SP1 o driver TCP/IP SP2 (Tcpip.sys) potrebbe richiedere più tempo del previsto per ripristinare la perdita di pacchetti.
Per risolvere questo bug basta installare una HotFix che sovrascrivre il file TCPIP.SYS.
Di seguito il link dove scaricarlo: http://support.microsoft.com/kb/922972

Enjoy.
Antonio

Come funziona una centrale telefonica?

Ponte radio

Il termine ponte radio si utilizza per indicare la connessione in radiofrequenza al fine di trasmettere a distanza dati, fonia, video o altre informazioni opportunamente codificate.I ponti radio (in inglese radio links) sfruttano la propagazione delle onde elettromagnetiche nello spazio vuoto o occupato da un mezzo non totalmente opaco alle lunghezze d'onda utilizzate. La capacità disponibile alla trasmissione dipende dallo spettro radio utilizzato (intervallo di frequenze o canale radio) e dalla complessità della modulazione utilizzata. Infatti nello stesso intervallo di frequenze si può trasmettere una quantità maggiore di informazioni se viene utilizzata una maggior complessità di codificazione delle informazioni. La contropartita è che a maggior complessità corrisponde una minor robustezza della trasmissione, che si risolve nella necessità di maggior potenza di trasmissione, nell'incremento della complessità dell'elettronica utilizzata e nelle maggior sensibilitá alle possibili interferenze naturali o artificiali. I limiti minimi di potenza ricevuta per ogni capacità e tipo di modulazione, sono determinati teoricamente a causa dell'inevitabile presenza di rumore elettronico nei ricevitori, che produce una probabilità d'errore nella sequenza del segnale ricevuto digitale, o una sua distorsione nel caso di segnali analogici. Gli intervalli di frequenze elettromagnetiche utilizzabili per i ponti radio commerciali, vanno dai MHz alle decine di GHz, e sono regolati in ogni paese dalle autorità competenti per ordinare e garantire una trasmissione senza interferenze e quindi con un livello di qualità opportuno. Al momento non esistono sistemi commerciali per frequenze superiori agli 80 GHz, mentre le frequenze più utilizzate sono quelle fra i 4 GHz e i 40 GHz.

Reti di cellulare

Universal Mobile Telecommunications System (UMTS) è la tecnologia di telefonia mobile di terza generazione (3G), successore del GSM. Tale tecnologia impiega lo standard base W-CDMA come interfaccia di trasmissione, è compatibile con lo standard 3GPP e rappresenta la risposta europea al sistema ITU di telefonia cellulare 3G. L'UMTS è a volte lanciato sul mercato con la sigla 3GSM per mettere in evidenza la combinazione fra la tecnologia 3G e lo standard GSM di cui dovrebbe in futuro prendere il posto.

Il sistema UMTS, con l'utilizzo del W-CDMA, supporta un transfer rate (letteralmente: tasso di trasferimento) massimo teorico di 21 Mb/s (con HSDPA[1]), sebbene gli utenti delle attuali reti hanno a disposizione un transfer rate fino 384 kbit/s utilizzando dispositivi R99 e fino a 7.2 Mbit/s con dispositivi HSDPA nelle connessioni in download. Le applicazioni tipiche attualmente implementate, usate ad esempio dalle reti UMTS in Italia, sono tre: voce, videoconferenza e trasmissione dati a pacchetto. Ad ognuno di questi tre servizi è assegnato uno specifico transfer rate, per la voce 12,2 kb/s, 64 kb/s per la videoconferenza e 384 kb/s per trasmissioni di tipo dati (scarico suonerie, accesso al web, ecc.). In ogni caso questi valori sono decisamente superiore ai 14,4 kb/s di un singolo canale GSM con correzione di errore ed anche al transfer rate di un sistema a canali multipli in HSCSD. UMTS è quindi in grado, potenzialmente, di consentire per la prima volta l'accesso, a costi contenuti, di dispositivi mobili al World Wide Web di Internet.

Flusso di una chiamata radiomobile

Di seguito una presentazione, realizzata dal sottoscritto, utilizzata per presentare ad alcuni clienti il funzionamento dell'autenticazione presso una centrale radiomobile.

Enjoy
Antonio