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
