1 /** @addtogroup architectures UDP Receptor
3 # UDP Receptor Architecture #
5 The rcpt module's responsibility is to listen to UDP beamformed packets, parse them, and transfer the data
6 within into the data structures used for processing in a timely manner.
8 The diagram below illustrates the mapping that it is expected to make, between the packets and the data structures
9 that are propagated through the pipeline. The illustration only shows a few packets for each chunk, but this is a configurable
10 parameter, and there are more likely to be many hundreds of packets per chunk.
12 UDP Packets : <pre>| 1 | 2 | 3 | 4 | 5 | 6 | 7 | ...</pre>
13 [TimeFrequency] Data structures : <pre>| chunk 1 | chunk 2 | ...</pre>
14 <pre>|----------- time --------------></pre>
16 In this example, the payload from UDP packets 1, 2, 3 and part of 4 map to the chunk 1.
17 The remainder of chunk 4's payload should fill the beginning of chunk 2. The remainder of chunk 2
18 should then contain the data from UDP packets 4, 5, 6 and part of UDP packet 7.
21 [TimeFrequency]: @ref TimeFrequency "TimeFrequency Data Structure"
22 [Context]: @ref panda::Context "A context object carrying state associated with a chunk"
23 release : when a [TimeFrequency] chunk is considered ready for passing down to the pipeline.
26 ## Level 1 Requirements ##
27 For LOW (reference SKA-TEL.CSP.LOW-CSP.PSS-ICD-001):
28 - 8192 data per spectrum
30 - ~10000 samples per second,
31 - 4 polarizations (in consecutive packets)
34 For MID (reference SKA-TEL-CSP-0000020):
36 - 4096 data per spectrum
38 - ~20000 samples per second
39 - 4 polarizations (in consecutive packets)
42 Current design has reception of 2 beams per node on a 10Gbps link.
44 ## Low Level Design Requirements ##
46 ### Pipeline Constraints
47 - All [TimeFrequency] chunks must be released in correct time order (i.e. chunk 1 must be released before chunk 2).
48 Rationale: This requirement allows us to reduce the complexity of the pipeline as all modules will be able to assume
49 time ordering. No attempt has been made to remove this constraint or analyse the consequences of doing so.
50 - [TimeFrequency] chunks must be released in a timely manner
51 Rationale: The data processing pipeline must be fed at a rate that can keep the compute resources utilised. Bunching
52 up of the throughput data may put unreasonable demands on the compute.
54 ### The UDP packet format shall be encapsulated.
56 - It is easy to change with evolving system requirements without effecting the rest of the code.
57 - A single source of these parameters
59 ### Out of Order Packets
60 - Packets may arrive out of order (UDP specification)
61 - If a packet arrives after the chunk it corresponds to has already been released by the rcpt, then it shall be ignored
63 - to keep the chunks ordered in time, they must be released in order. Ordered chunks are an assumption of the pipeline.
64 - the corresponding chunk will already of been released (or in the process of being released)i with the packet missing handler called.
65 - packets will have a sequence number embeded within it
66 Rationale: allow us to associate each packet with a specific place in a data chunk
69 - Packets may be missing
70 - All missing packets corresponding to a chunk, must be explicitly notified to some handler before it is released.
71 That handler must be free to update part or all of the data in the chunk as it sees fit.
73 The exact behaviour of how to compensate for missing packets in the data is undefined and open to research.
74 Using missing packet handlers allows us to try many stratergies without redesigning the whole rcpt component:
75 * In line processing :* we can perform some small scale calculations inside the handelr directly.
76 Compensation algorithms typically might want to access the rest of the data in the chunk to perform, for example, an interpolation.
77 * Queued processing :* we can use the handler to queue async processing tasks. This will require us to use some mechanism to stop the chunk being released (and
78 future chunks to maintain ordering) until the async tasks are completed.
79 * In pipeline processing:* If more data than this is required (e.g. maintianing running averages etc. then this handler could be used to flag the data
80 (using a suitable data structure chunk that supports flagging) deferring these decisions and processing for the main pipeline.
81 This has the advantage of leaving decisions to the pipeline stage (different pipelinesi and/or data conditions might prefer different stratergies).
82 The disadvantage is that we may have to use resource to iterate over the flags.
84 - Any incomplete [TimeFrequency] chunk on rcpt halt (or destruction) shall be suitably resized to accomodate the existing data and released.
86 The rcpt should not be making decisions about wether to use or abandon data. Its job is to pass on everything it is got in a consistent
89 ### Implementation Constraints
90 - The size of the [TimeFrequency] data chunks are configurable but can be considered to be constant for each run.
91 Rationale: This is simply a consequnece of the current implementation that maps the packets onto specific chunks.
92 No attempt has been made to remove this constraint.
94 - the first packet recieved after starting shall correspond to the beginning of the first chunk
95 Rationale: The chunks start time is not required to be on any boundary, so the first packet is most probably going to correspond
96 to the first data we wish to process.
97 - any [TimeFrequency] chunks previous to this first chunk shall be ignored
98 Rationale: it would be too expensive to realign an exisitng chunk, and we are unlikely to receive many other packets < first packet received
100 ### COnfiguration Constraints
101 - Number of threads used shall be configurable
102 Rationale: allows us to easily experiment for performance tuning
103 - The parameters of the chunk (number of samples, number of channels) shall be configurable.
104 Rationale: Allows us to experiment with different values for maximum throughput. These parameters may vary
105 with different data ranges, or other parameters.
106 - The UDP socket to listen to shall be configurable.
107 Rationale: we are expecting multiple beams on each node, each with its own rcpt module listening on a different port
109 ## Architecture Description ##
110 Previous experience with streaming UDP data from LOFAR and Alfaburst indicates that a single thread cannot process a real time data stream.
111 The solution is to use multiple-threads, however this turns a relatively simple problem into something rather more complex.
113 The rcpt has a single thread that responds to UDP packets arriving on the socket.
114 This thread creaates a context object, which allows access to the appropriate data chunk to which that packet
115 should belong as well as its relative location inside it.
117 The context is then passed onto a thread pool. As a thread becomes available it takes the packet and the context information to copy the payload into the chunk.
122 ### Measured Performance ##
123 **/@}/* // end doxygen group