bmalinowsky
commented
1 month ago With trace log, you should see the tunneling messages of the KNXnet/IP connection layer (i.e. one layer lower), and compare if the delay for the indication also happens there.
One reason I can think of why this is happening, is that your send logic is called from the notification thread? The notification you receive for a confirmation and indication runs in a dedicated thread. If that thread is not able to return from client code, this will delay the next notification.
coteclic
Good morning, I'm using an application developed with calimero 2.5 and I'm currently experiencing a problem that I don't have with my old application developed with calimero 1.4.6.
The KNX/IP routers are Siemens N146 for which here is the discover report:
["IP Router N146", KNX address 3.9.0, KNX medium TP1, Installation 0 - Project 0 (ID 0), KNX IP multicast address 224.0.23.12, MAC address 00:0e:8c:01:25:a5, S/N 0001:1003fba1d, Core (v1), Device Management (v2), Tunneling (v1), Routing (v1), Remote Configuration Diagnosis (v1), Object Server (v1)]The problem occurs for IP routers that are set to transmit telegrams. Example there are 5 IP routers (R1, R2, R3, R4 and R5). The application simply connects to router R1 and reads and writes to group addresses located on lines of routers 1 to 5.
With the old version 1.4.6, the application sends the read request and when it receives the confirmation, it also receives at the same time the telegram that was retransmitted by the router. On the other hand with version 2.5, when the application receives the confirmation, the telegram that is retransmitted by the router is not received immediately.
Both apps work the same way: once confirmation is received, there is a 50 millisecond pause before a new reading is requested. With version 2.5, the more readings we do in a sequence, the longer it takes to receive the telegram retransmitted by the router and therefore the reading response lengthens, this can go up to 5 seconds or more. It's like this the IP router confirmed but the telegram is not sent immediately so I think it ends up saturating. With version 1.4.6 when a new read request is sent, we are certain that the previous one was sent.
I specify that there are a lot of telegrams sent because there is a lot of material and users. We have several tunneling connections on several IP routers at the same time in the application. Only those that are set in the manner explained above pose a problem with version 2.5. The others for which the telegram setting is "filter" and for which we only request the reading of group addresses found on the line of the router itself, this works.
This the method used with 1.4.6 :
This the method used with 2.5 :
Do you know where the problem comes from ?
Thank you !