Inferno only, PTPv2 GrandMaster

[hitech95]

Hi,

I've been building an embedded audio node around your stack:

• inferno @75d9198, dev branch,
• statime from your fork (teodly/statime @244f20a, inferno-dev branch) as the PTPv2 daemon with
  usrvclock export.

You mentioned that a self-sustaining, PTPv2-only inferno setup should be possible.
but I cannot see how, and wanted to check whether I'm missing something.
I cant find in what issue/discussion only the related #40.

What I've observed on a single, isolated node (no other PTP device on the link):

• statime (slave_only=false) self-elects grandmaster via BMCA, as expected;
• but /tmp/ptp-usrvclock never carries any update;

So the ALSA plugin's clock receiver never becomes ready: snd_pcm_hw_params fails with ETIMEDOUT after ~5 s
"no clock available (timeout waiting for overlay update)", and no audio can flow.

Tracing the code, this looks structural rather than a misconfiguration:

• usrvclock::Server::send() is only ever called from the CallbackExporter closure in statime-linux/src/main.rs;
• that exporter only fires from OverlayClock::set_frequency()/step_clock() in `statime/src/overlay_clock.rs);
• those are only invoked by the filter (kalman/basic) update() path, which is fed by received Sync/FollowUp/DelayResp measurements;
• a grandmaster transmits syncs but receives none, so its servo never acts and the export socket stays silent - even though the grandmaster is, by definition, a perfectly valid clock source (its own underlying clock).

The only master-related special case I've found is the ClockExportGuard being skipped when
virtual_system_clock_base=TAI + usrvclock_export in statime-linux/src/main.rs, ~line 377)
but that only bypasses the abrupt-change guard; it does not make the exporter fire without measurements.

Is there a configuration I've overlooked that makes a lone PTPv2 node export a usable clock?
Or is a second statime instance (local master + slave pair) the intended approach?

As a workaround I'm currently creating a small patch in the build: a 1 Hz task that re-sends the last exported overlay while any port is in Master state.
On boot it starts from an identity overlay (clock_id = underlying clockid, shift = 0, freq_scale = 0), which translates to "the reference is my own underlying clock" - so a lone node can host inferno instances, and after a slave->master transition it keeps serving the last disciplined parameters(holdover).
It also matches the usrvclock Server::send documentation recommending "at least once per second" so newly connected clients do not wait for the first update.

Happy to clean it up and send a PR if you agree with the approach or to hear what the intended design is.

For completeness, two smaller things I noticed while digging:

• on a QEMU slirp link statime sees its own multicast reflected back and logs endless "Measurement too far from state, resetting" without ever locking;
• the Cargo.lock pins usrvclock @24da792 which does not compile on 32-bit (tv_nsec i32 vs i64); I re-pin to 53116cb in a pre-build hook.

Thanks a lot for inferno and the statime fork as dipping my toes into AoIP now seems feasible without buying expensive gear.
I'm just experimenting and trying to dip into PTP, maybe Jeff Geerling had a too big impact on me with his time "obsession" hobby as I now want to try a real word example of this tecnology.

Best regards,
Nicolò

[teodly]

TBH I have never tested it without an independent clock master - I have tested inter-Inferno routing but there was always some Dante device, used as a clock source.

You can also use /dev/ptp* as the CLOCK_PATH, then Inferno won't wait for the first clock update.

[hitech95]

Thanks, at the end I've tried with some different statime instances.
At the end for my tests I went with a GM on the host and the qemu guest (source and sync) are salve to it.
I had to patch both camillaDSP and Statime.

• CamillaDSP as it was not properly waiting for the frames and was starving with polling the capture thread.
• To make CamillaDSP happy I also patched Inferno to reduce the notify intervall on the buffer.
• As I dont have a root folder/user home I patched inferno to have a configurable path for the persistent configuration.
• Statime to export usrvclock in master mode with software PTM.

The work is shared here:
https://github.com/hitech95/AoIP-Virgilio

It is a POC to validate if this is something feasible with some cheap device.
I basically want to experiment in creating a DIY AoIP POE speaker pair.