Real-Time-Ethernet vermessen

[Stefan N. (mainframesk)]

Hallo,

ich habe vor ein Gigabit Real-Time-Ethernet auf Latenzzeiten zu 
vermessen. Was genau würdet ihr vorschlagen?

Es werden Pakete auf die Leitungen gelegt mit einem definierten 
zeitlichen Abstand. Diese Pakete sollen so wenig wie möglich jittern.

Eine Möglichkeit wäre direkt mit Oszi auf den Leitungen nach dem PhyCore 
zu messen. Allerdings wären Störungen möglich.

Möglichkeit 2 wäre die Messung mit einem Ethernet-Analyzer. Hab aber 
keine Ahnung was das passende Gerät wäre. Vielleicht hat einer von euch 
eine Lösung oder schon mal das Problem gehabt.

Vielen Dank und Viele Grüße,

Stefan

[doofi (Gast)]

Was hat
> Latenzzeiten
mit
> jittern
zu tun.

> Allerdings wären Störungen möglich.
Mit Sicherheit.

Wenns ums messen und nicht ums abschätzen geht, braucht es eine oder 
mehrere Tapprobs.
Guck mal bei Network Instruments.

Einfacher wäre es wohl die Treiber zu instrumentieren.

[Stefan N. (mainframesk)]

Hallo,

vielen Dank für die schnelle Antwort.

Ja, Latenz ist hier falsch. Es geht mir nur um den Jitter zwischen den 
Einzelnen Paketen. Ich werde mal deinen Hinweisen nachgehen.

VG
Stefan

[Axel (Gast)]

>Eine Möglichkeit wäre direkt mit Oszi auf den Leitungen nach dem PhyCore
>zu messen.

Mir ist nicht klar, ob Du den Sender, die Leitung, den Empfängerphy oder 
alle zusammen ausmessen willst.

Eine Idee wäre sicherlich, den GMII am Empfängerphy mit dem Oszilloskop 
auszumessen. Aber dann weisst Du noch nicht, wo der Jitter herkommt.

Gruss
Axel

[Peter (Gast)]

Auch bei RealTime gibt es doch nur eine foderrung nach das Maximalen 
laufzeit. Die Packet können aber auch schneller sein. Damit ist ein 
Jitter auch möglich.

Wenn ein Packet am Switch warten muss bis ein vorheriges übertragen ist, 
dann kommt es immer zu Latenzschwankungen.

[Axel (Gast)]

>Auch bei RealTime gibt es doch nur eine foderrung nach das Maximalen
>laufzeit. Die Packet können aber auch schneller sein. Damit ist ein
>Jitter auch möglich.
Nicht nur. Wenn man mehrere Knoten synchronisieren will, solltre der 
Jitter möglichst gering sein. Viele Protokolle verwenden auch 
Zeitscheibenverfahren für die Real Time Daten, auch dafür sollte die 
Latenz konstant sein.


>Wenn ein Packet am Switch warten muss bis ein vorheriges übertragen ist,
>dann kommt es immer zu Latenzschwankungen.
Sinn der ganzen Protokolle ist es ja, genau das zu vermeiden. Wenn ein 
Telegramm eine undefinierte Zeit am Switch warten muss, ist Real Time 
nicht mehr möglich.

Gruss
Axel

[Peter (Gast)]

> Sinn der ganzen Protokolle ist es ja, genau das zu vermeiden. Wenn ein
> Telegramm eine undefinierte Zeit am Switch warten muss, ist Real Time
> nicht mehr möglich.
jain, bei jedem RealTime definition die ich kenne, geht es um die die 
maximale Zeit. Wenn sichergestellt ist das das Packet innerhalb vom 10ms 
ankommt, dann kann es nach 1ms oder nach 9ms ankommen.

[Axel (Gast)]

"sichergestellt" ist aber durchaus ein Problem.

Ansonsten gibt es natürlich Anwendungen, bei denen man es schon genauer 
braucht.

Gruss
Axel

[Stefan N. (mainframesk)]

Messen will ich nur an einem Punkt. Ideal wäre am Empfänger Phy. An der 
GMII bzw am EMAC (Xilinx) Sender kann ich mir die Signale anschauen und 
die halten sehr genau das Timing ein was ich vorgebe. Die Pakete haben 
einen konstanten Abstand von 250us.

Evtl. reicht es auch zu die Datenblätter zu wälzten und sich auch die 
Timing-Angaben zu verlassen.

Mir ist auch in den Sinn gekommen ein weiteres FPGA Dev Board mit 
Ethernet Phy zu nehmen und das als Debugger Bord zu verwenden. Ich 
könnte dann die Zeit zwischen den Paketen ideal vermessen über die 
Header.

Gruß

Stefan