Scui queue filling

Version 2 - Written 22 Dec 2011

Location

No written procedure on Docushare.
Further detail: http://www.mssl.ucl.ac.uk/swift/docs/procedures/

Deal with a full scui queue.

The UDS will normally be periodically checking "errors" lists on http://twins.swift.psu.edu/hk.html or http://msslje.mssl.ucl.ac.uk/hk.html. If TMALI queue full errors, SCUI queue full errors or STNUMFRMS_SUVOT errors are seen, the "counts" graphs on http://twins.swift.psu.edu/hk.html or http://msslje.mssl.ucl.ac.uk/hk.html should also be checked more regularly to find out when and how the queues were filling. Obviously, you'll have to wait until after a MAL pass and after an ITOS playback before you'll see this information: the page updates about every 6 hr.
A STNUMFRMS_SUVOT limit violation indicates that there's a real problem with the amount of data UVOT has produced. This will be a SERS email/text alert.

The TMALI queue often goes up and often even goes up to 100% for a time. This is expected. This will look like

PKT_20070581852_itos.log:02 07-058-23:53:07   YEL_VIOL: Yellow high violation D_TMALI_QDEPTH raw = 59789916 at 07-058-17:07:38.24146

The SCUI queue can also go up and even hit 100% and this is OK for a few minutes (common during GRBs) but if it is staying up near 100% for most of the orbit, each orbit, there may be event modes with a high countrate (high background or lots of stars like the SMC) or too many multi-filter uvotmodes (like 0x20ed) per orbit.
```
PKT_20070581852_itos.log:02 07-058-23:53:07   YEL_VIOL: Yellow high violation D_SCUI_LPQDEPTH raw = 46126721 at 07-058-17:07:38.24146
```
Also periodically look at the "frames" graph on http://twins.swift.psu.edu/frames.png or http://twins.mssl.ucl.ac.uk/frames.png. If this is not following the usual sawtooth pattern and suddenly getting higher, this indicates a scheduling problem with too many event mode exposures, an event mode exposure with too high a count rate or too many multi-filter uvotmodes in use that orbit. If the number of frames goes above 100 000 the UDS will be paged.
If the SCUI is filling up and not emptying and it is decided that action is worth taking (as it will only get worse with the current PPST) it best to stop the UVOT response to PTs and allow ATs using:
```
start icu_enable_at
```
and then when the queues are empty and the PPST is not likely to cause trouble again use:
```
start icu_enable_at_pt
```
to re-enable the PT response (and keep the AT response).