>Message: 3 >Date: Tue, 11 Feb 2020 00:33:07 -0800 >From: Hal Murray <hmur...@megapathdsl.net> >To: devel@ntpsec.org >Subject: Anybody taking care of refclock_trimble? >Message-ID: > <20200211083307.a89ce406...@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. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
