Was spricht dagegen, immer ein ACK auf den Bus zu senden?

[mumpf]

Hi allerseits,

die Frage ist vielleicht etwas provokant, aber durchaus ernsthaft gemeint. Man kann ja bei einem LK immer einstellen, ob Telegramme immer bestätigt werden sollen oder nur wenn sie weitergeleitet wurden. Das alte WireGate hatte per Default die option --tpuarts-ack-all-group gesetzt. Ich hab das auch die letzten 4-5 Jahre so betrieben (also immer ACK senden) und es jetzt mal versuchsweise zurückgesetzt.

Und jetzt frage ich mich ernsthaft, was mir bzw. dem System ein "nicht immer bestätigen" bringt? Meine Beobachtungen, wenn man ein explizites ACK haben will:

• Für alle nicht-KNX-Geräte (Visu, Gateways zu anderen Protokollen) werden alle Telegramme 4 mal wiederholt. Klar, deren "Schuld", die müssten ein ACK senden. Tun sie aber nicht. Ist erstmal die Beobachtung.
• Buslast steigt (bei mir von 5%-15% auf 15%-35%), wohl durch die vielen Wiederholungen
• Das Programmieren von Geräten dauert länger, da es da vermehrt zu Wiederholungen kommt. Das verstehe ich nicht (eigentlich sollten ja nur Gruppenadressen immer bestätigt werden), aber das habe ich beobachtet (wenn mich hier jemand erleuchten könnte, wäre das auch schön).

Mir ist natürlich klar, wofür ein ACK aus Protokollsicht Sinn macht, und es ist auch klar, dass wenn ein ACK fehlt, die Quelle das Telegramm erneut wiederholen sollte, damit es nicht verloren geht. Aber ist das nicht in der Praxis nur eine vermeintliche Sicherheit?

• Wenn ich mir meine GA-Verknüpfungen ansehe, dann sind sehr viele davon mit mehr als zwei KO verbunden. Der Sender schickt seine Infos also an mehrere Empfänger. Der ACK kommt aber GLEICHZEITIG von allen Empfängern, wenn also nur einer von 3 Empfängern ein ACK macht, wird nicht wiederholt und 2 von 3 haben die Information nicht erhalten. Dass wirklich alle 3 kein Telegramm empfangen, ist wohl sehr selten, aber in diesem Fall würde ja wiederholt werden.
• Da nur einer ein ACK zu senden braucht, lebt man mit der Unsicherheit, dass das Telegramm bei den anderen verloren gegangen ist, sowieso schon (ist inhärent im Protokoll enthalten). Hier geht man offensichtlich davon aus, dass wenn es einer empfangen kann, es schon auch alle anderen empfangen haben werden. Damit würde für alle GA, die mit mehr als 2 KO verbunden sind, der "individuelle" ACK gleichwertig zu einem automatischen ACK sein.
• Jetzt kann man noch argumentieren, dass es immerhin was bringt, wenn eine GA mit nur 2 KO verbunden ist, denn dann wird dem Sender klar geantwortet, wenn das Telegramm empfangen wurde.
• Wenn aber bei mehreren Empfängern davon ausgeht, dass es reicht, dass es einer empfängt, dann kann ich doch auch bei einem Empfänger davon ausgehen. Wenn also mein LK das Telegramm empfangen hat, dann wird es wohl auch der eine Empfänger empfangen haben. Dann reicht es doch, dass nur der LK das Signal betätigt, oder?

Meine Schlußfolgerungen:

• Es ist wichtig, dass es ein ACK gibt. Das verhindert, dass ein Telegramm komplett verloren geht.
• Es muss nur EINER am Bus den ACK senden, wenn er ein vollständiges Telegramm empfangen hat, da dann auch alle anderen das Telegramm empfangen haben. Das ist protokollinhärent.
• Ein "alle Telegramme bestätigen" schadet somit dem Gesamtsystem nicht, es unterstützt es sogar und vermindert die Protokollast.

Die Fragen:

• Kann ich ohne schlechtes Gewissen Freunden, Bekannten und Forummitgliedern empfehlen, jedes Telegramm bestätigen zu lassen, vor allem wenn Visu-Software mit im Spiel ist?
• Oder noch allgemeiner: Ist es systemkonform, immer ein ACK zu senden, wenn man ein Telegramm empfangen hat, auch wenn das Telegramm nicht für einen bestimmt ist (und das Telegramm ansonsten vollständig ist)?

Hab ich irgendwas übersehen?

Gruß, Waldemar

[S. De Bruyne]

This is called "non-selective Layer-2 acknowledge" in the KNX Specifications, and it has been allowed, originally for "complex devices" - in the good ol' days with external processor - that did not have the speed to react in time with the proper Layer-2 acknowledgement.

Mind the difference between A. "Acknowledge" - the process of evaluating a received TP1 Frame and sending an ACH, NACK or BUSY - and B. "ACK", which is only the positive Acknowledge. This is, systematically sending ACK, also on corrupt Frames, should of course not be done.

[Klaus Gütter]

wenn also nur einer von 3 Empfängern ein ACK macht, wird nicht wiederholt und 2 von 3 haben die Information nicht erhalten

Wenn aber einer der 2, die nicht ACKen, das Telegramm zwar erkannt hat, aber nicht vollständig und korrekt, wird dieser ein NAK (oder BUSY wenn der Teilnehmer einfach zu beschäftigt war, um das Telegramm auszuwerten) senden. Und auf dem Bus gewinnen NAK/BUSY gegen das ACK.

[mumpf]

Hi Klaus,

Und auf dem Bus gewinnen NAK/BUSY gegen das ACK.

danke, das weiß ich. Aber gerade weil die gewinnen, spricht das nicht dagegen, den LK auf "immer ACK senden" zu stellen, oder?

This is, systematically sending ACK, also on corrupt Frames, should of course not be done.

Thanks for your Answer, too. I agree completely, an ACK should be only sent on correct Frames. The question is, what does a line coupler do? A quick search gave me just some information for the NCN5130:

NCN5130 starts accepting all frames whose destination address corresponds to the stored physical address or whose destination address is the group address by sending IACK on the bus. In case of an error detected during such frame reception, NCN5130 sends NACK instead of IACK.

This tells me, that there are at least hardware implementations, which handle this correctly. Probably I'll try this with this chip, just to see how it works.

"Acknowledge" - the process of evaluating a received TP1 Frame and sending an ACH, NACK or BUSY

I know about ACK, NACK and BUSY, but what is an ACH?

And - just for curiosity - is there any explanation, why turning off the "always ACK" function may result in longer programming times? I always thought, it is related to group address telegrams, not to individually addressed telegrams. I really see more repeated telegrams during programming in this case. Or is the only one explanation the higher bus load?

Thanks for your input,
Waldemar