Poquisima velecidad en navewgacion WEB

No soy el de antes, pero a mi me ocurre lo mismo, y soy de Portu.. (eso sí, a mi me va peor ahora, pero ya me va mal desde Septiembre)

Por cierto, a alguien más le ocurre que en los momentos que peor va si intentas resetear el modem o desenchufarlo para "arreglarlo" se queda el modem muchas veces estancado en la secuencia de conexión? (en mi RCA TCM245 los primeros 3 LED parpadeando indefinidamente)

Hola, efectivamente, soy de Algorta en concreto.

He pasado de tener un ping a google de alrededor de 85ms, a tenerlo
de 350ms y con numerosas perdidas de paquetes.

Acabo de llamar al 902540015 para quejarme. Me han dicho lo que le
diran a todos, que abren un parte de incidencia y que lo van a mirar.
Me han preguntado si las descargas me iban bien, y le he dicho que las
descargas me van perfectamente, pero que la navegacion no. Le he dicho
que se que navegamos a traves de su Proxy, y que tienen que mirar que
es lo que esta sucediendo.

No se luego si lo miraran o no, pero si somos muchos igual hacen algo.
Asi que animo a todos los que os vaya mal a llamar, que estamos en
nuestro derecho.

Saludos.

BILBOKOA, depende, aunque si como ves el ping mínimo "normal" es alrededor de 8ms, más de 150ms o 200ms no solo no es aceptable, es directamente una KK :-D . Mi humilde modem de 56k me da 100ms estables al primer nodo -va sobre otras lineas, en este caso Jazztel- así que ya ves. De todas formas es cierto que en redes saturadas el administrador de red puede priorizar un tipo de tráfico sobre otro para optimizar el uso, y por tanto el ping (protocolo ICMP) puede dar resultados sesgados por tener la peor prioridad. Ahora bien, en este caso está claro que los ping concuerdan con la realidad porque la navegación, descargas, etc.. están afectados.

Como ya he puesto antes ya he notado además que han cambiado varias veces las tablas de enrutamiento IP en los últimos días cuando el tiempo de respuesta a través de alter.net (la mayoría del tráfico parece que se enrutaba por esa red) se estaba disparando, me imagino que para equilibrar el tráfico entre distintas lineas. Eso quiere decir que habrá páginas web que vayan peor que otras, pq por lo que he visto ahora mismo hay *grandes* diferencias de ping entre unas y otras.

Por último, la gente que piensa que el "ping" o el "packet loss" son solo conceptos relativos a juegos y que piensan que eso no les afecta a ellos por que no usan la conexión para juegos están en un error, afectan mucho a los juegos online pero si son suficientemente malos afectan a cualquier tipo de aplicaciones que vayan sobre esa linea, navegación, FTP, P2P, video streaming, lo que sea.

PD: dudo que el "proxy transparente" de Euskaltel tenga algo que ver, pero si alguno usa un proxy público que funcione bien podría decir si hay alguna diferencia.

[edit] Bilbokoa, para afinar más en vez de "pingear" el servidor DNS de Euskaltel que me imagino que estará en el parque tecnológico de Zamudio puedes hacerlo directamente a tu cabecera, a la IP de la puerta de enlace predeterminada de tu conexión de cable. Esta IP esta asignada a la máquina que se conecta directamente a tu cable modem, así que al menos puedes comprobar si el aumento de ping a 212.55.8.132 se produce en la red de Euskaltel o se produce en la conexión entre el cable modem y la cabecera.

Si quieres comprobarlo para saber cual es la IP de la puerta de enlace predeterminada saca una ventana DOS haciendo menu inicio > Ejecutar.. y pon en la caja: cmd . Luego en el promt DOS teclea: ipconfig /all

@ Bilbokoa: pues eso lo que significa es lo que suponía, que el problema general viene dado por saturación o algun otro problema que afecta a la red de Euskaltel de manera global y no a las conexiones entre cable modem y cabecera (aunque en mi caso tb esta conexión anda mal :/ )

@ Gus:

En cuanto a lo de direcciones de correo creo que lo que buscas es o 015@euskaltel.es o 015@euskalnet.net , una de las 2 (creo que es la 2º) 8-)

Y desde luego yo no sé casi nada sobre el protocolo ARP -así que te imaginas que no soy ningún experto- pero sí sé que en la topología de las redes HFC se suelen dividir los cable-modems en diferentes subredes a nivel IP a pesar de compartir el mismo segmento físico. Por tanto el UBR de la cabecera, además de tener una IP primaria (IP privada que en Euskaltel esta configurada para que no responda a pings y aparece como timeout en el primer hop de las trazas) también tiene multiples IPs secundarias públicas que actúan como gateway de las distintas subredes, y tiene sentido porque con la máscara de subred de la conexión (255.255.254.0) sólo se pueden tener unos 500 usuarios por subred, y la cabecera da servicio a miles de usuarios.

O sea, que puede que tu tengas asignado ese gateway (212.142.154.1) y un vecino tuyo que tuviera tb cable modem tenga otro diferente, o que otra persona que ni siquiera está en tu mismo nodo de otra localidad pero que su nodo esté enganchado a la misma cabecera tenga el mismo gateway que tú. Por ejemplo yo mismo tenía durante 2 años asignada como gateway 212.142.146.1 y ahora tengo otra 212.142.144.1 . En todo caso me imagino que si las IPs de las subredes son contiguas para cada cabecera Así que como a todos los cable modems enganchados a la red HFC de tu cabecera les llegan los mismos datos parece lógico que veas broadcasts ARP que provengan de otros gateways. Tiene sentido esto? :-P

Yo llamé ayer al 902540015, les conté el problema y me dijeron que mandase un correo a 015@euskaltel.es con mis datos (DNI del titular de la cuenta, Tlfn, email) y con capturas de pantalla de los pings. Les mandé varios de yahoo, elpais,google, etc. todos entorno a los 400ms.

No se ni silo leerán pero es que el otro día fué peor porque me salió el típico técnico que te dice que resetees el cm y chorradas por el estilo que sabes que no tienen nada que ver.

Las tramas ARP se envían entre host que pertenezcan al mismo dominio de broadcast o difusión. Me explico.

El protocolo ARP lo que permite es obtener la dirección IP de un host a partir de su dirección MAC. Para poder enviar datos usando TCP/IP es preciso incluir en la cabecera de los datagramas tanto la IP de origen/destino como la MAC de origen/destino, y si no se conoce alguno de los cuatro datos se usa ARP (si sabes la IP pero no la MAC es ARP, si sabes la MAC pero no la IP es RARP -> Reverse ARP).

Llegados a este punto, lo que ocurre es que yo puedo ser un host que conoce su MAC, su IP y la IP de destino, pero no la MAC de destino. Así que genero una petición ARP, y para asegurarme de que la leen todos los host de mi segmento (alguno me contestará!) pongo como dirección MAC de destino la MAC de broadcast: FFFFFF-FFFFFF. Todos los host de la red procesan ese mensaje y miran a ver qué dirección IP de destino hay. Si es la suya dicen "anda, el host que ha enviado esta petición ARP quería conocer mi MAC", y responden mandado una respuesta ARP en la que incluyen su MAC y su IP al host que ha originado la petición.

¿Qué ocurre si el host que buscamos NO está dentro de nuestra red/subred? Que absolutamente todos los host que están conectados a ella han recibido nuestra petición ARP, pero ninguno nos ha podido responder. ¿Ninguno? Noo! Generalmente todas las redes tienen un Gateway por defecto (suele ser el router que nos da salida a la red), que lo que hace al recibir una petición ARP es mirar a ver si la IP de destino pertenece a esa red o no. De no ser así lo que hace es enviar una respuesta ARP al host que ha originado la petición diciéndole que la dirección MAC que quiere conocer es la suya propia, la del router (--> la MAC de la interfaz del router que está conectada a la red a la que pertenece el host que ha hecho la petición). Esto lo hacen los routers que ejecutan el protocolo ARP PROXY: envían la petición ARP a la red adecuada en función de cuál sea la IP destino de la misma (usa su propia tabla de enrutamiento para enviarla).

El problema que planteas es tener un exceso de tramas ARP (en todo caso no especificas si son peticiones o respuestas, pero supondremos que son sobre todo peticiones). Esto puede deberse a:

1) Que haya muchos host dentro del segmento.

2) Que el dominio de difusión sea muy grande. Es decir, antes hemos dicho que la petición ARP era procesada por todos los host del segmento porque se enviaban a la dirección MAC de difusión. Es decir, si tenemos varias redes conectadas por un dispositivo que lo único que es capaz de filtrar es direcciones MAC (caso de los switches), y la dirección MAC que estamos enviando es de difusión entonces todos los host, tanto los de la red de origen como los de todas las redes que estén conectados al switch, verán y procesarán esa trama ARP. Este es el mayor problema, generalmente. Los dominios de broadcast o difusión son muy grandes, y cuando un host envía una petición ARP se genera muchísimo tráfico. Por eso decía ahí arriba que sobre todo serían peticiones ARP lo que observas: la petición va a todos los host, pero la respuesta sólo la genera uno de ellos.

Por otra parte hay algunos sistemas operativos como Windows 95, 98, NT, etc. que antes de inicializar TCP/IP envían peticiones ARP para verificar si la IP que van a utilizar para conectarse a la red está duplicada o no. Es decir, cada ordenador cuando se conecta a la red (si es un cablemódem, sería en el momento de encender el ordenador) envía peticiones ARP. Supongo que dependiendo de la hora si hay mucha gente con cablemódem conectados a nuestro mismo segmento de red recibiremos muchas peticiones ARP. Del mismo modo si internamente en la red en vez de usar routers (que sí que filtran las peticiones ARP, pues tienen en cuenta también las IPs de destino, y no propagarían dichas tramas) se usan switches veremos las peticiones ARP no sólo de nuestro segmento sino también las del resto.

Desde luego que, contestando a tu pregunta, si las subredes están unidas por routers NO debería haber tráfico ARP entre subredes, sólo debería haber tramas ARP dentro de la propia subred. Porque el propio router, actuando como proxy ARP, sabe a qué subred enviar las peticiones ARP. Otra cosa es lo que te decía yo de que los usuarios enciendan su ordenador.

Espero no haber liado mucho la perdiz, je je.

Anerien ese test es de hoy a la mañana y para mi no es valido, porq ayer durante todo el dia tuve la conexion muy saturada navegacion mala, descarga muy mala, ping etc pero resulta que llega la 1 de la madrugada, quito todo el soft que podria interferir, hago un test en telefonica y tachan 35kb, mientras q durante todo el dia el maximo era de 20kb incluso dio 7kb, los pings mas de lo mismo vuelven a la normalidad y las descargas perfectas tanto emule, ftp y http.

hola bocadepez,estas por ahi?mira la hora a la q pongo ese mensaje,me interesaria hablar contigo un saludo

Hola, soy el que suele firmar como Gus

He tenido un nuevo corte de servicio, aunque solo haya sido de 06:00 a 06:20.
Estoy ya en el curro, y estoy viendo en remoto que mis
descargas han subido.
Concretamente tengo Despega Inicia de 128Kbits, y estoy
descargando a 19KBytes/s, lo que vendrian a ser unos
150Kbits/s
Normalmente no suelo pasar de 16-17KBytes/s, aunque
todavia es pronto para pensar que a los de 128 nos han
subido a 150 no?

Saludos.

Aupa:

A mi me sigue bien, pero, ya por curiosidad ¿podeis avisar cuando os vaya bien?

Venga gente

HOla
Eso creo yo tambien , no estamos acostumbrados a quejarnos y parece que como que se haria algo mal . No pasa nada por mandarles mails , igual alguno ahi por ahi que no hace sus deberes bien . El problema de la navegacion se deve de solucionar porque pagamos a precio de Oro lo que vale dos terceras partes asi que espavile quien tiene que espavilar.
Agur