<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Hi Mark,<br>
    <br>
        This is a great start. I have one quick question: have we
    verified that the reconstruction rate for the 10^8 data is the same
    as the 10^7? Even though the event rate to disk will be the same, I
    can imagine the 10^8 data being busier and therefore, take longer to
    process. They are hopefully comparable, but we should verify it if
    it hasn't been already. <br>
    <br>
        I'd also like to follow up a little on the discussion started a
    while back on the how the GRID is to be included in the computing
    plan. It seems clear that our collaborators feel this will be an
    important part of the GlueX experiment's operation. Chip has
    indicated though that supporting it from the JLab side has
    significant resource costs and must be clearly justified. Has there
    been any discussion as to what exactly these costs are? I thought
    from earlier conversations that this was a manpower cost on the JLab
    side, but at this point, I don't know what is required. The Physics
    Division maintains several software packages already (ROOT, CERNLIB,
    Xerces,...) are there additional resources besides software
    maintenance? I know the our original CDR called for something like
    an OC24 connection due to the anticipated high bandwidth usage. Are
    there other hardware costs involved?<br>
    <br>
        We'll need to start gathering cost information as we develop the
    benefit argument in order to make a valid cost-benefit analysis.<br>
    <br>
    Regards,<br>
    -David<br>
    <br>
    <br>
    <br>
    On 2/15/11 2:33 PM, Heyes Graham wrote:
    <blockquote cite="mid:008DECAA-9978-4908-97B8-4A33154B7FB7@jlab.org"
      type="cite">Thanks Mark, that's number overload. I'll make a quick
      pass at comparing this data with what Chip had from a few years
      ago.
      <div><br>
      </div>
      <div>Maybe something by late tomorrow. </div>
      <div><br>
      </div>
      <div>Graham<br>
        <div><br>
          <div>
            <div>On Feb 15, 2011, at 2:24 pm, Mark M. Ito wrote:</div>
            <br class="Apple-interchange-newline">
            <blockquote type="cite">
              <div text="#000000" bgcolor="#ffffff"> Folks,<br>
                <br>
                Find attached a spreadsheet that estimates our computing
                needs. First the caveats:<br>
                <ul>
                  <li>this is not the finished product</li>
                  <li>it has to be translated into terms for Graham's
                    spreadsheet</li>
                  <li>some of the numbers are still guesses</li>
                  <li>PWA is nowhere included</li>
                  <li>there will have to be a GlueX Note on this
                    eventually</li>
                  <li>things could be much better organized in the
                    spreadsheet</li>
                  <li>my spreadsheet skill could use an upgrade</li>
                  <li>the estimates do not distinguish between
                    JLab-resident and non-JLab-resident resources</li>
                  <li>the way we refer to "CPU's" needs to more
                    sophisticated (SPEC-int-like). <br>
                  </li>
                </ul>
                All of these will have to addressed. Still I thought
                that putting this out for discussion now would be better
                than waiting. So here it is.<br>
                <br>
                I am assuming steady state. The idea is that we need to
                do all of these things for each set of data we take
                (take the data, calibrate it, reconstruct it, compact it
                into multiple streams, simulate it, reconstruct the
                simulation...). If we do them all at a rate slower than
                that at which we take the data, we will fall farther and
                farther behind as the years go on. So to avoid that we
                have to keep up with the raw rate. There will be an
                initial ramp up and there may be long will be down
                periods, but eventually we will be doing all of these
                things on each set and I am not accounting in detail for
                the aforementioned edge effects.<br>
                <br>
                Note also that I assume the raw rate for this discussion
                is after a level three trigger, and that the at 10^7 the
                level three rejection rate is 0 and at 10^8 it is a
                factor of ten; i. e., independent of beam rate.<br>
                <br>
                On PWA: if people already have a good way of framing our
                needs in this area, let me know. I haven't looked
                through our notes or web pages on this yet.<br>
                <br>
                  -- Mark<br>
                <br>
                <br>
              </div>
              <span><computing_model.xls></span>_______________________________________________<br>
              Halld-offline mailing list<br>
              <a moz-do-not-send="true"
                href="mailto:Halld-offline@jlab.org">Halld-offline@jlab.org</a><br>
              <a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/halld-offline">https://mailman.jlab.org/mailman/listinfo/halld-offline</a></blockquote>
          </div>
          <br>
        </div>
      </div>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Halld-offline mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Halld-offline@jlab.org">Halld-offline@jlab.org</a>
<a class="moz-txt-link-freetext" href="https://mailman.jlab.org/mailman/listinfo/halld-offline">https://mailman.jlab.org/mailman/listinfo/halld-offline</a></pre>
    </blockquote>
  </body>
</html>