¿Es posible medir TDR sin un dispositivo especializado?

He visto dispositivos dedicados para medir TDR e incluso conmutadores de red de capa 2 y 3 con capacidad TDR. Mi pregunta es ¿qué evitaría que un enrutador doméstico estándar se programe para medir las mismas métricas? -¿Estar en la tercera capa OSI en lugar de las capas 2 y 3 como los interruptores avanzados? ¿O los interruptores y otros dispositivos tienen una pieza especial de hardware instalada que les permite detectar algo que otros dispositivos no pueden? He estado buscando en todo Google e incluso saqué los estándares de Ethernet IEEE para ver si eso me ayudaría a comprender mejor (gran parte del material 802.3 se me pasó por la cabeza).

El hecho de que casi nunca es necesario.
Muy cierto. Sin embargo, mi objetivo es determinar si sería posible, no necesariamente práctico. Actualicé el título para reflejar la distinción.
Si un osciloscopio no está "especializado", puede hacer algunas aproximaciones conectando el cable con una señal de estímulo de tiempo de subida corto y luego usando un conector T para conectarlo a la entrada del osciloscopio de alta Z para monitorear los retornos.
Estoy bastante seguro de que es una capacidad/limitación del hardware (si está integrada o no) y no simplemente un ajuste de programación. Pero no tengo fuentes autorizadas, solo cambios de ambos tipos.
@ user2943160 En este caso, consideraría un osciloscopio como un equipo especializado. Estoy buscando determinar la viabilidad de implementar un TDR utilizando la infraestructura de red existente. -Idealmente, mediante el diseño de software para mejorar las capacidades de los enrutadores básicos (es decir, un enrutador doméstico) que siguen los estándares IEEE actuales.
@Ecnerwal Eso está en la línea de lo que estoy pensando, pero no puedo encontrar documentación para confirmarlo. Parece que si alguien pudiera haberlo hecho sin el hardware especial, ya lo habría hecho. Aunque me gustaría saberlo con certeza.
Creo que es un modo especial de operación en el phy. Probablemente la mayoría de los físicos no lo admitan. Esto es sólo una suposición.

Respuestas (2)

Estoy buscando determinar la viabilidad de implementar un TDR utilizando la infraestructura de red existente.

La capacitancia del cable Ethernet es directamente proporcional a su longitud. Entonces, un analizador de red podría, supongo, realizar una medición de longitud de cable dentro de banda fuera de banda inyectando un pulso de tiempo de subida rápido u(t) en un extremo del cable, proporcionando una resistencia de valor conocido en el otro ( "medida") extremo del cable, y midiendo el tiempo de subida de la red RC para determinar la longitud del cable. Esta técnica permitiría el rango automático (seleccionando diferentes valores de resistencia bajo el control del software) y un hardware de costo relativamente bajo podría realizar este tipo de medición (por ejemplo, un microcontrolador suficientemente rápido con entradas de comparación y circuitos de contador de tiempo). Esto no sería un TDR "verdadero", pero creo que podría medir la longitud de un cable con una resolución y precisión adecuadas.

¿Sería factible adaptar una infraestructura de red existente con este tipo de sistema de medición de longitud de cable? En mi opinión, no; no es factible. En primer lugar, debe diseñar este sistema de medición de longitud de cable actualizado de tal manera que no degrade la señalización de 100/1000 Mb/s en el cable. Buena suerte con eso. En segundo lugar, el software de conmutación/enrutamiento que se ejecuta en la plancha dentro del conmutador/enrutador es varios órdenes de magnitud más lento que el tiempo de vuelo de las señales eléctricas en el cable (al menos dentro de un segmento de red local, este sería el caso). Por lo tanto, no tiene sentido intentar determinar las diferencias de tiempo de vuelo entre los cables A y B cuando esos valores de tiempo son del orden de unos pocos nanosegundos, considerando que el software que se ejecuta en el conmutador/enrutador requiere alrededor de un milisegundo (<

¡Perfecto! ¡Esto ayuda mucho! No había considerado los tiempos de retraso entre las señales físicas y el procesamiento del software. Cuando dice "degradar la señalización de 100/1000 Mb/s", ¿se refiere a cómo el pulso interrumpirá todas las demás señales en curso? ¿Cree que sería posible si uno ignorara la calidad de otras señales y enviara un pulso ligeramente más sostenido, lo suficientemente largo como para que el software tuviera tiempo de medir y procesar las diferencias entre el cable A y B?
"Cuando dice 'degradar la señalización de 100/1000 Mb/s', ¿se refiere a cómo el pulso interrumpirá todas las demás señales en curso?" Sí; la transmisión de tramas de Ethernet (supongo que Ethernet) debe detenerse momentáneamente para realizar la tarea de medición de la longitud del cable en banda. Además, me refiero a que el hardware de actualización no debe corromper ni degradar la integridad de las señales eléctricas en los cables durante el "funcionamiento normal" cuando no se realiza una medición de la longitud del cable.
Y sí, el ancho de pulso u(t) debe ser lo suficientemente ancho para impulsar una lógica alta en el cable durante todo el ciclo de medición al medir la longitud de cable más larga permitida (que IIRC es 100 m para cable Ethernet Cat 5/5e/6).
@JimFischer seguramente cualquier medida también requeriría que se desconecte un extremo del cable, de modo que la resistencia conocida se pueda introducir y medir con precisión. Esto impediría su uso en una red real.
@David "¿cualquier medida también requeriría [...]?" Para el sistema que describí anteriormente, sí. "Esto impediría su uso en una red real". No necesariamente. Es posible que el sistema BAJE sincrónicamente ambos extremos del cable (detenga el tráfico normal de la red a través del cable), realice la medición de la longitud del cable dentro de la banda y luego SUBA sincrónicamente ambos extremos y reanude el tráfico normal de la red. La señal de control ABAJO/ARRIBA podría enviarse en banda a través de una trama Ethernet especial (¿personalizada?), por ejemplo, o a través de algún canal de comunicación fuera de banda.
Tenga en cuenta que estoy ignorando deliberadamente todo tipo de problemas del "mundo real" que un sistema de actualización como este podría causar. Por ejemplo, si el conmutador Ethernet está enviando paquetes UDP (entrega de mejor esfuerzo) y el enlace del cable se DESACTIVA para realizar la medición de la longitud del cable, es probable que los paquetes UDP entrantes destinados a ese enlace se descarten mientras se realiza la medición de la longitud del cable. siendo realizado.

Solía ​​tener una tarjeta lan Intel Pro de 1 Gb en mi computadora de escritorio y venía con un software TDR básico que podía probar la longitud de cada uno de los ocho hilos en un cable lan (con una longitud mínima de 3 pies). Este software requería que el otro extremo del cable de red estuviera abierto (no conectado a nada) y solo mostraba la longitud de cada cable. No mostraba un gráfico como se ve con un TDR gráfico. Tuve esa NIC Intel hasta hace un par de años y no he encontrado ninguna NIC desde que sea capaz de hacer lo mismo.

Mi enrutador D'Link DIR-605L tiene una función disponible en su GUI web llamada Prueba de circuito virtual (VCT) que se supone que hace exactamente esto. Sin embargo, no es así, solo dice "TxPairError at meters" para cualquier enlace que esté caído.
¿Es posible medir TDR sin un dispositivo especializado?
RespuestasAquíPolítica de privacidad1y, 0v