Any time I have checked the time on the various ROCs against
dblast07 (their "ntp" server), it has agreed well. That doesn't guarantee
that they'll always agree, but it's a step in the right direction. The
"Time Correction" reported on the 2 FASTBUS ROCs (opitrig1 serial port
connections) is always small.
Karen
At 06:27 PM 12/21/2003 -0500, Tancredi Botto wrote:
> > Em, after Chris showed me how to save the ntuples before whole run is
> > crunched, the ideal situation I have in mind is that crunch does not have
> > to wait for run to end(we can do that right now with 2.96), analysis does
> > not have to wait for crunch to end(new version does that). In this case,
> > analysis(including some basic asymmetry analysis) could be almost real
> > time.
>
>yes yes but the point of our discussion affected also the statistics of
>the "almost real time" analysis. And so far the error bar in the fitted
>asymmetry is ca. 20-30%/hr of data. Then it seems almost futile to monitor
>on shorter time scales. Note however that our "fit" is done over a large
>range of angles. Of course we could put everything in one bin (ca 1000
>events/hr/state if you flip only one state and are reasonably efficient
>in taking data) after we are reasonable confident of the "shape"
>
>
>
> > checking if the time difference between physics event and the associated
> > epics/scaler is larger than 1 second will tell us if epics/scaler servers
> > are running as they are supposed to.
>
>or maybe that the ntp servers are drifting away ? I am not very happy to
>rely on that part. My computer boots 6-7 hrs late most often than not and
>even if I am running ntp on it I am not sure its time is always that good.
>If we can do without knowledge of absolute times, better.
>
>
>
> > when you enter a dst and try to select events and get the right charge
> > for those selected events, I do not see other ways than loop through event
> > by event. When Draw() is kicked out,
> > bool cut() { return (fill>23&&fill<50)||(fill=51)||(fill>53...); }
> > is the choice.
>
>I just hope that there is not a lenght limit like it happened with
>strings, TCuts, ntuple variables. Note that this year we have had ca 10000
>fills. Hence the suggestion of a post-production calculated quality flag.
>Again is the "large data set" management that is a bit problematic if we
>stick to one dst format (the other way to do it is ot filter and reduce...)
>
>Thanks for all of your updates....
>
> > I can experiment a little with TTreePlayer, so it will parse TStrings and
> > make such functions.
> >
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:30 EST