Done (in the CVS). On Wed, Jun 24, 2009 at 2:43 PM, Serg Oskin<serg <at> oskin.ru> wrote: > IMHO: In the future, it would be better the owtcl to move beyond the directory swig. Build owtcl now depends on swig, but it is not true. > > Serg. ------------------------------------------------------------------------------
On Tue, Jun 30, 2009 at 11:12 AM, Jaap Struyk<japie <at> minimumrisk.nl> wrote: > On 29-06-09 18:59, Paul Alfille wrote: > >> What are you trying to do? Purge the cache? > > Yes, since reading every uncached sensor costs some time (reading from > uncached or with --timeout_volatile=0) so in my case the total polling > time to poll all sensors is over a second but I want to poll every second. There are 2 issues here: 1. There is no automatic reread of data once a cached item times out. A timeout_volatile of 1 second would make the maximum lifespan of a data element be 1 second (but since the resolution of that timestamp is 1 second, it's more likely to be 1/2 second on average. 2. Purging the cache is a rather rough approach. We probably would only want to purge volatile data which would require a minor change.(maybe a volatile generation counter). The possible scenarios are: 1. Read only uncached data. (slow but certain). 2. Read uncached data every 1 second, and uncached the rest of the time. (Works well if there is one thread that really needs the new data -- like the data collection thread) and every other thread can read the cached data. Or a loop where there are several reads of the same data, and only the first will be the uncached -- easier than storing the data in a variable). 3. Use the cache purge -- best if the update frequency should be enforced and synchronized, and the data collection is mixed in the program logic. 4. Set a short volatile timeout. No one data element will be more than(Continue reading)
On 01-07-09 03:48, Paul Alfille wrote: > There are 2 issues here: > 1. There is no automatic reread of data once a cached item times out. > A timeout_volatile of 1 second would make the maximum lifespan of a > data element be 1 second (but since the resolution of that timestamp > is 1 second, it's more likely to be 1/2 second on average. Aha, that's where I misunderstood, so I must see it as an "expiration date" as soon as it expires the next read will refresh the cache. > 2. Purging the cache is a rather rough approach. We probably would > only want to purge volatile data which would require a minor > change.(maybe a volatile generation counter). That was the behaviour I had hoped for, a "refresh" rate... > 4. Set a short volatile timeout. No one data element will be more than > that number of seconds old. Not currently set up for resolutions under > a second or 2. Currently I have a setting of zero which seems to have the same behaviour as reading uncached. >> I tried timeout_volatile with values of 0.5 but that didn't worked... > Unlikely to work since the cache timestamp is in time_t (seconds) > resolution. It could easily be changed, but I doubt 1-wire really has > the speed to warrant higher resolution. If I poll a single sensor it takes between 0.1 and 0.2sec. depending on(Continue reading)
I've noticed a difference between version 2.5p1 and 2.6p0. When I do several owget -s 3000 /uncached/1F.FAC602000000/main/26.7AAB42000000/VAD the behaviour is different. In 2.5 the hub is not accessed at all (expect for the first time) which makes sense since I don't access anything else not on that branch, whereas in 2.6 owserver seems to communicate heavily with the hub every time, perhaps scanning its directory. Is this intentional? Trying: owget -s 3000 /1F.FAC602000000/main/uncached/26.7AAB42000000/VAD did not help. -- -- Steinar ; NIL DIFFICILE VOLENTI ; http://latinitas.org ; http://voksenlia.net ------------------------------------------------------------------------------
I noticed that there is probably some minor bug in the cache-timeout... I
did some tests with adding a test-device which worked as a clock.
The device had files like second, minute, hour, hhmmss, yyyymmdd etc.
All timeout values were set to fc_second, which should cache the values for
one second.
The time-data were fetched with:
time_t t = time(NULL);
struct tm *tm = localtime(&t);
and then I returned tm->tm_sec when reading the file
F1.000000000000/second
The problem was that reading the "second"-file inside a loop, I only got
even or odd seconds, eg. It was cached 2 seconds instead of 1.
Changing a compare-operator in ow_cache.c fixed the problem, and I can't see
any other side effects.
In ow_cache.c:Cache_Get_Common()
- if (duration[0] >= 0) {
+ if (duration[0] > 0) { // should probably be >, since
fc_second cache for 2 seconds...
/Christian
------------------------------------------------------------------------------
I'll look into the behavior for the current version, this is a bug that may still persist (We're at 2.7p22 rather than 2.6p0). The second part of your note is easier. The location of the "uncached" in the path is immaterial. The whole path is treated as "uncached". Paul Alfille On Thu, Jul 2, 2009 at 1:31 AM, Steinar Midtskogen<steinar <at> latinitas.org> wrote: > I've noticed a difference between version 2.5p1 and 2.6p0. When I do > several > > owget -s 3000 /uncached/1F.FAC602000000/main/26.7AAB42000000/VAD > > the behaviour is different. In 2.5 the hub is not accessed at all > (expect for the first time) which makes sense since I don't access > anything else not on that branch, whereas in 2.6 owserver seems to > communicate heavily with the hub every time, perhaps scanning its > directory. > > Is this intentional? > > Trying: > > owget -s 3000 /1F.FAC602000000/main/uncached/26.7AAB42000000/VAD > > did not help. ------------------------------------------------------------------------------(Continue reading)
Paul Alfille <paul.alfille <at> gmail.com> writes: > I'll look into the behavior for the current version, this is a bug > that may still persist (We're at 2.7p22 rather than 2.6p0). Yes, it's in 2.7p22 as well. I discovered the changed behaviour when I tried to move my snow depth sensor to 2.7p22. I use CNTL on a DS2409 to trigger a pulse in a transceiver (used to determine distance). That makes an audible click, so I can actually hear the communication. I had previously used 2.5p1 which works as expected. I tried do go from 2.7p22 as far back as 2.6p0 which still was like 2.7p22. > The second part of your note is easier. The location of the "uncached" > in the path is immaterial. The whole path is treated as "uncached". I supposed so. It was just a test to check whether something clever had been implemented in case the new behaviour was intenstional. -- -- Steinar ------------------------------------------------------------------------------
Hello! Soureforge has gone ahead and updated its websites. While I am still not happy with it, it does show something interesting. It lists me as an administrator on the project. (I'm the guy who's looking like Master Yoda on the site.) See here: http://sourceforge.net/project/memberlist.php?group_id=85502 ----- Gregg C Levine gregg.drwho8 <at> gmail.com "This signature was once found posting rude messages in English in the Moscow subway." ------------------------------------------------------------------------------
Hello! This is the first group: root <at> jimkirk2:/# man owtap Formatting page, please wait... <standard input>:24: can't open `description.1so': No such file or directory <standard input>:106: can't open `seealso.1so': No such file or directory ----- oot <at> jimkirk2:/# man owfs Formatting page, please wait... <standard input>:18: can't open `cmdline_mini.1so': No such file or directory <standard input>:21: can't open `description.1so': No such file or directory <standard input>:31: can't open `device.1so': No such file or directory <standard input>:41: can't open `temperature.1so': No such file or directory <standard input>:42: can't open `format.1so': No such file or directory <standard input>:43: can't open `job_control.1so': No such file or directory <standard input>:44: can't open `configuration.1so': No such file or directory <standard input>:45: can't open `help.1so': No such file or directory <standard input>:46: can't open `timeout.1so': No such file or directory <standard input>:60: can't open `seealso.1so': No such file or directory These seem to surface no matter which version I am using. ----- Gregg C Levine gregg.drwho8 <at> gmail.com "This signature was once found posting rude messages in English in the Moscow subway." ------------------------------------------------------------------------------
Today I tried to compile and link owfs 2.7p22, restart computer.
Everthing seemed to be ok, libow and owfs bin programs had today's date,
owfs lib links all point to version 22, but when I did owhttpd -V it
shows owfs 2.7p14. I have 3 versions in owfs lib 14, 21, 22.
owhttpd -V
owhttpd version:
2.7p14
libow version:
2.7p14
Any idea what I did wrong?
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
make[4]: Leaving directory `/home/wgb/owfs-2.7p22/module/owhttpd'
make[3]: Leaving directory `/home/wgb/owfs-2.7p22/module/owhttpd'
make[2]: Leaving directory `/home/wgb/owfs-2.7p22/module/owhttpd'
Making install in owserver
make[2]: Entering directory `/home/wgb/owfs-2.7p22/module/owserver'
make[3]: Entering directory `/home/wgb/owfs-2.7p22'
make[3]: Leaving directory `/home/wgb/owfs-2.7p22'
Making install in src
make[3]: Entering directory `/home/wgb/owfs-2.7p22/module/owserver/src'
make[4]: Entering directory `/home/wgb/owfs-2.7p22'
make[4]: Leaving directory `/home/wgb/owfs-2.7p22'
Making install in include
make[4]: Entering directory
`/home/wgb/owfs-2.7p22/module/owserver/src/include'
make[5]: Entering directory `/home/wgb/owfs-2.7p22'
(Continue reading)
RSS Feed48 | |
|---|---|
62 | |
86 | |
87 | |
79 | |
71 | |
124 | |
60 | |
64 | |
29 | |
76 | |
95 | |
135 | |
106 | |
106 | |
149 | |
212 | |
88 | |
110 | |
150 | |
93 | |
157 | |
70 | |
77 | |
47 | |
68 | |
183 | |
113 | |
237 | |
99 | |
93 | |
67 | |
83 | |
167 | |
64 | |
34 | |
122 | |
115 | |
178 | |
121 | |
92 | |
62 | |
36 | |
85 | |
17 | |
107 | |
119 | |
58 | |
114 | |
66 | |
55 | |
106 | |
84 | |
92 | |
115 | |
53 | |
43 | |
44 | |
23 | |
37 | |
47 | |
117 | |
51 | |
64 | |
79 | |
123 | |
57 | |
82 | |
122 | |
141 | |
57 | |
79 | |
88 | |
54 | |
60 | |
231 | |
157 | |
281 | |
165 | |
130 | |
139 | |
106 | |
92 | |
121 | |
200 | |
186 | |
132 | |
84 | |
73 | |
70 | |
55 | |
119 | |
95 | |
69 | |
123 | |
169 | |
44 | |
154 | |
114 | |
231 | |
192 | |
83 | |
21 |
