Frequency column in eCAL Monitor is showing weird values for slow publishers

[Blutkoete]

Problem Description

I created a simple Python publisher that publishes machine state from my machines at home like memory and CPU consumption. I configured the publisher to send out the data roughly once per second, which probably corresponds to a frequency of less than one Hz in reality.

Now the Frequency column in the eCAL Monitor toggles slowly between 0 and 0.2, which are both not really helpful values.

While I understand the 0 for cases in which no message is published during the calculation window for the frequency, the 0.2 makes no sense at all to me.

This is not a big issue, but maybe it's somehow possible to have the calculation window to adjust itself automatically so that the values for slow publishers are more accurate?

How to reproduce

1. Create a very slow (Python) publisher
2. Check it's frequency in eCAL Monitor

How did you get eCAL?

Custom Build / Built from source

Environment

• eCAL Version: 5.12.4
• OS: Arch Linux
• Python Version: 3.11

eCAL System Information

------------------------- SYSTEM ---------------------------------
Version                  : v5.12.4 (2024-02-08 09:01:15 +0100)
Platform                 : linux

------------------------- CONFIGURATION --------------------------
Default INI              : /etc/ecal/ecal.ini

------------------------- NETWORK --------------------------------
Host name                : jtb-desktop
Host group name          : jtb-desktop
Network mode             : local
Network ttl              : 2
Network sndbuf           : 5 MByte
Network rcvbuf           : 5 MByte
Multicast cfg version    : v1
Multicast group          : 239.0.0.1
Multicast mask           : 0.0.0.15
Multicast ports          : 14000 - 14010
Multicast join all IFs   : off
Bandwidth limit (udp)    : not limited

------------------------- TIME -----------------------------------
Synchronization realtime : "ecaltime-localtime"
Synchronization replay   : 
State                    :  synchronized 
Master / Slave           :  Master 
Status (Code)            : "everything is fine." (0)

------------------------- PUBLISHER LAYER DEFAULTS ---------------
Layer Mode INPROC        : off
Layer Mode SHM           : auto
Layer Mode TCP           : off
Layer Mode UDP MC        : auto

------------------------- SUBSCRIPTION LAYER DEFAULTS ------------
Layer Mode INPROC        : on
Layer Mode SHM           : on
Layer Mode TCP           : on
Layer Mode UDP MC        : on
Npcap UDP Reciever       : off

------------------------- EXPERIMENTAL ---------------------------
SHM Monitoring           : off
SHM Monitoring (Domain)  : ecal_mon
SHM Monitoring (Queue)   : 1024
Network Monitoring       : on
Drop out-of-order msgs   : off

[FlorianReimold]

Yeah, basically the frequency calculation does not really show proper information for frequencies below 1Hz. At some point, eCAL just decides that this topic probably is not published anymore (hence the 0Hz).

I have create a slow publisher with a 5 second loop and can reproduce the toggel between 0Hz and 0.2 Hz with that. However, if I publish the data with a 1-second loop I get a relatively stable 1-ish Hz Frequency in eCAL Mon. Maybe your loop time doesn't work as you expect it to work? You should be able to see the "Data Clock" increasing with each message, so if your loop works correctly, you should also see the data clock being increased each second.

[KerstinKeller]

We have seen that the current frequency calculations is problematic in multiple ways. What you described for frequencies < 1Hz, but also it is really unstable for frequencies ~2-3 Hz as well: For an exact frequency of 2.00Hz, the calculated frequencies are between 1.9 and 2.9 Hz, and diverging heavily. We will implement a more stable frequency calculation.

[Blutkoete]

Wow, thank you for your fast response & new calculator! Really impressive.