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
Gast
#1386014
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.
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
Gast
#1386047
>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
Gast
#1386060
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.
Gast
#1386124
>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
Gast
#1386136
> 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.
Gast
#1386148
"sichergestellt" ist aber durchaus ein Problem. Ansonsten gibt es natürlich Anwendungen, bei denen man es schon genauer braucht. Gruss Axel
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
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.