Ist es möglich, TDR ohne ein spezielles Gerät zu messen?

Ich habe dedizierte Geräte zum Messen von TDR und sogar Layer-2- und 3-Netzwerk-Switches mit TDR-Fähigkeit gesehen. Meine Frage ist, was würde verhindern, dass ein Standard-Heimrouter so programmiert wird, dass er dieselben Metriken misst? - Auf der 3. OSI-Schicht statt auf den Schichten 2 und 3 wie bei den erweiterten Switches? Oder haben die Switches und andere Geräte eine spezielle Hardware installiert, die es ihnen ermöglicht, etwas zu erkennen, was andere Geräte nicht können? Ich habe überall bei Google gesucht und sogar die IEEE-Ethernet-Standards gezogen, um zu sehen, ob mir das helfen würde, besser zu verstehen (ein Großteil des 802.3-Materials ging mir über den Kopf).

Die Tatsache, dass es fast nie benötigt wird.
Sehr richtig. Mein Ziel ist es jedoch festzustellen, ob es möglich wäre, nicht unbedingt praktikabel. Ich habe den Titel aktualisiert, um die Unterscheidung widerzuspiegeln.
Wenn ein Oszilloskop nicht „spezialisiert“ ist, können Sie einige Annäherungen vornehmen, indem Sie das Kabel mit einem Stimulussignal mit kurzer Anstiegszeit ansteuern und dann einen T-Stecker verwenden, um eine Verbindung zum Eingang des High-Z-Oszilloskops herzustellen, um auf Rückgaben zu überwachen.
Ich bin mir ziemlich sicher, dass es sich um eine Hardwarefähigkeit / -einschränkung handelt (ob sie eingebaut ist oder nicht), und nicht nur um eine Programmieroptimierung. Aber ich habe keine maßgeblichen Quellen, nur Schalter beider Art.
@ user2943160 In diesem Fall würde ich ein Oszilloskop als Spezialgerät betrachten. Ich möchte die Machbarkeit der Implementierung eines TDR unter Verwendung der vorhandenen Netzwerkinfrastruktur ermitteln. -Idealerweise durch Entwerfen von Software, um die Fähigkeiten von einfachen Routern (z. B. einem Heimrouter) zu verbessern, die den aktuellen IEEE-Standards entsprechen.
@Ecnerwal Das entspricht dem, was ich denke, aber ich kann keine Dokumentation finden, um dies zu bestätigen. Es scheint, dass, wenn jemand es ohne die spezielle Hardware hätte tun können, es bereits getan worden wäre. Ich möchte es aber genau wissen.
Ich denke, es ist eine spezielle Arbeitsweise in der Phy. Wahrscheinlich unterstützen die meisten Phys es nicht. Dies ist nur eine Vermutung.

Antworten (2)

Ich möchte die Machbarkeit der Implementierung eines TDR unter Verwendung der vorhandenen Netzwerkinfrastruktur ermitteln.

Die Kapazität des Ethernet-Kabels ist direkt proportional zu seiner Länge. Ich nehme an, ein Netzwerkanalysator könnte also eine Außerband-Inband -Kabellängenmessung durchführen, indem er einen u(t)-Impuls mit schneller Anstiegszeit in ein Ende des Kabels einspeist und am anderen einen Widerstand mit bekanntem Wert bereitstellt ( "Messung") Ende des Kabels und Messen der Anstiegszeit des RC-Netzwerks, um die Länge des Kabels zu bestimmen. Diese Technik würde eine automatische Bereichswahl ermöglichen (Auswahl unterschiedlicher Widerstandswerte unter Softwaresteuerung), und relativ kostengünstige Hardware könnte diese Art von Messung durchführen (z. B. ein ausreichend schneller Mikrocontroller mit Komparatoreingängen und Zähler-Zeitgeberschaltungen). Dies wäre kein "echter" TDR, aber ich denke, er könnte die Länge eines Kabels mit angemessener Auflösung und Genauigkeit messen.

Wäre es möglich, eine bestehende Netzwerkinfrastruktur mit einem solchen Kabellängenmesssystem nachzurüsten? Meiner Meinung nach nein; es ist nicht machbar. Erstens müssen Sie dieses nachrüstbare Kabellängenmesssystem so konzipieren, dass es die 100/1000 Mb/s-Signalisierung auf dem Kabel nicht verschlechtert. Viel Glück damit. Zweitens ist die Switching-/Routing-Software, die auf dem Bügeleisen im Switch/Router ausgeführt wird, um mehrere Größenordnungen langsamer als die Laufzeit der elektrischen Signale auf dem Kabel (zumindest innerhalb eines lokalen Netzwerksegments wäre dies der Fall). Es macht also keinen Sinn, die Flugzeitunterschiede zwischen den Kabeln A und B zu bestimmen, wenn diese Zeitwerte in der Größenordnung von wenigen Nanosekunden liegen, wenn man bedenkt, dass die auf dem Switch/Router ausgeführte Software etwa eine Millisekunde benötigt (<

Perfekt! Das hilft sehr! Ich hatte die Verzögerungszeiten zwischen den physikalischen Signalen und der Softwareverarbeitung nicht berücksichtigt. Wenn Sie sagen, "die 100/1000-Mbit / s-Signalisierung verschlechtern", beziehen Sie sich darauf, wie der Impuls alle anderen laufenden Signalisierungen unterbricht? Glaubst du, es wäre möglich, wenn man die Qualität anderer Signale außer Acht lassen und einen etwas nachhaltigeren Impuls senden würde - lang genug, dass die Software Zeit hätte, die Unterschiede zwischen Kabel A und B zu messen und zu verarbeiten?
"Wenn Sie sagen, 'die 100/1000 Mb/s-Signalisierung herabsetzen', beziehen Sie sich damit darauf, wie der Impuls alle anderen laufenden Signalisierungen unterbricht?" Ja; Die Übertragung von Ethernet-Frames (ich nehme an, Ethernet) muss vorübergehend angehalten werden, um die Aufgabe zur Messung der Inband-Kabellänge auszuführen. Außerdem meine ich, dass die Nachrüsthardware die Integrität der elektrischen Signale auf den Drähten während des "normalen Betriebs" nicht beschädigen oder beeinträchtigen darf, wenn keine Kabellängenmessung durchgeführt wird.
Und ja, die u(t)-Impulsbreite muss breit genug sein, um während des gesamten Messzyklus ein logisches Hoch auf das Kabel zu treiben, wenn die längste zulässige Kabellänge gemessen wird (wobei IIRC 100 m für Cat 5/5e/6-Ethernetkabel beträgt).
@JimFischer würde sicherlich jede Messung auch erfordern, dass ein Ende des Kabels getrennt wird, damit der bekannte Widerstand eingeführt und genau gemessen werden kann? Dies würde die Verwendung in einem tatsächlichen Netzwerk ausschließen.
@David "Jede Messung würde auch [...] erfordern?" Für das oben beschriebene System ja. "Dies würde die Verwendung in einem tatsächlichen Netzwerk ausschließen." Nicht unbedingt. Das System könnte denkbarerweise beide Enden des Kabels synchron HERUNTERFAHREN (den normalen Netzwerkverkehr über das Kabel anhalten), die Kabellängenmessung im Band vornehmen und dann beide Enden synchron HERAUFFAHREN und den normalen Netzwerkverkehr wieder aufnehmen. Das DOWN/UP-Steuersignal könnte zum Beispiel bandintern über einen speziellen (kundenspezifischen?) Ethernet-Frame oder über einen Außerband-Kommunikationskanal gesendet werden.
Beachten Sie, dass ich absichtlich alle möglichen Probleme der "realen Welt" ignoriere, die ein solches Nachrüstsystem verursachen könnte. Wenn beispielsweise der Ethernet-Switch UDP-Pakete (Best Effort Delivery) sendet und die Kabelverbindung DOWN geht, um die Kabellängenmessung durchzuführen, werden die eingehenden UDP-Pakete, die für diese Verbindung bestimmt sind, wahrscheinlich verworfen, während die Kabellängenmessung erfolgt durchgeführt werden.

Früher hatte ich eine Intel Pro 1 GB LAN-Karte in meinem Desktop-Computer und sie wurde mit einer grundlegenden TDR-Software geliefert, mit der die Länge jedes der acht Drähte in einem LAN-Kabel (mit einer Mindestlänge von 3 Fuß) getestet werden konnte. Diese Software erforderte, dass das andere Ende des Netzwerkkabels offen ist (mit nichts verbunden) und zeigte nur die Länge jedes Kabels an. Es wurde kein Diagramm angezeigt, wie Sie es bei einem grafischen TDR sehen. Ich hatte diese Intel-Netzwerkkarte bis vor ein paar Jahren und ich habe seitdem keine Netzwerkkarte gefunden, die dazu in der Lage ist.

Mein D'Link DIR-605L-Router verfügt in seiner Web-GUI über eine Funktion namens Virtual Circuit Test (VCT), die genau dies tun soll. Das tut es aber nicht, es sagt nur "TxPairError at meter" für jeden Link, der ausgefallen ist.