Towards a Reconfiguration Service

for Distributed Real-Time Java*

Pablo Basanta-Val

Marisol García-Valls

DREQUIEM LAB.

Universidad Carlos III de Madrid

* This work has been presented at REACTION Workshop 2012. Collocated with IEEE RTSS 2012 Symposium at Puerto Rico

Outline

• Context & contribution

▫ Online scheduling & open systems

• The reconfiguration service

▫ Distributed Java approach

Overview of real-time parameters

Reconfiguration points

▫ Contributed Reconfiguration service

Proposed Extensions

Evaluation of a policy

• Conclusion and future work

2

REACTION WORKSHOP

Context & Introduction

• Many real-time systems consider admission control as a offline line feature

▫ Clear advantages like exact algorithms

• However more and more systems are dynamic and applications may appear and disappear

▫ Real-time CLOUD computing or real-time Open Systems

▫ How to make dynamic admission control efficient !

• Admission control for real-time performance

▫ Exact algorithms tend to be very costly !

3

REACTION WORKSHOP

Context & Introduction A real-time reconfiguration service in a

nutshell • A Real-Time Reconfiguration Service for Distributed Real-

Time Java

▫ Idea: To define a template for reconfiguration in distributed real-

time Java applications

It may customized for different applications

▫ Benefits: Real-time Java community, and DRTSJ (The Distributed

Real-Time Specification for Java)

▫ Contribution: Extensions to current APIS

Real-time Reconfiguration Service

Example global partitioner algorithm with some performance results

REACTION WORKSHOP

4

Distributed Real-Time

Java middleware • Based on DREQUIEMI

▫ Layered approach for Distributed Real-time Java

Infrastructure

Distribution

Common Services

Applications

• Currently, it consists of three main technologies extending RTSJ

▫ Based on Java’s RMI, {RT}-CORBA , and TT tenets

5

REACTION WORKSHOP

Distributed RT Java QoS/RT configuration parameters

• Based on the model proposed by RTSJ

• They characterize

▫ Application release pattern

▫ Scheduling specific parameters

▫ Memory parameters

▫ Processing group options

▫ Other internal decisions

Thread-pool

Connection Pool

Memory Area pool

QoS parameters in

distribution layer

Meaning in DREQUIEMI

Scheduling Parameters

«Priority»

Priority used during the up-call at the

server

Release Parameters

«Release Time, Period,

Deadline, and Cost»

Invocation pattern at the server

according to the real-time scheduling

theory

Processing Group

Parameters

«Release Time, Period,

Deadline and Cost»

Group patterns at the server according

to the real-time scheduling theory

Memory Parameters Parameters used by the garbage

collector at the server

Thread Pool Thread pool used at the sever to

manage remote invocations

Connection Pool Connection pool used at the client to

carry out the remote invocation

Memory Area Pool Memory area pool used at the server to

accept remote invocations

port The IP port on which the remote object

is accepting incoming messages

RemoteStub The stub with the remote reference to

the remove object

EventCommonInt.

A remote object which allows

subscriptions and may be remotely

triggered.

6

REACTION WORKSHOP

Reconfiguration points

• Three reconfiguration points in Distribute RT Java

▫ Resources, distribution, and components

• Contributed reconfiguration applies to resource management/rescheduling:

▫ Location of tasks in Remote Nodes

▫ Processor, network, and memory

REACTION WORKSHOP

7

reconf

Reconfiguration Service Introducing Network parameters

• RTSJ does not support the network

▫ Centralized systems only!

• But it could be extended with it

▫ Adding new classes to the RTSJ

• Network parameters example:

▫ Priority for the IP packet (router)

▫ A maximum bit rate

▫ A complete RSVP stack, etc.

Scheduler

DistributedScheduler

Real-time Java

Distributed Real-time Java

uses

MemoryParameters

SchedulingParametersuses

3ResourcesSchedulerNetworkParameters

uses

Serializable

ReconfigurationService

uses

Schedulable

RemoteSchedulable

8

REACTION WORKSHOP

Reconfiguration Service Distributed Scheduler

• Based on RTSJ’s scheduler

• It allows invokers to assign schedulables to the task set

▫ Allocation

▫ Deallocation

• Each schedulable defines:

▫ Release parameters,

▫ memory parameters

▫ Processing parameters

▫ Network Parameters

▫ Scheduling Parameters

01: public interface DistributedScheduler

02: extends java.rmi.Remote {

03: boolean addIfFeassible(

04: Schedulable s,

05: ReleaseParameters rs,

06: MemoryParameters mp,

07: ProcessingGroupParameters pgp,

08: NetworkParameter np )

09: throws RemoteException;

10: boolean removeIfFeassible(Schedulable s)

11: throws RemoteException;

12:}

9

REACTION WORKSHOP

Reconfiguration Service Reconfiguration Service

• To introduce reconfiguration on the previous system

▫ The reconfiguration process is modelled as a real-time schedulable

• Based on that, the reconfiguration service ▫ reconfiguration service =

DistributedScheduler

+ scheduling info for DistributedScheduler

▫ The ReconfigurationService executes on top of a scheduler.

01: public interface ReconfigurationService extends

02 DistributedScheduler, Schedulable{

03: MemoryParameters getMemoryParameters()

04: throws RemoteException;

05: ProcessingGroupParameters

06: getProcessingGroupParameters()

07: throws RemoteException;

08: ReleaseParameters

09: getReleaseParameters()

10: throws RemoteException;

11: Scheduler getScheduler();

12: throws RemoteException;

13: SchedulingParameters getSchedulingParameters();

14: throws RemoteException;

15: NetworkParameters getNetworkParameters();

16: throws RemoteException;

17: void setMemoryParameters(MemoryParameters mp)

18: throws RemoteException;

19: void setProcessingGroupParameters(

10

REACTION WORKSHOP

Tested Scheduling Policy (1/4) End-2-End Flow-Shop

• Flow-Shop

▫ Defined as a sequence of subtasks that execute in order (i.e. with precedence constraints).

• Each end-to-end transaction (Γj | j 1..M) is defined as follows:

▫ Global deadline (Dj)

▫ A global period (Tj)

▫ A set of jn schedulable segments {Sj1….Sj

n}

A local execution priority (Pjn) for each end-to-end transaction segment

(Sjn).

A local worst-case execution time (Cjn) for each segment (Sj

n).

11

REACTION WORKSHOP

Tested Scheduling Policy (2/4) Some simplifications

Client1/

2Net1 serv1 Net2

Client

2/2

client router server

Local Priority (P)

and Cost (C)

Global Deadline (D) and period (T)

Local Priority (P)

and Cost (C)

Local Priority (P)

and Cost (C)

Local Priority (P)

and Cost (C)

Local Priority (P)

and Cost (C)

• Utilization based test

• The evaluation assumes T=D and fixed priority (RMA) assignment

▫ Each local deadline is calculated

• Each node runs a periodic enforcer

▫ It allows analyzing each flux in a node as local.

REACTION WORKSHOP

12

Tested Scheduling Policy (3/4) Partitioning tasks on different JVMs (T=D)

1. Global check based on global utilization

To check if it fits or not in advance

2. Sort all your tasks according to utilization

To avoid allocation anomalies

3. Assign a task to a Node (bin packing)

To select a node

4. Calculate your effective priority

To use the RTSJ 28 priorities only

5. Deploy tasks in each different node

Using a distributed scheduler

13

REACTION WORKSHOP

1.Feasibility

2.Sort

3. Assign.

5. Remote Deploy

4. Priority calculus

Fail

Ok

Tested Scheduling Policy (4/4) Additional code to be added to the policy

01: interface FlowShopSchedulables extends Schedulable{02: Vector getAllShedulable(); //It returns all sch. 03: }

01: interface PriorityBasedReconfigurationService02: extends ReconfigurationService{03:}

• The tested policy requires: ▫ A new subclass for a schedulable entity

▫ A new subclass for the reconfiguration system

• In this article we provide: ▫ FlowShopSchedulables for each transaction

▫ PriorityBasedReconfigurationService to encapsulate the scheduler

REACTION WORKSHOP

14

Evaluation Infrastructure

• One central node to deploy the system

▫ In charge of the reconfiguration service

• DREQUIEMI

▫ For execution

• A real-time router

▫ IP priority enforcement

Managerrouter

JVM1

JVM2

JVM N

A1 A2

...

796 Mhz

796 Mhz

Node 1

796 Mhz

300 Mhz

100 MbpsDREQUIEMI

Jtime (TimeSys)

PriorityBased

ReconfigService

DREQUIEMI

Jtime

(TimeSys)

Distributed

Scheduler

addIfFeasible( )

796 Mhz

Node 2

Node N

A1

A2addIfFeasible( )

Tester Node

DREQUIEMI

Jtime (TimeSys)

PriorityBased

ReconfigService (stub)

DREQUIEMI

Jtime

(TimeSys)

Distributed

Scheduler

DREQUIEMI

Jtime

(TimeSys)

Distributed

Scheduler

15

REACTION WORKSHOP

Cost tributaries Tasks and VMs

• Cost increases with the number of tasks and the number of processors

• Utilization, sorting, and assignment (no deployment)

16

REACTION WORKSHOP

1,E+00

1,E+01

1,E+02

1,E+03

1,E+04

1,E+05

1,E+06

1,E+07

64

32

16

8

4

2 1

Tim

e c

on

su

me

d (

us

)

Processors (JVMs) and Network available

Feasiblity test algorithm costs

4096Tasks

1024Tasks

64Tasks

1Task

796Mhz-100 Mbps

Cost tributaries Type of schedulable entity

• Schedulable entities ▫ Real-time threads, remote objects, and

async-event handlers

• Each schedulable offers different performance ▫ Asynchronous event handlers have the

worst allocation time

• Remote allocation adds an extra cost

17

REACTION WORKSHOP

1,E+03

1,E+04

1,E+05

1,E+06

1,E+07

1,E+08

40

96

102

4

25

6

64

8 1

Tim

e c

on

su

me

d (

us

)

Schedulable Segments (tasks) to deploy

Allocation costs depending on the kind of schedulable

AsyncEventHandler

RtRO

Rthread

1,E+03

1,E+04

1,E+05

1,E+06

1,E+07

1,E+08

40

96

102

4

25

6

64

8 1

Tim

e c

on

su

me

d (

us

)

Schedulable Segments (tasks) to deploy

Remote allocation of remote entities

AsyncEventHandler

RtRO

Rthread

796Mhz-100 Mbps

Total reconfiguration time

• Some interesting values ▫ A 1 seconds reconfiguration allows

reconfiguring 64 distributed tasks

• It depends on the number ▫ Of tasks ▫ Number of JVMs

• All schedulables are supposed to be event handlers ▫ They bound the worst time of a thread and a

remote object

REACTION WORKSHOP

18

1,E+04

1,E+05

1,E+06

1,E+07

1,E+08

40

96

102

4

25

6

64

8 1 Tim

e c

on

su

me

d (

us

)

Schedulable Objects to allocate

Total {re}configuration time

32JVM

16JVM

4JVM

Conclusions

• Next generation Java-based distributed real-time systems may benefit form having an embedded infrastructure with reconfiguration facilities ▫ Similar to the one described in the article

• However, one may choose the reconfiguration policy to suit specific application domains

19

REACTION WORKSHOP

Ongoing work

• To address other reconfiguration policies

▫ Different scheduling algorithms

▫ Mode change protocols As a way to introduce adaptation in DRTJava

Impact of multi-core policies

• Use of real-time OSGi platforms for reconfiguration

▫ Higher level adaptation closer to application

20

REACTION WORKSHOP

21

REACTION WORKSHOP

Distributed Real-Time Systems Laboratory (Drequiem Lab)