Guest Lecture TDDD07
Real Time Systems
Real-Time Simulation
Beautiful Real-Time
Patrik Sandahl, Ageing hacker
Ericsson
Outline
› Ericsson
› Real-time simulation for network load testing
› Avoid monolithic runtime architectures
› Beautiful real-time
› Lessons learned
› Final words
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 2
My Definition of Real-Time
› Programs (or systems) that:
– Reacts on events (e.g. timer or a message)
– Produces result within time (the result could be e.g. a calculation, a
message to send or an internal state update)
› Real-time programs often:
– Maintain many concurrent interactions (e.g. a base station connect
to many UE:s or a gaming server is connected to many players)
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 3
Ericsson
› Provider of network equipment
– Radio Base Stations.
– Routers and switches.
– 2G, 3G, 4G, 5G and WiFi.
– Core network.
› Cloud management.
› Data centers.
› Almost all Ericsson products are real-time by heart.
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 4
Real-time Simulation For Network Load
Testing
› User Equipment – UE - are things that connect to a mobile
network.
› Often UE:s are smartphones but can be any kind of
network device.
› In test simulation UE:s will have the same real-time
requirements as for the real UE:s
› A network simulator is a computer able to simulate many
(hundreds or thousands) of UE:s.
› A network simulator also simulate users and applications.
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 5
Real-time Simulation For Network Load
Testing
› Load testing of the 4G/LTE radio base station. Often called
eNodeB.
› In the network testing scenario the eNodeB is the system
under test – SUT.
› The system under test is connected to a mix of real and
simulated UE:s
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 6
Real-time Simulation for Load Testing
Simulated UE:s, simulated users
and simulated IP applications
IP network/
Internet
SUT
Core Network
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 7
LTE UE – subframe synchronization
Period for matching Uplink (UL) and Downlink (DL)
DL-data or UL-grant received at time ‘t’
1 ms
Must match the millisecond in its beginning
at both “receive” and “send”
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 8
DL-ACK or UL-data “on air” at time‘t+4’
1 ms
LTE UE stack
IP
PDCP
RLC
MAC
Synchronized with subframes
at downlink
PHY
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 9
Synchronized with subframes on uplink
Throughput vs. Response Time
› Scenario: Reception of UE downlink data
– LTE UE stack of PHY, MAC and RLC.
– The simulator shall read from the (simulated) radio interface every
subframe.
– In each subframe up to 32 UE:s in the simulator can receive data.
– On the UE downlink side PHY and parts of MAC are extremely
sensitive with regards to timing, but RLC is not ...
– The RLC layer assembles fragments of packets. A work that may
(sometimes but not always) take long time.
– What happens if the real-time sensitive parts are (in runtime)
bundled together with the long running parts?
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 10
Throughput vs. Response Time
RLC: Throughput workload, less time-critical
MAC: Highly time-critical
PHY: Highly time-critical
Completely failed subframe
Processing started late. Time constraints met
Completely successful subframe
Time trigger for subframe – should be close to start
Control returned to the timer event handler
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 11
Throughput vs. Response Time
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 12
Avoid Monolithic Run-time Architectures
› Remedy:
– Separate time critical tasks from (long running) throughput oriented
tasks by deploying them into different processes/threads.
– Make the time critical processes/threads execute at the higher
priority.
– Prefer a message passing interface between the processes/threads.
› Bonus:
– By implementing this strategy you will take a half-step towards a
concurrent and multi-core friendly architecture.
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 13
Avoid Monolithic Run-time Architectures
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 14
Beautiful Real-Time?
› Does it matter if a real-time – or any other - program is
“beautiful”?
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 15
Accidental Complexity
Accidental (or incidental) complexity is complexity that arises in computer programs
or their development process which is non-essential to the problem to be solved.
While essential complexity is inherent and unavoidable, accidental complexity is
caused by the approach chosen to solve the problem.
Accidental complexity is to be minimized in any good architecture, design, and
implementation; excessive accidental complexity is an example of an anti-pattern.
http://en.wikipedia.org/wiki/Accidental_complexity
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 16
Accidental Complexity
› “Any fool can write code that a computer can understand.
Good programmers write code that humans can
understand.”
– Martin Fowler
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 17
Accidental Complexity
› Real-time programs are often concurrent, asynchronous
and event driven.
› But the most common tools used for software development
is best suited for sequential, synchronous and batch
oriented problems.
› This is one major source of accidental complexity.
› One example is “callback hell”, where asynchronous code
is implemented using callbacks (common in Javascript).
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 18
“Callback hell”
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 19
Ways Towards Beautiful Real-Time
› One beautiful solution is using actors/green threads.
– Erlang/OTP.
– Scala (with Akka)
– Haskell
– Enea OSE (not really green threads, but the best you can get if you
need a more “bare bones” C-programming environment)
› Actors allows you to program in a sequential style while
being concurrent.
› The scheduling and dispatching of events is made invisible
by the runtime system.
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 20
Ways Towards Beautiful Real-Time
› Functional Reactive Programming, FRP
– FRP is an emerging discipline which combines concurrency and
event-based and asynchronous systems.
– FRP can be seen as a natural extension of higher-order functional
programming to concurrent systems that deal with distributed state
by coordinating and orchestrating asynchronous data streams
exchanged by actors.
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 21
Master Thesis at Ericsson 2014
› Functional Reactive Programming as programming model
for telecom server software, by Klervie Toczé.
– Link to master thesis
› Presented as poster at ACM Symposium on Applied
Computing in April.
– Link to SAC 2016
Guest Lecture TDDD07 Real Time Systems | Public | © Ericsson AB 2015 | December 2015 | Page 22