Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Linuxtopia - CentOS Enterprise Introduzione al System Administration - Larghezza di banda e potenza di processazione

Capitolo 3. Larghezza di banda e potenza di processazione

Delle due risorse affrontate in questo capitolo, una (la larghezza di banda), risulta spesso essere per gli amministratori di sistema difficile da capire, mentre l'altra (potenza di processazione) risulta essere generalmente un concetto pi� semplice.

In aggiunta, potrebbe sembrare che queste due risorse non siano cos� in relazione tra loro — perch� dunque metterle insieme?

La ragione � che le suddette risorse sono basate su hardware che dipende direttamente dalla capacit� di un computer di muovere e processare i dati. Per questo motivo essi possono essere correlati tra loro.

3.1. Larghezza di banda

Come definizione di base, la larghezza di banda rappresenta la capacit� di trasferire i dati — in altre parole, la quantit� di dati che � possibile trasferire da un punto ad un altro in un determinato arco di tempo.Avere una comunicazione dei dati da punto a punto, implica due cose:

  • Un insieme di conduttori elettrici usati per creare una comunicazione a basso livello

  • Un protocollo per facilitare una efficiente ed affidabile comunicazione dati

Vi sono due tipi di componenti del sistema idonei a questo scopo:

  • Bus

  • Datapath

La seguente sezione ne affronta in dettaglio le caratteristiche.

3.1.1. Bus

Come precedentemente osservato, i bus abilitano una comunicazione point-to-point e utilizzano una sorta di protocollo, per assicurare che tutte le comunicazioni siano eseguite in modo controllato. Tuttavia, i bus possiedono delle caratteristiche ben definite:

  • Caratteristiche elettriche standardizzate (come il numero di conduttori, i livelli di voltaggio, le velocit� di segnalazione ecc.)

  • Caratteristiche meccaniche standardizzate (come il tipo di connettore, la misura della scheda, la struttura fisica ecc.)

  • Protocollo standardizzato

La parola "standardizzato" � importante perch� i bus rappresentano il modo primario con il quale i diversi componenti del sistema sono collegati tra loro.

In molti casi, i bus permettono una interconnessione di hardware prodotto da diversi rivenditori; senza standardizzazione ci� non potrebbe essere possibile. Tuttavia, anche in situazioni dove un bus appartiene ad un produttore, la standardizzazione risulta essere molto importante perch� permette allo stesso produttore una pi� facile implementazione di componenti diversi tra loro, utilizzando una interfaccia comune — lo stesso bus.

3.1.1.1. Esempi di bus

Non ha importanza dove cerchiate, ci saranno sempre dei bus. Ecco i pi� comuni:

  • Bus di mass storage (ATA e SCSI)

  • Reti [1] (Ethernet e Token Ring)

  • Bus di memoria (PC133 e Rambus®)

  • Bus di espansione (PCI, ISA, USB)

3.1.2. Datapath

I datapath possono essere difficili da identificare, ma come i bus, essi sono dovunque. Anche loro possono permettono una comunicazione point-to-point. Tuttavia, a differenza dei bus, i datapath:

  • Utilizzano un protocollo pi� semplice (se presente)

  • Possiedono (se presente) una piccola standardizzazione meccanica

Il motivo per queste differenze � che i datapath sono generalmente interni ad alcuni componenti del sistema, e non vengono utilizzati per facilitare un collegamento ideale tra diversi componenti. Per questo i datapath sono ottimizzati per una situazione particolare, dove sono preferiti velocit� e basso costo alla flessibilit� per compiti generali pi� lenta e costosa.

3.1.2.1. Esempi di datapath

Ecco alcuni datapath tipici:

  • CPU per un datapath cache sul-chip

  • Processori grafici per il datapath per la memoria video

3.1.3. Potenziali problemi relativi alla larghezza di banda

Ci sono due modi attraverso i quali si possono verificare i problemi relativi alla larghezza di banda (sia per i bus che per i datapath):

  1. Il bus o il datapath possono rappresentare una risorsa condivisa. In questa situazione, un livello elevato di contesa per il bus, riduce la disponibilit� effettiva della larghezza di banda per tutti i dispositivi presenti sul bus.

    Un bus SCSI con diverse unit� disco attive, pu� rappresentare un buon esempio. Tali unit� possono saturare il bus SCSI, lasciando disponibile una larghezza di banda molto piccola per qualsiasi altro dispositivo presente sullo stesso bus. Il risultato finale � che tutti gli I/O per qualsiasi dispositivo presente su questo bus sono lenti, anche se ogni dispositivo non � molto attivo.

  2. Bus o datapath potrebbero rappresentare una risorsa con un numero fisso di dispositivi collegati ad essa. In questo caso, le caratteristiche elettriche del bus (e in alcuni casi la natura del protocollo usato), limitano la larghezza di banda disponibile. Questo generalmente interessa pi� i datapath che i bus. Ecco perch� gli adattatori grafici tendono a operare pi� lentamente quando utilizzano risoluzioni pi� elevate e/o profondit� del colore — per ogni refresh della schermata, vi � un numero maggioredi dati da indirizzare lungo il datapath che collega la memoria video ed i processori grafici.

3.1.4. Soluzioni potenziali relative alla larghezza di banda

Fortunatamente, i problemi relativi alla larghezza di banda possono essere risolti. Infatti, vi sono diversi approcci da seguire:

  • Distribuire il carico

  • Ridurre il carico

  • Aumentare la capacit�

Le seguenti sezioni affrontano tale approccio in modo pi� dettagliato.

3.1.4.1. Distribuire il carico

Il primo approccio � quello di distribuire in modo omogeneo l'attivit� del bus. In altre parole, se un bus � sovraccarico e un altro � in una posizione di idle, la situazione potrebbe migliorare se si sposta parte del carico su quest'ultimo bus.

Come amministratori di un sistema, questo rappresenta il primo approccio da considerare, in quanto spesso accade che sono presenti bus aggiuntivi nel vostro sistema. Per esempio, molti PC includono almeno due canali ATA (il quale rappresenta un altro nome per identificare un bus). Se avete due unit� disco ATA e due canali ATA, perch� entrambe le unit� devono essere sullo stesso canale?

Anche se la configurazione del vostro sistema non include bus aggiuntivi, la distribuzione del carico potrebbe sempre rappresentare un approccio molto indicato. Le spese inerenti l'hardware per affrontare tale approccio, dovrebbero essere minori rispetto la sostituzione di un bus esistente con un hardware con una capacit� superiore.

3.1.4.2. Ridurre il carico

Come primo impatto, la riduzione del carico e la distribuzione dello stesso possono sembrare parte di due procedure diverse ma simili tra loro. Dopo tutto, con la distribuzione del carico, si ha anche una riduzione dello stesso (almeno sul bus sovraccarico), non vi sembra?

Anche se questo punto di vista � corretto, esso non ha gli stessi effetti di una riduzione del carico in modo globale. La chiave � rappresentata dal fatto di poter determinare se vi sono alcuni aspetti inerenti il carico del sistema, che causano il sovraccarico di un bus. Per esempio, se una rete � sovraccarica a causa della presesnza di attivit� necessarie. Forse un piccolo file provvisorio � il destinatario di numerosi segnali I/O lettura/scrittura. Se il suddetto file risiede su di un file server di tipo 'networked', � possibile eliminare una gran parte del traffico di rete, operando in modo locale con il file.

3.1.4.3. Aumento della capacit�

La soluzione pi� ovvia per una larghezza di banda insufficiente � quella di aumentarla in qualche modo. Tuttavia, tale procedura potrebbe risultare costosa. Per aumentare la propria larghezza di banda, il controller SCSI (e probabilmente tutti i dispositivi ad esso collegati), dovrebbe essere sostituito con un hardware pi� veloce. Se il controller SCSI � una scheda separata, esso rappresenter� un processo piuttosto semplice,ma se il suddetto controller � parte di una scheda madre di un sistema, allora potrebbe essere pi� difficile giustificare una spesa cos� onerosa.

3.1.5. In generale…

Tutti gli amministratori di sistema dovrebbero essere a conoscenza della larghezza di banda, e come la configurazione e l'utilizzo del sistema possa influenzarla. Sfortunatamente, non � sempre facile determinare quale sia il problema relativo alla larghezza di banda. Talvolta, il problema non viene rappresentato dal bus di per s�, ma pu� essere relativo ad un componente ad esso collegato.

Per esempio, considerate un adattatore SCSI collegato ad un bus PCI. Se sono presenti alcuni problemi inerenti la prestazione con l'I/O del disco SCSI, essi potrebbero essere causati da un adattatore SCSI con prestazioni scadenti, anche se i bus PCI e SCSI non sono vicini alle rispettive capacit� per la larghezza di banda.

Note

[1]

Invece di un bus del tipo intra-system, le reti possono essere concepite come un bus inter-system.

 
 
  Published under the terms of the GNU General Public License Design by Interspire