Hallo zusammen,
Ich habe mir den Intel Compliance Guide etwas genauer angesehen.
https://community.intel.com/cipcp26785/ ... Manual.pdf
Jitter ist jede Fluktuation oder Verschiebung der Signalimpulse in einem hochfrequenten Digitalsignal.
Jitter bezeichnet in der Netzwerktechnik auch die Streuung der Laufzeit von Datenpaketen. Besonders störend ist dieser Effekt bei Multimediaanwendungen im Internet (zB Internetradio und Internettelefonie), da Pakete zu spät oder zu früh eintreffen können, um rechtzeitig ausgegeben werden zu können. Dies bezeichnet man als Ethernet oder Netzwerk Jitter:
https://www.ir.com/guides/what-is-network-jitter
jeder kennt die Probleme von Netzwerk-Jitter bei z.B. VoIP.
Das Intel-Handbuch spricht von 100 TX Sendejitter. Jitter in 100Base-TX-Signalen ist definiert als der Zeitintervallfehler zwischen einem idealen Takt bei der Symbolrate von 125 MHz und dem gemessenen Timing der ansteigenden und abfallenden Flanken der positiven und negativen Impulse. Der Referenztakt wird aus dem zu testenden Datensignal wiedergewonnen, indem ein numerischer PLL verwendet wird, der aus den Schwellenwertüberschreitungen des zu testenden Signals berechnet wird. Der Jitter-Test wird an einem verschlüsselten IDLE-Stream durchgeführt. Der IDLE-Stream wird von einer 100Base-TX-Schnittstelle generiert, wenn sie ohne Verbindungspartner terminiert wird, wie Lecroy in seinem QualiPHY-Handbuch für denselben Test schreibt.
Bei allen Verbindungen sind Grenzwerte für die Standards definiert, damit die Geräte einwandfrei funktionieren können - und im Zuge von Jitter sich nicht addieren.
Bei diesem Konformitätstest gibt es durch den in IEEE802.3 definierten Grenzwerten für ein 100 Base T(X) Netzwerk mit Cat 5 Kabeln von Jitter <1,4 ns nur ein „bestanden“ oder „nicht bestanden“. Bestehen, wenn der gemessene Jitterwert für +ve und -ve unter 1,4 ns liegt, und fehlschlagen, wenn er höher ist. Die Test-Suites, die viele Anbieter für geeignete Oszies zur Verfügung stellen (u.a. auch TEK) sollen einen schnellen und einfachen Überblick bieten.
https://www.tek.com/de/documents/applic ... 100base-tx
dort heisst es:
"Engineers designing or validating the Ethernet physical layer on their products need to perform a wide range of tests, quickly, reliably and efficiently. This application note describes various tests that ensure validation, the challenges faced while testing multi-level signals and how oscilloscope-resident test software enables unprecedented efficiency improvements with its wide range of tests, including return loss, faster validation cycles and higher reliability."
Dort steht u.a. unter dem einen Testpunkt von vielen (TX-Jitter):
"Being a three-level signal, it is extremely important to quantify the peak-to-peak jitter at both, the upper and lower, crossovers and determine the worst-case value of the two. Determining peak-to-peak jitter based on only one crossover can lead to inconclusive and, at times, incorrect results as shown in Figure 6."
das ganze Thema ist schon sehr sehr schwer zu verstehen, wenn man sich diese Unterlagen zum Thema mal ansieht:
https://www.researchgate.net/publicatio ... rial_Links
wenn man nicght gerade gelernter Professor ist... finde ich das schon als starker Tobak
https://manualzz.com/doc/21902485/jitte ... tems-telec...
"Jitter transfer is a measure of how much jitter is transferred from the input to the output of the network equipment. JTF is important for
cascaded clock recovery circuits in long-distance transmission systems with regenerators and line terminals. As a signal traverses a network,
the jitter generated by the equipment becomes the input jitter to the next part of the network. If this jitter is amplified, it can exceed the
jitter tolerance of the subsequent equipment.
Wobei wir das hier garnicht haben. Wir befinden und mit unseren Consumer-Switches am Ende der Würstchenkette.
https://www.google.com/url?sa=t&rct=j&q ... -YPw-rPLOX
wo er auch auf eine Besonderheit eingeht:
"Can a lossy channel “reduce” the amount of jitter?
Although it sounds counter-intuitive, this is possible, as well, but in very special cases of data-dependent jitter. For example, assume that a periodic pattern ‘001001001…’ is applied to the lossy channel, and the rising edge always comes early while the falling edge is always late.
For this type of input jitter, the length of the positive symbols becomes larger than 1 UI. However, as previously seen, the lossy channel reduces all spectral components with respect to DC. For the pattern with negative imparity (where the number of logical zeros dominates) the
DC component is negative. At the channel’s output, the waveform sinks deeper, thus reducing the time it remains in positive territory. With the right amount of loss, jitter could be reduced or even eliminated.
Imho sagt es nichts über die Notwendigkeit oder den Unsinn einer externen Uhr aus, es ist nicht geeignet, ein Benchmark zum Vergleichen von Schaltern oder zum Modifizieren von Schaltern zu sein, wenn ein einfaches -pass- (<1,4ns Jitter) ausreicht, um den Test zu bestehen . Dieses Augenmuster nur für den Tx100-Konformitätstest sollte nicht plötzlich zum neuen Goldstandard werden. Man kann da sicher viel rein interpretieren oder lesen, aber es fällt mir immer noch sehr schwer, dieses Thema ohne 7 Studiengänge komplett zu durchdringen - noch den direkten und unbedingt notwendigen Test als Basis für alle Erklärungen rund um das Thema Ethernet-Klang heranzuziehen.
https://www.semanticscholar.org/paper/T ... b157a2b036
Ich habe dies absichtlich im US-Forum zuerst gepostet, um den JS von Uptone ein wenig aus der Reserve zu locken, denn Alex war sofort bei Phase-Noise etc...
Bei Ethernet IEEE 802.3 ist der Transit/Transfer das nicht mehr anwendbar, wie diese Präsentation zeigt:
https://docplayer.net/30095003-Comparin ... works.html
Daher frange ich mich, warum wir uns damit so ausführlich beschäftigen, oder ob uns das näher an ein Ergebis bringt, was mit den Beobachtungen und Beschreibungen korroliert.
Allerdings sollte man sich beim Umbau eines Switches seit Ewigkeiten bekannte Lösungen anschauen, wie man mit HF hinsichtlich der verwendeten Zuleitungen, Abschirmung und Abstrahlung am besten umgeht.
Das Intel-Papier spricht zudem Im Anhang auch über Transfer-Jitter-Lösungen.
In Kapitel 14 werden zunächst die Messung und das Ziel definiert: „Peak-to-Peak-Jitter soll unter Verwendung des verschlüsselten HALT-Leitungszustands gemessen werden. Der gesamte Sende-Jitter, einschließlich Beiträgen von Arbeitszyklusverzerrungen und Basislinienwanderungen, darf 1,4 ns Spitze [zu] Spitze nicht überschreiten.“
in G10 dann die wahrscheinlichsten Ursachen:
( mit Google Translate... )
„Übertragungs-Jitter verursacht Probleme für die empfangende Einheit, da es schwieriger wird, den Wert von Bits zu unterscheiden, wenn der Jitter zunimmt. Systeme mit übermäßigem Jitter führen daher dazu, dass die empfangende Einheit hohe Bitfehlerraten aufweist. Es gibt mehrere Ursachen für Jitter in Board-Design und -Layout berücksichtigt.
Verrauschte Platinen und schlechte Gleichtaktunterdrückung erhöhen den Jitter. Das Rauschen kann noch verschlimmert werden, indem Hochgeschwindigkeitsspuren in der Nähe des Netzwerkcontrollers oder parallel zu den differentiellen Spuren ausgeführt werden. Um das Rauschen zu reduzieren, versuchen Sie so weit wie möglich, die Bodenfüllung unter dem Chip zu maximieren. Stellen Sie außerdem sicher, dass eine ausreichende Entkopplung zwischen VCC und Masse um den Netzwerkchip und um andere Chips herum besteht, die VCC Rauschen hinzufügen können. Eine obere Metallschicht mit mehreren großen Durchkontaktierungen bis hinunter zur Masseebene kann das Problem reduzieren.“
"Eine schlechte Gleichtaktunterdrückung kann durch asymmetrische Leiterbahnen verursacht werden. Sie sollten die gleiche Länge haben und von Ende zu Ende parallel zueinander verlaufen. Jitter kann auch durch einen Quarz oder Oszillator verursacht werden, der nicht die erforderliche Ausgangsfrequenz erzeugt. " (kein Wort über PN - oder Jitter - Nur Ausgangsfrequenz)
Daher kann das CM-Rauschen, das durch das längere interne nicht koaxiale Kabel der getesteten modifizierten Switches eingefangen wird, der Grund für den höheren Transfer-Jitter als bei den Original-Switches sein. Aber egal, jeder Switch, den Eric getestet hat - original oder modifiziert, oder Etherregen - wird im Transfer-Jitter-Compliance-Test ein einfaches <bestanden> erhalten ... das war's. Übrigens. Wenn ich die Ethernet-Kabel testen möchte... ist ein S-Parameter Test auf einem Networkanaylizer meine Wahl. Der Transfer-Jitter-Test hat seinen Worst-Case mit fehlangepassten Catv 5 Kabeln von 100 bis 120 Ohm
Tek hat für diese Messungen ein eigenes Board - und man kann auch das Oszi selber mit dem eigenen Ethernet-Port als Link-Partner nehmen.
https://www.calplus.de/tektronix-tf-gbe-atp.html
da möchte ich lieber nicht den Preis wissen. Wenn schon die Softwarem mal 6k USD gekostet hat.
Ich werde das Gefühl nicht los, wir verrennen uns mit dem Thema in Ecken...
Happy listening
Sunny