Re: [gpsd-dev] new regression failures

[Greg Troxel]

I think you should be treating reports as pairs of delays, rather than
independently, at least until we're sure that isn't warranted.

In particular, I wonder if it's really just that gpsfake needs to wait
until gpsd is done with the input, and that's about the processing time
it takes to consume the buffered data.  With smaller buffers, that would
be less.  I have no idea what buffer sizes are used in various pty
implementations, or if on Linux close on the pty blocks until the client
has read.

System is NetBSD 6, Core i5 (4 cpus).

0.001/0.2 had failures (645s)
0.001/0.4 had failures (662s)
0.004/0.8 all tests passed (including TCP ones) (696s)
0.001/0.8 all tests passed (697s)

I'll try a few more, but my recommendation now is to change to 0.001/0.8
for now, as the 50s extra is less than 10% and flakiness is very costly.

A run of clean, build (with ccache), and test took 12m3s, with the test
fixture reporting "Elapsed time: 697" (vs 644 with 0.001/0.2.  So the
gpsfake tests are almost all of the time.

I wonder if the systems that need bigger numbers have larger pty
buffers.  Perhaps if there is some way to cause a synthetic EOF, and
have the driver wait until gpsd exits and then signal gpsfake?  But it
seems running ktrace is in order to see what's actually going on before
jumping to solutions beyond delay fudging.

pgpwLt1k8egWE.pgp
Description: PGP signature