We need full access to the chrony config. We have very strict timing requirements and would like to increase the polling interval. Also large steps in time (forward or backward) are a no-go for us.
These are ‘standard’ chrony options, but we don’t have access to those, we can only add ntp servers.
Would it be possible to have full access?
(A instance per container doesn’t suit us as the containers need to be in sync and this would mean an instance per container. Also the balena logs will have timestamps which are off).
Hi, unfortunately balenaOS does not allow that level of customization. There are several options I can think about for you to consider:
From your description it seems what you really need is a device with an RTC that will keep the time between the standard NTP polls. The balenaFin for example is based on a CM3 module and contains an RTC.
Another option would be to run a chrony instance in a privileged container with its own settings that would set the system time. Not sure I follow your statement above that you would need an instance per container and that the logs would have the wrong timestamp - the system time is unique. There is really no difference between running chrony on the hostOS or a container with enough privileges.
The last option that I would not recommend is to build your own balenaOS version and customize as you wish. A custom OS cannot be updated via the dashboard, and will not be supported by Balena, but it’s a last resort choice.
unfortunately balenaOS does not allow that level of customization.
I can think of several files in the /etc directory that would be nice to modify on the host-os. Perhaps something to consider for the roadmap
what you really need is a device with an RTC
We use a ruggedized industrial PC. Switching board is unfortunately not an option. Ofcourse an RTC can be added externally, but that would probably need some configuration on the host → back to square 1.
Run a chrony instance in a privileged container with its own settings that would set the system time.
This sounds really promising. Do you have any pointers on this perhaps? I assume we need to disable chrony on the host using dbus? And can we set the system time in priviliged mode?
Not sure I follow your statement above that you would need an instance per container
That was a suggestion from another thread, never mind.
Correction on the RTC part: We already use an RTC. But sooner or later you will be out-of-sync on boot and the problem remains. So an RTC will help, but not solve the issue.
Hi, OS configuration is a path we don’t want to follow as it diverges the OS making issues more difficult to identify and debug and hence makes it more difficult to support the OS. Instead our aim is to set OS defaults that work for all use cases.
What the OS is currently missing to comply with the requirements for a time-sensitive application like yours is to make sure to always sync on NTP poll, and if not possible keep trying until it does. So instead of polling more often, which would impact bandwidth sensitive application, polling with the current 4h cadence, but keep trying indefinitely until the time syncs.
Would that, paired with the RTC, work for your use case?
One use-case in the past was to sync with a refclock (non-ntp source) like GPS. This needs it’s own chrony config.
Our current use-case is to disable timesteps at all times → also needs access to chrony config.
Also the time between two systems is critical, so we have a local ntp source. Criterium here is <1ms. This cannot be done with a 4h cadence, it needs to be a sub-minute interval.
Reason for this criterium is that more computer can have sensor sources attached which need to be timestamped correctly w.r.t. to eachother.
All of the above can be configured with access to the chrony.conf file.
OS configuration is a path we don’t want to follow
I get that, our use-case might be too far from the standard usage of balena. I think we’re good to go with this docker container, thanks for the suggestion
