Re: [gpsd-dev] Please test with WRITE_PAD zeroed

[Eric S. Raymond]

Hal Murray <address@hidden>:
> 
> > One of the solutions implies that it may in fact be possible to do away with
> > WRITE_PAD entirely; the counter-evidence was from running a atale version of
> > a shared library.
> 
> On Linux, WRITE_PAD is already 0.  I haven't seen any lost-packet troubles.
> 
> 
> On NetBSD, your timeout trap goes off on one or two tests of the standard 
> batch.
> 
> :; ./gpsfake -T; ./gpsctl -R 2>/dev/null; ./regress-driver test/daemon/*.log
> sys netbsd6 platform NetBSD-6.1.5-i386-32bit-ELF: WRITE_PAD = 0.00000
> 
> Processing test/daemon/haicom-305N.log
> Test timed out: increase WRITE_PAD = 0.0

Ah. Now that is interesting.  Since the last round of test trimming, the 
haicom-305N test is about four times as long as the next one.  The fact that
it in particular is failing supports the theory that the test frame is 
simply driving the tty layer too fast for it to keep up.  

While this is annoying and means we need to increase WRITE_PAD on that
platform, the data rate from real GPSes is low enough for it to be 
irrelevant to real-world performance.
 
> On FreeBSD, it goes off most of the time.  udp-test.log and tcp-test.log 
> work, or at least they did the few times I tried them.

OK, WRITE_PAD needs to increase there, then.
 
> You might look into bypassing the diff step if the data collection step 
> returns an error code.  That would improve the signal-noise ratio in the 
> printout when chasing things like this.

I will, but I need to make sure suppressing the diff output doesn't discard its
intended use - catching incorrect changes in the driver code leading to
incorrect packet parsing.

> Do you expect it to use 100% of a CPU while waiting?
> 
>   PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
> 92940 murray      1 103    0 16092K  7656K CPU1    1   0:51 100.00% python

Given that it's pumping test logs into a pty as fast as it can, this
is not vey surprising.

> I have another NetBSD box that always has troubles with timing delays, even 
> in SLOW mode.  It's 64 bit Atom (2x CPU) vs 32 bit Celeron above.  (I'm not 
> claiming that is important.)
> 
> sys netbsd6 platform NetBSD-6.1.5-amd64-x86_64-64bit-ELF: WRITE_PAD = 0.10000
> 
> Without SLOW mode:
> WRITE_PAD of 0.05 is not enough.
> WRITE_PAD of 0.1 works so far.

I guess those should go into gps/fake.py.  I'll take a patch.  
A good format would be something like:

NetBSD-6.1.5-amd64-x86_64-64bit-ELF from Hal Murray <address@hidden>:
 0.05 fails, 0.1 succeeds.

> For the record, as long as I'm testing things...
> 
> Processing test/daemon/superstar2.log
> Processing test/daemon/tcp-test.log
> gpsd:ERROR: TCP device open error can't connect to host/port pair.
> gpsd:ERROR: tcp://127.0.0.1:49194: device activation failed.
> Processing test/daemon/tcp-torture.log
> 
> Processing test/daemon/tcp-test.log
> gpsfake: unknown internal I/O error [Errno 48] Address already in use
> (snip diff output)
> Processing test/daemon/udp-test.log

The random-port-collision problem in the test frame is not expected to
entirely go away.  
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>