Wiser performance metrics

[morkovka]

Hi,

I would like to be able to add the performance metrics of wiser (CPU/memory/KNS-bus utilization) to the trends so I could see the charts related to them - is there a way to achieve it?

[Daniel]

https://forum.logicmachine.net/showthrea...7#pid13947

[morkovka]

https://forum.logicmachine.net/showthrea...7#pid13947

Great, works like a charm!

Only thing I'm missing is the KNX TP load - any ideas how to get it?

I would probably be able to find it myself if I had SSH access to wiser... is there a way to SSH into it or it's only for internal use by the R&D?

[admin]

See this: https://forum.logicmachine.net/showthread.php?tid=2552

[morkovka]

See this: https://forum.logicmachine.net/showthread.php?tid=2552

Thank you!

I notice that in the referenced script, with your improvements, they take into consideration only the TP RX+TX+repeats - while in the Wiser UI they include also the IP TX/RX when calculating the 'TP Load' percentage (last minute/hour/total).

Do you think it's correct to include IP RX/TX in the calculation of the KNX bus load or not?

[morkovka]

I guess it's not correct to include it because the load is not in the actual KNX bus / TP

Also I wonder if using telegram counting is the most correct way to establish the load - please correct me if I'm wrong, but it seems like in the case of TP the limitation is the bandwidth rather than the 'telegram rate', and due to different telegram sizes the maximum rate of telegrams/sec could alternate between 20-40 or so. In the Wiser (and I guess LM) UI the rate is used to establish the load, with a assumed maximum of 30 telegrams/sec - which could be wrong.

Seems like it be more accurate to look a the RX/TX/Repeat bytes instead of telegrams, knowing the maximum is 9.6 kbits/s - this way we could establish and display a 100% accurate KNX bus load with no assumptions.

Would be nice for the bytes stats to be exposed in knxlib.getstats()

[admin]

The current stats are good enough for most cases as usually telegrams contain not more than 2 bytes of data. What is the point of 100% bus load statistics?

[morkovka]

Well, currently the UI in my environment seems to display incorrect statistics, for example, I see around 20% of TP load, while in the scripts mentioned (I'll paste below) it's around 9% - that's quite a difference:

UI:


Using the script:



I was trying to understand what is the cause, and what I found is that W4K (incorrectly) includes IP TX/RX as part of the TP bus load, but those packets are not going over TP.

Isn't that a bug?

The script I use is a version of what you linked:

Code:

-- KNX bus load
maxS = 30  -- highest assumed telegram rate pr second - same as in wiser knx stats view
maxM = maxS*60 -- needs to be equal to this script's sleep interval
data = knxlib.getstats()

if data then
  sent = data.tptx -- + data.iptx -- if you want to see also KNX IP stats
  received = data.tprx -- + data.iprx -- if you want to see also KNX IP stats
  repeats = data.repeats
  traffic = sent + received + repeats
 
  if knx_prev then
    knx_load = ((traffic - knx_prev)*100)/ maxM
    grp.update('Wiser KNX bus load', knx_load)
  end
 
  knx_prev = traffic
end

About the bus load using throughput instead of rate, well I would prefer to have 100% correct information than 99% correct, when both options are equal in complexity to deliver, but it's your choice as a vendor of course to decide on the priorities of solving different problems.  I think this "good enough" logic is a bug, although of a low severity

[admin]

This example is not fully correct. First, repeats are already included in the received telegrams counter. Second, 30 telegrams per second is too high.
Anyway it's not trivial to calculate the real bus load. Apart from data telegrams there are also short ACK/NACK/BUSY frames and a specific free time between the telegrams. It's not a simple serial interface where the baudrate defines the throughput.

[morkovka]

Well in the statistics I screenshotted above there was a total of 1 TP repeat so it doesn't account for 11% deviation between the script load and the UI load calculation.

About the 30 telegrams per second - this is the assumption that the UI makes (and also my script) - in the last minute it shows:

TP RX (92) + TX (58) + IP RX (0) + IP TX (150) / divided by 60 seconds / divided by the "TP Load" of 16.67% == 30 seconds assumption

(92+58+150)/60/16.67 = 0.299...

This means the current user interface makes the same assumption: that there are 30 telegrams per second. And it also proves that it uses the IP statistics (RX/TX) in the calculation of the TP load - which is a mistake.

[Erwin van der Zwart]

Well in my opinion you should not have this at all, if you continuously need to monitor the busload like this it means you are always on the limit of the bandwidth…

In my honest opinion the busload only needs to be checked when issues might surface after initial deployment and a short monitoring should tell you where it goes wrong, if you need to monitor full time your (TP) architecture needs to be changed if you ask me..

Anyway that is my 50ct..

[morkovka]

The current stats are good enough for most cases as usually telegrams contain not more than 2 bytes of data. What is the point of 100% bus load statistics?

Well in my opinion you should not have this at all, if you continuously need to monitor the busload like this it means you are always on the limit of the bandwidth…

In my honest opinion the busload only needs to be checked when issues might surface after initial deployment and a short monitoring should tell you where it goes wrong, if you need to monitor full time your (TP) architecture needs to be changed if you ask me..

Anyway that is my 50ct..

I compare this to the IP networking - just as we have interface statistics, which we don't normally use (other than bandwidth bragging rights) - they are still there in any responsible network monitoring operation, for the off-chance that when a problem does arise, and it can be spotted using these statistics - it will be possible to look into the data.

I reckon similar logic applies to TP load.

Having said that - even if this is useful only for the deployment phase - it should still be displaying the correct bus load - for that relevant phase, don't you think?

Now it's displaying (for me) 11% more than it should because it's miscounting KNX IP packets for TP - maybe in other environments it'll be 30% more - I would say it's misleading at best.