lkml.org 
[lkml]   [2023]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] iio: dht11: Read bit stream from IRQ on falling edges only
On 2023-02-05 21:41, pelzi@flying-snail.de wrote:
> Following up on Harald's remark, I can provide some first comparison
> data indeed:
>
> Am 31.01.23 um 10:44 schrieb harald@ccbib.org:
>> 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.

Aside from different chips (and mostly the old DHT11) there are many
things,
that influence timing: cable lenght, input characteristic etc.

It looks good, but we should still be careful.

> Hope this helps, let me know if it'd pay to work on another version of
> the patch!

Thanks, these are indeed interresting results. If you want to move this
forward, the next steps would be:
1) Sharing your test script - yes it's trivial, but still ...
2) A theoretical analysis about possible regressions depending on timer
resolution as mentioned in an earlier message.
3) Ideally figuring out, why your version performs better then what we
currently have. I have some suspicions, but better understanding might
lead to a better approach. E.g. maybe recording the other edges isn't
the problem so long as we ignore them during decoding?

As I see it, the main thing we are losing with your current proposal is
some diagnostic features. If we keep them as much as possible and have
regressions understood and covered, I see no reason to reject your idea.

best regards,
Harald

> Best wishes
>
> Andreas

\
 
 \ /
  Last update: 2023-03-27 00:12    [W:0.061 / U:0.524 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site