Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-3611

Prepare for Winter 2016 work on LSE-68

    XMLWordPrintable

    Details

      Description

      Use a session at the LSST 2015 all-hands meeting to prepare for LSE-68 work in the Winter 2016 cycle.

        Attachments

          Issue Links

            Activity

            Hide
            gpdf Gregory Dubois-Felsmann added a comment -

            Planned a session on LSE-68 interface maturation at the August 2015 All Hands meeting.

            https://project.lsst.org/meetings/lsst2015/agenda/tuesday/camera-data-acquisition-interface-maturation-lse-68

            Preliminary discussions with Mike Huffer led to the following topics being planned:

            • visit versus image interface
            • O/S supported by DAQ interface
            • Physical requirements on DAQ host machines
            Show
            gpdf Gregory Dubois-Felsmann added a comment - Planned a session on LSE-68 interface maturation at the August 2015 All Hands meeting. https://project.lsst.org/meetings/lsst2015/agenda/tuesday/camera-data-acquisition-interface-maturation-lse-68 Preliminary discussions with Mike Huffer led to the following topics being planned: visit versus image interface O/S supported by DAQ interface Physical requirements on DAQ host machines
            Hide
            gpdf Gregory Dubois-Felsmann added a comment -

            Session was held on Tuesday August 18, 2015.

            Discussion covered:

            • OS support for the client (currently moving to RHEL7, will follow that line)
              • DAQ client will not require any kernel extensions (e.g., no zero-copy IP stack)
            • Timing of Summit CDS delivery (1-2 years before full camera)
            • Organization of buffer into "directories" with different fates in DM
            • Deletion policy
            • The fact that the DAQ system is not responsible for metadata (e.g., EFD) rendezvous
            • Discussion of Commissioning Cluster use cases. Do all CC nodes need to be on the DAQ network? To what extent can CC work rely on DM having already pulled images down to the Base Center buffer?
            • Availability of a CDS at NCSA (1.5-2 years from now)
              • Will probably go into an NCSA lab, not the NPCF
            • Discussion of making visits known to the DAQ and making the buffer searchable by visit
              • This would mean visit === image sequence. DM is not comfortable with this constraint.
              • Without doing this, a visit could be "sliced" by the buffer filling up after the first image
              • Probably OK with this
            • Discussion of the need for a naming policy that covers all test stands

            Mike is not yet ready to make a detailed API proposal. That is probably a prerequisite for substantive Phase 3 completion - look at all the requirements and see if they are sensibly implementable.

            Show
            gpdf Gregory Dubois-Felsmann added a comment - Session was held on Tuesday August 18, 2015. Discussion covered: OS support for the client (currently moving to RHEL7, will follow that line) DAQ client will not require any kernel extensions (e.g., no zero-copy IP stack) Timing of Summit CDS delivery (1-2 years before full camera) Organization of buffer into "directories" with different fates in DM Deletion policy The fact that the DAQ system is not responsible for metadata (e.g., EFD) rendezvous Discussion of Commissioning Cluster use cases. Do all CC nodes need to be on the DAQ network? To what extent can CC work rely on DM having already pulled images down to the Base Center buffer? Availability of a CDS at NCSA (1.5-2 years from now) Will probably go into an NCSA lab, not the NPCF Discussion of making visits known to the DAQ and making the buffer searchable by visit This would mean visit === image sequence. DM is not comfortable with this constraint. Without doing this, a visit could be "sliced" by the buffer filling up after the first image Probably OK with this Discussion of the need for a naming policy that covers all test stands Mike is not yet ready to make a detailed API proposal. That is probably a prerequisite for substantive Phase 3 completion - look at all the requirements and see if they are sensibly implementable.

              People

              Assignee:
              gpdf Gregory Dubois-Felsmann
              Reporter:
              gpdf Gregory Dubois-Felsmann
              Watchers:
              Gregory Dubois-Felsmann, Mike Huffer
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins

                  No builds found.