Auswirkungen der Priorität bei Kollisionen

[sqeez3r]

Hallo zusammen,

es ist klar, dass die Priorität einer GA regelt, welches Telegramm im Falle einer Kollision zuerst erneut verschickt wird.
Aber hat die Auswahl der Priorität auch einen Einfluss darauf, ob ein Telegraumm erneut verschickt wird?

Ich konnte hierzu leider nicht fündig werden.
Mir kommt es so vor, als ob Telegramme mit niedriger Priorität bei mir in bestimmten Situationen mit einem hohen Traffic verloren gehen.

Danke und viele Grüße
Simon

[gbglace]

Es werden nur Telegramme auf dem Bus verschickt, die GA ist Teil des Inhalt des Telegramms.

Was soll das für eine Anlage sein wo Du wirklich eine Priorisierung von GA benötigst, weil die allgemeine Buslast zu hoch ist?
In solchen Fällen ist wohl eher was anderes zumindest ungünstig implementiert.

[Klaus Gütter]

Nein, hat keine Auswirkungen auf Wiederholungen.
Was aber sein kann: wenn das Gerät sein Telegramm mit niedriger Priorität nicht loswird, bevor es das nächste Telegramm generiert, könnte evtl. eine interne Queue überlaufen.
Und Göran hat natürlich recht: dass so eine hohe Buslast überhaupt entsteht, ist ein Projektierungsfehler.

[rosebud]

In den CSMA-CD-Systemen (KNX, LON), also ohne Master-Slave-Strukturen wie bei MODBUS, ist der Datenverkehr geregelt. Meines Wissens ist im KNX ein Bit mit dem Wert "0" gegenüber einem mit Wert "1" priorisiert. Sendet ein Teilnehmer eine "1", ein anderer zugleich eine "0", so merkt der Teilnehmer mit "1", daß ihm jemand dazwischenfunkt und bricht sein Telegramm kommentarlos ab. 50 ms (?) nach dem Ende eines Telegramms auf der Leitung schaut er nach, ob die Luft rein ist und startet von neuem in der Hoffnung, daß alle anderen sendewilligen Teilnehmer ebenfalls den Finger in die Luft und sich zurückhalten.
Insofern hat die Priorität nur eine Bedeutung für den sendenden oder/und den hörenden Teilnehmer, nicht jedoch für den Datenverkehr auf der Leitung.

[S. De Bruyne]

Correct. Just, in KNX, we like to say that we have "CSMA/CA" - Collision Avoidance, or, better, "non-destructive collision": there may thus be collisions (simultaneous transmissions on the bus), but these do not lead to nonsense signals, opposite to e.g. Ethernet.

[rosebud]

CD means "collision detection".

[sqeez3r]

Vielen Dank für eure Antworten!

Wie ich geschrieben hatte, ist nicht die allgemeine Bus-Last zu hoch. Stattdessen tritt das Problem nur in einer speziellen Situation auf, wenn ich auf einmal fast im ganzes Haus das Licht ausschalte und die Jalousien herunterfahre (Heimkino-Szene).

Warum bei Ethernet allerdings "nonsense signals" entstehen sollen, leuchtet mir nicht ein, denn jede Verbindung ist Punkt-zu-Punkt und Full-Duplex. Auf dieser Schicht können doch gar keine Kollisionen entstehen. Naja, das ist sowieso ein anderes Thema

[gbglace]

Heimkino-Szene

Dann solltest mal in den Aktoren auch eine Szene anlegen und diese auch senden, weil dann ist das genau ein Telegramm mit der Szenen-ID und nicht zig Telegramme mit verschiedensten AN/AUS, Ziel-Dimmwerten, Rollo-Positionen.

[Gast1961]

Warum bei Ethernet allerdings "nonsense signals" entstehen sollen, leuchtet mir nicht ein, denn jede Verbindung ist Punkt-zu-Punkt und Full-Duplex. Auf dieser Schicht können doch gar keine Kollisionen entstehen.

Du bist zu jung

https://de.wikipedia.org/wiki/10BASE2

[sqeez3r]

Dann solltest mal in den Aktoren auch eine Szene anlegen und diese auch senden, weil dann ist das genau ein Telegramm mit der Szenen-ID und nicht zig Telegramme mit verschiedensten AN/AUS, Ziel-Dimmwerten, Rollo-Positionen.

Selbst dann habe ich aber immer noch die ganzen Rückmeldungen von den Kanälen.
Aber der Hauptgrund ist, dass ich die Szenen im X1 so schön zentral verwalten kann

Du bist zu jung

https://de.wikipedia.org/wiki/10BASE2

Ok, du hast Recht Aber das setzt ja heutzutage hoffentlich keiner mehr ein 🤣

[tubercel]

Du bist zu jung

https://de.wikipedia.org/wiki/10BASE2

Ganz so alt muß man nicht sein. Mit 100BASE-T gab das auch noch.
Das hängt auch mehr dran ob man einen Switch nimmt oder nen HUB.