La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
In un sistema DOCSIS (Data-over-Cable Service Interface Specifications), sono presenti diversi problemi che possono influire sulle prestazioni e sulla velocità dei modem via cavo. Questo documento cerca di affrontare le principali cause della lentezza del throughput dal punto di vista di un provider di servizi via cavo.
In questo documento viene innanzitutto illustrato come determinare con precisione quali livelli di throughput un utente finale sta raggiungendo e come verificare che le prestazioni misurate siano quelle della rete via cavo, anziché quelle di Internet in senso lato.
La sezione successiva esamina le cause potenziali più comuni della lentezza delle prestazioni e le soluzioni suggerite. Tali questioni comprendono:
Le prestazioni sono limitate dai limiti nel file di configurazione DOCSIS.
Prestazioni di download instabili o incostanti causate dall'utilizzo di uno schema di limitazione della velocità non ottimale nel sistema di terminazione del modem via cavo (CMTS).
Congestione del canale upstream e downstream.
Rete backhaul o congestione Internet.
Rumore o errori sull'impianto di cablaggio.
Apparecchiature CPE (end-premises equipment) sotto alimentazione.
Ognuna di queste caratteristiche, singolarmente o in combinazione, può influire sul throughput e sulle prestazioni di una rete cablata.
In questo documento non viene descritta la risoluzione dei problemi di perdita completa di connettività sulla rete via cavo o sui modem via cavo che non sono in linea. Per questo tipo di problemi, fare riferimento a Risoluzione dei problemi dei modem cablati uBR non in linea.
Non sono previsti prerequisiti specifici per questo documento.
Le informazioni fornite in questo documento si basano sulle versioni software e hardware riportate di seguito.
Software Cisco IOS® versione 12.1(9)EC per i CMTS uBR7200 e uBR7100.
la suite di prodotti CMTS Cisco uBR7100, uBR7200 e uBR7200VXR.
Le informazioni di questo documento sono rilevanti per tutte le altre versioni attualmente disponibili del software Cisco IOS basato su DOCSIS 1.0 per le apparecchiature CMTS con marchio Cisco.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Esistono diversi modi per misurare la velocità e le prestazioni di un sistema, tuttavia è importante capire esattamente quali parti del sistema vengono testate. Si consideri il diagramma riportato di seguito.
Figura 1 (per visualizzare il diagramma in formato video, fare clic qui).
In questo diagramma sono presenti diversi componenti:
La rete Hybrid Fiber Coax tra l'utente finale e il CMTS.
Il segmento della rete CMTS locale in cui il CMTS si connette alla rete del provider di servizi via cavo.
La rete interna del provider del servizio via cavo.
Internet pubblica.
Quando si esegue una prova di velocità tra due punti, viene misurata la velocità di tutti i componenti di rete tra i due punti.
Ad esempio, se si esegue un test di velocità tra il CPE e il server 3, connesso a Internet tramite una linea ISDN a 128 Kbps, le velocità non saranno mai superiori a 128 Kbps, anche se la larghezza di banda disponibile sul segmento di cavo è superiore a 128 Kbps.
Il modo più accurato per misurare le prestazioni del segmento di cavo è eseguire un test di velocità tra il CPE e il server 1, che è collegato allo stesso segmento di rete del CMTS. Questo accade perché l'unico dato del percorso da trasferire è il segmento del cavo coassiale. I dati devono inoltre viaggiare attraverso il segmento della rete CMTS locale, ma si presume che questo segmento abbia una larghezza di banda elevata (FastEthernet o superiore) e non abbia un elevato livello di congestione.
Se per qualche motivo non è possibile connettere alcun server al segmento della rete CMTS locale, il modo più accurato per verificare le prestazioni del segmento del cavo consiste nell'eseguire un test di velocità tra il CPE e il server 2. Si tratta di una misurazione accurata, a condizione che vi siano collegamenti sufficientemente veloci e non congestionati all'interno della rete interna del provider di servizi via cavo tra il CMTS e il CPE.
Il modo più impreciso per determinare le prestazioni del segmento del cavo è eseguire un test della velocità tra il CPE e un server su Internet. Ciò è dovuto al fatto che potrebbero esserci collegamenti congestionati nell'Internet pubblica tra il CPE e il server, o potrebbero esserci collegamenti a velocità molto bassa nel percorso tra il CPE e il server su Internet.
È molto importante essere in grado di ottenere una misurazione oggettiva dei livelli esatti di velocità di caricamento e scaricamento prima di trarre conclusioni sull'eventuale presenza di problemi di prestazioni in un sistema DOCSIS.
Il modo più semplice per determinare la velocità di caricamento e download consiste nel caricare o scaricare un file di grandi dimensioni tramite FTP o HTTP tra un dispositivo CPE collegato a un modem via cavo e un server dietro il CMTS. La maggior parte dei client FTP e HTTP è in grado di visualizzare la velocità alla quale si verifica un download o un caricamento durante il trasferimento o una volta completato il trasferimento. La velocità di trasferimento rilevata come risultato dell'operazione FTP o HTTP è in genere circa il 90% della velocità effettiva totale raggiunta. Infatti, la velocità di trasferimento FTP o HTTP visualizzata non tiene conto dell'ulteriore sovraccarico IP e DOCSIS che deve spostarsi tra il dispositivo CPE e il CMTS.
Esistono metodi più accurati per misurare il throughput, ad esempio utilizzando apparecchiature di test dedicate di terze parti, come Smartbit Netcom o un generatore di pacchetti IXIA, tuttavia questi sistemi non sono sempre facilmente disponibili o facilmente collegabili a una rete via cavo di produzione. Se i test del throughput vengono eseguiti in un ambiente lab, l'utilizzo di un dispositivo dedicato consente di visualizzare molte più informazioni rispetto al semplice test di download FTP o HTTP.
Nota: il test di caricamento e download basato su FTP o HTTP è affidabile solo per velocità di test di circa 3 Mbps o meno. A velocità più elevate, la potenza di elaborazione del dispositivo CPE, del server o delle schede di interfaccia di rete (NIC, Network Interface Card) può diventare un fattore limitante nel test. Per verificare velocità superiori a circa 3 Mbps, utilizzare apparecchiature dedicate per il test del throughput dei dati.
Nell'esempio seguente viene eseguito un semplice test di download e caricamento FTP tra una periferica CPE collegata a un modem via cavo e un server FTP sulla rete del provider di servizi via cavo. Il modem via cavo ha scaricato un file di configurazione DOCSIS che consente una velocità di download fino a 256 Kbps e una velocità di caricamento fino a 64 Kbps. In questo test è stato inserito un file da 3 MB sul server FTP all'indirizzo IP 172.17.110.132. L'utente del dispositivo CPE dispone di un nome utente e di una password per accedere al server FTP e scaricare il file dal server FTP, quindi caricarlo nuovamente sul server FTP. Per eseguire il trasferimento viene utilizzata l'utilità FTP della riga di comando. Questa utilità è disponibile praticamente in tutte le versioni di Microsoft Windows e UNIX.
Un test simile viene eseguito impostando un server Web HTTP nella rete del provider di servizi ed eseguendo un download HTTP.
Figura 2
Note: !--- Comments are in blue.
C:\>ftp 172.17.110.132 !--- Initiate the FTP session to the server. Connected to 172.17.110.132. 220 Solaris FTP server (SunOS 5.6) ready. User (172.17.110.132:(none)): anonymous !--- Enter the FTP server username. 331 Guest login ok, send your complete e-mail address as password. Password: user@samplenetwork.com.au !--- Enter the FTP server password. 230 User anonymous logged in. ftp> dir !--- View the contents of the current directory. 200 PORT command successful. 150 ASCII data connection for /bin/ls (64.104.207.118,1282) (0 bytes). total 74932 -rw-r--r-- 1 root other 3276800 Oct 10 19:31 cable.txt !--- A 3 M file that you can download. 226 ASCII Transfer complete. ftp: 105 bytes received in 0.12 Seconds 2.46 Kbytes/sec. ftp> bi !--- Turn on Binary File transfer mode. 200 Type set to I. ftp> get cable.txt !--- Retrieve the file cable.txt and wait for it to download. 200 PORT command successful. 150 Binary data connection for cable.txt (192.168.1.13,3154) (3276800 bytes). 226 Binary Transfer complete. ftp: 3276800 bytes received in 111.35 Seconds 29.43 Kbytes/sec. !--- Download complete. It seems that the download occurred !--- at 29.43 Kbytes/sec, which equals 235 Kbits/sec. This is about 90 percent of !--- the allowed 256 Kbps download rate for the modem being tested. ftp> put cable.txt !--- Begin uploading the file. You need to make sure you have !--- the correct access in order to upload a file to the FTP server or !--- you may get an access-denied error. 200 PORT command successful. 150 Binary data connection for cable.txt (192.168.1.13,3157). 226 Transfer complete. ftp: 3276800 bytes sent in 432.49 Seconds 7.58 Kbytes/sec. !--- Upload Complete. Here you see the upload !--- occurred at 7.58 Kbytes/sec, !--- which is equivalent to 60.64 Kbits/sec. This !--- is about 90 percent of the allowed !--- 64 Kbps upload rate for the modem being tested. ftp> quit !--- Exit the FTP client application. 221 Goodbye.
Durante il trasferimento FTP, è possibile monitorare l'avanzamento del test sul CMTS utilizzando il comando show interface cable X/Y sid Z counters, in cui il cavo X/Y è l'interfaccia del cavo a cui il modem sottoposto a test è collegato e Z è il numero ID servizio (SID) del modem sottoposto a test. Questo comando mostra quanti byte vengono trasferiti da o verso un particolare modem via cavo. Ad esempio, se il CPE da testare si trova dietro un modem via cavo con indirizzo MAC 0001.9659.4461.
Individuare innanzitutto il numero SID del modem da testare utilizzando il comando show cable modem. In questo caso, il SID del modem via cavo è 5.
uBR7246-VXR# show cable modem 0001.9659.4461 Interface Prim Online Timing Rec QoS CPE IP address MAC address Sid State Offset Power Cable3/0/U0 5 online 1996 0.25 5 2 10.1.1.24 0001.9659.4461
Durante il download o il caricamento, azzerare tutti i contatori dei pacchetti sul CMTS utilizzando il comando clear counters. Quando i contatori vengono azzerati, avviare un cronometro o un timer.
uBR7246-VXR# clear counters !--- Reset packet counter to zero. Clear "show interface" counters on all interfaces [confirm] !--- Start the stopwatch when you hit Enter.
Dopo che il cronometro o l'ora legge esattamente un minuto, eseguire il comando show interface cable X/Y sid Z counters. È consigliabile digitare il comando per primo e quindi premere Invio esattamente quando il timer indica un minuto. Il test può essere eseguito su un periodo più lungo o più breve. Più lungo è il periodo di prova, più accurato sarà il risultato, ma assicurati che il download o il caricamento non finisca prima che il timer del cronometro raggiunga il tempo specificato, altrimenti la misurazione non sarà accurata.
uBR7246-VXR# show interface cable 3/0 sid 5 counters !--- Hit enter when stopwatch is at exactly one minute. Sid Inpackets Inoctets Outpackets Outoctets Ratelimit Ratelimit BWReqDrop DSPktDrop 5 4019 257216 3368 1921488 0 149 uBR7246-VXR#
In questo caso è in corso il test della velocità di download. L'output del comando show interface cable X/Y sid Z counter indica che in un periodo di un minuto, il modem via cavo scarica 1.921.488 byte. La conversione di 1.921.488 byte in bit rivela:
8 bits per byte * 1,921,488 bytes = 15,371,904 bits.
Quindi, per trovare la velocità di download in bit al secondo, dividere questo numero totale di bit scaricati per il tempo necessario per scaricarli in secondi.
15,371,904 bits / 60 seconds = 256 Kbps.
La velocità di download indicata in questo esempio è di circa 256 Kbps, che corrisponde alla velocità di download consentita per il modem via cavo sottoposto a test.
Per esaminare la velocità di caricamento con il comando show interface cable X/Y sid Z counters, è necessario usare la colonna Ingettets per determinare il numero di byte inviati nella direzione a monte dal modem via cavo.
Per ulteriori informazioni sul comando show interface cable sid counters, consultare la guida di riferimento dei comandi di Cisco Broadband Cable.
La prima informazione da raccogliere per risolvere i problemi di prestazioni lente del modem via cavo è la classe di limiti di velocità di trasmissione del servizio prescritta per il modem via cavo. Quando un modem via cavo è in linea, scarica un file di configurazione DOCSIS contenente i limiti operativi per il modem via cavo, incluse le velocità massime di caricamento e download. In circostanze normali, il modem via cavo non può superare queste velocità.
Inizialmente è necessario identificare l'indirizzo MAC di un modem via cavo che presenta problemi. Utilizzo di un modem con indirizzo MAC 0050.7366.2223 che presenta problemi di velocità di trasmissione lenta,. per conoscere la classe del profilo del servizio utilizzata dal modem via cavo, eseguire il comando show cable modem <mac-address>, come mostrato nell'esempio che segue.
uBR7246-VXR# show cable modem 0050.7366.2223 Interface Prim Online Timing Rec QoS CPE IP address MAC address Sid State Offset Power Cable3/0/U1 1 online 1548 0.75 5 0 10.1.1.10 0050.7366.2223
In questo esempio, il modem via cavo ha un profilo QoS (Quality of Service) di 5. Per verificare le velocità a valle e a monte di questo profilo QoS, usare il comando show cable qos profile-number, dove profile-number è il profilo QoS desiderato.
uBR7246-VXR# show cable qos profile 5 ID Prio Max Guarantee Max Max TOS TOS Create B IP prec. upstream upstream downstream tx mask value by priv rate bandwidth bandwidth bandwidth burst enab enab 5 0 64000 0 256000 1600 0x0 0x0 cm no no
Qui mostra che il profilo QoS 5 corrisponde a un servizio che fornisce 256 Kbps in downstream e 64 Kbps in upstream. Tutti i CPE collegati ai modem via cavo che utilizzano il profilo QoS 5 non possono superare questi limiti. Le impostazioni del profilo QoS sono determinate dal contenuto dei file di configurazione DOCSIS scaricati dai modem via cavo dal server TFTP del sistema di provisioning, quindi il profilo QoS 5 nel sistema potrebbe non essere uguale al profilo QoS 5 nell'esempio mostrato sopra.
Se le prestazioni di download e caricamento di un utente finale sono correlate ai limiti indicati nel profilo QoS, si ottengono la classe di servizi e i livelli di velocità effettiva per cui il modem via cavo è stato predisposto e configurato. L'unico modo per aumentare la velocità di caricamento e download è modificare il file di configurazione DOCSIS scaricato dal modem via cavo in modo che abbia limiti di velocità più elevati. Per istruzioni dettagliate su come creare o modificare un file di configurazione DOCSIS, vedere il documento Building DOCSIS 1.0 Configuration Files Using Cisco DOCSIS Configurator.
Quando un utente finale sta tentando di scaricare dati da Internet a una velocità superiore a quella consentita dal file di configurazione DOCSIS del modem via cavo, il CMTS deve limitare la velocità del traffico inviato a tale utente per garantire che non utilizzi una quantità di larghezza di banda superiore a quella consentita.
Analogamente, quando un utente finale tenta di caricare o inviare dati a Internet a una velocità superiore a quella consentita dal file di configurazione DOCSIS, il modem via cavo stesso deve impedire al traffico in eccesso di viaggiare attraverso il segmento di cavo fino al CMTS. Se per qualche motivo il modem via cavo non riesce a eseguire correttamente la limitazione della velocità a monte, il CMTS impedisce esplicitamente al modem via cavo di trasmettere una velocità superiore a quella consentita. Questo comportamento nel CMTS garantisce che anche un modem via cavo con caratteristiche "hackerate" non sia in grado di sovvertire i limiti di velocità assegnati al provider di servizi.
Lo schema di limitazione della velocità predefinito utilizzato dal CMTS monitora la velocità del traffico da o verso ciascun modem via cavo su un periodo di un secondo. Se il modem via cavo invia o riceve più traffico della propria quota al secondo in meno di un secondo, il CMTS non consente il flusso di traffico verso il modem via cavo per il resto del secondo.
Ad esempio, si prenda un modem via cavo con un profilo QoS che consenta una velocità di download di 512 Kbps. Se il modem via cavo scarica 512 kilobyte (64 kilobyte) entro la prima metà di un secondo, per la metà successiva del secondo, il modem via cavo non potrà scaricare nulla. Questo tipo di comportamento di limitazione della velocità può avere l'effetto di uno schema di download frammentato che sembra interrompersi e iniziare ogni secondo o due.
Il miglior schema di limitazione della velocità a valle da utilizzare è l'algoritmo di limitazione della velocità del token bucket con traffic shaping. Questo schema di limitazione della velocità è stato ottimizzato per consentire un'esplorazione del Web fluida a una velocità costante, garantendo allo stesso tempo che agli utenti finali non sia consentito superare la velocità di download prescritta, come specificato nel file di configurazione DOCSIS.
Questo schema funziona per misurare la velocità con cui un modem via cavo scarica o carica i dati ogni volta che un pacchetto viene inviato da o verso il modem via cavo. Se l'invio o la ricezione del pacchetto in questione causa il superamento da parte del modem delle velocità di trasferimento consentite, il pacchetto viene memorizzato nel buffer o memorizzato nella cache nella memoria CMTS finché il CMTS non è in grado di inviarlo senza superare il limite della larghezza di banda a valle.
Nota: se la velocità del traffico a valle supera costantemente la velocità a valle consentita per il modem via cavo, i pacchetti vengono infine scartati.
Utilizzando questo metodo più uniforme di limitazione e shaping della velocità, la maggior parte delle applicazioni Internet basate su TCP, quali l'esplorazione Web HTTP e i trasferimenti di file FTP, funzionano in modo più agevole ed efficiente rispetto allo schema di limitazione della velocità predefinito.
Lo schema token-bucket rate-limiting-with-traffic-shaping può essere abilitato sul percorso a valle su un'interfaccia via cavo eseguendo il seguente comando di configurazione dell'interfaccia:
uBR7246-VXR(config-if)# cable downstream rate-limit token-bucket shaping
Nota: si consiglia di abilitare il token bucket shaping nel CMTS dell'utente. Questo comando è supportato a partire dal software Cisco IOS versione 12.0(5)T1 e 12.1(1)EC1.
Il token-bucket con schema di traffic shaping può essere applicato anche alle porte a monte, ma poiché spetta ai modem via cavo limitare la velocità a monte, lo schema di limitazione della velocità a monte applicato al CMTS non avrà alcun impatto sulle prestazioni del sistema.
uBR7246-VXR(config-if)# cable upstream 0 rate-limit token-bucket shaping
Per ulteriori informazioni sui comandi downstream rate-limit e upstream rate-limit, consultare la Cisco Broadband Cable Command Reference Guide.
Gli utenti possono verificare la gravità della limitazione del traffico del CMTS a un particolare modem via cavo utilizzando il comando show interface cable X/Y sid <Z>, dove cable X/Y è l'interfaccia a cui è connesso il modem via cavo e Z è il numero SID del modem rilevato. Questo comando visualizza il numero di volte in cui il CMTS ha scartato un pacchetto downstream o ha rifiutato di consentire un pacchetto upstream perché il modem superava i limiti di velocità consentiti. Se non si specifica alcun valore per Z, vengono visualizzate le informazioni del contatore per tutti i modem via cavo collegati al cavo di interfaccia X/Y.
uBR7246-VXR# show interface cable 3/0 sid 5 counters Sid Inpackets Inoctets Outpackets Outoctets Ratelimit Ratelimit BWReqDrop DSPktDrop 5 150927 9662206 126529 72008199 0 5681
Il campo Ratelimit DSPktDrop visualizza il numero di volte in cui il CMTS ha scartato pacchetti destinati al modem via cavo per il tentativo di superamento della velocità effettiva di downstream consentita.
Il campo Ratelimit BWReqDrop mostra quante volte il CMTS ha rifiutato a un modem via cavo di inviare un pacchetto nel percorso a monte a causa del tentativo del modem di superare la velocità di trasmissione upstream consentita. Nella maggior parte dei casi, questo contatore deve sempre rimanere uguale a 0. Se sale significativamente al di sopra di zero, è possibile che il modem via cavo osservato non stia eseguendo correttamente la limitazione della velocità a monte.
Nota: i valori visualizzati dal comando show interface cable X/Y sid Z counters possono essere azzerati usando il comando clear counters, come mostrato nell'esempio che segue.
uBR7246-VXR# show interface cable 3/0 sid counters Sid Inpackets Inoctets Outpackets Outoctets Ratelimit Ratelimit BWReqDrop DSPktDrop 1 7 1834 7 1300 0 0 2 2052 549150 0 0 0 0 3 2 1244 2 708 0 0 4 2 1244 2 714 0 0 5 160158 10253220 134294 76423270 0 6023 6 2 1244 2 712 0 0 7 9 1906 4 858 0 0 9 6 1076 3 483 0 0 12 616 165424 0 0 0 0 uBR7246-VXR# clear counters Clear "show interface" counters on all interfaces [confirm] <press enter here> uBR7246-VXR# show interface cable 3/0 sid counters Sid Inpackets Inoctets Outpackets Outoctets Ratelimit Ratelimit BWReqDrop DSPktDrop 1 0 0 0 0 0 0 2 0 0 0 0 0 0 3 0 0 0 0 0 0 4 0 0 0 0 0 0 5 111 7104 92 52728 0 6 6 0 0 0 0 0 0 7 0 0 0 0 0 0 9 0 0 0 0 0 0 12 0 0 0 0 0 0
Per ulteriori informazioni sul comando show interface cable sid counters, consultare la guida di riferimento dei comandi di Cisco Broadband Cable.
Il canale a monte è normalmente la risorsa più preziosa in un sistema di cavi. Attualmente, la maggior parte dei provider di servizi via cavo utilizza una larghezza del canale di 1,6 MHz e una modulazione QPSK (Quadrature Phase Shift Keying) nel percorso a monte. Ciò equivale a circa 2,5 Mbps di larghezza di banda upstream totale disponibile per tutti gli utenti connessi a un canale upstream. È importante garantire che il canale a monte non venga sovrautilizzato o congestionato, altrimenti tutti gli utenti del segmento a monte subiranno prestazioni insoddisfacenti.
L'utilizzo a monte per una particolare porta a monte può essere ottenuto eseguendo il comando CMTS show interface cable X/Y upstream <Z>, dove cable X/Y è il numero dell'interfaccia a valle e Z è il numero della porta a monte. Se Z viene omesso, verranno visualizzate le informazioni relative a tutti gli upstream sul cavo di interfaccia X/Y. Per ulteriori informazioni sul comando show interface cable upstream, consultare la guida di riferimento dei comandi di Cisco Broadband Cable.
uBR7246-VXR# show interface cable 6/0 upstream 0 Cable6/0: Upstream 0 is up Received 71941 broadcasts, 27234 multicasts, 8987489 unicasts 0 discards, 140354 errors, 0 unknown protocol 9086664 packets input, 4394 uncorrectable 122628 noise, 0 microreflections Total Modems On This Upstream Channel : 359 (354 active) Default MAC scheduler Queue[Rng Polls] 0/64, fifo queueing, 0 drops Queue[Cont Mslots] 0/104, fifo queueing, 0 drops Queue[CIR Grants] 0/64, fair queueing, 0 drops Queue[BE Grants] 0/64, fair queueing, 0 drops Queue[Grant Shpr] 0/64, calendar queueing, 0 drops Reserved slot table currently has 0 CBR entries Req IEs 64609697, Req/Data IEs 0 Init Mtn IEs 521851, Stn Mtn IEs 569985 Long Grant IEs 2781600, Short Grant IEs 2067668 Avg upstream channel utilization : 18% Avg percent contention slots : 77% Avg percent initial ranging slots : 2% Avg percent minislots lost on late MAPs : 0% Total channel bw reserved 37858000 bps CIR admission control not enforced Admission requests rejected 0 Current minislot count : 7301855 Flag: 0 Scheduled minislot count : 7301952 Flag: 0
Sulla porta a monte illustrata nell'esempio, l'utilizzo a monte è attualmente del 18% e vi sono 359 modem connessi a questo upstream.
Se l'utilizzo del canale a monte è costantemente superiore al 75% durante i tempi di picco, gli utenti finali iniziano a soffrire di problemi quali latenza, tempi di "ping" più lenti e un'esperienza Internet generalmente più lenta. Se l'utilizzo del canale upstream è costantemente al di sopra del 90% durante i tempi di picco, gli utenti finali sperimentano un livello di servizio estremamente basso perché gran parte dei dati upstream dell'utente finale dovrà essere ritardata o eliminata.
L'utilizzo del canale upstream cambia durante il giorno, poiché diversi utenti hanno la possibilità di utilizzare il modem via cavo, pertanto è importante monitorare l'utilizzo upstream durante gli orari più attivi del giorno piuttosto che in periodi di basso utilizzo.
I modi per ridurre la congestione a monte includono:
Riduzione del numero di modem via cavo per upstream: se vi sono troppi modem via cavo connessi a un particolare upstream, o se gli utenti di un particolare upstream sono utenti con uso intensivo della larghezza di banda upstream, la soluzione migliore è spostare alcuni utenti della porta upstream congestionata in una porta upstream sottoutilizzata o in una porta upstream completamente nuova. Questo avviene in genere spostando un nodo fibra da un gruppo di combinazione a monte a un altro o dividendo un gruppo di combinazione a monte in due gruppi di combinazione separati. Per ulteriori informazioni, vedere Qual è il numero massimo di utenti per CMTS.
Aumento della larghezza del canale a monte - Questo comporta un'analisi rigorosa e completa dello spettro a monte per trovare una banda sufficientemente ampia con le caratteristiche del rapporto segnale/rumore (SNR) adeguate per supportare l'aumento della larghezza del canale. La larghezza del canale a monte non deve essere modificata senza un'attenta pianificazione, in quanto questa modifica potrebbe influire su altri servizi nel sistema di cavi dell'utente. La larghezza del canale a monte può essere modificata utilizzando il cavo di comando dell'interfaccia del cavo a monte Z channel-width <new-channel-width> dove Z è il numero della porta a monte e la nuova larghezza del canale è una delle seguenti: 200000, 400000, 800000, 1600000 (impostazione predefinita) o 3200000. Di seguito è riportato un esempio.
uBR7246-VXR(config-if)# cable upstream 0 channel-width 3200000
Per ulteriori informazioni sul comando show interface cable upstream, consultare la guida di riferimento dei comandi di Cisco Broadband Cable.
Cambiare lo schema di modulazione digitale a monte in 16-Quadrature Amplitude Modulation (QAM) - Ancora una volta, questo richiede un'analisi rigorosa e completa dello spettro a monte per verificare se esiste una banda di frequenza disponibile a monte che può supportare la modulazione 16-QAM. Se l'analisi non viene eseguita correttamente, vi è il rischio che le prestazioni diminuiscano ulteriormente o che si verifichi un'interruzione completa a monte. Lo schema di modulazione a monte può essere modificato creando un profilo di modulazione a monte che utilizza la modulazione 16-QAM e quindi applicandolo a una porta a monte. Segue un esempio.
uBR7246-VXR(config)# cable modulation-profile 2 mix !--- Create an optimized 16-qam/qpsk modulation profile. uBR7246-VXR(config)# interface cable 6/0 uBR7246-VXR(config-if)# cable upstream 0 modulation-profile 2
Per ulteriori informazioni sui comandi cable modulation-profile e cable upstream-profile, consultare la Cisco Broadband Cable Command Reference Guide. Vedere anche Configurazione dei profili di modulazione del cavo sui sistemi di terminazione del modem via cavo di Cisco.
Riduzione della velocità di trasmissione upstream consentita per modem via cavo - Riducendo la velocità massima di trasmissione upstream nei file di configurazione DOCSIS appropriati, gli utenti del modem via cavo non sono in grado di trasmettere a una velocità altrettanto elevata nella direzione upstream e viene eliminata la congestione upstream. L'aspetto negativo di questo comportamento è che gli utenti di modem via cavo sono limitati a una classe di servizio più lenta. Vedere Creazione di file di configurazione DOCSIS 1.0 con Cisco DOCSIS Configurator.
Nota: le misure discusse in questa sezione non aumentano in modo significativo le prestazioni di un sistema già non congestionato.
Il canale a valle ha molto più larghezza di banda da condividere di un singolo canale a monte, quindi il canale a valle non è solitamente soggetto a congestione come il canale a monte. Tuttavia, un numero maggiore di utenti in genere condivide un canale a valle rispetto a qualsiasi singolo canale a monte, quindi se il canale a valle diventa congestionato, tutti gli utenti connessi al segmento a valle sperimentano prestazioni ridotte.
La tabella seguente mostra la larghezza di banda a valle totale disponibile associata ai quattro possibili schemi di modulazione a valle disponibili nei sistemi DOCSIS.
Schema di modulazione a valle | Larghezza di banda downstream disponibile |
---|---|
DOCSIS 64-QAM per il Nord America | 27 Mbps |
DOCSIS 256-QAM per il Nord America | 38 Mbps |
Euro DOCSIS 64-QAM | 38 Mbps |
Euro DOCSIS 256-QAM | 54 Mbps |
La maggior parte dei sistemi di cavi DOCSIS implementa attualmente il protocollo DOCSIS per il Nord America a 64 QAM e quindi ha a disposizione 27 Mbps per canale downstream.
L'utilizzo del canale downstream può essere determinato usando il comando show interface cable X/Y, dove cable X/Y è l'interfaccia del cavo osservata. La velocità di output visualizzata in bit al secondo deve essere confrontata con la larghezza di banda a valle disponibile, come indicato nella tabella precedente.
Nell'esempio seguente viene analizzata un'interfaccia che utilizza DOCSIS per il Nord America e la modulazione digitale 64-QAM.
uBR7246-VXR# show interface cable 3/0 Cable3/0 is up, line protocol is up Hardware is BCM3210 ASIC, address is 0005.5fed.dca4 (bia 0005.5fed.dca4) Internet address is 10.1.1.1.1/24 MTU 1500 bytes, BW 27000 Kbit, DLY 1000 usec, reliability 255/255, txload 9/255, rxload 5/255 Encapsulation MCNS, loopback not set Keepalive not set ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 00:45:01 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue :0/40 (size/max) 5 minute input rate 587000 bits/sec, 228 packets/sec 5 minute output rate 996000 bits/sec, 239 packets/sec 85560 packets input, 8402862 bytes, 0 no buffer Received 1013 broadcasts, 0 runts, 0 giants, 0 throttles 247 input errors, 35 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 65912 packets output, 38168842 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out
Il primo componente di questo output da notare è la larghezza di banda dell'interfaccia indicata dal parametro BW. Nel software Cisco IOS versione 12.1(8)EC e successive, questo valore viene regolato automaticamente in base allo schema di modulazione a valle e alla versione di DOCSIS utilizzata. Nelle versioni precedenti al software Cisco IOS versione 12.1(8)EC, questo valore deve essere configurato manualmente con il comando di interfaccia via cavo <larghezza di banda-in-kilo-bit-al-secondo>, altrimenti rimane sul valore predefinito di 27000 Kbps.
Il secondo componente da notare è il carico di trasmissione indicato dal parametro txload. Questo parametro fornisce una metrica su 255 dove 0/255 significa che non viene effettuato il flusso del traffico nella direzione a valle fino a 255/255, ovvero i dati vengono trasferiti nella direzione a valle alla velocità massima possibile (in questo caso a 27000 Kbps). Se questo parametro viene eseguito in modo costante a un valore superiore a circa il 75% durante il tempo di massimo utilizzo (ad esempio, superiore a 191/255), gli utenti finali inizieranno a sperimentare un accesso a Internet più lento e una latenza maggiore.
Il terzo componente da notare è la velocità di output, che mostra la velocità di throughput a valle media in bit al secondo. Se questo numero supera costantemente circa il 75% della larghezza di banda a valle disponibile durante i tempi di picco di utilizzo, gli utenti finali inizieranno a sperimentare un accesso a Internet più lento e una latenza più elevata.
Per impostazione predefinita, queste statistiche vengono calcolate su una media mobile di cinque minuti. Per ulteriori informazioni sul modo in cui viene calcolata la media, fare riferimento a Descrizione della definizione dei bit al secondo (bit/sec) dall'output del comando show interfaces. Il periodo durante il quale viene calcolata questa media può essere ridotto a soli 30 secondi usando il comando di interfaccia del cavo load-interval 30. Se si riduce questo periodo a 30 secondi, si calcola un valore più accurato e aggiornato per ciascuno dei parametri discussi in questa sezione.
L'utilizzo del canale downstream cambia durante il giorno, poiché diversi utenti hanno l'opportunità di utilizzare il modem via cavo, pertanto è importante monitorare l'utilizzo downstream durante gli orari più attivi del giorno piuttosto che nei periodi di basso utilizzo.
I modi per ridurre la congestione a valle includono:
Riduzione del numero di modem via cavo per downstream: se vi sono troppi modem via cavo collegati a un particolare downstream, o se gli utenti di un particolare downstream sono utenti assidui della larghezza di banda, la soluzione migliore è spostare alcuni utenti del canale a valle congestionato su un altro canale a valle. Ciò avviene in genere suddividendo un gruppo di nodi in fibra a valle associati al flusso a valle in due gruppi separati e assegnando ciascuno dei nuovi gruppi a canali a valle separati. Fare riferimento alla sezione Qual è il numero massimo di utenti per CMTS.
Modifica dello schema di modulazione digitale a valle a 256-QAM - Questa azione richiede un'analisi rigorosa e completa dello spettro a valle per verificare se il sistema può supportare un segnale 256-QAM. Se l'analisi non viene eseguita correttamente, vi è il rischio che le prestazioni diminuiscano ulteriormente o che si verifichi un'interruzione completa a valle. Lo schema di modulazione a valle può essere modificato usando il comando interface come mostrato di seguito.
uBR7246-VXR(config-if)# cable downstream modulation 256qam
Per ulteriori informazioni sul comando cable downstream modulation, consultare la Cisco Broadband Cable Command Reference Guide.
Riduzione del throughput a valle consentito per modem via cavo - Riducendo la velocità massima di trasmissione a valle nei file di configurazione DOCSIS appropriati, gli utenti dei modem via cavo non sono in grado di scaricare a una velocità così elevata nella direzione a valle e viene eliminata la congestione a valle. L'aspetto negativo di questo comportamento è che gli utenti di modem via cavo sono limitati a una classe di servizio più lenta. Fare riferimento alla sezione Creazione di file di configurazione di DOCSIS 1.0 con Cisco DOCSIS Configurator.
Nota: le misure discusse in questa sezione non aumentano in modo significativo le prestazioni di un sistema già non congestionato.
In alcuni casi, i problemi di prestazioni possono non essere causati da problemi dell'impianto cablato o del CMTS, ma possono essere dovuti a congestione o a problemi della rete backhaul utilizzata dal CMTS per connettersi a Internet o a parti di Internet.
Il modo più semplice per determinare se la congestione della rete backhaul è un problema è connettere una workstation allo stesso segmento di rete del CMTS e cercare di esplorare gli stessi siti Web a cui gli utenti finali che usano i modem via cavo stanno cercando di accedere. Se le prestazioni sono ancora lente, esiste un problema di prestazioni nella rete non correlato al CMTS o al segmento del cavo. Se le prestazioni del segmento di rete CMTS locale sono notevolmente migliori rispetto a quelle degli utenti connessi ai modem via cavo, concentrare gli sforzi sul segmento CMTS e sul segmento del cavo.
Figura 3
Nella rete sopra indicata, se il server 1, connesso allo stesso segmento di rete del CMTS, sta ottenendo prestazioni lente durante l'esplorazione di Internet, allora la causa del problema non è il CMTS. Invece, il collo di bottiglia o il problema di prestazioni da qualche altra parte. Per determinare la causa del problema, vengono eseguiti test delle prestazioni tra il server 1 e diversi altri server della rete del provider di servizi Internet (ISP) e la rete Internet pubblica.
Se in un sistema via cavo vi è una quantità eccessiva di rumore o ingresso, i pacchetti tra i modem via cavo e il CMTS possono essere danneggiati e persi. Ciò può causare un significativo peggioramento delle prestazioni.
Oltre a una riduzione delle prestazioni e del throughput, alcuni dei principali indicatori di rumore o radiofrequenza (RF) includono:
Modem cablati che si disconnettono sporadicamente o si bloccano negli stati init(r1) o init(r2).
Valore SNR stimato basso come mostrato nell'output di un cavo show controller X/Y a monte Z, dove cavo X/Y è l'interfaccia del cavo osservata e Z è la porta a monte osservata. La specifica DOCSIS richiede un rapporto vettore/rumore (CNR) di almeno 25 dB per tutti i segnali a monte. Ciò equivale a un SNR di circa 29 dB. Il Cisco CMTS è in grado di rilevare in modo coerente i segnali a monte QPSK a livelli SNR molto peggiori, tuttavia tutti i provider di servizi via cavo devono cercare di soddisfare i requisiti DOCSIS CNR nel proprio sistema. Di seguito è riportato un esempio di output Z a monte del cavo del controller X/Y.
uBR7246-VXR# show controller cable 6/0 upstream 0 Cable6/0 Upstream 0 is up Frequency 25.200 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps Spectrum Group is overridden SNR 28.6280 dB Nominal Input Power Level 0 dBmV, Tx Timing Offset 6446 Ranging Backoff automatic (Start 0, End 3) Ranging Insertion Interval automatic (102 ms) Tx Backoff Start 0, Tx Backoff End 4 Modulation Profile Group 1 Concatenation is enabled part_id=0x3137, rev_id=0x03, rev2_id=0xFF nb_agc_thr=0x0000, nb_agc_nom=0x0000 Range Load Reg Size=0x58 Request Load Reg Size=0x0E Minislot Size in number of Timebase Ticks is = 8 Minislot Size in Symbols = 64 Bandwidth Requests = 0x37EB54 Piggyback Requests = 0x11D75E Invalid BW Requests= 0x102 Minislots Requested= 0x65B74A2 Minislots Granted = 0x65B74A2 Minislot Size in Bytes = 16 Map Advance (Dynamic) : 2809 usecs UCD Count = 23068
Nell'esempio sopra riportato, il valore SNR stimato è 28,628 dB. Questa opzione è adeguata per il funzionamento upstream di QPSK. Si noti che la cifra SNR fornita nell'output di questo comando è solo una stima e non può sostituire una cifra SNR derivata da un analizzatore di spettro o da un'altra apparecchiatura di prova appropriata. Vedere la Cisco Broadband Cable Command Reference Guide per ulteriori informazioni sul comando show controller cable upstream spectrum.
Un numero in rapido aumento di errori FEC (Corr Forward Error Correction) e Uncorr FEC nell'output di un comando show cable hop. Corr FEC errors indica dati danneggiati da disturbi a monte ma recuperabili. Gli errori FEC di errore indicano dati danneggiati da rumori a monte e che non è stato possibile ripristinarli, con conseguente perdita di dati e riduzione delle prestazioni. Di seguito è riportato un output di esempio del comando show cable hop.
uBR7246-VXR# show cable hop cable 3/0 Upstream Port Poll Missed Min Missed Hop Hop Corr Uncorr Port Status Rate Poll Poll Poll Thres Period FEC FEC (ms) Count Sample Pcnt Pcnt (sec) Errors Errors Cable3/0/U0 25.200 Mhz 34 * * * set to fixed frequency * * * 196 55 Cable3/0/U1 25.200 Mhz 34 * * * set to fixed frequency * * * 1655 160 Cable3/0/U2 25.200 Mhz 34 * * * set to fixed frequency * * * 76525 9790 Cable3/0/U3 25.200 Mhz 34 * * * set to fixed frequency * * * 501 77 Cable3/0/U4 admindown 34 * * * interface is down * * * 0 0 Cable3/0/U5 admindown 34 * * * interface is down * * * 0 0
Nell'esempio di cui sopra, ciascuna porta a monte attiva sul cavo 3/0 sembra aver subito una perdita di pacchetto a causa del rumore. La porta a monte 0 sembra essere la meno interessata e la porta a monte 2 sembra essere la più colpita. Il fattore importante da notare è la velocità con cui gli errori FEC aumentano anziché il numero totale di errori. Per ulteriori informazioni sul comando show cable hop, consultare la guida di riferimento dei comandi di Cisco Broadband Cable.
Un numero elevato di eventi "flap" nell'output di un comando show cable flap-list. Le statistiche di flap più rilevanti per possibili problemi di RF o di rumore sono la colonna Miss, che indica le richieste di range mancanti, e la colonna P-Adj, che indica i livelli di potenza a monte che variano rapidamente. Di seguito è riportato un esempio di output del comando show cable flap-list.
uBR7246-VXR# show cable flap-list MAC Address Upstream Ins Hit Miss CRC P-Adj Flap Time 0000.d025.1b99 Cable3/0/U0 23 58 30 0 *27 77 Oct 23 03:08:23 0002.ddfa.0aa5 Cable3/0/U1 5 518 1260 0 0 131 Oct 23 03:09:43 0001.e659.43bd Cable3/0/U1 541 342 1467 0 0 746 Oct 23 03:09:17 0001.7659.44c7 Cable3/0/U1 0 694 0 0 1 1 Oct 23 01:44:23 0050.9366.22d3 Cable3/0/U1 0 708 0 0 1 1 Oct 23 01:38:14 0001.f659.44e7 Cable3/0/U1 0 701 0 0 1 1 Oct 23 02:25:11
Modem cablati che visualizzano un "* "o un "!—" nell'output di un comando show cable modem o show cable flap-list. Un "*" indica un modem via cavo che sta cambiando rapidamente i livelli di potenza a monte. Ciò è indicativo di una scarsa connessione all'impianto cablato, di un amplificatore a percorso inverso difettoso o di una rapida variazione dell'attenuazione dell'impianto cablato a causa della temperatura o di altri effetti ambientali. Un "!—" indica un modem via cavo che ha raggiunto il livello massimo di potenza in upstream. Ciò indica che l'attenuazione tra il modem via cavo e il CMTS è eccessiva o che la connessione tra il modem via cavo e l'impianto è insufficiente. Di seguito è riportato un output di esempio del comando show cable modem.
uBR7246-VXR# show cable modem Interface Prim Online Timing Rec QoS CPE IP address MAC address Sid State Offset Power Cable3/0/U1 1 online 1549 !--- -1.00 5 0 10.1.1.10 005a.73f6.2213 Cable3/0/U0 2 online 1980 0.75 5 0 10.1.1.16 009b.96e7.3820 Cable3/0/U0 3 online 1981 *0.75 5 0 10.1.1.18 009c.96d7.3831 Cable3/0/U1 4 online 1924 0.25 5 0 10.1.1.24 000d.96c9.4441 Cable3/0/U1 5 online 1925 0.50 5 0 10.1.1.13 000e.96b9.4457
Nell'esempio precedente, il modem via cavo con indirizzo MAC 005a.73f6.2213 sta trasmettendo alla sua potenza massima in uscita. In questo modo il modem non è in grado di trasmettere al livello corretto. Di conseguenza, le trasmissioni a monte di questo modem non vengono ascoltate con la stessa chiarezza delle trasmissioni da altri modem. Il modem via cavo con indirizzo MAC 009c.96d7.3831 ha una potenza di uscita che varia rapidamente a causa della diversa attenuazione del sistema. Per ulteriori informazioni sul modem show cable e i comandi show cable flap-list, consultare la guida di riferimento dei comandi di Cisco Broadband Cable.
Nota: per ulteriori informazioni sull'identificazione e la risoluzione dei problemi di rumore RF, vedere Determinazione dei problemi di RF o di configurazione sul CMTS e Collegamento del router Cisco serie uBR7200 all'headend via cavo.
In alcune circostanze un Cisco CMTS può sovraccaricare il sistema a causa di una configurazione non ottimale, di un uso eccessivo di alcune funzioni di gestione o di un numero molto elevato di pacchetti instradati dal CMTS.
Il modo migliore per determinare l'utilizzo della CPU da parte di un Cisco CMTS è eseguire il comando show process cpu. L'utilizzo corrente della CPU è indicato nella prima riga dell'output del comando.
Nelle righe di output mostrate sotto la prima riga, viene mostrato ciascun processo in esecuzione sul CMTS insieme alla parte di CPU utilizzata da quel processo. Questa sezione dell'output show process cpu è utile per determinare se un particolare processo o funzione è la causa dell'elevata CPU CMTS.
uBR7246-VXR# show process cpu CPU utilization for five seconds: 45%/21%; one minute: 45%; five minutes: 31% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 12 9220 1 0.00% 0.00% 0.00% 0 Load Meter 2 69816 18276677 3 21.79% 22.10% 9.58% 2 Virtual Exec 3 36368 5556 6545 0.00% 0.06% 0.05% 0 Check heaps 4 0 1 0 0.00% 0.00% 0.00% 0 Chunk Manager 5 96 1436 66 0.00% 0.00% 0.00% 0 Pool Manager 6 0 2 0 0.00% 0.00% 0.00% 0 Timers 7 0 2 0 0.00% 0.00% 0.00% 0 Serial Backgroun 8 0 1 0 0.00% 0.00% 0.00% 0 CMTS ping 9 17020 101889 167 0.00% 0.00% 0.00% 0 EnvMon 10 0 1 0 0.00% 0.00% 0.00% 0 OIR Handler . . . . . . . <snip> . . . . . . . 89 3304 81013 40 0.00% 0.00% 0.00% 0 PIM Process 90 12 769 15 0.00% 0.00% 0.00% 0 CEF Scanner 92 0 385 0 0.00% 0.00% 0.00% 0 DHCPD Timer 93 40 13058 3 0.00% 0.00% 0.00% 0 DHCPD Database
Nell'esempio precedente, il carico della CPU corrente sul CMTS è del 45%/21%. Ciò significa che l'utilizzo totale della CPU è al 45% della capacità del sistema. Inoltre, il 21% della CPU viene utilizzato per servire gli interrupt. Questa seconda cifra in genere equivale alla parte della CPU utilizzata per instradare i pacchetti e instradare il traffico di switch attraverso il CMTS.
Se l'utilizzo della CPU nei cinque minuti è costantemente superiore all'80% durante il tempo di picco del sistema, gli utenti finali potrebbero iniziare a sperimentare prestazioni più lente e una maggiore latenza. Se l'utilizzo della CPU nei cinque minuti è costantemente superiore al 95% durante il tempo di picco, adottare misure urgenti per garantire che il CMTS rimanga stabile.
Le strategie comuni per ridurre l'utilizzo elevato della CPU nel CMTS includono:
Aggiornamento al software Cisco IOS versione 12.1(9)EC o successive, attivazione del comando di configurazione globale ip cef e verifica che sulle interfacce del CMTS non sia configurato il comando no ip route-cache. In questo modo, l'utilizzo della CPU correlata al traffico viene in genere ridotto del 10-15%. Accertarsi che tutte queste operazioni vengano eseguite congiuntamente.
Accertarsi che le stazioni di gestione SNMP (Simple Network Management Protocol) non siano troppo aggressive per il polling del CMTS. Ciò comporta un utilizzo elevato della CPU nel processo SNMP IP.
Il comando show tech non viene eseguito più volte in successione. Ciò determina un utilizzo artificialmente elevato della CPU nel processo Virtual Exec.
Accertarsi che non siano in esecuzione comandi di debug sul CMTS.
Per ulteriori informazioni sull'utilizzo elevato della CPU sui router Cisco, tra cui i prodotti Cisco CMTS, consultare il documento sulla risoluzione dei problemi di utilizzo elevato della CPU sui router Cisco.
In molti casi, la causa della lentezza di accesso a una rete via cavo è un problema nelle apparecchiature CPE dell'utente finale. Se solo uno o pochi utenti riscontrano un throughput lento e il resto della popolazione di utenti non incontra alcun problema, ciò indica chiaramente che potrebbe esserci un problema unico nell'ambiente di quell'utente.
CPE sottoalimentato o sovraccarico: se gli utenti finali che si lamentano delle difficoltà utilizzano apparecchiature CPE obsolete o apparecchiature che potrebbero non essere sufficientemente potenti per eseguire il sistema operativo o il software di accesso a Internet prescelto, l'utente finale avrà difficoltà. L'unica risoluzione in questo caso è che l'utente finale deve aggiornare le proprie apparecchiature CPE.
Firewall o software di misurazione delle prestazioni: se l'utente finale utilizza un firewall, un sistema di misurazione delle prestazioni della rete o un altro software simile, per risolvere il problema è consigliabile disattivare il software e verificare se influisce sulle prestazioni. Spesso questo tipo di software può avere un impatto negativo sulle prestazioni.
Impostazioni TCP/IP non configurate correttamente: la maggior parte dei provider di servizi richiede che gli utenti finali acquisiscano un indirizzo IP, una maschera di rete, un gateway predefinito e i server DNS tramite il protocollo DHCP (Dynamic Host Configuration Protocol). Verificare che gli utenti finali che riscontrano problemi dispongano di dispositivi CPE configurati per l'utilizzo di DHCP per acquisire tutti questi parametri.
Se un utente finale dichiara di non avere nessuno dei problemi elencati in precedenza, confermare che l'utente finale non superi la velocità massima di download o caricamento indicata nelle sezioni precedenti.
Una rete cablata DOCSIS è un sistema sofisticato che richiede un'adeguata pianificazione e manutenzione. La maggior parte dei problemi di prestazioni nei sistemi di cavi DOCSIS è il risultato diretto della mancata esecuzione di attività di pianificazione e manutenzione appropriate. Nell'attuale mercato dell'accesso a Internet, in cui esistono diverse alternative per l'accesso a Internet a banda larga, è importante che i fornitori di servizi via cavo affrontino rapidamente qualsiasi problema di prestazioni o congestione nel loro sistema prima che i problemi diventino sufficientemente significativi da interessare in modo significativo gli utenti finali e, di conseguenza, prendere in considerazione un mezzo alternativo di accesso a banda larga.