Peer mode does work, thank you.
Using peer mode on clients side does work as what client-server mode do,
but it's still a little weird using peer mode in virtually client-server relationships.
A better way to monitor the clients would be to enable them as NTP
servers and specify them as servers with the noselect option on the
monitoring node. This way you would get a better estimate of their
error, compensated and filtered for the network delay.
Yes I agree that monitoring with 'noselect' does provide better estimate accuracy
by fully counteract the network delay. But there're some disadvantages why we didn't
choose that at the beginning:
1. We have ten thousands or more of clients in a local network to be monitored,
thus we need to write every client's ip address into config file, and every time we
add or remove client devices we must edit the monitor's config file manually.
As a contrast, passively logging client's transmit timestamp doesn't need any priori knowledge of
the clients, we could monitor every surviving ntp client and generate an alarm when
one's time/polling interval/root delay or something else is out of threshold automatically.
2. As the large number of clients, monitoring them actively costs more resources,
and I think 'enable them as NTP servers' doesn't provides more security than cancelling
the random information in client packets.
I still believe a configurable switch to turn-off randomization in client packets is a better solution.