[Steinar Midtskogen]
> I've now run the latest owserver for a couple of hours, and all
> devices are still there. I still see the duplication, though.
I might have been too quick to report improvement. owserver ran fine
for a couple of days, then it crashed and when I restarted, it quickly
lost
[Steinar Midtskogen]
> I've now run the latest owserver for a couple of hours, and all
> devices are still there. I still see the duplication, though.
I then tried to run my logger program without queueing. It creates
one thread per sensor, each going into a loop polling its sensor once
every f
Steinar Midtskogen wrote:
> [Steinar Midtskogen]
>
>
>> [Paul Alfille]
>>
>>
>>> I think the duplication should be fixed.
>>>
>> I can give it a try if you commit to cvs (I just did an update, but
>> there didn't seem to be any changes)
>>
>
> Or perhaps there were changes, just
[Steinar Midtskogen]
> [Paul Alfille]
>
>> I think the duplication should be fixed.
>
> I can give it a try if you commit to cvs (I just did an update, but
> there didn't seem to be any changes)
Or perhaps there were changes, just that cvs doesn't report them at
update as svn which I'm more used
[Paul Alfille]
> I think the duplication should be fixed.
I can give it a try if you commit to cvs (I just did an update, but
there didn't seem to be any changes)
> Which bus master? The possibilities include poor electrical connection
> (less likely if some versions work), a problem in the micr
I think the duplication should be fixed.
Which bus master? The possibilities include poor electrical connection
(less likely if some versions work), a problem in the microhub
selection code (which is why I wanted to find out your topology) or a
problem in the device discovery/location caching.
I
Paul Alfille writes:
> Drat!
>
> Can you describe your topology a little? Are these DS18S20's off a
> DS2409 microhub? Which bus master? Which devices (seem like rather
> high temperatures mixed in).
Here are the files accessed:
1F.BCFD0400/main/12.70945300/TAI8570/pressure
1F.BCFD0
Drat!
Can you describe your topology a little? Are these DS18S20's off a
DS2409 microhub? Which bus master? Which devices (seem like rather
high temperatures mixed in).
Paul
On Wed, Aug 5, 2009 at 9:38 AM, Steinar Midtskogen wrote:
> Paul Alfille writes:
>
>> There were problems with the DS2409
Paul Alfille writes:
> There were problems with the DS2409 microhub support. I think I've
> fixed it. (At least it works well in extensive testing here).
>
> New Release 2.7.24 includes the changes.
I've just tried the new release. I still lose devices pretty quickly
until I restart owserver.
There were problems with the DS2409 microhub support. I think I've
fixed it. (At least it works well in extensive testing here).
New Release 2.7.24 includes the changes.
Paul Alfille
On Sun, Aug 2, 2009 at 10:57 AM, Steinar
Midtskogen wrote:
> "Christian Magnusson" writes:
>
>> Trying to do so
"Christian Magnusson" writes:
> Trying to do something like this will not crash owserver anymore...
>
> #!/bin/bash
> while [ 1 ]; do
> /opt/owfs/bin/owget /uncached/10.01/temperature &
> sleep 0.1
> done
I grabbed the current cvs version today to try it. Using that code I
quick
[Steinar Midtskogen]
> [Matthias Urlichs]
>
>> Hi,
>>
>> Steinar Midtskogen:
>>> In some directory listings for the hubs, I notice that the hub
>>> (1F.xxx) and others on hte main bus reappear. Is that an error?
>>>
>> Yes. That shouldn't happen.
>
> Is it most likely anything more than a bit an
[Matthias Urlichs]
> Hi,
>
> Steinar Midtskogen:
>> In some directory listings for the hubs, I notice that the hub
>> (1F.xxx) and others on hte main bus reappear. Is that an error?
>>
> Yes. That shouldn't happen.
Is it most likely anything more than a bit annoying, i.e. harmless?
I see this
readonly is pretty good. It blocks all writes.
Probably the best other thing to block would be all the "temperature9
temperature10 fasttemp, ...) Each requires changing the resolution
setting on the temperature chip and performing a new (slow) read.
We could set up a "safe" mode -- read-only, lim
[Paul Alfille]
> So I'd guess that people access an public owhttpd should be pretty
> safe, as long as the 1-wire devices aren't controlling something
> delicate.
Apart from the queueing issue, my main "worry" (if it turns out to be
a problem, I'll just remove access) has been that a lot of uncac
owhttpd safety:
File system.
owhttpd is very safe. There is only 2 places in the code where any
file operations are done:
1. The "PID" file, which is set from the command line and specifies a
file to write the pid number to.
2. The "configuration" file, again specified from the command line.
Both
developers@lists.sourceforge.net
> Subject: Re: [Owfs-developers] Two owserver problems
>
> "Christian Magnusson" writes:
>
> > Trying to do something like this will not crash owserver anymore...
> >
> > #!/bin/bash
> > while [ 1 ]; do
> >
"Christian Magnusson" writes:
> Trying to do something like this will not crash owserver anymore...
>
> #!/bin/bash
> while [ 1 ]; do
> /opt/owfs/bin/owget /uncached/10.01/temperature &
> sleep 0.1
> done
Excellent. I've put my bus at risk by having all my sensors available
publ
something
like:
ServerRead: Error receiving data on /uncached/FF.0001/temperature
/Christian
-Original Message-
From: Steinar Midtskogen [mailto:stei...@latinitas.org]
Sent: den 6 juli 2009 15:24
To: owfs-developers@lists.sourceforge.net
Subject: Re: [Owfs-developers] Two ows
[Christian Magnusson]
> So, what is a suitable limitation when reading from a remoteserver? Should
> it be allowed to do 10, 20 or 50 concurrent requests?
> As I can see, something must be really wrong if it increase over 20
> concurrent requests for one single 1-wire adapter.
10 or 20 is probabl
@lists.sourceforge.net
Subject: Re: [Owfs-developers] Two owserver problems
I added a simple semaphore to limit number of concurrent connections to 10 +
10 queued connection due to listen().
It may need some tuning or possibility to change with some command-line
parameters perhaps.
A read-timeout could perhaps also
h too many requests.
Is this ok for you all?
/Christian
-Original Message-
From: Christian Magnusson [mailto:m...@mag.cx]
Sent: den 10 juni 2009 19:36
To: owfs-developers@lists.sourceforge.net
Subject: Re: [Owfs-developers] Two owserver problems
Right now we seldom have more than 1
[Christian Magnusson]
> Right now we seldom have more than 1 connecting request in the listen-queue
> at a time... mostly since the code _very_ quickly accepts all connections
> and removes them from the queue. I'm sure nobody would notice any difference
> if the listen-queue was lowered from 10 t
e.net
Subject: Re: [Owfs-developers] Two owserver problems
On Wed, Jun 10, 2009 at 2:37 AM, Christian Magnusson wrote:
>
> Listen() in ow_net_server.c handles #1 automatically, more or less...
It's
> set to handle 10 requests today, and according to the man-pages you see
> this:
>
On Wed, Jun 10, 2009 at 2:37 AM, Christian Magnusson wrote:
>
> Listen() in ow_net_server.c handles #1 automatically, more or less... It's
> set to handle 10 requests today, and according to the man-pages you see
> this:
> "If a connection request arrives when the queue is full, the client may
ex and will be hard to implement I think.
/Christian
-Original Message-
From: Paul Alfille [mailto:paul.alfi...@gmail.com]
Sent: den 10 juni 2009 04:21
To: owfs-developers@lists.sourceforge.net
Subject: Re: [Owfs-developers] Two owserver problems
Hi Steinar,
I've been playing wi
Hi Paul,
> I'm not sure of the best way to handle this. Some thoughts:
> 1. limit the total requests being processed at the same time,
>A by not accepting new sockets until there is space, or
>B. by returning an EBUSY error message.
> 2. try to merge requests. (Only works if the same requ
Hi Steinar,
I've been playing with your setup, and noticed one design problem
right away -- currently there is no throttling of the number of
queries queued by owserver.
The loop can wrap around while owserver is still busy with the prior
set of requests.
I'm not sure of the best way to handle th
Paul Alfille writes:
> Great, a nice test case. Should be fixable. I like the shell script approach.
...
> The problem seems to be that owserver is relatively fine as long as
> the requests come in an orderly fashion, such as in this script:
...
> But if I change the script to requ
Great, a nice test case. Should be fixable. I like the shell script
approach.
Paul Alfille
On Tue, May 26, 2009 at 10:15 AM, Steinar Midtskogen
wrote:
> Matthias Urlichs writes:
>
> > Hi,
> >
> > Steinar Midtskogen:
> >> In some directory listings for the hubs, I notice that the hub
> >> (1F.xx
Matthias Urlichs writes:
> Hi,
>
> Steinar Midtskogen:
>> In some directory listings for the hubs, I notice that the hub
>> (1F.xxx) and others on hte main bus reappear. Is that an error?
>>
> Yes. That shouldn't happen.
I'm suspecting that this is another issue, and less harmful. Both of
the
Steinar Midtskogen writes:
> Paul Alfille writes:
>
>> On 5/25/09, Steinar Midtskogen wrote:
>>> digitemp fails to see quite a few sensors (but occationally it finds
>>> them but incorrectly list them on the main bus), whereas Oww never has
>>> had any problems after years of use.
>>>
>>
>> Sou
Hi,
Steinar Midtskogen:
> In some directory listings for the hubs, I notice that the hub
> (1F.xxx) and others on hte main bus reappear. Is that an error?
>
Yes. That shouldn't happen.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | sm...@smurf.noris.de
Disclaimer: Das Zitat wurde zuf
Paul Alfille writes:
> On 5/25/09, Steinar Midtskogen wrote:
>> digitemp fails to see quite a few sensors (but occationally it finds
>> them but incorrectly list them on the main bus), whereas Oww never has
>> had any problems after years of use.
>>
>
> Sounds like I should look at OWW implement
On 5/25/09, Matthias Urlichs wrote:
> Hi,
>
> Steinar Midtskogen:
>>* When it's time to write to the log file, the parent will cancel
>> all the threads, process all data from every thread (average, max,
>> min, whatever to be logged etc) and log to file.
>>
> Hmm. Thread canceling
On 5/25/09, Steinar Midtskogen wrote:
> digitemp fails to see quite a few sensors (but occationally it finds
> them but incorrectly list them on the main bus), whereas Oww never has
> had any problems after years of use.
>
Sounds like I should look at OWW implementation, then. We are closer
to di
On 5/25/09, Steinar Midtskogen wrote:
>I've written a C program using owcapi, which makes an Oww like log
>file by accessing several owservers. The idea is get several
>sources into one log file and one offline source is not to affect
>logging from the other sources and have owser
Steinar Midtskogen writes:
> I've run into two problems with owserver (on an NSLU2 with a DS9490R
> USB adapter). I've been using 2.7p17 and 2.7p21, both have the same
> problems.
>
> 1. Owserver is unable to read all sensors on my Hobby Boards hub, but
>the sensors are there in the director
Hi,
Steinar Midtskogen:
> > Why not just add a lock around accesses to the relevant data structures?
>
> The idea behind the design is to able to access several owservers
> simultaniously; my 1-wire network is pretty big and I've split it into
> several seperate 1-wire adapters. More important,
[Matthias Urlichs]
> Steinar Midtskogen:
> >* When it's time to write to the log file, the parent will cancel
> > all the threads, process all data from every thread (average, max,
> > min, whatever to be logged etc) and log to file.
> >
>
> Hmm. Thread canceling might cause proble
Hi,
Steinar Midtskogen:
>* When it's time to write to the log file, the parent will cancel
> all the threads, process all data from every thread (average, max,
> min, whatever to be logged etc) and log to file.
>
Hmm. Thread canceling might cause problems
(memory leaks? Non-release
I've run into two problems with owserver (on an NSLU2 with a DS9490R
USB adapter). I've been using 2.7p17 and 2.7p21, both have the same
problems.
1. Owserver is unable to read all sensors on my Hobby Boards hub, but
the sensors are there in the directory listings. E.g.:
This sensor is ok
42 matches
Mail list logo
