> On 6 Aug 2020, at 21:42, Mick Sulley <m...@sulley.info> wrote: > > I did change to persistent and I didn't see a difference. > >
Just a quick background. The persistent=True option is useful to shave a few milliseconds from each owserver query by not having to create and pull down a TCP socket and for limiting the number of sockets in the TIME_WAIT status, which usually is not a problem, but could be problematic for machines with limited memory. You can check the sockets in TIME_WAIT with the shell command ss -a '( dport 4304 or sport 4304 )' > /settings/timeout/presence is what is causing it. I had tried changing it > yesterday, via the httpd web page, but this time I checked it with owread and > that showed it still at 120, so I changed it to 20 with owwrite re-ran my > Python script and yes it slows every 20 seconds > > What is the purpose of /settings/timeout/presence? The man page says > 'Seconds until the presence and bus location of a 1-wire device expires in > the cache.', but I don't really understand what it does. Surely the presence > is confirmed by any read of the sensor. > There is a message in the owserver protocol to check the presence of a sensor shell: owpresent XXX pyownet: owproxy.present(“XXX”) I rarely use it but I assume that the reply to this query is cached, with a timeout of /settings/timeout/presence … > I have just tried setting it to -1, that is invalid, I thought it may disable > it. I set it to 0 and it is slow every time. I have now set it to 9999999, > not sure what the limit would be. > > Comments? > > Mick > > On 06/08/2020 16:48, Martin Patzak wrote: >> looks like you are getting close :-) >> >> I checked, and the only timeout of owserver that matches 120 is >> /settings/timeout/presence >> >> >> >> On 06.08.20 16:21, Mick Sulley wrote: >>> Well this gets more curious. I am now measuring the time for each read, >>> reading type, power and latesttemp. Time for all is generally < 0.1 >>> seconds, but then when I hit the slow loop the read for type is around 0.7 >>> seconds, the others still < 0.1 seconds. I don't really need type so I >>> removed it and re-tested, on slow loops the power read is around 0.7 >>> seconds, latesttemp still < 0.1 seconds. So I removed power as well, just >>> reading latesttemp, on slow loops that is now around 0.7 seconds. So it >>> seems that at some point a sensor takes many times longer for its next >>> read, irrespective of which field is read. >>> >>> I have now tested with 19, 11 and 2 sensors and the slow loop occurs every >>> 120 seconds. I am intrigued to know what causes this, any ideas? >>> >>> Thanks >>> >>> Mick >>> >>> On 06/08/2020 10:23, Mick Sulley wrote: >>>> OK I will log read times and see what that shows. >>>> >>>> You say 'I also log if the error of the 1wire bus changes.' how do you do >>>> that? >>>> >>>> No I don't really need to read that fast, this is just a test setup to get >>>> a better understanding so I can hopefully fine tune my main system. >>>> >>>> There should not be anything else running. I just tried running top at >>>> the same time, I monitored it at the point of the slow scan and didn't see >>>> anything else significant. >>>> >>>> Mick >>>> >>>> On 06/08/2020 09:06, Martin Patzak wrote: >>>>> It looks like your timing has improved after all! >>>>> >>>>> in your original Python-code you could time every read for each sensor. >>>>> I have also powered sensors and a read is usually faster than 0.1 seconds. >>>>> I log in a file if the read took longer than 0.3 seconds, which is almost >>>>> never the case. >>>>> I also log in the file if the whole reading loop took longer than 3 >>>>> seconds, which again is almost never the case. >>>>> >>>>> I also log if the error of the 1wire bus changes. >>>>> >>>>> I read 25 sensors every full and every half minute, so maybe you could >>>>> implement a delay as well and see if things get more consistent. >>>>> Do you need to read so fast in a loop for you application? >>>>> >>>>> What else is running on your machine? You could run top in parallel to >>>>> your python loop. >>>>> >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Owfs-developers mailing list >>>> Owfs-developers@lists.sourceforge.net >>>> <mailto:Owfs-developers@lists.sourceforge.net> >>>> https://lists.sourceforge.net/lists/listinfo/owfs-developers >>>> <https://lists.sourceforge.net/lists/listinfo/owfs-developers> >>> >>> >>> >>> _______________________________________________ >>> Owfs-developers mailing list >>> Owfs-developers@lists.sourceforge.net >>> <mailto:Owfs-developers@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/owfs-developers >>> <https://lists.sourceforge.net/lists/listinfo/owfs-developers> >> > _______________________________________________ > Owfs-developers mailing list > Owfs-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/owfs-developers
_______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
