[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] Please test with WRITE_PAD zeroed
From: |
Hal Murray |
Subject: |
Re: [gpsd-dev] Please test with WRITE_PAD zeroed |
Date: |
Sun, 15 Feb 2015 14:26:56 -0800 |
>> 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.