Bueno, este post sera bastante duro para algunos pero allá va.
En anteriores post ya me había quejado de la lentitud de mi conexion a Jazztel 1 Mega. Con el D-Link ya habia comprobado los SNR y las atenuaciones con valores por cierto muy buenos. Sin embargo cuando hacia pings se me perdian alrededor del 5-10% y no me gustaba nada. Maxime cuando los que respondian solian tener valores bastante parecidos por lo que no parecia una saturacion.
Los datos que presento son de un ping de 300 paquetes con tamaño >1000 bytes y de los cuales me habia perdido 18.
La solucion solo pasaba por una cosa: poner un router adsl Cisco y que me chivara qué cojones estaba pasando.
Efectivamente, los valores de la linea eran buenos y en principio no aparecian errores de CRC ni correcciones Reed-Solomon:
ATU-R (DS) ATU-C (US)
Modem Status: Showtime (DMTDSL_SHOWTIME)
DSL Mode: ITU G.992.1 (G.DMT)
ITU STD NUM: 0x01 0x01
Vendor ID: 'ALCB' 'ALCB'
Vendor Specific: 0x0000 0x0000
Vendor Country: 0x00 0x0F
Capacity Used: 13% 40%
Noise Margin: 45.5 dB 27.0 dB
Output Power: 20.0 dBm 12.0 dBm
Attenuation: 18.0 dB 12.0 dB
Defect Status: None None
Last Fail Code: None
Selftest Result: 0x00
Subfunction: 0x15
Interrupts: 646 (1 spurious)
Activations: 1
Init FW: embedded
Operartion FW: embedded
SW Version: 3.9.220
FW Version: 0x1A04
Interleave Fast Interleave Fast
Speed (kbps): 1024 0 320 0
Reed-Solomon EC: 0 0 0 0
CRC Errors: 0 0 0 0
Header Errors: 0 0 0 0
Bit Errors: 0 0
BER Valid sec: 0 0
BER Invalid sec: 0 0
Pero sin embargo sí me aparecian errores de CRC en el interfaz ATM:
ATM0 is up, line protocol is up
Hardware is PQUICC_SAR (with Alcatel ADSL Module)
MTU 1500 bytes, sub MTU 1500, BW 320 Kbit, DLY 80 usec,
reliability 142/255, txload 2/255, rxload 1/255
Encapsulation ATM, loopback not set
Encapsulation(s): AAL5 AAL2, PVC mode
10 maximum active VCs, 64 VCs per VP, 1 current VCCs
VC Auto Creation Disabled.
VC idle disconnect time: 300 seconds
Last input never, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/224/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: Per VC Queueing
5 minute input rate 0 bits/sec, 2 packets/sec
5 minute output rate 3000 bits/sec, 2 packets/sec
735 packets input, 244191 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 10 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
827 packets output, 305834 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 output buffer failures, 0 output buffers swapped out
Entonces ¿como podia tener errores de CRC si en los parametros de linea no ponia nada anomalo? Pues casi me rompo los cuernos hasta que hago:
show controller atm 0 y me sale entre otras cosas:
Num length errors (LN) = 10, Num CRC errors (CR) = 10
Num frames received with CLP bit set (CLP) = 49
Ay! Justo el numero de errores CRC! Y qué significa esto? Pues buscando encuentro este doc de Cisco:
En el, hay un parrafo en el que dice que la perdida en recepcion de una celda ATM podria implicar no solamente la perdida de 1 paquete IP sino de 2 en el caso que se pierda aquella que marca el final del paquete IP, contando como un error de CRC y de longitud.
Ademas, si os fijais, se reciben muchas celdas con el bit CLP a 1 lo que quiere decir que es tráfico que se sobrepasa al caudal contratado y que los equipos de Telefonica pueden descartar si tienen saturacion en la red.
Como conclusión, los errores de CRC que me aparecian finalmente se deben a que la conexión que hace Jazztel a la red GigADSL de Telefonica esta saturada, lo que fuerza a que se pierdan celdas ATM y los paquetes no se puedan reconstruir enteramente, dando errores de CRC en el router.
Ahi queda eso.
Saludos!!!!!
