File: README

package info (click to toggle)
nws 2.11-3
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 2,700 kB
  • ctags: 2,820
  • sloc: ansic: 28,849; sh: 3,289; java: 1,205; makefile: 697; perl: 12
file content (221 lines) | stat: -rw-r--r-- 8,442 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
$Id: README,v 1.30 2004/10/22 00:03:08 graziano Exp $

IMPORTANT
---------

As of version 2.11 the nws_sensor needs a nws_memory of at least version
2.11. Older sensors can use the new memory but the other way around is
not anymore true.

As of version 2.11 FORECASTAPI_ComputeForecast (and
NWSAPI_ComputeForecast)  returns 1 on success and 0 on failure!! THIS
REVERSE THE PREVIOUS BEHAVIOUR!!

As of version 2.9 a consolidation of the number of user commands has been
started. nws_ctrl(1) will substitue most of the nws commands. Take a look
at its man pages for information.

As of version 2.7 the default experiment size for the bandwidth
experiments is 256kB. This change may impact slow network considerably.
The change was decided because 64kB (the previous default value) wasn't
enough to read reliable measurements.

As usual, you can change the deafult message size, experiment size and
buffer to be used on a per clique base (you can see start_activity(1) for
more explanations on this values.).

INDEX
-----

1. Building NWS
2. Building NWS with globus
3. Using NWS
4. Packaging NWS with GPT
5. Reporting bugs
6. Adding new experiment
7. Copyright
8. Authors



1. Building NWS
---------------

The NWS build process attempts to automatically configure the sources to work
with a variety of Unix systems.  The build process is divided in 2 steps:
configuration and build. Autoconf takes care of the configuration
process, so you need to 
  cd <NWS root>
  ./configure
  make all

where <NWS root> is the NWS source root directory.  After these steps you
should have a new directory under <NWS root> where all objects file,
binaries and libraries resides (build-host-type where host-type is what
config.guess detected). Send mail to graziano@cs.ucsb.edu if you
experience difficulties building the binaries.  After the above steps,
you can use NWS from the build directory. If you want you can install NWS
into some more appropriate location with 

  make install

By default NWS will install under /usr/local/{bin,lib,include}. If you
want the binaries placed elsewhere, use a --prefix switch when you run
the configure program to specify the installation root directory:

  ./configure --prefix=$HOME/WhereToPutNWS

and then run make install. In this example, "make install" would leave a
copy of the NWS executables in $HOME/WhereIPutNWS/bin. For a finer
control to where put binaries, libraries etc... you can use the usual
configure switches (--bindir, --libdir, --incdir etc...).  configure
takes a number of other standard options, few of which are likely to be
useful to you.  For a complete list, see the GNU autoconf documentation,
or enter

  ./configure --help

on the command line.  You can compile the binaries with debugging symbols
using

   ./configure --enable-debug


You can compile and install only parts of NWS (only sensors or only
servers). Running 

	make

without any target will show the possible targets.


2. Building NWS with globus
---------------------------

If you have globus installed on your system (globus 2.0 or greater) you
can install NWS into the globus installation tree (Nwslapd will be
compiled). To do so you have to run
	
	./configure --includedir=<globus_dir>/<flavor> --prefix=<globus_dir> --with-globus=<globus_dir> --with-globus-flavor=<flavor>

where globus_dir is where globus is installed and flavor is the flavor
wich you want to compile NWS (you have to have already installed globus
with the same flavor). For most user it should be gcc32dbgpthr (but for
Solaris consider the vendorcc32 option).

Remember that the flavor will override the --enable-debug and the
--enable-threads configure options.

3. Using NWS
------------

Please see the file INSTALL for installation instructions and 
Doc/users_guide.html for information on configuring and running 
the system.


4. Packaging NWS with GPT
-------------------------

If you want to package NWS using GPT you can take a look at the NMIbuild
script to obtain both client and server package. 


5. Reporting bug
----------------

You can send email to nws@nws.cs.ucsb.edu or nws@pompone.cs.ucsb.edu to
report a bug. There is a link from our (by now completely oblosete) web
site http://nws.cs.ucsb.edu.

8. Adding a new experiment
--------------------------

Assuming that you already have code that measure something that you are
intersted in, following the following steps you will be able to create a
new NWS experiment. 

You can create a directory, say  $NWS/Sensor/ExpNew, in which you put
your .c and .h files and your Makfile which should have the following
targets: all, clean, dist and install (only all and clean are really
used, and dist only if you want to generate a new NWS distribution). You
need to add 2 functions to your code: one to tell if the skill is
available, and the other which does the real job.  The signature are in
skills.c and they are:

typedef int (*MonitorIsAvailable)(const char *options);
typedef void (*MonitorUseSkill)(const char *options, int *length, SkillResult **results);

#options# are the options that your skill understand (in the name:value
forms): for example the CPU skill undestand nice:5 to set its own nice
value before running. You can add your options to OPTION_FORMATS in
skills.c.

#results# is an array or results written by your UseSkill function. You
don't need to know how is setup, just you can call AppendResult with the
resource (later on the resource), the options used to generate the
result, a flag to tell if succeeded and finally #results# and #length#.
You need to create the right options for AppendResult, if your skill
can excute multiple measurements at the same time (for example the CPU
sensors understands options "nice:0,nice:1,nice:2" and will call
AppendResult 3 times with "nice:0", "nice:1" and "nice:2" with the
respective results.  AppendResult will add the results to the array for
you. GetOptionsValue and GETTOK (defined in strutil.h) should help you to
find the value(s) of your options. 

NOTE: there are control options (look in skills.c in controlOptions).
These options are added to the options that your skill understands (of
course only the options appropriate for your skill's control will be
added). 

NOTE: extra options are added to the options passed to your skill. One is
"timeout:float": you can use it to set the max time your skill can take
to do what your skill does best. Another one is "forceport:int" only for
clique-skills: when set it instructst the sensor to open up server socket
only using that port (used only when calling *Available() for the first
time).

MonitorIsAvailable is called to check if your skill is available on the
system given the #options#. It should be a lightway function since will
be called quite often.

You need to come up with a "resource" and a "skill": the resource is what
you are measuring and the skill is the capability used to measure (you
can have one skill that monitor multiple resources). To add resource and
skill you need to modify skills.h and skills.c. In skills.h 
	- get the right RESOUCE_COUNT and SKILL_COUNT
	- add skill to KnownSkills and resource to MeasuredResources
In skills.c:
	- add your options to OPTION_FORMATS
	- add a new record to myResources
	- add a new record to mySkills
	- add an #include for your header
In myResources you associate a name and a label for the unit of your
measured quantity with the resource. In mySkills you associate your
skill with a name, with resources, with the control (it can be periodic
or clique), with the accepted options and their default values, and with
the 2 previously discussed functions.

The last step is to modify the build structure. You need to modify:
	- Sensor/Makefile to tell the compiler where your header file is
	- modify SENSORS_DIRS (in Makefile) and SENSORS_OBJS (in 
	  configure.in) to include your directory and your object
and you should be ready to go. For experimental sensors there is a
EXPERIMENTAL flags sets into the configure.in script that you might be
interested in.


7. Copyright
------------

It's the usual UC copyrights. Take a look at Doc/Copyright to have a full
text. 

8. Authors
----------

NWS is an original idea coming from the never stopping mind of Rich
Wolski (rich@cs.ucsb.edu). Neil Spring, Jim Hayes and Martin Swany were
developers and maintainer of NWS. Graziano Obertelli
(graziano@cs.ucsb.edu) is the current maintainer and who's to blaim for
the current bugs.