gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] new regression failures


From: Eric S. Raymond
Subject: Re: [gpsd-dev] new regression failures
Date: Mon, 11 Nov 2013 09:59:49 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

Greg Troxel <address@hidden>:
> I think you should be treating reports as pairs of delays, rather than
> independently, at least until we're sure that isn't warranted.

Good point.  Reorganized and pushed.
 
> 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.

I don't know either.  But I have some thoughts.

1. If it's about the processing time to consume the data, why such large
variations cross-platform?  It's the same data, and the buffer processing
ought to take place entirely in core.

2. Damn.  Linux is doing something impressively right here. Even on
slower processors it's getting away with much smaller delays.

3. Michael Tatarinov's numbers on an ARM running at less than half the clock
speed of my Core Duo strongly suggest that hardware speed isn't the main
driver, nor is architecture.  Whgat does that leave but overhead differences
at the software level?

4. Possibly relevant fact: calling tcdrain() on the gpsfake (master) side
of the pty seems to have no effect on the delay required.  When exercising 
TCP transport, shutdown() doesn't help either.

> 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)

That's good data, thanks.

> 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.

But going to an 0.8 close-delay slows down *my* tests by a factor of 5.
That is rather a lot.

> 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.

Same thing observed here.

> 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?

That would be complicated and fragile.  I don't want to incur so much
technical debt just to speed up testing by a few seconds.

>                                                               But it
> seems running ktrace is in order to see what's actually going on before
> jumping to solutions beyond delay fudging. 

Agreed.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]