ATLAS RoB-in project -- design issues

Event Fragment Indexing

Main index table

The events are indexed by using the least significant 10 bits of the event ID as an offset into a fixed size data structure. This allows for a span of 1024 between the lowest and highest event ID's in the buffer (or ~10ms @100kHz), we expect to have on average ~100 events buffered at any one time.

Secondary list(s)

In the new RoB-in prototype it is proposed to supplement the main index table strategy with secondary lists for longer lived events.

Releasing fragments

Fragments are released by writing their page numbers back on to the free page FIFO. If the fragment was still indexed in the index table, its entry is marked as free. If it was on the secondary list its slot number is placed on the list of spare slots.

Unresolved points

Handling of "forgotten" fragments

Deletion of "forgotten" fragments after a timeout is an inherently dangerous policy. There may well be events with significant latency in the level 2 system and in the case of sequential processing with a "reject as soon as possible" policy as suggested by Saclay, the longer an event is in the buffer the more tests it has passed!

It should be a general principle that buffer managers do not autonomously destroy data. There are at least 2 solutions to the "forgotten" fragment problem which don't violate this principle.

  1. The buffer manager could ask the supervisor for clarification of the status of the fragment (has this event been rejected?).
  2. The supervisor could periodically send special records saying "all current events are in the range nnn - mmm". Allowing the buffer manager to remove fragments of events ouside the current range.

GJC / gjc@hep.ucl.ac.uk