Ability to configure PTP hardware clock in chrony

[cristi-]

What I'd like:

We would like to be able to configure chrony with the PTP protocol for precision timing according to: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configure-ec2-ntp.html#connect-to-the-ptp-hardware-clock

The ability to enable the option phc_enable for the ena driver is available ✅ :

apiclient apply <<EOF
[settings.boot.kernel-parameters]
"ena.phc_enable" = ["1"]
EOF

however i couldn't find any way to add the following config option to /etc/chrony.conf

refclock PHC /dev/ptp_ena poll 0 delay 0.000010 prefer

Any alternatives you've considered: maybe configuring chrony.conf from a k8s privileged pod (update: after reading a few issues it looks like changing files in /etc/ is not a good idea)?

[koooosh]

Hey @cristi- , thanks for submitting this request. Can you please share more details on your use-case for this?

For example, do you need this config to persist on instance reboot? If not, you could perhaps try this:

1. On the node, enter the admin container
2. Run vi /.bottlerocket/rootfs/etc/chrony.conf and add that config option
3. Restart the chrony service with: sheltie systemctl restart chronyd.service

After running that, I do see that config saved in /etc/chrony.conf:

bash-5.1# cat /etc/chrony.conf
pool 169.254.169.123 iburst
pool 2.amazon.pool.ntp.org iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
dumponexit
dumpdir /var/lib/chrony
user chrony
rtcsync
refclock PHC /dev/ptp_ena poll 0 delay 0.000010 prefer

although, in my case, the service fails with Could not open /dev/ptp_ena : No such file or directory

Again this change won't persist on system reboot, which may or may not work depending on your use-case. More info on the nature of /etc on Bottlerocket can be found here.

[cristi-]

Hey,

Thank you @koooosh for taking a look at this. We would just like to have chronyd configured with access to the Precision Hardware Clock on the ena interface (the actual /dev/ptp_ena may be a mistake, i think we need a extra symlink to get that).

Ideally if we could configure chronyd with these settings after each boot that would be nice, however since these are EKS nodes i don't see them rebooting. Based on your example, would creating a new Host Container that configures chronyd work (we have constantly rotating EKS nodes and some automated solution would be ideal) ? My concern with that was that the file being in /etc/ would change the lifecycle of the node ?

[koooosh]

Thanks for sharing your use case.

A host-container based approach is still quite hacky, and you will likely come across the same persistence issue on reboot as described in this example.

The "correct" solution for this is to add a setting to the API to set this config. We will add this feature request to our backlog.