Anybody taking care of refclock_trimble?

[Trevor N.]

>Message: 3
>Date: Tue, 11 Feb 2020 00:33:07 -0800
>From: Hal Murray <hmurray at megapathdsl.net>
>To: devel at ntpsec.org
>Subject: Anybody taking care of refclock_trimble? 
>Message-ID:
>	<20200211083307.A89CE40605C at ip-64-139-1-69.sjc.megapath.net>
>Content-Type: text/plain; charset=us-ascii
>
>
>        /* get timestamp after triggering since RAND_bytes is slow */
>        get_systime(&pp->lastrec);
>
>
>Back in December, I fixed get_systime to use random() rather than ntp_random() 
>which calls RAND_bytes().

When I added that comment I found that RAND_bytes() was taking
hundreds of nanoseconds on the same system that was taking the classic
version's local random less than 100ns.  Since this is no longer the
case, I'll check the performance of the new method -- but it should be
safe to remove the comment.

I revisited that area when the --disable-fuzz option was added in
order to experiment with also removing fuzzing from the refclocks. I
got a very significant reduction in jitter when switching from
get_systime() to clock_gettime().

I'll create an issue on the tracker this weekend to discuss the
possibility of switching the Trimble driver to clock_gettime().  I
would also like to propose changes to the driver that will improve
performance with unstable system oscillators.