Re: [gpsd-dev] new regression failures

[Eric S. Raymond]

Greg Troxel <address@hidden>:
> > Remind me of your OS and hardware?  I want to start tracking the
> > failure thresholds for these figures on different platforms.  Some
> > pattern might emerge.
> 
> NetBSD 6 (current stable branch), i386, 4-core ~2 year old CPU, HTT
> disabled in bios
> 
> cpu0 at mainbus0 apid 0: Intel(R) Core(TM) i5-2310 CPU @ 2.90GHz, id 0x206a7
> (and then 1,2,3)

This grows more interesting.  Recall that we started with WRITE_PAD =
0.01 and CLOSE_DELAY = 0.4 and Hal Murray reported that working on
freebsd.  Here is what I currently have:

# The two magic numbers below have to be derived from observation.  If
# they're too high you'll slow the tests down a lot.  If they're too low
# you'll get random spurious regression failures that usually look
# like lines missing from the end of the test output relative to the
# check file.  The need for them may be symptomatic of race conditions
# in the pty layer or elsewhere.

# WRITE_PAD: Define a per-line delay on writes so we won't spam the
# buffers in the pty layer or gpsd itself.  Removing this entirely was
# tried but caused failures under NetBSD.  Values smaller than the
# system timer tick don't make any difference here.
#
# Eric Raymond got success with 0.0 on Linux 3.11.0 under an
# Intel Core Duo at 2.66GHz.
#
# Greg Troxel reported failure with 0.001, success with 0.004, on
# NetBSD 6, i386, 2.90GHz.
#
if sys.platform.startswith("linux"):
    WRITE_PAD = 0.0
elif sys.platform.startswith("freebsd"):
    WRITE_PAD = 0.001
else:
    WRITE_PAD = 0.004

# CLOSE_DELAY: We delay briefly after a GPS source is exhausted before
# removing it.  This should give its subscribers time to get gpsd's
# response before we call the cleanup code. Note that using fractional
# seconds in CLOSE_DELAY may have no effect; Python time.time()
# returns a float value, but it is not guaranteed by Python that the C
# implementation underneath will return with precision finer than 1
# second. (Linux and *BSD return full precision.)
#
# Field reports:
#
# Eric Raymond got success with 0.1, failure with 0.05 on Linux 3.11.0 under an
# Intel Core Duo at 2.66GHz.
#
# From Hal Murray on NetBSD 6.1.2 on an Intel(R) Celeron(R) CPU 2.80GHz
#  CLOSE_DELAY = 0.4    Works, takes 688.69 real
#  CLOSE_DELAY = 0.3    Fails tcp-torture.log, takes 677.53 real
# Both observations with WRITE_PAD = 0.01
#
# Greg Troxel reported failure with 0.4, success with 0.8, on
# NetBSD 6, i386, 2.90GHz.
#
if sys.platform.startswith("linux"):
    CLOSE_DELAY = 0.1
elif sys.platform.startswith("freebsd"):
    CLOSE_DELAY = 0.4
else:
    CLOSE_DELAY = 0.8

Two things jump out at me:

1. Whatever's behind these numbers, it probably ain't CPU speed unless 
faster processors need *more* delay, not less.  Notice how little padding
I get away with.

2. You and Hal, running very similar NetBSD 6 systems, need wildly
different delays.

Hal, can you confirm that the sys.platform.startswith("freebsd") test
works to identify that platform?

Anyone else got interesting data, or a theory about these?
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

signature.asc
Description: Digital signature