Numerical result out of range

[zonque]

thread 'tokio-runtime-worker' (6368) panicked at /home/daniel/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/clock-steering-0.2.1/src/unix.rs:594:13:
internal error: entered unreachable code: error code `34` (Os { code: 34, kind: Uncategorized, message: "Numerical result out of range" }) should not occur

This error should be handled gracefully as drivers may return this error when the correction is too large for them to handle.

[davidv1992]

Is this a bug you are running into with your own software or with statime or ntpd-rs?

[zonque]

Is this a bug you are running into with your own software or with statime or ntpd-rs?

Sorry, I should have provided more context here. I am running statime on an embedded device, and the logs indicate that the clock steering is not working. I will report this in a different ticket.

That leads to a situation where clock_adjtime() is called with a value that is higher than what the driver I am working with is capable of handling (100000 ppb). The PTP core layer in Linux then returns -ERANGE.

[davidv1992]

Thank you for the additional detail. We will start thinking how to make handling of this more graceful.

In the meantime, if you are compiling from source you could try modifying the maximum steering and maximum frequency offset values in statime/src/filters/kalman.rs. Assuming a maximum steering range of 100 ppm, max_steer: 40.0 and max_freq_offset: 80.0 should be reasonable, but if your hardware can steer less, just reduce these two numbers. That should avoid the risk of the problem reoccuring, though it probably wont fix the steering not working issues, which could be a number of different things. Feel free to open an issue on the statime repo if you need more help with that and think we might be the cause.

[zonque]

The steering implementation should query the hardware for its capabilities through the PTP_CLOCK_GETCAPS ioctl, and never issue values that are beyond the supported range.

[davidv1992]

Ideally yes, at some point we would implement that. Note however that works only for ptp clocks, which is not all clocks. Also given the general implementation state around ptp clocks in linux, I wouldn't want to count on it as our only option for dealing with this as I have seen drivers do some nasty stuff within those apis.