1-wire network design & OWFS

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

1-wire network design & OWFS

Wright, Ryan P
I could use a little help with the design of my 1-wire network. My
intention is to build a temperature sensing grid throughout a data
center using several hundred sensors.

1. Out of the available supported interfaces (RS232: ibuttonlink,
DS9097E, DS9097; USB: DS9490, PuceBaboon), which would you recommend for
this application, keeping in mind the large network involved? It is my
understanding that, due to network weight limitations, I will probably
need to use multiple interfaces & run multiple instances of OWFS. I'm
hoping to get ~100 sensors and ~700-800 feet of cable per interface.

2. Are any 1-Wire to Ethernet interfaces supported, or are there plans
to do so in the near future (eg, HA7Net, LinkHubE)?

3. Which temperature sensor would you recommend? There seem to be half a
dozen varieties. I was looking at the DS18S20.

4. Speeds: Parasitic mode just takes too long. If I want to apply power
to my sensors to make things fast, how would I go about it? I'm assuming
an external 5VDC power supply providing power on the third pin of the
sensors, grounded to the 1-Wire bus? Does anyone know how much current
I'd need to provide to feed ~100 sensors?

Any other thoughts or ideas would be greatly appreciated.

-___-----------------------------------------------------------------
| , |      ___   ___ _  -- Ryan P. Wright
| _/__  __/ _ \ |   | | -- MSCF Operations
|   \ \/ / /_\ \| | | | -- [hidden email]
|_|\_\  /_/---\_\_|___| --
-----|_|-------------------------------------------------------------




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r 
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: 1-wire network design & OWFS

Steve Lancaster

[In a message on Thu, 09 Jun 2005 16:31:22 PDT,
  ""Wright, Ryan P"" wrote:]
>I could use a little help with the design of my 1-wire network. My
>intention is to build a temperature sensing grid throughout a data
>center using several hundred sensors.
>

Several hundred sensors?

Most data centers will run out of floor space before you can put that
many racks in the room!

We haven't seen much "value" in a sensor per machine.. the air is so mixed
by the fans in the box that you really can't predict much about what is going
on with a given machine in the rack.

You don't want to put sensors inside the machines, because you will block, a
possibly "significant", amount of airflow with the sensor.

Our best luck has been a sensor per rack and a "grid" of sensors on the
ceiling.


Putting a sensor on the input and output of the air handlers gives us and
idea of how much "work" the AC's are doing... and is the canary in the
mine for AC problems. If the deltaT approaches zero and the room temp isn't
below the set point of the thermostat, you have had an AC failure!

We have "never" had an instance where the load on the room was zero.. so
we have always needed cooling, even in the winter. We have had some "near
zero" loads.. but it's been when we had a major machine room shutdown.. and
even then the deltaT was always negative.

With the "one sensor per rack" we spot overloaded racks.

With the ceiling grid we spot areas where we need more "holes" in the
floor.. and

with the AC delta t we spot ac problems....

With a couple of hundred machines we only have about 40 racks.

We can easily scan our entire collection in less than a minute.. and
we log temps every 5 minutes. (RRD handles the average duties.)

We alarm if we get three successive readings above a threshold temp... and
will take either three readings from different sensors in the same
scan or three readings from the "same" sensor on successive scans as
sufficient to trigger an alarm.

Three on one scan says the whole room is getting hot. Three on successive
scans from the "same" sensor says that one rack is getting hot. Either way,
it's an issue we need to look into.. and it has prevented "all" false
alarms due to one hot reading on one sensor. (On the raw data, we would
get a couple of "spikes" in a given month.. probably due to glitched readings.)

Given that it takes about 40 minutes to get someone on site.. 15 minutes to
trigger the alarm isn't a significant time period. (We don't have operators
on duty 24 hours per day.)

The biggest "step" we see in our sensor grid is when someone opens the
back door to a rack, and cool air is mixed in with the exhaust air. (an
open door is good for 7 to 15 degrees F depending on which rack.)

Try instrumenting one rack "all over the place" and another just at
the exhaust and see if you can convince yourself that you can see something
of value in any given reading change before you commit to putting dozens of
sensors in every rack.

Another interesting experiment is putting a dozen sensors in a closed ice
chest (no ice) and watching the results... There is a delta t, even in
a fairly isothermal box.... which ones' right? Some of this may be due to
self heating in the sensors.. (Yes, doing a reading does cause some
energy to be expended the the chip.. more readings.. more heat.... this
effect is probably worse on powered loops than parasitic power..)

Our most useful reading for alarms is the deltaT on the airhandler.. it's
where the first indication of an AC problem shows up.

Steve



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: 1-wire network design & OWFS

Paul Alfille
In reply to this post by Wright, Ryan P
On Thursday 09 June 2005 07:31 pm, Wright, Ryan P wrote:
> 2. Are any 1-Wire to Ethernet interfaces supported, or are there plans
> to do so in the near future (eg, HA7Net, LinkHubE)?
Yes, the LinkHubE is planned. I have been in contact with Bill Farmer.

Paul


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

RE: 1-wire network design & OWFS

Alfille, Paul H.,M.D.
In reply to this post by Wright, Ryan P
Steve,

Do you use 1-wire sensors and OWFS for your server-room monitoring? If so, that
would be the largest implementation of OWFS that I know of. Your experiences
would be quite interesting.

Paul Alfille

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]]On Behalf Of Steve
Lancaster
Sent: Thursday, June 09, 2005 8:43 PM
To: [hidden email]
Subject: Re: [Owfs-developers] 1-wire network design & OWFS



[In a message on Thu, 09 Jun 2005 16:31:22 PDT,
  ""Wright, Ryan P"" wrote:]
>I could use a little help with the design of my 1-wire network. My
>intention is to build a temperature sensing grid throughout a data
>center using several hundred sensors.
>

Several hundred sensors?

Most data centers will run out of floor space before you can put that
many racks in the room!

We haven't seen much "value" in a sensor per machine.. the air is so mixed
by the fans in the box that you really can't predict much about what is going
on with a given machine in the rack.

You don't want to put sensors inside the machines, because you will block, a
possibly "significant", amount of airflow with the sensor.

Our best luck has been a sensor per rack and a "grid" of sensors on the
ceiling.


Putting a sensor on the input and output of the air handlers gives us and
idea of how much "work" the AC's are doing... and is the canary in the
mine for AC problems. If the deltaT approaches zero and the room temp isn't
below the set point of the thermostat, you have had an AC failure!

We have "never" had an instance where the load on the room was zero.. so
we have always needed cooling, even in the winter. We have had some "near
zero" loads.. but it's been when we had a major machine room shutdown.. and
even then the deltaT was always negative.

With the "one sensor per rack" we spot overloaded racks.

With the ceiling grid we spot areas where we need more "holes" in the
floor.. and

with the AC delta t we spot ac problems....

With a couple of hundred machines we only have about 40 racks.

We can easily scan our entire collection in less than a minute.. and
we log temps every 5 minutes. (RRD handles the average duties.)

We alarm if we get three successive readings above a threshold temp... and
will take either three readings from different sensors in the same
scan or three readings from the "same" sensor on successive scans as
sufficient to trigger an alarm.

Three on one scan says the whole room is getting hot. Three on successive
scans from the "same" sensor says that one rack is getting hot. Either way,
it's an issue we need to look into.. and it has prevented "all" false
alarms due to one hot reading on one sensor. (On the raw data, we would
get a couple of "spikes" in a given month.. probably due to glitched readings.)

Given that it takes about 40 minutes to get someone on site.. 15 minutes to
trigger the alarm isn't a significant time period. (We don't have operators
on duty 24 hours per day.)

The biggest "step" we see in our sensor grid is when someone opens the
back door to a rack, and cool air is mixed in with the exhaust air. (an
open door is good for 7 to 15 degrees F depending on which rack.)

Try instrumenting one rack "all over the place" and another just at
the exhaust and see if you can convince yourself that you can see something
of value in any given reading change before you commit to putting dozens of
sensors in every rack.

Another interesting experiment is putting a dozen sensors in a closed ice
chest (no ice) and watching the results... There is a delta t, even in
a fairly isothermal box.... which ones' right? Some of this may be due to
self heating in the sensors.. (Yes, doing a reading does cause some
energy to be expended the the chip.. more readings.. more heat.... this
effect is probably worse on powered loops than parasitic power..)

Our most useful reading for alarms is the deltaT on the airhandler.. it's
where the first indication of an AC problem shows up.

Steve



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r 
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

RE: 1-wire network design & OWFS

jerry scharf
Steve,

I've done a bit of research on this. I have a setup that will have in the
order of 70 sensors across 3 buses. My sensors aren't as orderly as you
will be.

As a preface, the 1-wire sensors are cheap, but the communications design
is weak IMO. It is not resilient or noise immune in the way 10baseT
ethernet is. Some people have reported problems with 1-wire and fluorescent
lights, so that's something to think about when running the wires.

First, I decided to go with the ibuttonlink link45 product. My initial test
had 9 sensors and about 700' of cat5e signal run. Things worked fine. I
want to try to run it out to what they say is an approximate limit of 400m
and see how things work. I have found much less published experience that I
had hoped for. Ibuttonlink has both ethernet and USB based products on the
drawing board, but they are a small shop and can only do so many products.
This leaves the serial product for now.

Second, you asked about sensors. I decided to go with the 18B20 in the TO92
package. It can vary between 9 and 12 bits of reading. At 12 bits, I found
them to not quite meet the specs of +/- 1 degree C for accuracy. I don't
know the accuracy needs of the project, but I would plan of +/- 3 degrees C
for the 18S20. In most cases I recommend the B20, because the accuracy is
there and bus time is rarely a problem. In your case, with lots of sensors
on the bus, the S20 may be slightly better.

As for adding power, the ibuttonlink doesn't supply the +5, so you will
have to add a +5 regulated supply between ground and pin 3. I decided on my
own wiring design rather than the RJ45 layout of the ibottonlink product,
so adding this was straight forward. As for your wiring design, I would
give a great deal of thought to that. You will need to be able to add and
drop sensors as configurations change and to be able to diagnose problems.

best of luck,
jerry

Jerry Scharf
laguna way consulting


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

RE: 1-wire network design & OWFS

Wright, Ryan P
In reply to this post by Wright, Ryan P
Steve,

>> Several hundred sensors?
>>
>> Most data centers will run out of floor space before you can
>> put that many racks in the room!
>>
>> We haven't seen much "value" in a sensor per machine.. the
>> air is so mixed by the fans in the box that you really can't
>> predict much about what is going on with a given machine in the rack.
>>
>> You don't want to put sensors inside the machines, because
>> you will block, a possibly "significant", amount of airflow
>> with the sensor.
>>
>> Our best luck has been a sensor per rack and a "grid" of
>> sensors on the ceiling.

I should clarify: I was only planning two sensors per rack. One under
the floor to measure incoming temperatures and one at the top of the
rack. Plus two sensors per air handler (same configuration). We have
over 175 racks now and are getting ready to begin construction to double
the floor space of our data center.

Last year, our supercomputer was #3 on the top 500 list. We've dropped
to #16 now:
http://www.top500.org/sublist/Site.php?id=1391

As far as I know, we will be the first supercomputing center to utilize
such an extravagant temperature monitoring system.

>> With a couple of hundred machines we only have about 40 racks.

We have in the neighborhood of 1200 machines now. Our primary
supercomputer has 968 nodes alone plus over a dozen racks of network
infrastructure.

It sounds like you have "been there, done that" in this application; I
have a lot to learn from you. Where in the rack did you mount your
sensor? I'd planned on the top of the rack, but maybe that isn't the
best place for it.

I'm also interested in your equipment configuration. How many sensors do
you have? Which interface are you using? Which sensors? My biggest
hangup was cabling; how did you wire your sensors up? I'm trying to
avoid the time consuming job of soldering up custom cables for every
sensor.

>> We can easily scan our entire collection in less than a
>> minute.. and we log temps every 5 minutes. (RRD handles the
>> average duties.)

How many sensors and are you using parasitic power? I'd still prefer the
ability to get nearly instant readings. I'd planned on coding a web
interface where one could query a group of sensors (or the whole room)
and get rapid feedback. I suppose I could simply have the web interface
query the database; it wouldn't be "real time", but should be close
enough.

>> Try instrumenting one rack "all over the place" and another
>> just at the exhaust and see if you can convince yourself
>> that you can see something of value in any given reading
>> change before you commit to putting dozens of sensors in every rack.

Nope - never thought there would be any value in this. I just have a big
data center. (Actually, in my world our data center is tiny... The
really big ones span acres.)

>> Our most useful reading for alarms is the deltaT on the
>> airhandler.. it's where the first indication of an AC
>> problem shows up.

Absolutely; that was one of the first things on my list to monitor.

-___-----------------------------------------------------------------
| , |      ___   ___ _  -- Ryan P. Wright
| _/__  __/ _ \ |   | | -- MSCF Operations
|   \ \/ / /_\ \| | | | -- [hidden email]
|_|\_\  /_/---\_\_|___| -- (509) 376-3502
-----|_|-------------------------------------------------------------


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r 
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: 1-wire network design & OWFS

Steve Lancaster

Our sensor network is two separate runs off of a (http://www.aag.com.mx)
TAI8595 hub.

One run goes around the ceiling and to the air handler sensors. We have
sensors in each quadrant of the room, and a humidity/temp sensor in the
center.

We placed our sensors in the center of each quadrant of the room, in order
to stay away from the low flow areas near the walls and from doors to the
outside.

Our sensors are DS18S20's and DS2438's (from AAG as well.)

we ordered pre-made jumpers from

http://www.connectworld.net/cgi-bin/iec/home.html

We had to special order them as plenum rated.. and we ordered blue colored
cables and hoods to make sure that no one mistook them for ethernet.

(Don't forget that the AAG connectors are 6 pin, not 4 or 8 which are
much more common.)

We did some early tests of things like distance and "accuracy"... to confirm
that we could go as far as we needed to.

We put a bunch of them on a loop in an icechest, with a small electric fan
inside.. The heat from the motor gave us a "changing" temperature to measure
and the fan kept the air moving. We left the covers off of the sensors
to get the fastest settling time. Even with this attempt at an isothermal
environment, there was almost a 3 degree difference between the lowest and
highest readings. (Good enough for our purposes.)

We did punch some more holes in the covers of the sensors because there wasn't
enough flow past the sensor itself. The time constant was too long otherwise.

We then put sensors all over a rack to see if we could make sense of the
readings.. and the answer was "not really".... There was some variability
based on where we put the sensors.. but not enough to say "we are having a
problem with the left most fan on the SunXXX...". Factors such as cable
placment, how "full" the back area of the rack was.. and whether or not
the back door was open, ventilated, solid had much more effect on the outcome.

About the best overall look at what a rack was doing was achieved by mounting
the sensor with a tie wrap to the grill on the underside of the fan in the
top of the rack.

Our racks are full of all sorts of things, from "salvaged" Sun desktops to
dual processor AMD 64's in 1u chassias.

The fans in the units do a lot of air mixing, making the change in a given
reading hard to relate to what caused the change.. and other factors just
swamped the "small signal" changes due to things like stalled fans.

Most of what we see is temperature traces which march in parallel fashion
across the graph.. with overall shifts that match what happens with the
room temperature.. There will be an occasional "baseline shift" which
is usually due to opening or closing a rack back door.

The biggest factor in the change is "what's the room temp". We do
see about a 2 degree change when the tape robot lights off for the
nightly backup run in the ceiling sensor just above the robot.

Our ceiling temps vary across the room by about 5.5 degrees from coolest
to warmest..

And the delta T across the air handlers runs from a low of -2.5 degrees on
a lightly loaded day to a high of 6.5 degrees under heavy load.

Humidity goes from a low of 34 to a high of 62.. tracking nothing I've
been able to spot.. except that it's highest on days of low delta T... which
makes sense.. it's hard to remove moisture from a room that's already
cold enough. We don't do reheat for humidity control. (We could.. but
since we don't have the "problem" we don't want to pay high energy bills
to solve the nonexistent problem. :-))


If I had lots and lots of racks to do, I'd probably run the sensor cable
across the top of the racks, tie wrapped to the top grill of the fan.. you
will get the fan motor heat added to the heat coming from the machines in
the rack... but it's not all that significant.. and you can run short
jumpers from one rack to the other, instead of going down to the floor
and all the way back up again in the adjacent rack.

Entering air temp matched the air handler exit temperature to such a great
extent that we didn't bother to put a sensor at the bottom of the racks.

Alarms are done by scanning the rrd database for high readings.. we look for
three high readings before we page.. either three high in one scan (the whole
room is getting hot).. or three high in three different scans.. "one rack is
getting hot" before we fire off a page. It cut our false alarms to ZILCH.. we
do have an an occasional "spike" in a reading for reasons we have not been
able to correlate with anything in particular.

Spikes went WAY down after we solved this problem:
http://www.wes.net/construction_remediation_services-zinc_whisker_detail.htm

(I'm not endorsing this company... just using their web site.. We used a
local contractor.. and replaced the entire raised floor in the computer
room. We did do surveys using a scanning electron microscope to tell when
the cleanup was adequately done.. and it was a MESS.. We had MANY power supply
failures while this mess was going on.. it's a real threat... with real results. At one point we were loosing a couple of power supplies a week..
Fortunately it was rare to loose both supplies on a redundant supply box.)

Watch the airflow patterns of dissimilar machines.. some draw cool air
from the front and exhaust hot air out the back.. some draw from the
sides... you can end up with "closed loops" forming between adjacent
machines that are hotter than you expect. and mixing with cooler air by
the fan at the top can hide this result. Mixed racks may be good candidates
for "more than one sensor".

From just one sensor per rack.. and other "environmental" sensors arrayed
around the room we get pretty reasonable results, without spending a
fortune to "over sense" a chaotic world for no gain.


Steve




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

RE: 1-wire network design & OWFS

jerry scharf
In reply to this post by Wright, Ryan P
Ryan,

Some comments from the peanut gallery. I've built a few large setups,
data/colo, networking and video production. I never counted racks, so I
guess that means they had a bunch. For us everything was driven of mean
power per volume. Everything else came and went, but changing that took
serious work (especially the cooling.)

When you talk about a few hundred sensors, everything becomes a bit more
serious. You are completely correct you don't want to solder cables, but
you are going to have to bring it all together yourself. That's the trade
off for getting dirt cheap sensors.

First some general comments: I would definitely use +5 power and
simultaneous reads. For me it's about making the controls a bit more
stable. Even at 50-100 sensors per bus, I just think it's easier this way.

If I was attacking this, I would start by designing a simple PC board that
gets RJ45 connectors and places to mount the sensors. Then a tech wires up
the boards. I would design the board so wiring could be done in 3 ways,
true daisy chain, star wired cat5e with sequential data bus (see my recent
postings about this) and 4 wire pass through (an extension of the star/bus
design.) Then use jumpers to set up the way it works in any given location.
All of the wires are just 8 wire RJ45s on the sensor end. On the daisy
chain and pass through, the other end is also RJ45, in the star/bus they
come to blocks. To keep lengths to a minimum, I would have local clusters
that can have racks and such easily added and removed. I would also leave
room on the board to have humidity sensors or other 1-wire capabilities.

In my mind's eye, this seems relatively easy to get all the data collected.
I have some single board linux computers that I am happy with. I run
owserver on these, then gather all the buses together with a parent machine.

I would not use RRD or anything like that to handle the data directly. At a
dollar per GB, why not keep all the sensor data forever? Then use alarm
tools, RRD and the like working against the data store. You never know what
question you might want to ask tomorrow, and without raw data you lose that
ability. All you need to capture is the sensor id, type, value and sample
time. Given the research flavor of the site, this seems quite reasonable.

Hope this rambling was of some help.

jerry

Jerry Scharf
laguna way consulting


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

RE: 1-wire network design & OWFS

Wright, Ryan P
In reply to this post by Wright, Ryan P
Thanks Steve. I'm guessing you bought the pre-boxed DS18S20 ("TAI8520")
sensors from AAG for $20 a pop, then? That makes things a lot easier in
terms of cabling.

Jerry:

>> First some general comments: I would definitely use +5 power and
>> simultaneous reads. For me it's about making the controls a bit more
>> stable. Even at 50-100 sensors per bus, I just think it's easier this
way.

I tend to agree, and this is the route I was looking at. Do you happen
to know how much current the sensors draw, max? I'm going to have to
find this info so I know how big / how many power supplies I need.

>> If I was attacking this, I would start by designing a simple PC board
that
>> gets RJ45 connectors and places to mount the sensors. Then a tech
wires up
>> the boards.

I had a second crazy thought that will require some testing first. I
believe I can crimp a DS18S20 right into the back of an RJ45 connector.
I don't have a DS18S20 handy but I do have some transistors with the
same form factor and they fit beautifully. I can then use RJ45 splitters
to run the daisy chain of RJ45 cables & RJ45-fitted DS18S20s from rack
to rack. Only real concern here is airflow past the sensor.

Failing that, creating (or outright purchasing) some PC boards would be
the next best way to go. However, I'm guessing that doubles the cost of
my installation - not including labor. What I'm doing here is more of a
research project / proof of concept thing so I'm trying to keep costs
low.

-___-----------------------------------------------------------------
| , |      ___   ___ _  -- Ryan P. Wright
| _/__  __/ _ \ |   | | -- MSCF Operations
|   \ \/ / /_\ \| | | | -- [hidden email]
|_|\_\  /_/---\_\_|___| -- (509) 376-3502
-----|_|-------------------------------------------------------------



>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On
>> Behalf Of Steve Lancaster
>> Sent: Friday, June 10, 2005 11:54 AM
>> To: [hidden email]
>> Subject: Re: [Owfs-developers] 1-wire network design & OWFS
>>
>>
>>
>> Our sensor network is two separate runs off of a
>> (http://www.aag.com.mx)
>> TAI8595 hub.
>>
>> One run goes around the ceiling and to the air handler
>> sensors. We have sensors in each quadrant of the room, and a
>> humidity/temp sensor in the center.
>>
>> We placed our sensors in the center of each quadrant of the
>> room, in order to stay away from the low flow areas near the
>> walls and from doors to the outside.
>>
>> Our sensors are DS18S20's and DS2438's (from AAG as well.)
>>
>> we ordered pre-made jumpers from
>>
>> http://www.connectworld.net/cgi-bin/iec/home.html
>>
>> We had to special order them as plenum rated.. and we
>> ordered blue colored cables and hoods to make sure that no
>> one mistook them for ethernet.
>>
>> (Don't forget that the AAG connectors are 6 pin, not 4 or 8
>> which are much more common.)
>>
>> We did some early tests of things like distance and
>> "accuracy"... to confirm that we could go as far as we needed to.
>>
>> We put a bunch of them on a loop in an icechest, with a
>> small electric fan inside.. The heat from the motor gave us
>> a "changing" temperature to measure and the fan kept the air
>> moving. We left the covers off of the sensors to get the
>> fastest settling time. Even with this attempt at an
>> isothermal environment, there was almost a 3 degree
>> difference between the lowest and highest readings. (Good
>> enough for our purposes.)
>>
>> We did punch some more holes in the covers of the sensors
>> because there wasn't enough flow past the sensor itself. The
>> time constant was too long otherwise.
>>
>> We then put sensors all over a rack to see if we could make
>> sense of the readings.. and the answer was "not really"....
>> There was some variability based on where we put the
>> sensors.. but not enough to say "we are having a problem
>> with the left most fan on the SunXXX...". Factors such as
>> cable placment, how "full" the back area of the rack was..
>> and whether or not the back door was open, ventilated, solid
>> had much more effect on the outcome.
>>
>> About the best overall look at what a rack was doing was
>> achieved by mounting the sensor with a tie wrap to the grill
>> on the underside of the fan in the top of the rack.
>>
>> Our racks are full of all sorts of things, from "salvaged"
>> Sun desktops to dual processor AMD 64's in 1u chassias.
>>
>> The fans in the units do a lot of air mixing, making the
>> change in a given reading hard to relate to what caused the
>> change.. and other factors just swamped the "small signal"
>> changes due to things like stalled fans.
>>
>> Most of what we see is temperature traces which march in
>> parallel fashion across the graph.. with overall shifts that
>> match what happens with the room temperature.. There will be
>> an occasional "baseline shift" which is usually due to
>> opening or closing a rack back door.
>>
>> The biggest factor in the change is "what's the room temp".
>> We do see about a 2 degree change when the tape robot lights
>> off for the nightly backup run in the ceiling sensor just
>> above the robot.
>>
>> Our ceiling temps vary across the room by about 5.5 degrees
>> from coolest to warmest..
>>
>> And the delta T across the air handlers runs from a low of
>> -2.5 degrees on a lightly loaded day to a high of 6.5
>> degrees under heavy load.
>>
>> Humidity goes from a low of 34 to a high of 62.. tracking
>> nothing I've been able to spot.. except that it's highest on
>> days of low delta T... which makes sense.. it's hard to
>> remove moisture from a room that's already cold enough. We
>> don't do reheat for humidity control. (We could.. but since
>> we don't have the "problem" we don't want to pay high energy
>> bills to solve the nonexistent problem. :-))
>>
>>
>> If I had lots and lots of racks to do, I'd probably run the
>> sensor cable across the top of the racks, tie wrapped to the
>> top grill of the fan.. you will get the fan motor heat added
>> to the heat coming from the machines in the rack... but it's
>> not all that significant.. and you can run short jumpers
>> from one rack to the other, instead of going down to the
>> floor and all the way back up again in the adjacent rack.
>>
>> Entering air temp matched the air handler exit temperature
>> to such a great extent that we didn't bother to put a sensor
>> at the bottom of the racks.
>>
>> Alarms are done by scanning the rrd database for high
>> readings.. we look for three high readings before we page..
>> either three high in one scan (the whole room is getting
>> hot).. or three high in three different scans.. "one rack is
>> getting hot" before we fire off a page. It cut our false
>> alarms to ZILCH.. we do have an an occasional "spike" in a
>> reading for reasons we have not been able to correlate with
>> anything in particular.
>>
>> Spikes went WAY down after we solved this problem:
>> http://www.wes.net/construction_remediation_services-zinc_whi
sker_detail.htm

(I'm not endorsing this company... just using their web site.. We used a
local contractor.. and replaced the entire raised floor in the computer
room. We did do surveys using a scanning electron microscope to tell
when the cleanup was adequately done.. and it was a MESS.. We had MANY
power supply failures while this mess was going on.. it's a real
threat... with real results. At one point we were loosing a couple of
power supplies a week.. Fortunately it was rare to loose both supplies
on a redundant supply box.)

Watch the airflow patterns of dissimilar machines.. some draw cool air
from the front and exhaust hot air out the back.. some draw from the
sides... you can end up with "closed loops" forming between adjacent
machines that are hotter than you expect. and mixing with cooler air by
the fan at the top can hide this result. Mixed racks may be good
candidates for "more than one sensor".

From just one sensor per rack.. and other "environmental" sensors
arrayed around the room we get pretty reasonable results, without
spending a fortune to "over sense" a chaotic world for no gain.


Steve




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
shotput a projector? How fast can you ride your desk chair down the
office luge track? If you want to score the big prize, get to know the
little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Owfs-developers mailing list [hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r 
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

RE: 1-wire network design & OWFS

jerry scharf
--On 06/10/2005 02:03:36 PM -0700 Wright, Ryan P wrote:

> Thanks Steve. I'm guessing you bought the pre-boxed DS18S20 ("TAI8520")
> sensors from AAG for $20 a pop, then? That makes things a lot easier in
> terms of cabling.=20
>
> Jerry:=20
>
>>> First some general comments: I would definitely use +5 power and=20
>>> simultaneous reads. For me it's about making the controls a bit more=20
>>> stable. Even at 50-100 sensors per bus, I just think it's easier this
> way.
>
> I tend to agree, and this is the route I was looking at. Do you happen
> to know how much current the sensors draw, max? I'm going to have to
> find this info so I know how big / how many power supplies I need.

Spec sheet on the 19S20 says 1-1.5ma with 5V Vdd, so a 1A supply would
drive the entire set.

>
>>> If I was attacking this, I would start by designing a simple PC board
> that=20
>>> gets RJ45 connectors and places to mount the sensors. Then a tech
> wires up=20
>>> the boards.
>
> I had a second crazy thought that will require some testing first. I
> believe I can crimp a DS18S20 right into the back of an RJ45 connector.
> I don't have a DS18S20 handy but I do have some transistors with the
> same form factor and they fit beautifully. I can then use RJ45 splitters
> to run the daisy chain of RJ45 cables & RJ45-fitted DS18S20s from rack
> to rack. Only real concern here is airflow past the sensor.

I would maybe consider this for a few, but not in your application. 300 is
a large number, and the time you spend figuring out what's wrong could
really add up over time.

>
> Failing that, creating (or outright purchasing) some PC boards would be
> the next best way to go. However, I'm guessing that doubles the cost of
> my installation - not including labor. What I'm doing here is more of a
> research project / proof of concept thing so I'm trying to keep costs
> low.

I get the cost issue, but being successful and producing useful data is the
payoff. IMO, data dropouts really stand out and can cause others to
question the value of all the data.

Since you're doing this, I would also pick a few racks and sensor the air
intake and exhaust for each machine. In particular, I would want to see if
the machines at the top of the rack are getting hotter intake air than at
the bottom, which could cause system life problems. There are all sorts of
subtle airflow dynamics, just keep it simple and consistent to start with.

As for reading variations, first check to make sure it's not the chips. I
do bulk calibrations as follows: Take a water bath, put a bunch of sensors
in a latex glove or two and plunk them into the water. Swish them around a
bit then take a simultaneous read of the set. If you have a precision temp
sensor like a platinum RTD, you can calibrate the sensors. If not, you can
do bulk averages and record the differences against average. My experience
with this was that the chips did not meet the accuracy that was listed.

Since you didn't answer about the required accuracy, I would assume that a
couple degrees C don't matter as long as any sensor is repeatable.

jerry

>
> -___-----------------------------------------------------------------
>| , |      ___   ___ _  -- Ryan P. Wright
>| _/__  __/ _ \ |   | | -- MSCF Operations
>|   \ \/ / /_\ \| | | | -- [hidden email]
>| _|\_\  /_/---\_\_|___| -- (509) 376-3502
> -----|_|-------------------------------------------------------------
>
>
>
>>> -----Original Message-----
>>> From: [hidden email]=20
>>> [mailto:[hidden email]] On=20
>>> Behalf Of Steve Lancaster
>>> Sent: Friday, June 10, 2005 11:54 AM
>>> To: [hidden email]
>>> Subject: Re: [Owfs-developers] 1-wire network design & OWFS
>>> =20
>>> =20
>>> =20
>>> Our sensor network is two separate runs off of a=20
>>> (http://www.aag.com.mx)=20
>>> TAI8595 hub.
>>> =20
>>> One run goes around the ceiling and to the air handler=20
>>> sensors. We have sensors in each quadrant of the room, and a=20
>>> humidity/temp sensor in the center.
>>> =20
>>> We placed our sensors in the center of each quadrant of the=20
>>> room, in order to stay away from the low flow areas near the=20
>>> walls and from doors to the outside.
>>> =20
>>> Our sensors are DS18S20's and DS2438's (from AAG as well.)
>>> =20
>>> we ordered pre-made jumpers from
>>> =20
>>> http://www.connectworld.net/cgi-bin/iec/home.html
>>> =20
>>> We had to special order them as plenum rated.. and we=20
>>> ordered blue colored cables and hoods to make sure that no=20
>>> one mistook them for ethernet.
>>> =20
>>> (Don't forget that the AAG connectors are 6 pin, not 4 or 8=20
>>> which are much more common.)
>>> =20
>>> We did some early tests of things like distance and=20
>>> "accuracy"... to confirm that we could go as far as we needed to.
>>> =20
>>> We put a bunch of them on a loop in an icechest, with a=20
>>> small electric fan inside.. The heat from the motor gave us=20
>>> a "changing" temperature to measure and the fan kept the air=20
>>> moving. We left the covers off of the sensors to get the=20
>>> fastest settling time. Even with this attempt at an=20
>>> isothermal environment, there was almost a 3 degree=20
>>> difference between the lowest and highest readings. (Good=20
>>> enough for our purposes.)
>>> =20
>>> We did punch some more holes in the covers of the sensors=20
>>> because there wasn't enough flow past the sensor itself. The=20
>>> time constant was too long otherwise.
>>> =20
>>> We then put sensors all over a rack to see if we could make=20
>>> sense of the readings.. and the answer was "not really"....=20
>>> There was some variability based on where we put the=20
>>> sensors.. but not enough to say "we are having a problem=20
>>> with the left most fan on the SunXXX...". Factors such as=20
>>> cable placment, how "full" the back area of the rack was..=20
>>> and whether or not the back door was open, ventilated, solid=20
>>> had much more effect on the outcome.
>>> =20
>>> About the best overall look at what a rack was doing was=20
>>> achieved by mounting the sensor with a tie wrap to the grill=20
>>> on the underside of the fan in the top of the rack.=20
>>> =20
>>> Our racks are full of all sorts of things, from "salvaged"=20
>>> Sun desktops to dual processor AMD 64's in 1u chassias.
>>> =20
>>> The fans in the units do a lot of air mixing, making the=20
>>> change in a given reading hard to relate to what caused the=20
>>> change.. and other factors just swamped the "small signal"=20
>>> changes due to things like stalled fans.
>>> =20
>>> Most of what we see is temperature traces which march in=20
>>> parallel fashion across the graph.. with overall shifts that=20
>>> match what happens with the room temperature.. There will be=20
>>> an occasional "baseline shift" which is usually due to=20
>>> opening or closing a rack back door.
>>> =20
>>> The biggest factor in the change is "what's the room temp".=20
>>> We do see about a 2 degree change when the tape robot lights=20
>>> off for the nightly backup run in the ceiling sensor just=20
>>> above the robot.
>>> =20
>>> Our ceiling temps vary across the room by about 5.5 degrees=20
>>> from coolest to warmest..=20
>>> =20
>>> And the delta T across the air handlers runs from a low of=20
>>> -2.5 degrees on a lightly loaded day to a high of 6.5=20
>>> degrees under heavy load.
>>> =20
>>> Humidity goes from a low of 34 to a high of 62.. tracking=20
>>> nothing I've been able to spot.. except that it's highest on=20
>>> days of low delta T... which makes sense.. it's hard to=20
>>> remove moisture from a room that's already cold enough. We=20
>>> don't do reheat for humidity control. (We could.. but since=20
>>> we don't have the "problem" we don't want to pay high energy=20
>>> bills to solve the nonexistent problem. :-))
>>> =20
>>> =20
>>> If I had lots and lots of racks to do, I'd probably run the=20
>>> sensor cable across the top of the racks, tie wrapped to the=20
>>> top grill of the fan.. you will get the fan motor heat added=20
>>> to the heat coming from the machines in the rack... but it's=20
>>> not all that significant.. and you can run short jumpers=20
>>> from one rack to the other, instead of going down to the=20
>>> floor and all the way back up again in the adjacent rack.
>>> =20
>>> Entering air temp matched the air handler exit temperature=20
>>> to such a great extent that we didn't bother to put a sensor=20
>>> at the bottom of the racks.
>>> =20
>>> Alarms are done by scanning the rrd database for high=20
>>> readings.. we look for three high readings before we page..=20
>>> either three high in one scan (the whole room is getting=20
>>> hot).. or three high in three different scans.. "one rack is=20
>>> getting hot" before we fire off a page. It cut our false=20
>>> alarms to ZILCH.. we do have an an occasional "spike" in a=20
>>> reading for reasons we have not been able to correlate with=20
>>> anything in particular.
>>> =20
>>> Spikes went WAY down after we solved this problem:=20
>>> http://www.wes.net/construction_remediation_services-zinc_whi
> sker_detail.htm
>
> (I'm not endorsing this company... just using their web site.. We used a
> local contractor.. and replaced the entire raised floor in the computer=20
> room. We did do surveys using a scanning electron microscope to tell
> when the cleanup was adequately done.. and it was a MESS.. We had MANY
> power supply failures while this mess was going on.. it's a real
> threat... with real results. At one point we were loosing a couple of
> power supplies a week.. Fortunately it was rare to loose both supplies
> on a redundant supply box.)
>
> Watch the airflow patterns of dissimilar machines.. some draw cool air
> from the front and exhaust hot air out the back.. some draw from the
> sides... you can end up with "closed loops" forming between adjacent
> machines that are hotter than you expect. and mixing with cooler air by
> the fan at the top can hide this result. Mixed racks may be good
> candidates for "more than one sensor".=20
>
> From just one sensor per rack.. and other "environmental" sensors
> arrayed around the room we get pretty reasonable results, without
> spending a fortune to "over sense" a chaotic world for no gain.
>
>
> Steve
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
> shotput a projector? How fast can you ride your desk chair down the
> office luge track? If you want to score the big prize, get to know the
> little guy. =20
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=3D20
> _______________________________________________
> Owfs-developers mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
> shotput a projector? How fast can you ride your desk chair down the
> office luge track? If you want to score the big prize, get to know the
> little guy.   Play to win an NEC 61" plasma display:
> http://www.necitguy.com/?r=20
> _______________________________________________
> Owfs-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers



Jerry Scharf
laguna way consulting


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: 1-wire network design & OWFS

Vadim Tkachenko
In reply to this post by jerry scharf
jerry scharf wrote:

> I would not use RRD or anything like that to handle the data directly.
> At a dollar per GB, why not keep all the sensor data forever? Then use
> alarm tools, RRD and the like working against the data store. You
> never know what question you might want to ask tomorrow, and without
> raw data you lose that ability. All you need to capture is the sensor
> id, type, value and sample time. Given the research flavor of the
> site, this seems quite reasonable.

I'd second that. I've been collecting the raw data for DIY Zoning
project since 2001 (up to 10 sensors) - and the trace file is barely
over 10M in size.

On the other hand, RRD and suchlike are handy for keeping statistics,
data visualization etc. So I'd suggest storing the data both in the raw
trace and RRD - the overhead is minimal.

Oh, and when you store the raw data, make sure that it is in a
grep(1)pable and cut(1)table format - helps a lot.

> Jerry Scharf

--vt



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: 1-wire network design & OWFS

Steve Lancaster
Is 10 year old temperature data really worth ANYTHING? (Unless you are the
weather forecasters.)?

While the "cost per megabyte" is low, that assumes that the machine you use
to store it... and the backup tapes and labor you use to back it up, and the
staff you take to support the processes are "free"..

Just because you can isn't a good reason to store piles of useless data...


Tell me.. do you remember where sensor 10.2C0442000800 was 10 years ago?
Or what the configuration of all the machines in all the racks was?
Do you even HAVE the same machines you had 10 years ago?
I thought not.

:-)

Steve  


[In a message on Sat, 11 Jun 2005 12:00:19 PDT,
  "Vadim Tkachenko" wrote:]

>jerry scharf wrote:
>
>> I would not use RRD or anything like that to handle the data directly.
>> At a dollar per GB, why not keep all the sensor data forever? Then use
>> alarm tools, RRD and the like working against the data store. You
>> never know what question you might want to ask tomorrow, and without
>> raw data you lose that ability. All you need to capture is the sensor
>> id, type, value and sample time. Given the research flavor of the
>> site, this seems quite reasonable.
>
>I'd second that. I've been collecting the raw data for DIY Zoning
>project since 2001 (up to 10 sensors) - and the trace file is barely
>over 10M in size.
>
>On the other hand, RRD and suchlike are handy for keeping statistics,
>data visualization etc. So I'd suggest storing the data both in the raw
>trace and RRD - the overhead is minimal.
>
>Oh, and when you store the raw data, make sure that it is in a
>grep(1)pable and cut(1)table format - helps a lot.
>
>> Jerry Scharf
>
>--vt
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
>a projector? How fast can you ride your desk chair down the office luge track?
>If you want to score the big prize, get to know the little guy.  
>Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
>_______________________________________________
>Owfs-developers mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/owfs-developers

Steve




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: 1-wire network design & OWFS

jerry scharf
--On 06/13/2005 09:56:30 AM -0700 Steve Lancaster wrote:

> Is 10 year old temperature data really worth ANYTHING? (Unless you are the
> weather forecasters.)?
>
> While the "cost per megabyte" is low, that assumes that the machine you
> use to store it... and the backup tapes and labor you use to back it up,
> and the staff you take to support the processes are "free"..
>
> Just because you can isn't a good reason to store piles of useless data...
>
>
> Tell me.. do you remember where sensor 10.2C0442000800 was 10 years ago?
> Or what the configuration of all the machines in all the racks was?
> Do you even HAVE the same machines you had 10 years ago?
> I thought not.
>
> :-)
>
> Steve
>
>

Steve,

Why the contentious tone?

I'd give this the famous "it depends." If there is some forethought as to
sensor location and collection, yes it can be. I would love to have the raw
data for any number of 25 year old research projects. They might have
flaws, but they generated seminal works and it would be very interesting to
see how hindsight views the analysis.

In the case of the person doing the rack sensor logging, I would think it
is very useful. With almost 10K nodes, you have a large population and
should be able to look for correlations between temperature and things like
system failures. And yes, believe it or not, there are systems where the
racks run untouched other than maintenance for many years. When you're
dealing with 10k nodes, you don't just up and decide to replace a few.

Now let's look at the cost and effort of storing the data. By far the
hardest/most expensive part is defining the format that the data will be
stored in, so let's just guess it will be XML with a bunch of tags. Now
let's assume a reading generates 256 bytes of XML to be stored. With 300
sensors generating samples every 30 seconds, I come up with 221 MB per day.
You get around 21 days on a DVD-R which costs about a buck and would take 5
minutes of someone's time to unmount and store the old one, then label and
mount the new one. We could make it part of a weekly operator action, and
the net cost is really quite small.

If I were doing the failure tracking of a cluster this size, I sure would
want to have this data to look for correlations. How many nodes fail each
day? Do top of rack units do worse? Do certain floor areas do worse? Do
temporary peaks cause accelerated failures, and if so what is the window
before the effects get lost in the noise.

Many moons ago I used to be a physicist. Every run of every experiment in a
synchotron is recorded forever. There are physicists who make a living on
reanalyzing old data. Not only do new results come up, but also the design
of experiments improves with this kind of review.

jerry



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: 1-wire network design & OWFS

Vadim Tkachenko
In reply to this post by Steve Lancaster
Steve Lancaster wrote:

>Is 10 year old temperature data really worth ANYTHING? (Unless you are the
>weather forecasters.)?
>  
>
Yes - see below

>Tell me.. do you remember where sensor 10.2C0442000800 was 10 years ago?
>  
>
I may not, but my scripts definitely do

>Or what the configuration of all the machines in all the racks was?
>  
>
Assuming you're dealing with machines. I don't - my area of interest i HVAC.

>Do you even HAVE the same machines you had 10 years ago?
>  
>
Generally speaking, yes. My relay box is the first computer I've owned -
it's a Pentium 233MMX with 64M RAM. Very useful, and more than enough
for the task - mail relay, POP/IMAP server, Squid cache, Web server, DNS
server, limited edition file server, etc. Made somewhere in 1997. My
main workstation is PIII 550MHz 640M RAM, made in 1999.

The equipment I'm collecting the data on has a usable lifetime of at
least 20, often in excess of 30 years.

There is one ultimate reason to keep the boatload of old data - pattern
analysis. Whereas the operating conditions (and machinery related to it)
change, patterns don't. And at any given moment of time you may or may
not be smart enough to apply yet another pattern analysis algorithm to
the data you have and see critical correlations you didn't see before.

>I thought not.
>
>:-)
>  
>
Think again :)

And, some food for thoughts:

http://www.joelonsoftware.com/articles/fog0000000017.html

Oh, and while I am at it, who needs a computer with more than 640K RAM
in it?

>Steve  
>  
>
--vt

PS: Don't take offense, I didn't mean any. You just touched a raw spot :)



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: 1-wire network design & OWFS

rohbags

>
> Oh, and while I am at it, who needs a computer with more than 640K RAM
> in it?
>

here! here!
If its good enough for man to go to the moon - its good enough for me!

PS: nah seriously, as long as i can play pong and write BASIC im happy!

cheers,

rohbags.

--
Proud owner of 486 DX4/100 32MB, P1 133Mhz 64MB, PII 400Mhz 128MB, AMD 900
512MB, AMD XP 2400+ 512MB, P4 2.4G 256MB...and the rest! - and the first 3
are the most stable!




-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
Reply | Threaded
Open this post in threaded view
|

Re: 1-wire network design & OWFS

Steve Lancaster
In reply to this post by Vadim Tkachenko



[In a message on Mon, 13 Jun 2005 20:06:46 PDT,
  "Vadim Tkachenko" wrote:]
>Steve Lancaster wrote:
>

>>Do you even HAVE the same machines you had 10 years ago?
>>  
>>
>Generally speaking, yes. My relay box is the first computer I've owned -
>it's a Pentium 233MMX with 64M RAM. Very useful, and more than enough
>for the task - mail relay, POP/IMAP server, Squid cache, Web server, DNS
>server, limited edition file server, etc. Made somewhere in 1997. My
>main workstation is PIII 550MHz 640M RAM, made in 1999.

Gee, I'm sorry!.. :-) (and 1999 isn't 10 years ago.. yet...)

"My" first machine was a PDP-8.. followed by an 8008.. and all of those
are LONG gone. Yes, there are a few antiques out there.. still running...
and yes, I pitched PILES of punched paper tape with stuff folks might like
to have.. like the old 2 pass assembler for a PDP-8... but, life is too
short to haul that sort of baggage around.

>
>The equipment I'm collecting the data on has a usable lifetime of at
>least 20, often in excess of 30 years.

And often control systems for AC systems are replaced before things like
compressors and fan coil units are.. and very often, the old systems aren't
compatible with the new ones.

They are often replaced because the new systems offer enough energy savings
or labor savings to pay for the replacement.

If you really think about it.. once a building has been characterized in
terms of it's heat flow most of the old data could be re-created if you
went to the trouble to model it properly.

Now.. there are some things you might catch.. like say a cooling tower
scaling up... but this can also be measured "on the spot" once you know
what the tower's capacity was in it's initial "as built" condition.

Sure, there is lots of stuff out there that can be "mined" for useful
information....

BUT.. there is a lot of stuff that's being saved with no thought to
"why save it?"

The stuff you "saved" from 20 years ago.. It's likely on old 8" floppies..
Have you got a reader for them any more? Can you still read the data?

If you are lucky, it's on old circular chart recorders which you can still
read with the Mark I eyeball. (If you arn't it's on "thermal paper" which
has all turned to a uniform shade of tan by now! :-) )

>
>There is one ultimate reason to keep the boatload of old data - pattern
>analysis. Whereas the operating conditions (and machinery related to it)
>change, patterns don't. And at any given moment of time you may or may
>not be smart enough to apply yet another pattern analysis algorithm to
>the data you have and see critical correlations you didn't see before.

Well.. maybe... but, for the most part our "initial conditions" have
changed so much from year to year that the "pattern" is swamped by
the "changes".

We just added another 20 tons of AC to our computer room... (Based on
heat load calculations and some short term temp measurements, confirming
the calculations.)

Keeping data from the "olden days" when we had a bunch of VAX's doesn't
bear much resemblance to the racks of 1u stuff we have now.. and probably
won't bear much resemblance to what we will have in the next 10 years.

It looks like we will consolidate our computer room with another one in
the next year or so... because we've got so much more compute power in
such small packages that we can do what we used to do... and more... in
less physical space.

All that being said.. having 6 months worth of detail data, and a couple
of years worth of re-sampled long term data is useful... and I'm grateful
to Paul and the other developers of OWFS.. and various other 1 wire
products for their efforts.

There is stuff worth keeping.. but I'm just advocating for a "sane"
retention policy that matches what you will really use.

>Oh, and while I am at it, who needs a computer with more than 640K RAM
>in it?
>

If you need one like this, let me know.. I've got one in my garage gathering
dust..

Steve - who's been drowning in "data" for way too long! :-)



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Owfs-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/owfs-developers