Hi Antonio,
The prefered way of starting a PROOF session is now by: TProof::Open("localhost")
I will put more info about the local machine setup this afternoon on our
current PROOF website:
http://root.cern.ch/twiki/bin/view/ROOT/PROOF
Cheers,
Jan
Antonio Bulgheroni wrote:
> Dear Leandro,
> thanks for the link. It's very good. But I've a problem I cannot
> solve.
>
> I followed the procedure and I copied the installation dir into
> /usr/local/ even if I'm used to have it in /cern (is it really needed?)
>
> I added the xinetd services and I'm able to connect remotely via rootd.
>
> I wrote the following configuration file for PROOF in
> /usr/local/root/etc/proof/proof.conf
>
> master 192.168.10.246 <http://192.168.10.246> image=local
>
> worker 192.168.10.246 <http://192.168.10.246> perf=100 image=local
> worker 192.168.10.246 <http://192.168.10.246> perf=100 image=local
>
> where 192.168.10.246 <http://192.168.10.246> is the IP address of the
> host. I've also tried with localhost but with the same results.
>
> But when I start ROOT and I type gROOT->Proof(" 192.168.10.246
> <http://192.168.10.246>") I get:
>
> Error: Can't call TROOT::Proof("192.168.10.246 <http://192.168.10.246>")
> in current scope (tmpfile):1:
> Possible candidates are...
> *** Interpreter error recovered ***
>
> In fact, Proof is not an allowed completion of gROOT. What I'm missing?
>
> I'm using ROOT 5.15/01 on a FC4 with gcc 4.
>
>
> Thanks for your help,
>
> Antonio
>
>
>
> On 12/19/06, *Leandro Franco* <lfranco_at_cern.ch <mailto:lfranco_at_cern.ch>>
> wrote:
>
>
> Hi...
>
> Yes, you can use it in multi-core machines. But you have to add your
> local machine as a Master and you have to add the same machine as a
> slave (or slaves) also.
>
> You can find an example here:
> http://pnilsson.web.cern.ch/pnilsson/PROOF_install_notes.htm
> <http://pnilsson.web.cern.ch/pnilsson/PROOF_install_notes.htm>
>
>
> The idea is to make this process transparent to the user but it will
> take some time.
>
>
> Cheers,
> Leo
>
> On Dec 19, 2006, at 5:37 PM, Antonio Bulgheroni wrote:
>
>> Dear Rene, >> thanks for the prompt answer, I'm having a look to the >> websites you suggested me. Do you think that PROOF can be >> exploited also on a multi-processor PC and not on a cluster (this >> is actually my case)? >> >> Thanks again, >> >> Antonio >> >> -- >> Antonio Bulgheroni, PhD >> >> Win98 error 009: Press any key to continue or any other key to quit. >> >> On 12/19/06, * Rene Brun* <Rene.Brun_at_cern.ch >> <mailto:Rene.Brun_at_cern.ch>> wrote: >> >> Antonio, >> >> What you describe is precisely what the PROOF system is doing. >> See: >> http://higweb.lns.mit.edu/twikis/proof/bin/view/Proof/WebHome >> http://higweb.lns.mit.edu/twikis/proof/bin/view/Proof/ProofDocs >> <http://higweb.lns.mit.edu/twikis/proof/bin/view/Proof/ProofDocs> >> etc >> >> Rene Brun >> >> Antonio Bulgheroni wrote: >> > Dear ROOTers, >> > I have browsed the ROOT-Talk archive but I wasn't >> able to find >> > an updated answer to my question. This is what I would like >> to do: >> > >> > I have a TFile with a TTree containing lots of events and I >> want to >> > process them in parallel. Since I just have to apply the same >> > procedure to all events, I think that the easiest possible >> way to >> > perform parallel computing is to split the amount of events among >> > different threads each of which is doing the same things. >> > >> > Here comes the first question. I've read somewhere that ROOT >> I/O is >> > not (yet) thread safe. Does it mean that different threads >> cannot >> > GetEntry from the same TTree on one TFile? Should I >> TMutex::Lock() and >> > UnLock() each GetEntry() call? >> > >> > During the event process, I would like to fill a bunch of >> histograms >> > and an output TTree. Can it be done by different threads? Again, >> > should I mute every Fill() call? >> > >> > In the TThreadFactory abstract base class it is written that >> depending >> > on which factory is active one gets the Posix or Win32 >> implementation >> > of the TThread but I'm not able to find the TWin32Thread. >> Does it exist? >> > >> > I'm using ROOT 5.15/01 on a Fedora Core 4 linux box with gcc >> 4.0.2 >> > >> > Thank you very much for your help, >> > >> > regards, >> > >> > Antonio >> > >> > -- >> > Antonio Bulgheroni, PhD >> > >> >>
### ### Example of simple xrootd config file. ### ### The first part enables a simple data server exposing to clients ### the root paths /tmp and /data1. ### The second part shows how to enable password-based strong ### authentication using the ROOT special password in $HOME/.rootdpass ### The third part shows how to concurrently enable the PROOF serving ### features ### ### To load this configuration file: ### ### ~> xrootd -c $ROOTSYS/etc/xrootd.cf ### ### See http://www.slac.stanford.edu/xrootd for more details on the ### data serving part. ### ###
### Specify a non-default port here:
### - overwritten by -p <port> on the command line
# xrd.port 2094
### Export path directives, i.e. the root paths which can accessed
### by clients ('xrootd.export /' exports the whole file system).
### An arbitrary number of these can be defined. The default is
### to export /tmp.
### NB: specifying any of these directives removes the default /tmp
### from the internal list; in such a case a directive needs to
### be given explicitely if /tmp needs to be exposed.
xrootd.export /tmp
###
### To enable an alias: access as TFile::Open("root://redir//rootdata/file1.root")
###
# xrootd.export /rootdata
###
### FS lib
# xrootd.fslib libXrdOfs.so
###
### OSS section
#oss.path /rootdata r/o
#oss.localroot /home/ganis
###
### Example: enable password-based strong authentication checking ### also the special ROOT password in $HOME/.rootdpass. ### NB: if the application complains about a missing password file in ### $HOME/.xrd/ just create an empty one running 'xrdpwdadmin' and ### replying to the questions # xrootd.seclib /home/ganis/local/xrootd/ROOT/xrootd/lib/libXrdSec.so # xrootd.seclib libXrdSec.so # sec.protocol pwd -d:2 -a:0 -vc:1 -upwd:2 -cryptfile:.rootdpass ###
### Load the XrdProofd protocol: ### a) if the ROOT lib paths are known by the linker/loader # xrd.protocol xproofd:1093 libXrdProofd.so ### b) using absolute paths (<ROOT_sys> with the path to the ROOT distribution) # xrd.protocol xproofd:1093 /home/ganis/local/root/head/root/lib/libXrdProofd.so
xrd.protocol xproofd /opt/jani/workspace/root/lib/libXrdProofd.so # ji
### ### Directives governing the behaviour of the XrdProofd plug-in. ### Except when explicitely indicated, all the following directives support ### an optional 'if <pattern>' condition at the end of the line, e.g. ### xpd.rootsys /opt/root if lxb*.cern.ch ### xpd.rootsys /usr/local if lxp*.cern.ch ### Patterns may contain any number of wild cards; the best match is retained ### (max number of matching chars; if two are equal, the last specified wins). ### ### ROOTSYS path (alternative to rootsys: above)xpd.rootsys /opt/jani/workspace/root
### ### Location of the temporary directory [/tmp] # xpd.tmp /usr/tmp ### ### Internal wait timeout in secs [5]
###
### Defines what to do when no client sessions are attached to a client area.
# Format:
# xpd.shutdown <opt> <delay>
# where:
# <opt> is the type of action to be taken when a client completly
# disconnets; the options are:
# 0 remain connected
# 1 terminate when idle
# 2 terminate no matter the processing state
#
# <delay> is the delay after which the action for option 1 or 2
# is performed; in seconds; to indicate minutes or hours use
# the suffix 'm' or 'h', respectively; e.g. 5m for 5 minutes.
# default:
# xpd.shutdown 1 0
# xpd.shutdown 1 2m
# xpd.shutdown 1 1s
###
### Max number of PROOF sessions [-1, i.e. mo limit]
# xpd.maxsessions 10
###
### Image name of this server [node name]
# xpd.image <image>
###
### Working directory for sessions [<User_Home>/proof]
#xpd.workdir /tmp/proof ji
###
### Resource finder
### NB: 'if <pattern>' not supported for this directive.
# "static", i.e. using a config file
# <cfg_file> path alternative config file
# [$ROOTSYS/proof/etc/proof.conf]
# <user_cfg_opt> if "yes": enable user private config files at
# $HOME/.proof.conf or $HOME/.<usr_def>, where
# <usr_cfg> is the second argument to
# TProof::Open("<master>","<usr_cfg>") ["no"]
# <max_workers> Maximum number of workers to be assigned to user
# session [-1, i.e. all]
# <selection_mode> If <max_workers> != -1, specify the way workers
# are chosen:
# "roundrobin" round-robin selection in bunches
# of n(=<max_workers>) workers.
# Example:
# N = 10 (available workers), n = 4:
# 1st (session): 1-4, 2nd: 5-8,
# 3rd: 9,10,1,2, 4th: 3-6, ...
# "random" random choice (a worker is not
# assigned twice)
# xpd.resource static [<cfg_file>] [ucfg:<user_cfg_opt>] [wmx:<max_workers>] [selopt:<selection_mode>]
# xpd.resource static ~/.proof.test.conf wmx:2 selopt:random
xpd.resource static ~/.proof.conf
# xpd.resource static /opt/root/proof/etc/proof.conf ### ### Master(s) allowed to connect. Directive active only for Worker or ### Submaster session requests. Multiple 'allow' directives can ### be specified. By default all connections are allowed. # xpd.allow lxb6041.cern.ch ### ### Server role (master, submaster, worker) [default: any] ### Allows to control the cluster structure. ### The following (commented) example will set lxb6041 as master, and all ### the others lxb* as workers # xpd.role worker if lxb*.cern.ch # xpd.role master if lxb6041.cern.ch ### ### URL and namespace for the local storage if different from defaults. ### By the default it is assumed that the pool space on the cluster is ### accessed via a redirector running at the top master under the common ### namespace /proofpool. ### Any relevant protocol specification should be included here. # xpd.poolurl root://lxb0105.cern.ch # xpd.namespace /store ### xproofd specific security directives, allowing for independent ### rules from the ones applying to data serving. ### NB: 'if <pattern>' not supported for these directives (protbind can ### used for similar purposes). ### In the example, GSI authentication is required with no control on CRL. ### If this section is missing xproofd falls back to the security setup ### defined for data serving.
This archive was generated by hypermail 2.2.0 : Mon Jan 01 2007 - 16:32:02 MET