Giles, thank you for the useful pointers to chronyc commands. According to the man pages  "An absolute bound on the computer's clock accuracy (assuming the stratum-1 computer is correct) is given by: clock_error <= |system_time_offset| + root_dispersion + (0.5 * root_delay)"

With your sample output of the "watch chronic tracking" command the absolute bound clock error appears to be: 23,6 ms. I just tested with my RPi and end up with similar order of magnitude values: approx 13.1 ms after 30 min uptime, improving to 10.8ms after 75 min of uptime. So indeed the order of 10ms magnitude that can be expected with NTP over a good nework connection (and nobody watching netflix here at the moment :-).

David, I should have clarified that I choose the RTC and a GPS dongle primarily because I have a portable setup with NTP connection not easily available and I am fine with a time error of a second or so. I configured EKOS that the mount gets time and location information from GPSD as a convenience. The RTC will be synchronized by NTP every time I do have a network connection.

I have been looking into using GPS as an accurate local time source but as Giles points out, this will not work with a serial GPS dongle.  A GPS hat that also makes an accurate 1s time pulse available on an GPIO pin should work though - see for example this project In my setup that would require a different case and then there is the concern of USB3 interference I mentioned so I have not yet pursued this.

In your case I would first check if your  NTP time synchronization over your network is good enough for you.  If this is not sufficiently accurate, given that you are on a network, you could setup a GPS based time server in any convenient location on your network (based on another RPi or  otherwise) away from any interference  and then configure the RPi in your observatory to use this as one time source.