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

Respond to comments on LDM-612 in RFC-556

    XMLWordPrintable

Details

    • Story
    • Status: Done
    • Resolution: Done
    • None
    • None
    • None

    Description

      RFC-556 raised several points that need to be incorporated; this ticket branch will hold them as part of the CCB approval.

      Attachments

        Issue Links

          Activity

            ebellm Eric Bellm added a comment -

            SAC comments from mstrauss, by email:

            -Section 2.2.4: I am still confused by this notion of 100 simultaneous users. You are limited by bandwidth, so I think this is a limit on how many alerts can go out via the filter at any given time, not the number of filters that individuals are running at any given time. Is that correct? I could imagine hundreds or thousands of people uploading filters that would be triggered by rare events of various sorts (e.g., optical counterparts to GRBs or gravitational wave events); the bandwidth that these events would use would be tiny.
            On the other hand, one sloppily written filter that ends up triggering on a substantial fraction of all the alerts could completely eat up the bandwidth, precluding everybody else from the system. How do we deal with such a situation.

            -The very last paragraph of this document makes reference to the possibility that brokers will be reviewed, and new brokers added, as the survey continues. This is an important point, and I think needs to be made earlier. In Section 4.6, I would add a subsection taking about the longevity of the proposed broker and plans for upgrades/improvements through the survey based on the changing technological and scientific landscape and what is learned from the LSST datastream itself.

            mstrauss's annotated PDF is attached.

            ebellm Eric Bellm added a comment - SAC comments from mstrauss , by email: -Section 2.2.4: I am still confused by this notion of 100 simultaneous users. You are limited by bandwidth, so I think this is a limit on how many alerts can go out via the filter at any given time, not the number of filters that individuals are running at any given time. Is that correct? I could imagine hundreds or thousands of people uploading filters that would be triggered by rare events of various sorts (e.g., optical counterparts to GRBs or gravitational wave events); the bandwidth that these events would use would be tiny. On the other hand, one sloppily written filter that ends up triggering on a substantial fraction of all the alerts could completely eat up the bandwidth, precluding everybody else from the system. How do we deal with such a situation. -The very last paragraph of this document makes reference to the possibility that brokers will be reviewed, and new brokers added, as the survey continues. This is an important point, and I think needs to be made earlier. In Section 4.6, I would add a subsection taking about the longevity of the proposed broker and plans for upgrades/improvements through the survey based on the changing technological and scientific landscape and what is learned from the LSST datastream itself. mstrauss 's annotated PDF is attached.

            People

              ebellm Eric Bellm
              ebellm Eric Bellm
              Eric Bellm, Leanne Guy
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Jenkins

                  No builds found.