OK I agree… mine was a misguided suggestion (due to the lack of understanding of what a write to /simultaneous/temperature actually does.)
If I got it right, everything boils down to these points. - By simultaneous conversion, we mean a broadcast that tells all sensors to start a temperature conversion. The single sensors do not report back when and if the conversion was done. - There is no way from the client side to have the owserver lock the 1-wire bus and avoid that during the background temperature conversion other clients start conflicting operations on the 1-wire bus. The assumption here is that you have complete control of all owserver clients: due to the lack of owserver synchronisation/lock primitives, everything has to be done with IPC primitives client side. - Due to the atomic nature of the scratchpad update, race conditions cannot occur: a very loose client synchronisation is enough for most applications. A section 4 manpage (src/man/man4/owfs.man) would be very useful to document the bunch of special nodes in the OWFS tree, and their use. Docs about the working of the special nodes (like /simultaneous/temperature) is a little bit scattered and not easily accessible. (Sorry I do not volunteer for writing this manpage, because my understanding of the inner working of owfs is a little weak, as my posts demonstrate.) Stefano > On 03 Feb 2016, at 02:07, Jan Kandziora <j...@gmx.de> wrote: > > Am 03.02.2016 um 01:06 schrieb Stefano Miccoli: >> >> On the contrary a write to /simultaneous/temperature is >> asynchronous, since it will return *before* data is available. IMHO >> for consistency also a write to /simultaneous/temperature should >> *block* until all conversions are performed. >> > There is no way to ensure this. A broadcast command may reach a chip or > it may not. That's hard-wired into the term "broadcast". > > So if you are using /simultaneous, you have to accept you are fully on > your own. Synchronizing and error handling is all your own business. I > don't think it is useful to have owfs doing a "fake" synchronization, > making users unaware of the implications of using a broadcast command. > > >> >> I.e. ‘simultaneous’ ops >> should be synchronous: by doing so there is no need for the 'sleep 1’ >> before the owread commands. >> >> Moreover what happens if process A writes to >> /simultaneous/temperature and process B reads from >> /uncached/10.AE9C54020800/temperature before the 1.0s for the >> conversion are over? Will this result in a race condition? >> > As far as I've tested it, the scratchpad is updated in an atomic > fashion, so you would either read the old or the new value, never a > mixture of both. IIRC I asked Paul the same years ago and he tested it, > too (as the datasheet says nothing about it) and found that it is. > > For using /simultaneous, there should be only one process triggering > these conversions. In fact, with "latesttemp" we can finally fix all > these RRD problems users reported: > > RRD cooking recipe: > ================================================================== > Run this: > ------------------------------------------------------------------ > #!/bin/sh > while : ; do owwrite /simultaneous/temperature 1 ; sleep 1 ; done > ------------------------------------------------------------------ > > Then tell your RRD tool to read "latesttemp" instead of "temperature". > You'll get a nice chart of temperatures updated every second without > those stupid lockup problems. > ================================================================== > > I even postulate most people want temperature sampling to be > asynchronous, as temperatures are very very seldom sampled in regard to > a certain trigger condition but continously instead. > > And even if we had a certain trigger, e.g. monitoring how temperature is > changing after turning on a burner, people would just oversample it and > correlate the trigger later on. The long time constants of heat > dissipation usually allow that. > > >> Maybe all >> operations involving temperature should be blocked during the >> simultaneous conversion. >> > That would make the temperature conversion code even more complicated > and error-prone and /simultaneous/temperature less useful. Plus, it's a > fake. > > >> >> Finally we have different temperature resolutions. >> >> /structure/22/temperature >> 't,000000,000001,ro,000012,v,' /structure/22/temperature10 >> 't,000000,000001,ro,000012,v,' /structure/22/temperature11 >> 't,000000,000001,ro,000012,v,' /structure/22/temperature12 >> 't,000000,000001,ro,000012,v,' /structure/22/temperature9 >> 't,000000,000001,ro,000012,v,' >> >> which one will be returned by latesttemp? >> > The value from the scratchpad. That is, the lastest resolution you've > set on the chip. Power-up-default is 12 bits, but that's programable, > though OWFS lacks an interface to do that. Yet. > > >> /structure/22/last/temperature >> 't,000000,000001,ro,000012,v,' /structure/22/last/temperature10 >> 't,000000,000001,ro,000012,v,' /structure/22/last/temperature11 >> 't,000000,000001,ro,000012,v,' /structure/22/last/temperature12 >> 't,000000,000001,ro,000012,v,' /structure/22/last/temperature9 >> 't,000000,000001,ro,000012,v,' >> > That would require to have OWFS keep track of the different values, > which again makes the temperature conversion code even more complicated > and error-prone. Plus, I doubt anyone ever needs that bug. > > > Did I mention you always have to check for power-up? You cannot just > read a conversion result and take for granted it's valid. That's the > infamous 85°C reading. OWFS takes some measures against this, but it's > only heuristics. The only safe way to check for power-up is to never do > 12-bit conversions and then test whether the resolution has changed back > to 12-bit since the last conversion trigger. (Or setup the EEPROM for > another default and check for this.) Reading temperature and resolution > is atomic, fortunately. > > > If I had to decide, I would implement this safe, atomic 85°C reading > tomorrow and throw out the heuristics completely. Hardly anyone needs > the 12-Bit resolution, that's less than 0.2°C, even with the chip being > calibrated your mounting certainly is not and I doubt anyone using OWFS > has a setup to calibrate it. You'd need a physics lab to do that. Better > than 1°C accuracy is 99% fake. > > > > My opinion: "latesttemp" is simple and stupid, that's why it "just > works". It gives you the cooked value you could also read from the > undocumented "scratchpad" node. Nothing more. > > > Kind regards > > Jan > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Owfs-developers mailing list > Owfs-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/owfs-developers ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
