---------- Forwarded Message ----------
Date: vendredi 3 juin 2005 11:16 -0700
From: "James A. Hamilton" <jimh@slac.stanford.edu>
To: Nicolas Arnaud <narnaud@lal.in2p3.fr>
Subject: Re: Fastmonitoring downsampling

Nicolas,

(Copied Oep-HN as I thought this might be of general interest)

The ratio is variable, as you observe.  It starts with a factor of about 50%, 
because each FM node can see only one L3 node.  There are 29 (currently - the 
"full complement" is 30) L3 nodes, and 15 FM nodes.  So the events from the 
other 14 L3 nodes is lost to FM.

Secondly, the FM nodes simply process as fast as they can, so the rate depends 
on the complexity of the events. They do more work than the L3 nodes, so the 
rate at which they can process is only about 40% of the L1 rate that is 
available to each node.  L3 does not queue L1 events for FM, but simply 
returns the latest one whenever FM requests one.

So the 18% rate that you saw is pretty typical.  It seems to go as low as 12% 
(unusual) and as high as 26% (also unusual). The typical range is about 16% 
to about 24%, with an overall average of 20%.  These numbers are based on a 
recent series of run 5 runs.  As the luminosity goes up, these numbers will 
go down.

We have for some time been considering roughly doubling the number of FM 
processes, by taking advantage of the fact that each FM node is a dual 
processor and FM is essentially single-threaded.  This is not a free ride. 
There are some downsides relating to the load that the trickle-stream clients 
place on the L3 nodes (which is substantial), and a few other issues. I don't 
know how to assess the value of having a greater percentage of L1 events 
included in FM.  If we used the second processor, my guess is we might 
process something like 30% of the events instead of 20%.

Jim