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

[Hal Murray]

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

That was while testing with WRITE_PAD set to 0.  The current built-in number 
for FreeBSD works for me.

-----

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

Length may be relevant, but I wouldn't jump to any conclusions from a sample 
of one.

>From one run:

Processing test/daemon/bn-9015.log
Test timed out: increase WRITE_PAD = 0
Processing test/daemon/garmin-10x.log
Test timed out: increase WRITE_PAD = 0
Processing test/daemon/magellan315.log
Test timed out: increase WRITE_PAD = 0
(no diff output for that one)
Processing test/daemon/nd-1005.log
Test timed out: increase WRITE_PAD = 0
Processing test/daemon/ublox-lea-4t.log
Test timed out: increase WRITE_PAD = 0
Regression test FAILED: 4 errors in 89 tests total (0 not found).

Note that only 4 out of 5 got counted.  I assume the no-diff case had the 
timeout after all the data and either didn't return an error code or the 
wrapper didn't check the return code.

Another run:

Processing test/daemon/GPSmap-76S.log
Test timed out: increase WRITE_PAD = 0
Processing test/daemon/blumax-gps009.log
Test timed out: increase WRITE_PAD = 0
Processing test/daemon/bu353s4.log
Test timed out: increase WRITE_PAD = 0
Processing test/daemon/ch-4711.log
Test timed out: increase WRITE_PAD = 0
Processing test/daemon/com-1289.log
Test timed out: increase WRITE_PAD = 0
Processing test/daemon/sounder.log 
Test timed out: increase WRITE_PAD = 0
Processing test/daemon/ublox-lea-5q.log
Test timed out: increase WRITE_PAD = 0
Regression test FAILED: 7 errors in 89 tests total (0 not found).

----------

[Context is reducing printout after known error like timeout,]
> 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. 

How about skipping the printout if the output file is empty?


[100% of CPU]
> Given that it's pumping test logs into a pty as fast as it can, this is not
> vey surprising. 

Why is it getting a timeout if it's pumping stuff into a log file?

The 100% CPU that I observed was while it was waiting for things to time out. 
 Most tests only take a few seconds.  There is plenty of time to catch it 
while it is timing out.




-- 
These are my opinions.  I hate spam.