Latency is defined as the time between when an event is triggered and when it arrives on an analyzer's disk. Data from the main analysis tags (high multiplicity, upgoing track, cascade/tau) should have a 1-2 week latency, which includes possible further processing/filtering in the north. Monitor data should have a latency of less than 24 hrs. Supernova data should have as close to zero latency as possible. One way to implement a very short latency time is to use the Iridium system (if it remains available). Data volumes for supernova triggers are small enough to make this feasible. IceCube can then be a full-fledged participant in SNEWS, the Supernova Early Warning System [48].
Possible uses of 24/7 low-bandwidth coverage beyond SNEWS include IceCube monitor data. This would have the clear advantage of allowing us to keep close track of detector performance, including during times when the winter-overs would be sleeping. This coverage would also be very handy for small system maintenance tasks and for sending alarms to to the winterovers. Obviously, the South Pole becomes much less remote with this kind of coverage.
After the first six-string year, the full raw data has a latency of at least a year, corresponding to the movement of tapes from the Pole to the north. For IceCube design purposes, the latency of this data sample should be considered infinite since the resources needed to use it are not in the current budget.
Another latency issue arises due to calibration constants (e.g., geometry) which will be needed by the Pole filters. We envision three categories of constants:
