Following up on Harald's remark, I can provide some first comparison
data indeed:
Am 31.01.23 um 10:44 schrieb harald@xxxxxxxxx:
This seems like a really small benefit. And we would lose the
low state timings in debug output, which I personally find quite
convenient. Unless there is data, that this change actually improves
something for somebody, I'd reject it.
Running test script against the original kernel module (see below where
on):
# real [s] user [s] sys [s] success fails err per succ
1 222,068 0,515 0,506 83 96 115,66 %
2 223,152 0,603 0,493 86 99 115,12 %
*3* 223,502 0,563 0,411 91 68 74,73 %
*4* 209,626 0,431 0,189 100 15 15,00 %
*5* 209,689 0,46 0,193 100 19 19,00 %
*6* 220,35 0,413 0,315 100 35 35,00 %
Running the patched module:
# Real User Sys Successes Failures Error rate
1 223,061 0,459 0,258 88 25 28,41 %
2 222,431 0,561 0,367 75 57 76,00 %
3 225,675 0,436 0,178 92 19 20,65 %
4 222,746 0,444 0,194 98 23 23,47 %
5 222,668 0,416 0,205 97 20 20,62 %
*6* 204,126 0,34 0,138 100 0 0,00 %
*7* 210,495 0,393 0,199 100 16 16,00 %
*8* 212,563 0,447 0,139 100 19 19,00 %
All tests run on the same board, Allwinner H3 sold as BananaPi M2 Zero,
under kernel 6.2.0-rc5+. The devicetree overlay is setting the
input-debounce property of &pio to 5µs, or, because of the excessive
error rates of the original driver in this configuration, to 1µs (lines
marked with an asterisk).
The test simply tries to read temperature and humidity from the IIO/dht11
exposed input files every 2 seconds, immediately repeating after an error.
Real/User/Sys is determined by good ol' time command, successes and
failures are counted by the test script.
Two aspects strike:
1) the patched version of the driver is working satisfactory even with
5µs input-debounce filter, where the original driver shows more failed
than successful reads in this configuration.
2) The error rate is consistently lower with the patched driver
(67,9% to 33,8% average)
I believe to see similar results, i.e. a noticable improvement on the error
rate, on my old trusted RaspberryPi 2B (without any devicetree fiddling, of
course), however without quantitative comparison and based on some Raspbian
patch level rather than based on kernel 6.2.0-rc5+.
Of course I have only access to a handful of DHT22 devices, most probably
from the same production batch. But I think at least I'd like to stick
with the patched version, tbh.
Hope this helps, let me know if it'd pay to work on another version of
the patch!
Best wishes
Andreas
