1. Philips Research 1st meeting of project EES.5653 15 June 2015 Alina Albu, m.a.albu@tue.nl TU/e Computer Science, System Architecture and Networking Philips Research Laboratories Eindhoven 1 Quality of Service for In-Home Digital Networks PROGRESS PROJECT EES.5653 Terminal QoS M.A. Weffers-Albu

2. Philips Research 1st meeting of project EES.5653 15 June 2015 Alina Albu, m.a.albu@tue.nl TU/e Computer Science, System Architecture and Networking Philips Research Laboratories Eindhoven 2 Contents Project goals Approach Description of analyzed systems Trimedia Streaming Software Architecture A characterization of streaming applications execution DVD player case study Future work

3. Philips Research 1st meeting of project EES.5653 15 June 2015 Alina Albu, m.a.albu@tue.nl TU/e Computer Science, System Architecture and Networking Philips Research Laboratories Eindhoven 3 QoS in IN-Home Digital Networks Network Aim: provide guaranteed and optimised Quality of Service (QoS) for interconnected real-time embedded systems. Prediction & Optimisation of Performance Attributes: AT, RT, NCS, RU. Terminal QoS: Reliability & Performance Predictability of system.

4. Philips Research 1st meeting of project EES.5653 15 June 2015 Alina Albu, m.a.albu@tue.nl TU/e Computer Science, System Architecture and Networking Philips Research Laboratories Eindhoven 4 Component-based Real-Time Embedded Systems … … … … … Physical Platform Goals Nearly optimised design for optimal resource utilization of the subsystems involved (good performance).  Interference limited - reduced to a minimum through good design practices (good reliability).  Fast integration of pre- designed subsystems.

5. Philips Research 1st meeting of project EES.5653 15 June 2015 Alina Albu, m.a.albu@tue.nl TU/e Computer Science, System Architecture and Networking Philips Research Laboratories Eindhoven 5 Component-based Real-Time Embedded Systems … … … … … Physical Platform Challenges Scarcity of resources  Resource sharing  Low Predictability  Non-guaranteed Reliability & Performance

6. Philips Research 1st meeting of project EES.5653 15 June 2015 Alina Albu, m.a.albu@tue.nl TU/e Computer Science, System Architecture and Networking Philips Research Laboratories Eindhoven 6 Component-based Real-Time Embedded Systems … … … … … Physical Platform Approach Resource requirements  Resource reservations  Virtual Platforms  Guaranteed resource availability while Resource usage restricted to a configured maximum. VP 1 VP 2 VP n-1 VP n

7. Philips Research 1st meeting of project EES.5653 15 June 2015 Alina Albu, m.a.albu@tue.nl TU/e Computer Science, System Architecture and Networking Philips Research Laboratories Eindhoven 7 Component-based Real-Time Embedded Systems Approach 1.Derive the VPs of the subsystems involved by predicting performance quality parameters (NCS, AT, RT, RU) for each of the subsystems. (Specifications in terms of behaviour and performance). 2.Control performance quality parameters - find good practices of design for the subsystems so that their resources needs can be satisfied on the physical platform. Example: Predict the number of context switches (NCS) – the overhead occurring during the execution of a system. Give guidelines for priority assignment such that the NCS is minimized.

8. Philips Research 1st meeting of project EES.5653 15 June 2015 Alina Albu, m.a.albu@tue.nl TU/e Computer Science, System Architecture and Networking Philips Research Laboratories Eindhoven 8 Component-based Real-Time Embedded Systems Approach 3. Resources needs - strongly related to events that occur during the execution of a subsystem.  Repetitive patterns of events => Execution predictable  Identify the patterns of events during the execution of a subsystem… · the conditions under which the events adopt repetitive patterns… · the relations between the patterns of events.

9. Philips Research 1st meeting of project EES.5653 15 June 2015 Alina Albu, m.a.albu@tue.nl TU/e Computer Science, System Architecture and Networking Philips Research Laboratories Eindhoven 9 … EQ FQ EQ FQ C1C1 C2C2 CnCn …     Empty Queue Full Queue Empty Queue Component Processing code  Get Full PacketPut Full Packet Put Empty PacketGet Empty Packet Typical execution scenario of a TSSA component  - get 1 FP from input FQ,  - get 1 EP from input EQ,  - processing,  - put 1EP in output EQ.  - put 1FP in output FQ. TriMedia Streaming Software Architecture

10. Philips Research 1st meeting of project EES.5653 15 June 2015 Alina Albu, m.a.albu@tue.nl TU/e Computer Science, System Architecture and Networking Philips Research Laboratories Eindhoven 10 TriMedia Streaming Software Architecture TSSA components Data driven. Execution determined by: - Availability of necessary input - Priority of component task - Data driven with blocking due to communication with hardware. Execution determined by: - Availability of necessary input - Average blocking time - Time driven. Execution determined by: - Availability of necessary input. (Or NOT) - Priority - Periodicity.

11. Philips Research 1st meeting of project EES.5653 15 June 2015 Alina Albu, m.a.albu@tue.nl TU/e Computer Science, System Architecture and Networking Philips Research Laboratories Eindhoven 11 TriMedia Streaming Software Architecture TSSA components All types. Execution determined by: -Average computation time. -n->m relation between input and output. -If m variable – average m or distribution over time for the values of m. -Average times needed to get each input FP/EP. -Average times needed to produce each output FP/EP.

12. Philips Research 1st meeting of project EES.5653 15 June 2015 Alina Albu, m.a.albu@tue.nl TU/e Computer Science, System Architecture and Networking Philips Research Laboratories Eindhoven 12 A characterization of streaming applications execution. Theorem Let C1, C2, C3, …, Cn be a chain of components communicating through a set of queues as in Figure 1. Provided that the components are designed such that their execution in the chain does not lead to deadlock, and provided that the input is sufficiently long, the execution of the components in the chain will adopt a repetitive pattern after a finite number of steps. Hyperperiod Initialization Phase Stable Phase Finalization Phase

13. Philips Research 1st meeting of project EES.5653 15 June 2015 Alina Albu, m.a.albu@tue.nl TU/e Computer Science, System Architecture and Networking Philips Research Laboratories Eindhoven 13 A characterization of streaming applications execution. Definitions Initialization phase – the interval of time until the execution of the components reaches a repetitive pattern. Stable phase - the interval of time during which the all components execute according to a repetitive pattern. Hyperperiod – the interval of time needed for the execution of the repetitive pattern. Finalization phase – interval of time following the stable phase. The finalization phase starts when the first component does not have input anymore and finishes its execution. During the finalization phase the last transactions in the queues are completed and all the components are stopped

14. Philips Research 1st meeting of project EES.5653 15 June 2015 Alina Albu, m.a.albu@tue.nl TU/e Computer Science, System Architecture and Networking Philips Research Laboratories Eindhoven 14 A characterization of streaming applications execution. Chain: - N data driven components - n->m: 1->1 - priorities in descending order. EQ FQ EQ FQ C1C1 C2C2 CNCN P(C 1 ) > P(C 2 ) > …> P(C N ) … C1C1 C2C2 CNCN … Initialization phase: C 1 : executes until output FQ is filled => C 1 - Blocked (b). C 2 (p)C 1 (b), C 2 (p)C 1 (b), …, until C 2 (b) (FQ filled, EQ empty)C 1 (b), C 3 (p)C 2 (p)C 1 (b) C 2 (b), C 3 (p) C 2 (p)C 1 (b) C 2 (b)… C 3 (p) C 2 (p)C 1 (b) C 2 (b), C 3 (b) C N (p)C N-1 (p)… C 2 (p)C 1 (b)C 2 (b)…C N-1 (b), Hyperperiod Stable phase: C N (p)C N-1 (p)… C 2 (p)C 1 (b)C 2 (b)…C N-1 (b),

15. Philips Research 1st meeting of project EES.5653 15 June 2015 Alina Albu, m.a.albu@tue.nl TU/e Computer Science, System Architecture and Networking Philips Research Laboratories Eindhoven 15 DVD player case study FRead VDecSSEVO EQ FQ EQ FQ FRead VDecSSEVO FQ P(FRead) > P(VDec) > P(SSE) > P(VO) FRead - Data driven with blocking VO -Time driven - 1->2 VDec -Data driven -1->m, m variable SSE -Data driven -1->1

16. Philips Research 1st meeting of project EES.5653 15 June 2015 Alina Albu, m.a.albu@tue.nl TU/e Computer Science, System Architecture and Networking Philips Research Laboratories Eindhoven 16 DVD player case study NCS_hyperperiod(FRead) = 5, NCS_hyperperiod(VDec) = 9, NCS_hyperperiod(SSE) = 8, NCS_hyperperiod(VO) = 8. the total NCS_hyperperiod = 5+9+8+8 =30; In order to validate our results we measure the NCS on a duration of the stable phase equal with 30 hyperperiods. NCS_StablePhaseMeasured = 895; NCS_StablePhaseCalculated = 900;

17. Philips Research 1st meeting of project EES.5653 15 June 2015 Alina Albu, m.a.albu@tue.nl TU/e Computer Science, System Architecture and Networking Philips Research Laboratories Eindhoven 17 Current & Future Work Current Work Proof “Stable State Theorem” in a general case of components types combinations. Provide design guidelines for optimizing the NCS, RU Find patterns in the input stream that can be related to the pattern of execution. Future Work Analyze patterns of memory access, bus utilization Find relations between memory accesses, bus utilization and the pattern of execution. Provide ways for controlling the above patterns. Consider multi-processor platforms.