Notions on Real-Time Databases and
Quality of Service
Real-time databases
Mikael Asplund
Real-Time Systems Laboratory
Department of Computer and Information Science
Linköping University, Sweden
The lecture notes are partly based on lecture notes by Calin Curescu, Jörgen Hansson,
and Thomas Gustafsson. These lecture notes should only be used for internal teaching
purposes at Linköping University.
Notions on Real-Time Databases andQuality of Service
Mikael Asplund
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
2
Usage
Motivation for real-time databases
• Fact1: The amount of information that is handled by realtime systems increases, motivating the need for database
functionality
– As opposed to ad hoc techniques and internal data
structures
– Related fact: Development costs of RTS are very high!
• Fact 2: Conventional databases do not give real-time
guarantees.
• Fact 3: Tasks and transactions have both similarities but
also distinct
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
3
Sources of unpredictability
4
What’s a real-time database?
• Database Systems:
– Dynamic paging and I/O
– Data and resource conflicts
– Transaction aborts
• rollbacks/restarts
– Transaction execution time
• A real-time database (RTDB) ensures
– predictable response, and
– application-acceptable levels of
• External consistency
• Temporal consistency
• Logical consistency
• Atomicity
• Permanence
• Distributed Databases:
– Network communication
– Distributed commit processing
• Distributed rollbacks/restarts
– Site failures
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
• A database system facilitate description of data
maintenance of correctness and integrity of data efficient
access to data correctness of transaction execution.
5
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
6
Example: Engine Control Unit
Applications
•
•
•
•
Air Traffic control
Command Control Systems
Manufacturing Plant
Navigation and Positioning Systems
– Automobiles, airplanes, etc.
• Network Management Systems
• Telecommunication
– Mobile phones, etc.
• Training Simulation System
– Pilot training, etc.
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
7
ACID Properties
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
8
Temporal constraint on transactions
• Atomicity
– An atomic transaction is a database transaction which either
completely occurs (commits), or has no effects (rolled back).
• Consistency
– A consistent transaction is one that does not violate any
integrity constraints during its execution.
• Isolation
– The changes made by a transaction are not visible to other
simultaneous transactions on the system until its completion.
• Durability
– Transactions that are successfully committed will survive
permanently and will not be undone by system failure.
• Execution Time of Transactions
– texec= tdb + tI/O + tint + tappl + tcomm
– tdb = processing of DB operations
– tI/O = I/O processing
– tint = transaction interference
• data conflicts, transaction restarts
– tappl = non-DB application processing - optional
– tcomm = communication time - optional
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
9
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
10
AVI
Temporal Constraints on Data
• External consistency
– State of environment and reflection in DB
– Absolute Validity Intervals (AVI)
– d : (value, avi, ts)
• ts = time of observation
– (current_time - ts) ≤ avi
• Temporal consistency
– Among data used to derive other data
– Relative Validity Intervals (RVI)
∀d’ ∈ R , |ts - ts’| ≤ rvi
– d ∈R, R – relative consistency set
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
11
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
12
RVI
Tasks vs. transactions
• Tasks
– Are generally designed to be nonterminating cooperative
– Critical regions / rendez-vouz – i.e. not serializable
– Wait primarily/only for other tasks
– Run-time behavior statically predictable
• Transactions
– Are always designed to terminate
– Require isolation in order to ensure consistency – i.e.
serialisable
– Wait for completion of I/O events (and possibly other data
objects)
– Dynamic run-time behavior depends on data values etc.
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
13
Tasks vs. transactions
• Tasks
– Resources accessed by more than one task in a RTS are few
in number
– Resources are generally known at design time.
14
Conventional vs. rt correctness criteria
• Conventional DBS
– Logical consistency
– ACID properties
• Real-Time DBS
– Logical consistency
– ACID properties (may be relaxed)
– Enforce time constraints
• Transactions
– External consistency
• Absolute validity interval (AVI)
– Temporal consistency
• Relative validity interval (RVI)
• Transactions
– Number of resources (data objects) is very large
– Resources not known at design time
– Usually the database is normally much larger than its active,
in-use subset, at any moment.
– Very low probability of conflict between transactions.
• Potential conflict is high
• Actual conflict is low
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
15
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
Distinct types of transactions
• Write-only transactions
– Store sensor data in DB
• e.g. temperature
– Monitoring of environment
– Ensure external consistency
16
Update transactions
• Triggering of transactions to refresh data items
– Refresh data items before they are used
• Triggering criterion
• On-demand updating can be either
– Consistency-centric, or
– Throughput-centric
• Update transactions
– Derive new data and store in DB
– Based on sensor data
• Read-only transactions
– Forward data to actuators
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
17
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
18
Transactions: concurrency control
Pessimistic concurrency control
• Optimistic (OCC)
• Locks the data it wants to use
• Pessimistic (PCC)
• Two-Phase Locking (2PL)
– all locking operations precedes the first unlock operation
in the transaction
– expanding phase (locks are acquired)
– shrinking phase (locks are released)
• Speculative
• Exploit data similarity
• Allows deadlock
• Allows priority inversion
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
19
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
2PL priority inversion
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
21
Possible strategies
20
2PL deadlock
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
22
Optimistic concurrency control
• No checking of data conflicts during transaction execution
– Read phase
• Read values from DB
• Updates made to local copies
– Validation phase
• backward validation or forward validation
• conflict resolution
– Write phase
• if validation ok then local copies are written to the DB
otherwise discard updates and (re)start transaction
• Non-blocking
• Deadlock free
• May need conflict resolution
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
23
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
24
OCC example
OCC: validation phase
• If a transaction Ti should be serialised before a transaction
Tj, then two conditions must be satisfied
• Read/Write rule
– Data items to be written by Ti should not have already
been read by Tj
• Write/Write rule
– Ti’s should not overwrite Tj’s writes
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
25
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
26
Overview
• General QoS concepts
Quality of Service
• Enforcing QoS in IP networks
• Allocation Optimisation
• Conclusions
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
27
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
Why care about QoS?
• Nowadays communication networks (Internet, Wireless)
support several types of applications:
• Voice Service, Audio Phone
• Video conferences
• Video on Demand, Interactive Multimedia
• Email, SMS
• Remote login, e-commerce, online banking
• File Transfer Services (FTP, HTTP download)
A QoS definition
• Performance assurance
– Applications have different requirements
• Video conference – strict bandwidth and delay
requirements
• FTP – no strict requirements
– System should provide guarantees
• Service differentiation
– Network has to differentiate between applications and
offer the right service
• E.g: Videoconference more important than FTP
• Applications can work at different QoS levels
• User requirements (payment) can also vary
• Only one type of service: best-effort
• All packets are treated similarly – FCFS basis
• What if the network gets overloaded?
• Can we prevent?
• Can we control?
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
28
29
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
30
Providing QoS
QoS parameters
• By Allocating Resources
– CPU (application scheduling on the hosts)
– Network link bandwidth (packet scheduling)
– Memory (packet buffers, RAM pages)
• Enforcement level (low)
– bandwidth, delay, jitter, packet loss rate, energy
consumption, CPU time
• Application level (high)
– Picture quality, compression levels, viewing size
– Security, redundancy
• Frameworks and Mechanisms to enforce resource
allocation
– Intserv, Diffserv, etc.
• User satisfaction
– Perceived benefit (utility)
– Willingness to pay a certain amount for a certain service
• Performance Optimisation (policy level)
– How to allocate/utilise resources in the best way
– Traffic engineering
• QoS – based routing
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
31
Classic Real-time Systems
• Resource allocation -- Scheduling
• Resource -- CPU time
• QoS parameters
– CPU utilisation
– Deadlines
– Jitter
32
QoS enforcement in IP networks
• Control plane
– QoS routing (path establishment)
– Admission control
– Resource reservation
– Corrective control of congestions (overloads)
• Data plane (packet level)
– Classifier
– Meter
– Shaper
– Queue
– Scheduler (FCFS, WFQ, PQ, EDF)
• Optimisation criterion
– Construct a feasible schedule (if possible)
• RT Scheduling is subset of QoS allocation
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
33
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
Internet QoS frameworks: Intserv
• Session must first declare its QOS requirement and
characterize the traffic it will send through the network
– T-spec: defines the traffic characteristics
• Token bucket – average rate, burst size, burst rate
– R-spec: defines the QOS being requested
• Rate, delay
34
Token Bucket Shaping
• Token Bucket mechanism, provides a means for limiting
input to specified Burst Size and Average Rate.
• Bucket can hold b tokens;
• tokens are generated at a rate of r token/sec
– unless bucket is full of tokens.
• Over an interval of length t, the size of all admitted packets
is less than or equal to (r t + b).
• A signalling (reservation) protocol
– Needed to carry the R-spec and T-spec to the routers where
reservation is required
– Resource Reservation Protocol (RSVP)
• Admission control
– At every router
– Depends on: T-spec & R-spec & already allocated resources
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
35
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
36
T-spec and R-spec
• T-spec (traffic specification)
– A token bucket specification
• token rate - r
• bucket size - b
• peak rate - p
• maximum packet size - M
• minimum policed unit - m
Intserv Classes
• Guaranteed Service
– Deterministic guarantees
• On bandwidth and delay
• Admission control based on worst case
– Could be used for hard real-time applications
• Controlled Load
– Statistic guarantee
• Admission control based on average
• Only T-spec used
– Simulates a “lightly loaded best effort traffic”.
• R-spec (reservation specification)
– Service Rate – R
• The bandwidth requirement
– Slack Term – S
• The delay requirement
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
37
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
QoS routing
BW
20,
D=
B
=9
0
D
,B
=5
W
0
=9
D = 14, BW = 90
D
W
,B
=5
D = 10, BW = 90
0
=9
, BW
D=3
Intserv Shortcomings
• Scalability
– Maintaining “flow states” by routers in high speed
networks is difficult due to the very large number of flows
20
=5
,B
W
D=
3, B
W=
• Complicated signalling in RSVP
– Admissions, reservations, timeouts
= 90
D
5, B
W=
90
A
5
=5
D = 7, BW
D=
38
• Rigid service models
– Intserv has only two classes
= 105
• A “relative” notion of service might be desired
• Instead of T-spec and R-spec
• Constraints
– total delay < 25; available bandwidth > 30
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
39
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
Diffserv
• Complex functionality in edge routers
– Classification:
• marks packets according to some specified rules
– Traffic Conditioning:
• may delay and then forward or may discard
40
Per-Hop-Behaviour (PHB)
• Diffserv does not specify service classes
• instead provides functional components for creating them
• Proposed PHBs
– Expedited Forwarding
• Simple functionality in core routers
– Class-based forwarding
• Per class instead of per flow
– No state info must be maintained in the routers
• Big advantage over Intserv
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
• Absolute assurance
• Always prioritised
• Admission control
– Assured Forwarding
• Relative assurance
41
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
42
Performance Optimisation
• Intserv & Diffserv provide the framework & mechanisms
Wireless Networks
• Always resource constrained compared to wireline
– Limited spectrum, energy, processing power
– but not the intelligence.
• Optimise system-wide performance by
• But also more complicated
– Interference
• A node’s bandwidth is influenced by neighbour nodes
– Mobility
• Old routes break, other are formed, resource availability
can quickly change
– Hard to offer guarantees
– Allocating resources to the “best” connections first
– Proposing the “best” route to a new connection
• Shortest path routing usually creates uneven load
• Global vs. local allocation decisions
– Only knowing the status of the whole network one can
hope for a best allocation
• unrealistic in a large, open, dynamic network
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
43
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
Concluding remarks
• New hot area: Sensor Networks
– Tradeoffs between performance and energy consumption
• Service Types
– Constant bit rate (CBR)
– Constant Rate, delay guarantees
• Pricing schemes from economics
– To calculate the costs and benefits of using a certain
resource, used for optimisation
– Variable bit rate (VBR)
– Rt-VBR – avg. rate, burst rate, delay guarantees
– Nonrt-VBR – avg. rate, burst rate guarantees
– Available bit rate
• The more restrictive and complex environment, the higher the
need for QoS management
– Minimum rate guarantees, uses network feedback for higher rates
– Unspecified bit rate (UBR)
45
Reading
• Chapter 1 from Wei Zhao book about QoS
• Section 1 (Introduction) from Ramamrithan paper
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
ATM & QoS
• Asynchronous Transfer Mode – network technology
– Small, fixed size packets (cells)
– Connection oriented
– Adm. ctrl. + res. alloc. at connection setup
• Active research is going on concerning performance
optimisation
– Both in wireline and wireless networks
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
44
47
Notions on Real-Time Databases and Qualiry of Service
Mikael Asplund
46