ETS Gruppenmonitor Timestamps

[Klaus Gütter]

Das ist plausibel

[gbglace]

OK dann kann das ja sein, das der EIBPC sich die Route Tunnel1 zu Tunnel2 intern direkt in sich selbst verteilt. Aber eben der Readrequest diese Abkürzung mit Ziel ETS nicht nehmen kann, weil der ja erstmal ganz durch die Schnittstelle muss um dann als allgemeines Telegramm auf dem Bus vom quasi sendenden Tunnel gehört zu werden. Also ReadRq auf der Expressroute von Tunnel1 zu Tunnel2 und ebenso die Antwort von Tunnel2 zu Tunnel1, gleichzeitig beides aber auch auf das TP-Level geht. Aber nur von dort aus Tunnel1 sich quasi selbst hören kann und der ETS ReadRq damit langsamer zurück bei der ETS ist als die Antwort vom SRV.

[TabSel]

ich nutze den eibpc2, der hat zwei Tunnel, einen für die ETS (ETS 1.0.255) und einen für dessen „Programm“ (SRV 1.0.254)

[Klaus Gütter]

Grundsätzlich ist der Zeitstempel bei den Requests die Zeit, zu der die Bestätigung bei der ETS eintrifft. Kann schon passieren, dass sich die Antwort vor die Bestätigung drängelt. Was für eine Schnittstelle ist das?

[TabSel]

das ist das ungefilterte log. Ich bin selbst erstaunt. Ist reproduzierbar.

ich hab die Zeitreise erfunden…

[gbglace]

Ist das alles in dem Log oder gefiltert zu der GA?

[TabSel]

ETS Gruppenmonitor

[Beleuchtfix]

Ist der Auszug aus der ETS oder irgendwie im EIBPC gemacht?

[TabSel]

Also da kann was nicht stimmen mit den Timestamps: Ich hab ein eibpc2-programm laufen, dass auf GroupValue_Read-requests mit einer GroupValue_Response antwortet.
Im Gruppenmonitor der ETS setze ich das Read-request ab, und kann ja erst danach eine Reaktion auf dieses Telegramm vom eibpc2 rechnen, der eibpc2 kann ja nicht in die Zukunft gucken ob er ein Read-request erhalten wird und schon vorab darauf reagieren. Tut er aber: siehe Telegramme 17/18, da kommt laut Timestamps die Response noch VOR dem Read-request...

Kann mir das einer erklären?

image.png