[Bug 758323] New: tests: Fix spuriously failing netclientclock test on OSX

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=758323

            Bug ID: 758323
           Summary: tests: Fix spuriously failing netclientclock test on
                    OSX
    Classification: Platform
           Product: GStreamer
           Version: unspecified
                OS: All
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: hfink at toolsonair.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.