4 respuestas
11 mensajes

Este tema lleva más de 6 meses inactivo. Es recomendable que abras un nuevo tema para retomar la conversación.
    • #2202250

      a veces hay que llamar para activarlo.. aquí tienes una traza…

      a veces hay que llamar para activarlo..

      aquí tienes una traza (me parece que con fastpath)

      64 bytes from 89.248.106.100: seq=0 ttl=51 time=62.424 ms
      64 bytes from 89.248.106.100: seq=1 ttl=51 time=69.607 ms
    • #2202253

      Primero es saber si tienes acceso directo o indirecto. En…

      Primero es saber si tienes acceso directo o indirecto. En indirecto, que va por telefónica, no hay esa posibilidad. En cuanto a directo, mira bien tus datos de atenuación, si son elevados (>20), puedes tener problemas de perdida de paquetes y te puede ir peor.

          • #2202267

            Al revés, en Interleaving si se corrigen y por eso el aumento…

            Al revés, en Interleaving si se corrigen y por eso el aumento de la latencia. Contento

            En la linea influyen muchos factores, y la atenuación es una de ellas pero no única y determinante. Y ya no entramos tampoco en el comportamiento del FEC, HEC del ATU-R (CPE), de si la corrección se hace por TCP o sin ella por UDP, del SNRm, etc.

            Lineas con menos de 10dB pueden tener pérdidas de paquetes por errores, y lineas de más de 35dB no tener. ¿Se entiende porque no se sostiene? En ningún momento digo que no pueda darse el caso o que la atenuación no influya.

            El enlace que pones ya lo indica (que no lo de la atenuación), y que es frente al ruido impulsivo (tampoco especifican nada de la diafonía ni por muchas otras causas). Ese ruido, se puede estar generando en cualquier tramo de la linea independientemente de la atenuación que tenga. Lo que si se podría decir es que a mayor longitud de par (más atenuación), más posibilidades de encontrarse con ese ruido o elemento que lo genere, así cómo estar acompañado en el multipar por multitud de otras lineas y que entre ellas se hagan la puñeta (diafonía). En fin, que se podrían enumerar muchas cosas que habría que tener en cuenta para "posiblemente tener errores", y en resumen, es la calidad general de cada linea individual.

            Aquí una pequeña y sencilla explicación sobre la corrección de errores.

            Saludos.

            • #2202319

              En general, con atenuaciones elevadas fastpath suele ir mal.…

              En general, con atenuaciones elevadas fastpath suele ir mal. Es lo habitual y no es la norma. Lo mejor es siempre llamar, que activen y probar si existen perdidas de paquetes en pruebas.

    • #2202271

      Si llamas e insistes si; PING google.com (173.194.34.231)…

      Si llamas e insistes si;

      PING google.com (173.194.34.231) 56(84) bytes of data.
      64 bytes from mad01s09-in-f7.1e100.net (173.194.34.231): icmp_req=1 ttl=56 time=10.3 ms
      64 bytes from mad01s09-in-f7.1e100.net (173.194.34.231): icmp_req=2 ttl=56 time=10.2 ms
      64 bytes from mad01s09-in-f7.1e100.net (173.194.34.231): icmp_req=3 ttl=56 time=10.5 ms
      64 bytes from mad01s09-in-f7.1e100.net (173.194.34.231): icmp_req=4 ttl=56 time=10.7 ms
      --- google.com ping statistics ---
      4 packets transmitted, 4 received, 0% packet loss, min/avg/max/mdev = 10.203/10.440/10.722/0.195 ms
      
      
        • #2205553

          En eso tienes razón, yo llamé 3 veces y la última es la que…

          En eso tienes razón, yo llamé 3 veces y la última es la que supo lo que era, y era "sud americano", las dos primeras españolas y no sabian ni que era y me negaban que se pudiese.

          Eso cuando quise ponerlo.

          Saludos