GNOME Bugzilla – Bug 758323
tests: Fix spuriously failing netclientclock test on OSX
Last modified: 2018-11-03 12:30:48 UTC
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.
Created attachment 315876 [details] [review] tests: Fix spuriously failing netclientclock test on OSX 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. This patch first of all replaces the startup sync code in the test with the new gst_clock_wait_for_sync API, and secondly, doesn't try to test for startup sync to be fast. Instead we set some high timeout for sanity reasons (10 seconds), and whenever the clock says it's ready, we check (like before), if the server/client times are close enough. Lastly, observed diff now uses GstClockTimeDiff and related macros for logging.
Higher deviation for low RTTs makes sense too
Ok, so in the example above, we'd have to use a factor of 6 to let the observation pass. How to configure the max deviation best? Some suggestions: (1) if RTT < 1 ms, always let it pass (2) if RTT < 1 ms, use some other factor (8?) What do you think?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/139.