VUB-RECOIL Archives

Vub measurement using recoil of fully reconstructed Bs

VUB-RECOIL@LISTSERV.SLAC.STANFORD.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Riccardo Faccini <[log in to unmask]>
Date:
31 Oct 2002 10:54:29 -0800 (PST)Thu, 31 Oct 2002 10:54:29 -0800 (PST)
Content-Type:
TEXT/PLAIN
Parts/Attachments:
TEXT/PLAIN (166 lines)
Hi Alessio,
each of the skimmed root files you would produce would be 300 times larger
than the original one. Is this something we can handle? I do not know the
answer...
	thanks
	ric

On Thu, 31 Oct 2002, Alessio Sarti wrote:

> I'm proposing to having skimmed rootfiles (just ~10) obtained running
> against a splitted chain.
>
> Let say:
> I start with a chain with 9000 rootfiles.
> I split it up in 10 pieces.
> I run 10 skimming jobs on 900 rootfiles each.
> I'm producing just 10 output files.
> And then you can safely just run against them!
> what do you thyink about that?
>
> Alessio
>
> ______________________________________________________
> Alessio Sarti     Universita' & I.N.F.N. Ferrara
>  tel  +39-0532-781928  Ferrara
> roma  +39-06-49914338
> SLAC +001-650-926-2972
>
> "... e a un Dio 'fatti il culo' non credere mai..."
> (F. De Andre')
>
> "He was turning over in his mind an intresting new concept in
> Thau-dimensional physics which unified time, space, magnetism, gravity
> and, for some reason, broccoli".  (T. Pratchett: "Pyramids")
>
> On Thu, 31 Oct 2002, Riccardo Faccini wrote:
>
> > Sorry Alessio,
> > I am not sure I understand your proposal: you suggest to produce the
> > reduced root files and make chains over them? But these root file are only
> > 3 times smaller than the default ones, how can you claim we will need more
> > than ten times less
> > jobs?
> > 	thanks
> > 	ric
> >
> >
> > On Thu, 31 Oct 2002, Alessio Sarti wrote:
> >
> > > Hi all,
> > > I propose another workaround!
> > >
> > > I've produced the chains.
> > > I can split them and run the skim job that produces in lees thatn 2 hours
> > > 6-10 job contaiing ALL the generic / data/ cocktail info in such a way
> > > that we donot longer rely on hundreds of job running.....
> > >
> > > What do you think about that?
> > > Alessio
> > >
> > > ______________________________________________________
> > > Alessio Sarti     Universita' & I.N.F.N. Ferrara
> > >  tel  +39-0532-781928  Ferrara
> > > roma  +39-06-49914338
> > > SLAC +001-650-926-2972
> > >
> > > "... e a un Dio 'fatti il culo' non credere mai..."
> > > (F. De Andre')
> > >
> > > "He was turning over in his mind an intresting new concept in
> > > Thau-dimensional physics which unified time, space, magnetism, gravity
> > > and, for some reason, broccoli".  (T. Pratchett: "Pyramids")
> > >
> > > On Thu, 31 Oct 2002, Daniele del Re wrote:
> > >
> > > >
> > > > Hi Yury,
> > > >
> > > >  one example is
> > > >
> > > >  ~daniele/scra/newchains_1030/data-2
> > > >
> > > >  and the tipical message is
> > > >
> > > >  Error in <TFile::TFile>: file /nfs/farm/babar/AWG18/ISL/sx-080702/data/2000/output/outputdir/AlleEvents_2000_on-1095.root does not exist
> > > >
> > > >  on AWG8 this pathology happened just few times when there were >~300 jobs
> > > > reading the same disk if I remember correctly.
> > > >
> > > >  Do you know which is the difference between AWG8 and AWG18?
> > > >
> > > >  My proposal is to split things on different disks, if possible.
> > > >
> > > >  Thanks a lot,
> > > >
> > > >  Daniele
> > > >
> > > > On Thu, 31 Oct 2002, Yury G. Kolomensky wrote:
> > > >
> > > > > 	Hi Daniele,
> > > > >
> > > > > do you have an example of a log file for these jobs ? I do not know
> > > > > exactly what servers these disks have been installed on, but we
> > > > > noticed in E158, where most of the data were sitting on one
> > > > > (relatively slow) server, jobs were limited by I/O throughput to about
> > > > > 2 MB/sec. This limit comes from the random access pattern that split
> > > > > ROOT trees provide. If your job is sufficiently fast, you can saturate
> > > > > I/O limit quite quickly -- with 2-3 jobs. If you submit too many jobs
> > > > > (tens or even hundreds), the server will thrash to the point that the
> > > > > clients will receive NFS timeouts. ROOT usually does not like that --
> > > > > you may see error messages in the log file about files not found (when
> > > > > the files are actually on disk), or about problems uncompressing
> > > > > branches. These are usually more severe on Linux clients, where the
> > > > > NFS client implementation is not very robust..
> > > > >
> > > > > There are several ways to cope with this problem:
> > > > >
> > > > > 1) Submit fewer jobs at one time. I would not submit more than 10
> > > > >    I/O-limited jobs in parallel.
> > > > > 2) Place your data on different servers. That means, different sulky
> > > > >    servers is best. Even if you are on the same sulky server but split
> > > > >    your data onto different partitions, you still get the benefit of
> > > > >    parallelizing disk access
> > > > > 3) Re-write your jobs to first copy your data onto a local disk on the
> > > > >    batch worker (for instance, /tmp), then run on the local copy, then
> > > > >    delete the local copy. The benefit of that is that the cp command
> > > > >    will access the file in direct-access mode (with 10-20 MB/sec
> > > > >    throughput, depending on the network interface throughput).
> > > > > 4) Make your ntuples non-split (very highly recommended). This usually
> > > > >    increases the throughput by a factor of 10-20. If your typical job
> > > > >    reads most of the branches of the tree, making tree split makes no
> > > > >    sense. Non-split trees provide direct access to disk, which is much
> > > > >    more optimal.
> > > > >
> > > > > 							Yury
> > > > >
> > > > >
> > > > > On Thu, Oct 31, 2002 at 09:26:08AM -0800, Daniele del Re wrote:
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > >  in the last two days I tried to run on data and MC on the new disk AWG18.
> > > > > > No way. I got problems in the 80% of the jobs. Someone crashed, most of
> > > > > > them have did not read a large number of root files (actually there).
> > > > > >
> > > > > >  This problem seems to be worse than ever. Do we have to contact
> > > > > > computing people about this?
> > > > > >
> > > > > >  Daniele
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>




ATOM RSS1 RSS2