tests: Fix spuriously failing netclientclock test on OSX
@heinrich.fink
Submitted by Heinrich Fink Link to original bug (#758323)
Description
On OSX, startup sync might take longer than what has been assumed in the test,
hence failing the test. OSX seems to be exposed to more OS scheduling jitter,
i.e. the observed RTTs take some time to be become stable enough.
As the comment in the original test says:
"can't in general make a precise assertion here, because this depends on
system load and a lot of things. however within half a second they should
at least be within 1/10 of a second of each other... "
IMO, if we can't make a precise assertion here, we shouldn't make it at all in
the unit test. See attached patch for a fix.
Related to this, here is the debug output of one of the observations being
dropped (originally causing the longer sync time on OSX):
<netclientclock0>
Dropping observation, long RTT 0:00:00.000977094 > 2 * avg 0:00:00.000182319
That shows that the RTT is of course very low (via localhost), but that this
observation is too far off the avg, likely because OS schedule jitter. slomo
(thanks for the analysis of the problem) suggested that maybe we can also
allow a higher deviation for RTTs lower than 1-2 ms. However, I am not
familiar enough with the netclientclock to write a patch for that/further
discuss if that makes sense or not. It would make the initial sync faster on
OSX in this case. Due to the dropped observations, sync can sometimes take
longer than 500ms on that platform. Does anybody have comments on that?
Anyway, IMO the test should be fixed nonetheless, patch is attached.