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.

[zonque]

Shouldn't the clock-steering Crate report the maximum steering capabilities to its users? I would suggest calling into the PTP_CLOCK_GETCAPS ioctl and if that returns -ENOTTY, the file descriptor does not reference a PTP device and hence some other defaults can be assumed.

Would you accept a patch to do that?

[zonque]

And apart from that, the ERANGE error should be handled gracefully, and that's a low-hanging fruit.

[davidv1992]

Having some capability to report steering capabilities would probably be a decent option, assuming the other defaults can be found with some certainty. If you can provide a patch for that that would be nice and we would accept that.

Handling the ERANGE error gracefully is a bit more complicated, as even if it wouldn't cause a crash here, neither statime nor ntpd-rs are currently unprepared for steering to fail, and their standard response (regardless of cause) is that can't steer means we have no business continuing trying. This is a concious protection mechanism as poor steering usually is worse than no steering.

[zonque]

Handling the ERANGE error gracefully is a bit more complicated, as even if it wouldn't cause a crash here, neither statime nor ntpd-rs are currently unprepared for steering to fail, and their standard response (regardless of cause) is that can't steer means we have no business continuing trying. This is a concious protection mechanism as poor steering usually is worse than no steering.

I agree, but as far as this Crate is concerned, it should simply return a proper error to its callers. The users then need to be amended as well, but that needs to be done separately.