Re: Modificar velocidad placa de red (LAN)
El día 19 de enero de 2017, 5:37, Rivera Valdez
<riveravaldezmail@gmail.com> escribió:
> 2017-01-05 15:16 GMT-03:00 Matias Mucciolo <mmucciolo@suteba.org.ar>:
>>
>>
>> On Thursday 05 January 2017 14:59:01 Rivera Valdez wrote:
>>> 2017-01-05 10:06 GMT-03:00 Jorge A. Secreto <jorgesecreto@gmail.com>:
>>> > Hola
>>> >
>>> > El 4 de enero de 2017, 22:16, Rivera Valdez <riveravaldezmail@gmail.com>
>>> > escribió:
>>> >>
>>> >> > ----- Original Message -----
>>> >> > From: "Rivera Valdez" <riveravaldezmail@gmail.com>
>>> >> > To: "debian-user-spanish" <debian-user-spanish@lists.debian.org>
>>> >> > Sent: Wednesday, January 4, 2017 3:30:27 PM
>>> >> > Subject: Modificar velocidad placa de red (LAN)
>>> >> >
>>> >> > Qué tal,
>>> >> >
>>> >> > tengo una notebook conectada por cable de red a un router que a su vez
>>> >> > está conectado también por cable de red a una máquina de escritorio
>>> >> > (es decir, una LAN hogareña, bah, que consiste sólo en esto que
>>> >> > mencioné). Ambas máquinas tienen distros basadas en Debian.
>>> >> >
>>> >> > Las máquinas se ven y comunican entre sí sin problemas, salvo que -por
>>> >> > algún motivo que no consigo elucidar- la velocidad de transmisión de
>>> >> > archivos entre ellas (sea mediante gestores gráficos o mediante sftp
>>> >> > por terminal) ha bajado y está clavada en 1.1MB/s. Antes, durante un
>>> >> > par de años y normalmente, la velocidad era mucho mayor.
>>> >> >
>>> >> > ¿Desde dónde puedo controlar y modificar esto?, la velocidad a la cual
>>> >> > se comunican/transmiten datos entre sí.
>>> >> >
>>> >> > ¡Muchas gracias!
>>> >> 2017-01-04 21:13 GMT-03:00 Matias Mucciolo <mmucciolo@suteba.org.ar>:
>>> >> >
>>> >> > Buenas
>>> >> > proba con mii-tool
>>> >> > o ethtool
>>> >> >
>>> >>
>>> > -------
>>> >>
>>> >> >
>>> >> > --
>>> >> > Matias Mucciolo
>>> >> >
>>> >> > Area de Infraestructura.
>>> >> > Piedras 737 C.A.B.A
>>> >> > SUTEBA
>>> >> >
>>> >>
>>> >> Muchas gracias, Matias, !
>>> >>
>>> >> Por lo que estoy viendo ethtool tiene una manpage bastante poblada,
>>> >> ahora me voy a poner a leerla en detalle.
>>> >>
>>> >> Mientras, por si alguno detecta rápidamente cuál puede ser el
>>> >> problema, pego la salida que me da:
>>> >>
>>> >> $ ethtool eth0
>>> >> Settings for eth0:
>>> >> Supported ports: [ TP MII ]
>>> >> Supported link modes: 10baseT/Half 10baseT/Full
>>> >> 100baseT/Half 100baseT/Full
>>> >> 1000baseT/Half 1000baseT/Full
>>> >> Supported pause frame use: No
>>> >> Supports auto-negotiation: Yes
>>> >> Advertised link modes: 10baseT/Half 10baseT/Full
>>> >> 100baseT/Half 100baseT/Full
>>> >> 1000baseT/Half 1000baseT/Full
>>> >> Advertised pause frame use: Symmetric Receive-only
>>> >> Advertised auto-negotiation: Yes
>>> >> Link partner advertised link modes: 10baseT/Half 10baseT/Full
>>> >> 100baseT/Half 100baseT/Full
>>> >> Link partner advertised pause frame use: Symmetric
>>> >> Link partner advertised auto-negotiation: Yes
>>> >> Speed: 100Mb/s
>>> >> Duplex: Full
>>> >> Port: MII
>>> >> PHYAD: 0
>>> >> Transceiver: internal
>>> >> Auto-negotiation: on
>>> >> Cannot get wake-on-lan settings: Operation not permitted
>>> >> Current message level: 0x00000033 (51)
>>> >> drv probe ifdown ifup
>>> >> Link detected: yes
>>> >>
>>> >> Reitero que, de momento, con ese resultado, la velocidad de
>>> >> transmisión real en la práctica es de 1.1MB/s, ¿alguna pista?
>>> >>
>>> >> Gracias de nuevo, !
>>> >>
>>>
>>> Qué tal, Jorge, muchas gracias por la ayuda:
>>>
>>> > Lo primero que pensé fué en probar los cables.
>>> > Aunque si fueran un desastre, la negociación debería haber elegido 10 y no
>>> > 100
>>> > Por las dudas los chequearía igual.
>>>
>>> En principio los cables no sufrieron ningún "acto de violencia", pero
>>> en cuanto pueda voy a buscar otro cable y hacer la prueba.
>>>
>>> > Otra cosa a tener en cuenta es que no estén pasando cerca de una fuente de
>>> > ruido.
>>> > O paralelos a un cable de alimentación. Salvo que estés usando cables
>>> > blindados.
>>>
>>> No son blindados, pero están en el lugar de siempre, sin
>>> modificaciones en ese sentido, ni nuevos equipos que se hayan
>>> instalado cerca.
>>>
>>> > Como decís que originalmente funcionaban bien, buscaría algún cambio de ese
>>> > estilo.
>>>
>>> En ese sentido no hubo cambios.
>>>
>>> > O que hayan pisado el cable con una silla. ese tipo de cosas.
>>>
>>> Cabe la posibilidad. Cuando testée con otro par de cables (si puedo
>>> esta noche) te confirmo.
>>>
>>> > ¿Probaste de desconectar todo lo demás del router? Que funcione solamente
>>> > como switch.
>>>
>>> Ídem. Esta noche hago la prueba.
>>>
>>> > ¿Puede ser que alguien haya habilitado alguna regla de calidad de servicio
>>> > en el router?
>>>
>>> En principio, no. Ese router lo administro sólo yo, y no modifiqué
>>> nada en él (salvo haber pasado el protocolo de seguridad WiFi de WEP
>>> -que venía por defecto- a WPA2; pero entiendo que no tiene nada que
>>> ver con esto, y además fue posterior a esta caída en velocidad de la
>>> conexión por red cableada).
>>>
>>> > Ah, y la negociación de velocidad es contra el router. ¿Las dos máquinas se
>>> > conectan a 100Mb al router?
>>>
>>> Esta es la salida de la otra máquina (de escritorio) de ethtool (creo
>>> que no importa, pero por las dudas aclaro que la estoy haciendo desde
>>> la notebook, vía ssh):
>>>
>>> [desktop] ~$ ethtool eth0
>>> Settings for eth0:
>>> Supported ports: [ MII ]
>>> Supported link modes: 10baseT/Half 10baseT/Full
>>> 100baseT/Half 100baseT/Full
>>> 1000baseT/Full
>>> Supported pause frame use: No
>>> Supports auto-negotiation: Yes
>>> Advertised link modes: 10baseT/Half 10baseT/Full
>>> 100baseT/Half 100baseT/Full
>>> 1000baseT/Full
>>> Advertised pause frame use: No
>>> Advertised auto-negotiation: Yes
>>> Speed: 100Mb/s
>>> Duplex: Full
>>> Port: MII
>>> PHYAD: 3
>>> Transceiver: external
>>> Auto-negotiation: on
>>> Cannot get wake-on-lan settings: Operation not permitted
>>> Cannot get link status: Operation not permitted
>>>
>>>
>>> Y repito la de la notebook:
>>>
>>> [notebook] ~$ ethtool eth0
>>> Settings for eth0:
>>> Supported ports: [ TP MII ]
>>> Supported link modes: 10baseT/Half 10baseT/Full
>>> 100baseT/Half 100baseT/Full
>>> 1000baseT/Half 1000baseT/Full
>>> Supported pause frame use: No
>>> Supports auto-negotiation: Yes
>>> Advertised link modes: 10baseT/Half 10baseT/Full
>>> 100baseT/Half 100baseT/Full
>>> 1000baseT/Half 1000baseT/Full
>>> Advertised pause frame use: Symmetric Receive-only
>>> Advertised auto-negotiation: Yes
>>> Link partner advertised link modes: 10baseT/Half 10baseT/Full
>>> 100baseT/Half 100baseT/Full
>>> Link partner advertised pause frame use: Symmetric
>>> Link partner advertised auto-negotiation: Yes
>>> Speed: 100Mb/s
>>> Duplex: Full
>>> Port: MII
>>> PHYAD: 0
>>> Transceiver: internal
>>> Auto-negotiation: on
>>> Cannot get wake-on-lan settings: Operation not permitted
>>> Current message level: 0x00000033 (51)
>>> drv probe ifdown ifup
>>> Link detected: yes
>>>
>>> > Saludos
>>>
>>> Saludos, y muchas gracias por cualquier pista para resolver esto, !
>>>
>>
>> Buenas otra ves
>> como estas haciendo la prueba ?
>>
>> proba con este este comando(cambiando USER y SERVER por los correctos):
>>
>> $ dd if=/dev/zero bs=1024 count=1048576 | ssh USER@SERVER 'cat > /dev/null'
>>
>> a mi me tira algo como:
>> 1048576+0 records in
>> 1048576+0 records out
>> 1073741824 bytes (1.1 GB) copied, 100.15 s, 10.7 MB/s
>>
>> 10MB/s que esta bien serian 100mb/s
>>
>> en un enlace de 1gb me da:
>> 1048576+0 records in
>> 1048576+0 records out
>> 2147483648 bytes (2.1 GB) copied, 32.8301 s, 65.4 MB/s
>>
>> con un switch ocupado.
>> proba de ambos sentidos
>>
>> ahora a mi me suena a que estas usando la WIFI de la notebook.
>> es la tipica velocidad de wifi.
>> trata de hacer las pruebas con el wifi apagado.
>>
>> saludos
>> Matias
>
> Gracias a todos y perdón por la demora, recién hoy dispuse del espacio
> y tiempo para hacer más pruebas.
>
> Aparentemente es cosa del cable (cuestión que me descolocó porque
> coincidió *justo* con unos problemas de drivers y cambios de kernel,
> con lo que me parecía *demasiada* casualidad que *justo* el cable se
> jodiera en ese preciso momento, pero...), acabo de hacer la prueba con
> un cable corto que tenía a mano y parece estar funcionando ok.
>
> $ dd if=/dev/zero bs=1024 count=1048576 | ssh USER@PC 'cat > /dev/null'
> USER@PC's password:
> 1048576+0 registros leídos
> 1048576+0 registros escritos
> 1073741824 bytes (1,1 GB) copiados, 94,4255 s, 11,4 MB/s
>
> Copiando [put/get] con sftp también, tengo una velocidad que ronda los 11.0MB/s.
>
> $ sudo mii-tool eth0
> [sudo] password for user:
> eth0: negotiated 100baseTx-FD flow-control, link ok
>
> La salida de ethtool sigue siendo la misma que posteé antes.
>
> Habrá que joderse y reemplazar el largo cable...
> Si tienen alguna sugerencia más, les agradezco cualquier idea/propuesta.
>
Primero con un tester de red, verifica la señal de punta a punta, si
cables ok, reaprieta o cambia conectores. Si efectivamente el cable
esta dañado, identificar el par o cable específico dañado y utilizar
el par que esta libre, revisa lo relativo a la norma 568. Claro está
que este procedimiento no te dejara certificada la red ya que estas
alterando el orden del cableado estructurado, ahora que eléctricamente
será lo mismo, aunque podría darte un poco de problemas en la señal,
¡Por algo esta normado, no!. Esto podría salvarte la situación hasta
que reemplaces el cable.
568 - A
El pin 1 Bl/Ve RD +
El pin 2 Ve RD -
El pin 3 Bl/Na TD +
El pin 4 Az libre
El pin 5 Bl/Az libre
El pin 6 Na TD -
El pin 7 Bl/Ca libre
El pin 8 Ca libre
Suerte.
--
usuario linux #274354
normas de la lista: http://wiki.debian.org/es/NormasLista
como hacer preguntas inteligentes:
http://www.sindominio.net/ayuda/preguntas-inteligentes.html
Reply to: