IP Router verschluckt Telegramme

[RolfWettstein]

Hallo zusammen

Ich bin gerade dabei das KNXnet Protokoll (also cEMI) auf AMX zu implementieren. Das heisst ich möchte von meinen AMX Controller über Multicast Gruppenadressen ansprechen. Das funktionier soweit auch zufriedenstellend.
Ein Belastungstest ergab jedoch, dass mein ABB IPR/S2.1 Router ab 30 Telegramme pro Sekunde nicht mehr mitkommt, und Telegramme einfach verschluckt werden. Ab 25 Tel/s kommen sie teilweise noch verzögert am Gerät an.
Nun schliesse ich daraus einen zu kleinen Puffer im Router.
Kennt jemand das Problem? Gibt es Router mit grösserem Puffer?

Problem dabei ist, dass wir mit sieben Lienen auf einen Ethernetbackbone kommen. Wenn nun jede Linie im Schnitt 4 Tel/s in den Backbone lässt sind alle IP-Router ausgelastet und es gehen Befehle verloren...
Da ein HS und etwa 60 AMX-Controller im Backbone liegen, geben die natürlich auch noch einige Befehle ab, und müssen schliesslich Rückmeldungen erhalten, was der Grund ist, dass die Filtertabelle nicht ganz so schlank gehalten werden kann.

Gruss
Rolf

[S. De Bruyne]

Did you see any ROUTING_BUSY?

[RolfWettstein]

No. Where sould I see that? in the ETS? But about every 200 Telegram, the ETS stops for about one second recordning. At the same time, the Router LEDs LAN/LINK and Telegram stop blinking for one second, too.
In the picture you find a simplified diagram of my experiment.

Cheers

[S. De Bruyne]

KNXnet/IP Routing specifies a flow control protocol that includes the transmission of a ROUTING_BUSY frame. If any Router gets into distress, it can send out such a frame and all other devices have to pause their transmission.

[enertegus]

Hallo zusammen
Ich bin gerade dabei das KNXnet Protokoll (also cEMI) auf AMX zu implementieren. Das heisst ich möchte von meinen AMX Controller über Multicast Gruppenadressen ansprechen. Das funktionier soweit auch zufriedenstellend.
Ein Belastungstest ergab jedoch, dass mein ABB IPR/S2.1 Router ab 30 Telegramme pro Sekunde nicht mehr mitkommt, und Telegramme einfach verschluckt werden. Ab 25 Tel/s kommen sie teilweise noch verzögert am Gerät an.

Dabei ist der ABB noch weitaus performanter als die von mir getestete , siehe https://knx-user-forum.de/knx-eib-fo...nterfaces.html

[RolfWettstein]

I checked the traffic with Wireshark and get some ROUTING_LOST Messages from the Router, but no ROUTING_BUSY.
It's exactly this moment, in which the ETS and the Router stop for a second
But in The ROUTING_LOST Message, i can't find any information whick package was lost. So it's difficult to retry such a package...
any suggestions?

[S. De Bruyne]

There is no identification of which package has gone lost, only an indication about how many packets have gone lost.
You could check whether it is possible to reduce the traffic on either the IP side or on the connected TP1 Subnetworks.
Obviously, in your AMX implementation, you could react as well to ROUTING_LOST and pause your traffic.

[RolfWettstein]

I'm going even further, and stopping all transmissions, if the amount of telegrams is greater than 20 tel/s.
But the Problem is that we have seven TP1 lines with 60 group adresses each (that are routet to the mainline for feedback purposes) and so the chance of an overflow is relatively high.
Aren't there Router with greater buffers?

[S. De Bruyne]

It may be that the Router does not support the flow control (ROUTING_BUSY).
Further on, a larger buffer does not solve the problem, certainly if the cause is permanent, it only delays the time when the problem occurs.

[swenga]

It may be that the Router does not support the flow control (ROUTING_BUSY).
Further on, a larger buffer does not solve the problem, certainly if the cause is permanent, it only delays the time when the problem occurs.

The current implementation is IMHO not a flow control, since individual packets are not tagged and no one can say that one single packet has been transferred or not.

The bigger buffer could be useful IF the implementation would be changed to the error indication ROUTING_BUSY shall be sent out if the TP-layer lags message rate. Then the IP-side will cease sending new packets for a certain time frame, the buffered packets can be sent to the TP and IP can again feed data.

Right now it is my impression that the Error indications are happening if packets are really dropped. So you have no chance to react beforehand on the situation itself and prevent the dropping.

Even, the highest succesful packet rate IP->TP is much lower than what you would theoretically expect from the TP itself. IMHO there are some performance issues with the currently used KNX-router implementations.

Best regards,

[RolfWettstein]

oh ok, i noticed the post from enertegus not until now. So I'm glad we use ABB-Routers
You're right, it only would delay the problem if the load is permanently. But if you have some central-functions for a whole building, then the load is only high for several seconds...
But somehow we have to manage the physical possibilities...

thanks for all the answers!
Cheers

[S. De Bruyne]

The current implementation is IMHO not a flow control, since individual packets are not tagged and no one can say that one single packet has been transferred or not.

First of all, one can discuss what is understood by flow control.
Secondly, how would one request a push button to resend a message?
Thirdly, how would another receiver be able to differentiate between an original and a renewed transmission?

The bigger buffer could be useful IF the implementation would be changed to the error indication ROUTING_BUSY shall be sent out if the TP-layer lags message rate. Then the IP-side will cease sending new packets for a certain time frame, the buffered packets can be sent to the TP and IP can again feed data.

This is basically how it works, but for once ... size does not matter. That is proven by calculation and implementation experience.

Right now it is my impression that the Error indications are happening if packets are really dropped. So you have no chance to react beforehand on the situation itself and prevent the dropping.

ROUTING_LOST_MESSAGE is indeed an error indication.
ROUTING_BUSY is a warning.

Even, the highest succesful packet rate IP->TP is much lower than what you would theoretically expect from the TP itself. IMHO there are some performance issues with the currently used KNX-router implementations.

A lot depends on how the devices and the applications (senders, receivers) are placed on the network.

[swenga]

First of all, one can discuss what is understood by flow control.

Take a look. Flow control - Wikipedia, the free encyclopedia
It should be prevented that data is lost from buffer overflow, when the transceiver has a higher data rate than the receiver.

Secondly, how would one request a push button to resend a message?

I think there is a standardized mechanism for that in KNX TP. There is also a standardised mechanism in Ethernet (CSMA/CD), however we are not talking data loss from low network level disfunction/collision but from application level!

Thirdly, how would another receiver be able to differentiate between an original and a renewed transmission?

Again: The same case applies to a packet resend in KNX TP.

This is basically how it works, but for once ... size does not matter. That is proven by calculation and implementation experience.

Well, my experience is, it doesnt work as stable as required. A Gira Homeserver connected by FT1.2/TP has a higher sustainable data rate than one connected via KNX-IP/Routing.

No harm intended, but in my opinion the upcoming technology for more and more processing devices will be IP. If Konnex wants to have stable and suitable interoperability on the IP side, the signaling and gateway behaviour in load scenarious and the suitability of the KNX/IP Multicast protocol in those scenarios shall be reviewed.

Best regards,

[S. De Bruyne]

Take a look. Flow control - Wikipedia, the free encyclopedia

There as well, there is no indication about tagging transmitted messages and in case of loss requesting renewed transmission by the original sender.

...disfunction/collision but from application level!..

KNX typically has spontaneous transmissions, not requested transmissions. The receivers do not know when the sender will send something.

Well, my experience is, it doesnt work as stable as required. A Gira Homeserver connected by FT1.2/TP has a higher sustainable data rate than one connected via KNX-IP/Routing.

I guess you assume then the sustainable data rate at the IP side. Is that TCP or UDP?

No harm intended, but in my opinion the upcoming technology for more and more processing devices will be IP. If Konnex wants to have stable and suitable interoperability on the IP side, the signaling and gateway behaviour in load scenarious and the suitability of the KNX/IP Multicast protocol in those scenarios shall be reviewed.

It is our primary concern to give the same reliability to KNX IP as well-known from KNX TP1. The KNX IP flow control protocol is one measure and other can be added or are under consideration.