SlideShare a Scribd company logo
1 of 42
Download to read offline
The Computing Continuum: Beyond the Cloud Data
Centers
Dragi Kimovski
Pre-submission Habilitation Talk
Klagenfurt University
30.06.2022
About me
Dragi Kimovski
Postdoc assistant with “Zielvereinbarung”
Previous positions:
• 2016-2018 Senior Researcher and Lecturer, University of
Innsbruck, Austria
• 2013-2019 Assistant Professor, University of Information
Science and Technology, Macedonia
• 2009-2013 Teaching Assistant, University of Information
Science and Technology, Macedonia
Visiting positions:
• University of Utrecht, Netherlands (December 2022)
• University of Michigan - Ann Arbor, US
• University of Bologna, Italy
• University of Granada, Spain
Project experience:
• H2020 ASPIDE (2018-2021), Scientific coordinator
• H2020 Entice project (2016-2018), WP leader and integration
manager
• H2020 DataCloud (2021-2023), WP leader
• FFG KärntnerFog (2022-2024), WP Leader
• OeAD AtomicFog (2018-2020), Coordinator
Publications:
Over 50 publications in Journals and Conferences
2
Dragi Kimovski
Postdoc assistant with “Zielvereinbarung”
Teaching experience:
• Distributed systems, Distributed computing
infrastructures, Cloud computing and IoT,
Advanced programming in C++ @ University of
Klagenfurt, Austria
• Parallel Systems, Distributed Systems@ University
of Innsbruck, Austria
• Parallel computing, High performance computing,
Computing organization, Computer networks,
Computing systems configuration, Programming
@ University of Information Science and
Technology, Macedonia
• Parallel processing @ Technical University of Sofia,
Bulgaria
Supervision:
• 13 Bachelor thesis (2 in progress)
• 3 Master thesis (5 thesis in progress)
• 2 PhD thesis (Co-supervision)
3
About me
Introduction and overview
Cloud computing and Internet of Things
5
The computing continuum and Internet of Things
Jetson Nano
6
Added value of the computing continuum
Reduction of the amount of
data being sent to the Cloud
Faster response times Support for new applications
(Smart cities, e-health, …)
7
Improved data security Reduced CO2 emissions
Is the computing continuum “magical”?
8
• Can the computing continuum solve the computational issues
related to the emerging Internet of Things application?
• The answer is: Na ja.
Issues (At least some of them)
Heterogeneity of devices Devices can move Application distribution
9
Various control domains Data management and
distribution
10
Open problems and questions
How to predict the mobility and the behavior of the
resources?
How to optimize storage repositories?
How to parallelize and distribute monolithic
applications?
How to characterize the resources and the
computing continuum architecture?
How to adaptively place and schedule IoT
applications?
Resources
characterization
Placement and
scheduling
Mobility patterns
prediction
Application
distribution
Storage
optimization
11
02 Resources characterization
The heterogenity of the computing continuum
• The heterogeneity of the computing continuum raises multiple
application management challenges:
– where to offload an application from the cloud to the fog or to
the edge.
• Large diversity of the devices:
– single-board computers such as Raspberry Pis;
– powerful multi-processor servers.
12
Performance characterisation
• To answer this question it is essential to characterize the
performance of the resources across the computing continuum.
• We present an analysis of:
• computational and network performance;
• carbon emissions.
• The main goal is to support the decision process for offloading an
application.
The Carinthian Computing Continuum – C3
Table 1: Description of the resources available in the C3
testbed.
Conceptual layer Device / Instance type Architecture (v)CPU Memory [GiB] Storage [GiB] Network Physical processor Clock [GHz] Operating system
Cloud layer
AWS t2.micro
64-bit x86
1 1
32
Moderate Intel Xeon  3.1
Ubuntu 18.04
AWS c5.large 2 4
 10 Gbps
Intel Xeon Platinum 8000 series  3.6
AWS m5a.xlarge 4 16 AMD EPYC 7000 series  2.5
Fog layer
Exoscale Tiny
64-bit x86
1 1
32  10 Gbps
Intel Xeon  3.6
Ubuntu 18.04
Exoscale Medium 2 4
Exoscale Large 4 8
ITEC Cloud Instance 4 8 Intel Xeon Platinum 8000  3.1
Edge layer
Edge Gateway System 64-bit x86 12 32 32  10 Gbps AMD Ryzen Threadripper 2920X  3.5 Ubuntu 18.04
Raspberry Pi 3B
64-bit ARM 4
1
64  1 Gbps
Cortex - A53  1.4
Pi OS Buster
Raspberry Pi 4 4 Cortex - A72  1.5
Jetson Nano 4 Tegra X1 and Cortex - A57  1.43 Linux for Tegra R28.2.1
2.2 Fog layer
112
The fog layer comprises computing infras-
113
tructures consolidated in small data-centers
114
in close vicinity to the data sources. This layer
115
comprises resources from two providers in
116
the C3
testbed [4]: Exoscale and University of
117
Klagenfurt. We allocate these providers in the
118
fog layer as a result of the low round-trip com-
119
munication latency ( 7 ms) and high band-
120
width ( 10 Gbps). The Exoscale cloud com-
121
prises data centers in Vienna and Klagenfurt
122
(Austria). We selected three computing opti-
123
mized x86-64 instances from the Exoscale
124
cloud offering: Tiny, Medium and Large.
125
University of Klagenfurt provides a private
126
cloud infrastructure operated by OpenStack
127
3 Benchmark applications 150
We selected three representative appli- 151
cation classes with complementary require- 152
ments to evaluate the computational perfor- 153
mance and the CO2 emissions of the com- 154
puting continuum. 155
3.1 Video encoding 156
Video encoding allows transmission of 157
video content with different qualities over 158
limited and heterogeneous communication 159
channels. It compresses an original raw video 160
to reduce its effective bandwidth consump- 161
tion, while maintaining a subjective high qual- 162
ity for viewers. Video encoding has wide fields 163
of applications, including content delivery (live 164
and on-demand video streams), traffic control 165
14
Video encoding
• Ffmpeg version 3.4.6 with the most popular H.264/MPEG-4 video
encoder.
• Raw video segment with length of 4 second and size of 514 MB.
rge
tion
nce
Fm-
ular
by
We
eg-
MB,
deo
HD-
ates
ding
urce
achieved the lowest encoding and transfer 233
time due to the low utilization rate and its high 234
computing and networking capabilities.
R
P
i
3
B
R
P
i
4
J
e
t
s
o
n
E
G
S
E
S
T
i
n
y
E
S
M
e
d
i
u
m
E
S
L
a
r
g
e
A
W
S
t
2
.
m
i
c
r
o
A
W
S
c
5
.
l
a
r
g
e
A
W
S
m
5
a
.
x
l
a
r
g
e
0
10
20
30
40
30.6
4.8
3.6
0.4
1
0.68
0.75
4.7
0.7
0.6
32.3
5.5
4
0.5
1.4
0.89
0.93
4.7
0.8
0.7
36.3
8.2
6.4
0.9
3.1
1.4
1.2
5.2
1.4
1.3
Execution
time
[s]
HD-Ready (720p) Full HD (1080p) Quad HD (1440p)
(a) Average encoding time.
200
7.5
170.6
63.8
4 Performance evaluation
191
4.1 Video encoding
192
We evaluate the encoding performance
193
of the computing continuum using FFm-
194
peg version 3.4.6 with the most popular
195
H.264/MPEG-4 video encoder4
deployed by
196
more than 90% of the video industry5
. We
197
perform the encoding on a raw video seg-
198
ment with length of 4 s and size of 514 MB,
199
available in the Sintel6
video-set. The video
200
segment is encoded in three resolutions (HD-
201
ready, Full HD and Quad HD) with data rates
202
of 1500, 3000, and 6500 kbps.
203
Figure 2 depicts the average encoding
204
time and transfer time, from the video source
205
(located at the University of Klagenfurt) to
206
the encoding device or instance, for a single
207
raw video segment in the three resolutions.
208
The standard deviation ranges from 1.3%
209
for the AWS m5a.xlarge instance to 3.6%
210
for the Raspberry Pi 3B devices. We ob-
211
serve that the older generation single-board
212
computers (Raspberry Pi 3B) have a signif-
213
icantly higher encoding time than the other
214
resources. However, the Raspberry Pi 3B
215
devices provide lower transfer times than the
216
cloud instances and are suitable for video-on-
217
demand services employing offline encoding.
218
The Raspberry Pi 4 and the Jetson Nano de-
219
R
P
i
3
B
R
P
i
4
J
e
t
s
o
n
E
G
S
E
S
T
i
n
y
E
S
M
e
d
i
u
m
E
S
L
a
r
g
e
A
W
S
t
2
.
m
i
c
r
o
A
W
S
c
5
.
l
a
r
g
e
A
W
S
m
5
a
.
x
l
a
r
g
e
0
10
20
30
40
30.6
4.8
3.6
0.4
1
0.68
0.75
4.7
0.7
0.6
32.3
5.5
4
0.5
1.4
0.89
0.93
4.7
0.8
0.7
36.3
8.2
6.4
0.9
3.1
1.4
1.2
5.2
1.4
1.3
Execution
time
[s]
HD-Ready (720p) Full HD (1080p) Quad HD (1440p)
(a) Average encoding time.
R
P
i
3
B
R
P
i
4
J
e
t
s
o
n
E
G
S
E
S
T
i
n
y
E
S
M
e
d
i
u
m
E
S
L
a
r
g
e
A
W
S
t
2
.
m
i
c
r
o
A
W
S
c
5
.
l
a
r
g
e
A
W
S
m
5
a
.
x
l
a
r
g
e
0
50
100
150
200
12.5
5.1
9.2
5.1
74.5
63.1
67.1
157.5
170.6
163.8
Transfer
time
[s]
(b) Average raw video segment transfer time.
Figure 2: Average encoding performance of a
4 s long video segment with the x264 codec
and FFmpeg 3.4.6. 15
Machine learning
• Tensor Flow training:
– A quantum neural network using the MNIST data-set limited to
20000 samples with a size of 3.3MB with 90% accuracy;
– A convolutional neural network using the Kaggle data-set with a
size of 218MB with 80% accuracy.
enarios
ages:
ng the
amples
rio cre-
ers and
r to the
each a
0%.
ing the
18 MB.
s 80%.
e layers
er uses
e range
we use
tization
nsions.
execu-
network
e train-
the de-
raining.
m 1.2%
4% for
aluation
neural
is significantly higher for the convolutional 296
neural network, the cloud and fog resources 297
outperform the edge devices, except EGS. 298
Recommendation. We recommend the 299
model training with large data-sets and 300
multiple layers in the cloud or on dedicated 301
systems (such as EGS), whenever possible. 302
We recommend offloading to the edge only 303
when the training data is of limited size, or 304
when the neural network has few layers.
R
P
i
3
B
R
P
i
4
J
e
t
s
o
n
E
G
S
E
S
T
i
n
y
E
S
M
e
d
i
u
m
E
S
L
a
r
g
e
A
W
S
t
2
.
m
i
c
r
o
A
W
S
c
5
.
l
a
r
g
e
A
W
S
m
5
a
.
x
l
a
r
g
e
0
100
200
300
400
500
54.1
35.6
40.1
6.2
8.4
8.7
8.4
5.3
6.2
8.6
1,630
1,050
432
65.2
210.2
192.1
134.26
220.1
178.83
180.3
Execution
time
[s]
Quantum neural network Convolutional neural network
(a) Average training time.
80
.3
1
The convolutional network has three layers
262
with a kernel size of three. Each layer uses
263
increasingly higher filter sizes in the range
264
[32, 64, 128]. After each layer, we use
265
a max-pooling sample-based discretization
266
process to reduce the spatial dimensions.
267
We repeat the training five times.
268
Figure 3 analyzes the average execu-
269
tion time for training the two neural network
270
types and the transfer times of the train-
271
ing data from centralized storage to the de-
272
vice or instance that performs the training.
273
The standard deviation ranges from 1.2%
274
for the Raspberry Pi 4 devices to 5.4% for
275
the AWS t2.micro instance. The evaluation
276
shows that the less complex quantum neural
277
network requires a relatively lower training
278
time across all resources. The old generation
279
single-board computers show again a lower
280
performance, and their suitability for training
281
heavily depends on the size of the training
282
data and the model. The other fog and edge
283
devices provide similar performance to the
284
cloud resources. The single-board computers
285
provide lower training performance for the
286
convolutional network. The only exception are
287
the Jetson Nano devices able to train the
288
convolutional network up to four times faster
289
than the Raspberry Pi devices. In general,
290
the EGS provides the lowest training time
291
R
P
i
3
B
R
P
i
4
J
e
t
s
o
n
E
G
S
E
S
T
i
n
y
E
S
M
e
d
i
u
m
E
S
L
a
r
g
e
A
W
S
t
2
.
m
i
c
r
o
A
W
S
c
5
.
l
a
r
g
e
A
W
S
m
5
a
.
x
l
a
r
g
e
0
100
200
300
400
500
54.1
35.6
40.1
6.2
8.4
8.7
8.4
5.3
6.2
8.6
1,6
1,0
432
65.2
210.2
192.1
134.26
220.1
178.83
180.3
Execution
time
[s]
Quantum neural network Convolutional neural network
(a) Average training time.
R
P
i
3
B
R
P
i
4
J
e
t
s
o
n
E
G
S
E
S
T
i
n
y
E
S
M
e
d
i
u
m
E
S
L
a
r
g
e
A
W
S
t
2
.
m
i
c
r
o
A
W
S
c
5
.
l
a
r
g
e
A
W
S
m
5
a
.
x
l
a
r
g
e
0
20
40
60
80
0.1
0.1
0.1
0.1
0.4
0.4
0.4
1
1
1
5.4
2.2
3.9
2.1
32.2
27.3
29.1
68.3
65.1
68
Transfer
time
[s]
Data-set (Quantum neural network) Data-set (Convolutional neural network)
(b) Average training data transfer time.
Figure 3: Average training and data transfer 16
Carbon emissions analysis
• We evaluate the power consumption of the physical devices used
for the convolutional neural network training in TensorFlow.
– We use a digital multimeter to physically measure the average
electrical current;
– We rely on an AWS research report to approximate the power
consumption of the fog devices and cloud instances.
S
E
S
T
i
n
y
E
S
M
e
d
i
u
m
E
S
L
a
r
g
e
A
W
S
t
2
.
m
i
c
r
o
A
W
S
c
5
.
l
a
r
g
e
A
W
S
m
5
a
.
x
l
a
r
g
e
55.1
65.3
61.2
26.9
24.8
25.2
0.94
7.1
7
7
22.1
20.7
20.1
R
P
i
3
B
R
P
i
4
J
e
t
s
o
n
E
G
S
E
S
T
i
n
y
E
S
M
e
d
i
u
m
E
S
L
a
r
g
e
A
W
S
t
2
.
m
i
c
r
o
A
W
S
c
5
.
l
a
r
g
e
A
W
S
m
5
a
.
x
l
a
r
g
e
0
1
2
3
4
5
6
1
0.7
0.71
1.5
2.3
4.1
3.9
2.4
3.8
5.4
Carbon
emission
[g]
Carbon emissions
Figure 6: Carbon footprint for training a neural
17
What we learned
• We compiled a set of recommendations for practitioners on where
to offload their applications across the computing continuum.
• However, is this enough for proper application management?
Recommendations for application offloading across the computing co
Application
Requirement
Low network load Low execution time Low CO2 emissions
Video encoding Edge/Fog Cloud Edge
Machine learning Edge Cloud/Fog Edge
In-memory analytic Cloud/Fog Cloud Edge
ional Conference on the Internet of Things
Prodan, R., Barrionuevo, J. J. D., Fahringer,
ay). A multi-objective approach for workflow
n heterogeneous environments. In 2012 12th
International Symposium on Cluster, Cloud
puting, and communication in UAV swa
Radu Prodan is professor in distribute
ITEC, Klagenfurt University. He receive
gree in 2004 from the Vienna University
and was Associate Professor until 201
versity of Innsbruck (Austria). His rese
Research papers:
1. Dragi Kimovski, Josef Hammer, Narges Mehran, Hermann Hellwagner and Radu Prodan, “Cloud, Fog or Edge: Where to Compute”, IEEE Computing Magazine, 2021.
2. Roland Matha, Dragi Kimovski, Anatoliy Zabrovsky, Christian Timmerer and Radu Prodan, “Where to Encode: A Performance Analysis of x86and Arm-based Amazon EC2 Instances”, eScience 2021.
18
19
Scheduling and mobility prediction
Placement and scheduling
• To efficiently place and schedule complex distributed
applications’ workflows in heterogeneous environment, with
limited computing and storage capacity.
20
Approach
• To cope with the complexity of the
problem we apply multi-objective
approach.
• Searching for a set of non-
dominated scheduling/placements
of applications on the continuum.
• An automated decision-making
module to select an appropriate
solution.
21
Approach
• Objectives:
• Time à lower completion time;
• Energy à reduce energy consumption;
• Cost à reduce monetary cost.
• Constrained on devices in the computing continuum that tend to
move (roam) less.
22
Objectives
• Time objective:
• The computation time;
• The time required for transferring data among
components.
Computation time
rk
rj
mi
pred
(mi)
23
Objectives
• Energy objective:
• Energy for executing the component on a device;
• Energy for receiving data;
• Static energy consumption for maintaining the device active.
24
Objectives
• Cost objective:
• Processing the application on
CPUj
• Storing the data on STORj
• Communication cost between
resources
25
The scheduling and placement problem
i | i 2 N, 0  i   }, where |M|= . Each decision vari-
ble i is the placement of one component mi onto a
source: i = plc (mi). The goal is to find a placement
c(A) for an application A that assigns all its components
the set R of resources that minimizes the three objectives:
8
>
>
>
<
>
>
>
:
f1(T) = min
plc(A)=R
T(A,R);
f2(E) = min
plc(A)=R
E(A,R);
f3(C) = min
plc(A)=R
C(A,R).
(11)
Searching an optimal placement plc(A) results in a set
solutions, which must satisfy the processing, memory
nd storage constraints on device rj = (CPUj, MEMj, STORj)
signed to each component mj, and the movement proba-
lity of a device rj within a given time window P W
rj
(s):
to the set R of resources that minimizes the three objectives:
8
>
>
>
<
>
>
>
:
f1(T) = min
plc(A)=R
T(A,R);
f2(E) = min
plc(A)=R
E(A,R);
f3(C) = min
plc(A)=R
C(A,R).
(11)
Searching an optimal placement plc(A) results in a set
of solutions, which must satisfy the processing, memory
and storage constraints on device rj = (CPUj, MEMj, STORj)
assigned to each component mj, and the movement proba-
bility of a device rj within a given time window P W
rj
(s):
8
>
>
<
>
>
:
CPU (mi) < CPUj;
MEM (mi) < MEMj;
STOR (mi) < STORj;
P W
rj
(s) < km.
(12)
where k is a mobility constraint coefficient defined by
• We utilize NSGA-II to tackle this NP-complete optimization
problem
26
Mobility constraint
• Improve application scheduling by addressing the mobility
characteristics of the Fog/Edge devices in the computing
continuum.
• Prediction of the mobility allows to optimize:
• Application placement: select the device having lowest
mobility;
• Priority scheduling: assign „harder“ tasks to less mobile devices
and vice versa.
27
Mobility characterization
• By modeling the devices in the continuum 𝑟
!
through (first order) discrete Markov chains (MC).
• Calculates the probability of a system to reach a
particular state in future.
• Consists of (already specialized):
• Finite set of states, i.e. {𝑆", 𝑆#, 𝑆$}.
• 𝑆" − 𝐷𝑖𝑠𝑐𝑜𝑛𝑛𝑒𝑐𝑡𝑒𝑑;
• 𝑆# − 𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑒𝑑;
• 𝑆$ − 𝑅𝑜𝑎𝑚𝑒𝑑.
𝑆!
𝑆"
𝑆#
"
1
3
0
"
2
3
0
1
"
3
4
0
0
"
1
4
28
Markov chain mobility prediction
• Given a MC for a (𝑤, 𝑑) – tuple and the functions:
– 𝑖𝑛𝑑𝑒𝑥 𝑟 ≔
𝑅𝑒𝑡𝑢𝑟𝑛𝑠 𝑡ℎ𝑒 𝑙𝑜𝑤𝑒𝑠𝑡 𝑖𝑛𝑑𝑒𝑥 𝑐𝑜𝑛𝑡𝑎𝑖𝑛𝑖𝑛𝑔 𝑡ℎ𝑒 𝑚𝑎𝑥𝑖𝑚𝑢𝑚 𝑜𝑓 𝑡ℎ𝑒 𝑣𝑒𝑐𝑡𝑜𝑟 𝑟 ∈
0, 1 ! × #
– 𝑠𝑡𝑎𝑡𝑒 𝑖𝑛𝑑𝑒𝑥 ≔ ;
𝑖𝑛𝑑𝑒𝑥 = 1 → 𝑆$
𝑖𝑛𝑑𝑒𝑥 = 2 → 𝑆%
𝑖𝑛𝑑𝑒𝑥 = 3 → 𝑆&
• We can derive the next state that is most likely to occur by:
𝑠$%& = 𝑠𝑡𝑎𝑡𝑒 𝑖𝑛𝑑𝑒𝑥 𝜋 ⋅ (𝑃!!
'(
)$
/ 𝑖 ∈ ℕ 𝑖𝑠 𝑡ℎ𝑒 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑡𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛𝑠
= 𝜋 ⋅ 𝑃!)
"#
⋅ … ⋅ 𝑃!)
"#
= 𝑖 𝑡𝑖𝑚𝑒𝑠
29
Case studies
Mental health care
Insulin pump
7: end if
8: end for
9: return True . Constraints fulfilled
10: end function
Algorithm 3 mMAPO automated decision making
1: function DECISION_MAKING(Y )
2: Input:
!
OPV . Objective priority vector
3: IC initiate_centroids( ~
OPV )
4: CP cluster_pareto(Y, IC)
5: returnselect_pareto_solution(CP)
6: end function
IoT micro-sensors embedded in the patient body [33]. The
sensors send the blood sugar information to the resources
executing machine learning algorithms to create a model
that identifies the patient state variation and computes
the proper level of insulin upon abnormal state detection.
Afterwards, the pump controller receives the information
through eight components interacting as in Fig. 4:
• Compute blood sugar level of the patient;
• Compute insulin level and store it in a remote database;
• Retrieve patient records from the database;
• Review values of a patient for taking proper decisions;
• Send to doctor the blood sugar for review of insulin
intake;
• Send review results back with the proper insulin dose
based on the patient history.
• Compute pump command and adjust miniaturized pump
pressure to avoid the risk of falling into coma;
• Control insulin pump needle for delivering the correct
dose.
6.2 Mental healthcare
This application manages near real-time information of pa-
tients who suffer from mental disorders [33] in a number of
UK hospitals (Fig. 5). Due to privacy concerns, the patients
may not always attend the same clinic and need support
through appointments and emergency services:
• Determine mental state for a specific patient’s record;
• Decompose the safety concern for the patient to prevent
Compute
insulin
level
doctor
Compute
pump
command
insulin
pump
Log insulin
dose
patient
records
 sensor pump
Review
values
blood
  sugar
Figure 4. Insulin pump application.
Decom-
pose the
safety
concern
Mental
health act
Find the
closest
clinic
Generate
record for
medical
staff 
Smart
wearable
device 
Emergency
services
Determine 
mental
states
Summarize
View
patient
history
Figure 5. Mental healthcare application.
7 EXPERIMENTAL SIMULATION
We implemented the mMAPO Pareto analysis algorithm in
the jMetal [34] framework and integrated within the Sched-
uler of the ASKALON environment. We created elaborate
simulation scenarios using iFogSim [14], which considers
the computational and storage characteristics of both the
Edge devices and the Cloud virtual machine instances.
7.1 Experimental design
We evaluated the benefits of mMAPO for application place-
ment compared to three state-of-the-art methods: 1) Fog
Service Placement Problem (FSPP) [11] based on linear inte-
ger programming model focused on reducing the economic
cost and improving resources utilization; 2) Edge-ward de-
lay-priority (EW-DP) [8] that implements a hierarchical best
fit algorithm to cope with users mobility; and 3) Best-fit
Queue (BQ) [12] as a queuing algorithm that reduces the
completion time by primarily using Edge devices. We con-
sidered completion time, energy consumption and economic
cost for executing a request from the IoT sensors until the
final data collection at another device or end-user.
6
nents
ri) _
filled
filled
ector
The
urces
model
putes
ction.
ation
ase;
ns;
sulin
Table 1
Resource requirements per component.
Application CPU [MI] MEM [MB] Storage [MB]
Insulin pump 200 – 2000 10 – 60 256 – 1024
Mental healthcare 200 – 2000 10 – 50 256 – 512
Compute
insulin
level
Send to
doctor
Compute
pump
command
Control
insulin
pump
Log insulin
dose
Retrieve
patient
records
Blood
 sensor
Insulin
pump
Review
values
Compute
blood
  sugar
Figure 4. Insulin pump application.
Decom-
pose the
safety
concern
Mental
health act
Find the
closest
clinic
Generate
record for
medical
staff 
Smart
wearable
device 
Emergency
services
Determine 
mental
states
Summarize
View
patient
history
Figure 5. Mental healthcare application.
7 EXPERIMENTAL SIMULATION
We implemented the mMAPO Pareto analysis algorithm in
the jMetal [34] framework and integrated within the Sched-
uler of the ASKALON environment. We created elaborate
simulation scenarios using iFogSim [14], which considers
the computational and storage characteristics of both the
6
Table 1
Resource requirements per component.
Application CPU [MI] MEM [MB] Storage [MB]
Insulin pump 200 – 2000 10 – 60 256 – 1024
Mental healthcare 200 – 2000 10 – 50 256 – 512
Send to
doctor
Control
insulin
pump
Retrieve
patient
records
Blood
 sensor
Insulin
pump
Compute
blood
  sugar 30
Evaluation (placement and scheduling)
Figure 3: Insulin pump application completion time, energy consumption, and economic cost for different data size
Figure 4: Mental health care application completion time, energy consumption, and economic cost for different CPU load
31
Evaluation (mobility prediction)
Figure 5: Experimental evaluation of the Markov chain single-transition mobility prediction model
Figure 6: Average request probability failure
32
1,000 2,000 4,000
0
50
INSTR [MI]
Co
1,000 2,000 4,000
0
1,000
INSTR [MI]
Energ
1,000 2,000 4,000
0.5
1
INSTR [MI]
Ec
Figure 11. Mental healthcare application time, energy, and cost for different CPU workloads.
0 25 50 100 200
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
Number of prediction samples per device
Execution
time
[
s
]
25 50 100 200
80
90
100
Number of prediction samples per device
Accuracy
[%] 0 25 50 100
80
90
100
Number of single-step predictions per device
Accuracy
[%]
DPM
IDV
Figure 12. Experimental evaluation of the Markov chain single-transition mobility prediction model.
9.4 Request failure probability
This section evaluates the effect of the mobility on the
request failure probability for executing the mental health
application. We performed a series-based reliability analysis
[39] that identifies the average time spent by the Edge
devices in a connected Sc or roamed Sr state in the four
ime windows W defined in Section 9.2: Morning (MO),
Forenoon (FN), Afternoon (AN) and Night (NI). The empir-
cal analysis shows that the average connected or roamed
ime T for each time window W is 2790 s, 2888 s, 3322 s
and 2442 s, respectively. We therefore utilize this informa-
ion to create probability function for a request failure f in
failure rate. In contrast, FSPP primarily relies on the Cloud
infrastructures with limited use of Edge devices, which
results in a relatively low failure probability of around 35%.
The introduction of the mobility prediction reduced the
failure probability of mMAPO to less than 10%. The high
probability of a request failure in EW-DP, BQ and FSPP
indirectly increases the energy and execution costs by a
factor of two to six compared to mMAPO.
9.5 Complexity and quality analysis
We investigate the ability of mMAPO to provide optimized
MO FN AN NI
0
20
40
60
80
100
Window W
Requests
probability
failure
[%]
FSPP
mMAPO
EW-DP
BQ
Figure 13. Average request probability failure for mental healthcare
application.
Cloud. Moreover, the mMA
Edge devices can reduce th
up to 80%. The results also s
is more energy efficient for
require high performance r
munication latency has a l
time than the data size. L
devices can have large impa
proper consideration durin
REFERENCES
[1] What edge computing me
04 Storage optimization and distribution
IoT application storage repositories
• The modern methods for IoT applications delivery utilize
virtualization as an efficient tool for software packaging.
• This is usually done using virtual machine images (VMI) or
containers.
• The VMIs and containers are stored in either centralized or
distributed storage repositories.
34
IoT application storage repositories
• Unfortunately, these repositories are not optimized and are not
able to transparently distribute VMIs based on the IoT
application requirements and usage history.
• Therefore, we present a novel multi-objective middleware for
the management of VMIs in federated computing continuum
repositories with replication support.
35
The ENTICE optimization middleware
• The ENTICE middleware provides easy to use interface capable of receiving
unmodified and functionally complete VM images from its users.
• It can transparently distribute the VMIs to a specific infrastructure in a federation
concerning their size, configuration, and geographical distribution, such that they are
loaded, delivered, and executed faster and with improved QoS compared to their
current behavior.
36
Multi-objective Middleware for Distributed VMI Repositories in Federated Cloud Environment 305
Fig. 5.1. Top level view of the Multi-objective Optimization Framework for VM Image distribution
The ENTICE middleware data flow
37
.1 VMI cost objective
model the cost objective, we use the notion of the financial resources required to store particular VMI in a given repository site Cstorage and the
t for transferring the data from the initial to the new repository in the federation Ctransfer. For each VMI, we calculate the cost objective by addin
two components C = Cstorage + Ctransfer.
URE 5 Virtual machine image redistribution framework flowchart
Evaluation (Repository optimization)
38
13 of 16
1 0.8 0.6 0.4 0.2 0
0
200
400
600
800
1000
1200
1400
1600
Value of replication coeficient − K
Execution
time
(ms)
hm execution time for different values of k
hm execution time for different numbers of individual evaluations
n framework with replication support has been evaluated on the bases of the quality of the Pareto optimal solutions
1 0.8 0.6 0.4 0.2 0
0
200
Value of replication coeficient − K
FIGURE 8 Optimization algorithm execution time for different values of k
FIGURE 9 Optimization algorithm execution time for different numbers of individual evaluations
Furthermore, the optimization framework with replication support has been evaluated on the bases of the quality of the Pareto optimal s
fordifferentvaluesofthegeneticparameters,suchasnumberofindividualsandnumberofevaluations/generations.Theassessmentwasco
for a specific scenario enclosing the redistribution of 100 VMIs with replication coefficient k = 1. The hypervolume indicator24 has been
compare the quality of the separate solutions provided during the experiments. Figure 10 presents a comparison of the mean value and
deviation of the quality of the solutions in contrast to the number of utilized individuals and performed evaluations per experiment. By a
the results, it can be concluded that in the cases when low computational time is required, it is essential to reduce both the number of in
and performed evolutions, thus guaranteeing best computational performance to quality ratio. Contrary, when the computational time
issue, like in the case of off-line VMI redistribution, higher populations sizes with increased number of evolutions should be used. For ex
the case when 100 individuals are being utilized, we can expect best quality of the solutions when less then 5000 separate individual eva
are performed. Above this threshold, the low number of individuals can easily lead to low diversity and reduced search capabilities, thus p
solutions with limited hypervolume values. In the case of ENTICE, the redistribution and replication are performed off-line, thus requi
population size and increased number of evolutions. T
o better illustrate the difference in quality among the solutions, on Figure 11, we p
comparison between the best solutions gathered from the experiments with 100 and 500 individuals.
Lastly, in T
able 3, we provide a comprehensive review of the exact objective values for the optimal trade-off distribution solutions calcu
the optimization framework. Moreover, a comparison has been presented with a set of mapping solutions determined by using nonoptimize
robin” mapping model for storing VMIs, and a multi-objective redistribution algorithm without replications support.17 The cost objecti
been calculated based on the publicly provided price list for storing data in the Cloud by public companies, such as Amazon S3 and Microso
The delivery time (performance) objective has been modeled based on the reported communication performance measures for 10 Gbit an
KIMOVSKI ET AL.
imal solutions in contrast with the number of individuals
14 of 16 KIMOVSKI ET AL.
FIGURE 10 Quality of the optimal solutions in contrast with the number of individuals
FIGURE 11 Visualized comparison of the best and worst solutions provided by the optimization framework
TABLE 3 Comparison between different virtual machine image redistribution strategies
Figure 7: Optimization algorithm scalability
for different replication coefficients
Figure 8: Optimization algorithm scalability
with and without replication
Figure 9: Quality of the repository
optimization solutions
Figure 10: Analysis of the optimization
solutions
39
Summary and future directions
Summary and future work
• We proposed a new resource characterisation approach with
pollutants emissions analysis.
• We researched and developed a multi-objective scheduling
approach with a Markov-chain based model for predicting when an
edge device might move (roam) within the computing continuum.
• We introduced a novel middleware for optimisation of the storage
distribution of the IoT applications across the computing
continuum.
• In future we plan to merge the developed software in a single
toolset for management of IoT applications across the computing
continuum. 40
References
41
Research papers:
1. Dragi Kimovski, Sasko Ristov and Radu Prodan, “Decentralized Machine Learning for Intelligent Health Care Systems on the Computing Continuum”, IEEE Computer
Magazine, 2022.
2. Dragi Kimovski, Josef Hammer, Narges Mehran, Hermann Hellwagner and Radu Prodan, “Cloud, Fog or Edge: Where to Compute”, IEEE Internet Computing
Magazine, 2021.
3. Roland Matha, Dragi Kimovski, Anatoliy Zabrovsky, Christian Timmerer and Radu Prodan, “Where to Encode: A Performance Analysis of x86and Arm-based Amazon
EC2 Instances”, eScience 2021.
4. Vincenzo De Maio and Dragi Kimovski, “Multi-objective scheduling of extreme data scientific workflows in Fog”, Future Generation Computer Systems, Volume 106,
2020, pp. 171-184.
5. Narges Mehran, Dragi Kimovski and Radu Prodan, “MAPO: A Multi-Objective Model for IoT Application Placement in a Fog Environment”, Proceedings of the 9th
International Conference on the Internet of Things, 2019, pp. 1-8.
6. Dragi Kimovski, Narges Mehran, Christopher Kerth and Radu Prodan, , “Mobility-Aware IoT Application Placement in the Cloud -- Edge Continuum”, IEEE
Transactions on Services Computing, 2021.
7. Dragi Kimovski, Julio Ortega, Andres Ortiz and Raul Banos, “Parallel alternatives for evolutionary multi-objective optimization in unsupervised feature selection”,
Elsevier Expert Systems with Applications No.9/Vol.42, 2015
8. Dragi Kimovski, Julio Ortega, Andres Ortiz and Raul Banos, “Leveraging cooperation for parallel multi-objective feature selection in high-dimensional EEG data”,
Concurrency and Computation: Practice and Experience No.18/Vol.27, 2015
9. Dragi Kimovski, Julio Ortega, Andres Ortiz and Raul Banos “Feature selection in high-dimensional EEG data by parallel multi- objective optimization”, 2014 IEEE
International Conference on Cluster Computing, 2014
10. Nishant Saurabh, Dragi Kimovski, Francesco Gaetano and Radu Prodan, ”A Two-Stage Multi-Objective Optimization of Erasure Coding in Overlay Networks”, CCGrid
2017, Madrid, Spain 2017
11. Dragi Kimovski, Attila Marosi, Sandi Gec, Nishant Saurabh, Atilla Kertezs, Gabor Kecskemeti, Vlado Stankovski and Radu Prodan “Distributed Environment for
Efficient Virtual Machine Image Management”, Concurrency and Computation: Practice and Experience
12. Sandi Gec, Dragi Kimovski, Uros Pascinski, Radu Prodan and Vlado Stankovski “Semantic approach for multi-objective optimisation of the ENTICE distributed Virtual
Machine and container images repository”, Concurrency and Computation: Practice and Experience
13. Dragi Kimovski, Nishant Saurabh, Vlado Stankovski, Radu Prodan, “Multi-Objective Middleware for Distributed VMI Repositories in Federated Cloud Environment”,
Scalable Computing: Practice and Experience, No.4/Vol.17, 2016
14. Dragi Kimovski, Nishant Saurabh, Sandi Gec, Polona Stefancic, Gabor Kecskemeti, Vlado Stankovski, Radu Prodan, Thomas Fahringer, “Towards Decentralized
Repository Services for Efficient and Transparent Virtual Machine Operations: The ENTICE Approach”, IEEE International Conference on Cloud Networking,
CloudNet 2016, Pisa, Italy, October 2016
Questions?

More Related Content

What's hot

What's hot (20)

How to migrate workloads to the google cloud platform
How to migrate workloads to the google cloud platformHow to migrate workloads to the google cloud platform
How to migrate workloads to the google cloud platform
 
GREEN CLOUD COMPUTING BY SAIKIRAN PANJALA
GREEN CLOUD COMPUTING BY SAIKIRAN PANJALAGREEN CLOUD COMPUTING BY SAIKIRAN PANJALA
GREEN CLOUD COMPUTING BY SAIKIRAN PANJALA
 
Tom Grey - Google Cloud Platform
Tom Grey - Google Cloud PlatformTom Grey - Google Cloud Platform
Tom Grey - Google Cloud Platform
 
Applying Network Analytics in KYC
Applying Network Analytics in KYCApplying Network Analytics in KYC
Applying Network Analytics in KYC
 
Services comparison among Microsoft Azure AWS and Google Cloud Platform
Services comparison among Microsoft Azure AWS and Google Cloud PlatformServices comparison among Microsoft Azure AWS and Google Cloud Platform
Services comparison among Microsoft Azure AWS and Google Cloud Platform
 
A comparative study between cloud computing and fog
A comparative study between cloud computing and fog A comparative study between cloud computing and fog
A comparative study between cloud computing and fog
 
Using Google Compute Engine
Using Google Compute EngineUsing Google Compute Engine
Using Google Compute Engine
 
Challenges of the Cloud Migration Journey
Challenges of the Cloud Migration JourneyChallenges of the Cloud Migration Journey
Challenges of the Cloud Migration Journey
 
Assessing Disaster Recovery Options for Business Continuity
Assessing Disaster Recovery Options for Business ContinuityAssessing Disaster Recovery Options for Business Continuity
Assessing Disaster Recovery Options for Business Continuity
 
How Apache Spark and Apache Hadoop are being used to keep banking regulators ...
How Apache Spark and Apache Hadoop are being used to keep banking regulators ...How Apache Spark and Apache Hadoop are being used to keep banking regulators ...
How Apache Spark and Apache Hadoop are being used to keep banking regulators ...
 
Cloud Encryption
Cloud EncryptionCloud Encryption
Cloud Encryption
 
Microsoft Fabric.pptx
Microsoft Fabric.pptxMicrosoft Fabric.pptx
Microsoft Fabric.pptx
 
Microsoft Cloud Computing
Microsoft Cloud ComputingMicrosoft Cloud Computing
Microsoft Cloud Computing
 
Green Cloud Computing
Green Cloud ComputingGreen Cloud Computing
Green Cloud Computing
 
네이버클라우드플랫폼이 제안하는 멀티클라우드(박기은 CTO) - IBM 스토리지 세미나
네이버클라우드플랫폼이 제안하는 멀티클라우드(박기은 CTO) - IBM 스토리지 세미나네이버클라우드플랫폼이 제안하는 멀티클라우드(박기은 CTO) - IBM 스토리지 세미나
네이버클라우드플랫폼이 제안하는 멀티클라우드(박기은 CTO) - IBM 스토리지 세미나
 
BATbern52 Swisscom's Journey into Data Mesh
BATbern52 Swisscom's Journey into Data MeshBATbern52 Swisscom's Journey into Data Mesh
BATbern52 Swisscom's Journey into Data Mesh
 
Google cloud platform introduction
Google cloud platform introductionGoogle cloud platform introduction
Google cloud platform introduction
 
Digitalization of Trading by Platinion at ETOT 2017
Digitalization of Trading by Platinion at ETOT 2017 Digitalization of Trading by Platinion at ETOT 2017
Digitalization of Trading by Platinion at ETOT 2017
 
Modern-Data-Warehouses-In-The-Cloud-Use-Cases-Slim-Baltagi
Modern-Data-Warehouses-In-The-Cloud-Use-Cases-Slim-BaltagiModern-Data-Warehouses-In-The-Cloud-Use-Cases-Slim-Baltagi
Modern-Data-Warehouses-In-The-Cloud-Use-Cases-Slim-Baltagi
 
Building End-to-End Delta Pipelines on GCP
Building End-to-End Delta Pipelines on GCPBuilding End-to-End Delta Pipelines on GCP
Building End-to-End Delta Pipelines on GCP
 

Similar to The Computing Continuum.pdf

The Network Ip Address Scheme
The Network Ip Address SchemeThe Network Ip Address Scheme
The Network Ip Address Scheme
Erin Rivera
 
Mi0035 computer networks...
Mi0035  computer networks...Mi0035  computer networks...
Mi0035 computer networks...
smumbahelp
 
High Performance Communication for Oracle using InfiniBand
High Performance Communication for Oracle using InfiniBandHigh Performance Communication for Oracle using InfiniBand
High Performance Communication for Oracle using InfiniBand
webhostingguy
 
Ceph Day Berlin: Deploying Flash Storage for Ceph without Compromising Perfor...
Ceph Day Berlin: Deploying Flash Storage for Ceph without Compromising Perfor...Ceph Day Berlin: Deploying Flash Storage for Ceph without Compromising Perfor...
Ceph Day Berlin: Deploying Flash Storage for Ceph without Compromising Perfor...
Ceph Community
 

Similar to The Computing Continuum.pdf (20)

Cloud, Fog, or Edge: Where and When to Compute?
Cloud, Fog, or Edge: Where and When to Compute?Cloud, Fog, or Edge: Where and When to Compute?
Cloud, Fog, or Edge: Where and When to Compute?
 
guna_2015.DOC
guna_2015.DOCguna_2015.DOC
guna_2015.DOC
 
Migration of corperate networks from ipv4 to ipv6 using dual stack
Migration of corperate networks from ipv4 to ipv6 using dual stackMigration of corperate networks from ipv4 to ipv6 using dual stack
Migration of corperate networks from ipv4 to ipv6 using dual stack
 
Achieve high throughput: A case study using a Pensando Distributed Services C...
Achieve high throughput: A case study using a Pensando Distributed Services C...Achieve high throughput: A case study using a Pensando Distributed Services C...
Achieve high throughput: A case study using a Pensando Distributed Services C...
 
A Comparison of Four Series of CISCO Network Processors
A Comparison of Four Series of CISCO Network ProcessorsA Comparison of Four Series of CISCO Network Processors
A Comparison of Four Series of CISCO Network Processors
 
A Comparison of Four Series of CISCO Network Processors
A Comparison of Four Series of CISCO Network ProcessorsA Comparison of Four Series of CISCO Network Processors
A Comparison of Four Series of CISCO Network Processors
 
A Comparison of Four Series of CISCO Network Processors
A Comparison of Four Series of CISCO Network ProcessorsA Comparison of Four Series of CISCO Network Processors
A Comparison of Four Series of CISCO Network Processors
 
PoC Requirements and Use Cases
PoC Requirements and Use CasesPoC Requirements and Use Cases
PoC Requirements and Use Cases
 
ODSA - PoC Requirements and Use Cases
ODSA - PoC Requirements and Use CasesODSA - PoC Requirements and Use Cases
ODSA - PoC Requirements and Use Cases
 
Facebook_TIP_Nov
Facebook_TIP_NovFacebook_TIP_Nov
Facebook_TIP_Nov
 
Facebook and Telecom
Facebook and TelecomFacebook and Telecom
Facebook and Telecom
 
R43019698
R43019698R43019698
R43019698
 
A COMPARISON OF FOUR SERIES OF CISCO NETWORK PROCESSORS
A COMPARISON OF FOUR SERIES OF CISCO NETWORK PROCESSORSA COMPARISON OF FOUR SERIES OF CISCO NETWORK PROCESSORS
A COMPARISON OF FOUR SERIES OF CISCO NETWORK PROCESSORS
 
The Network Ip Address Scheme
The Network Ip Address SchemeThe Network Ip Address Scheme
The Network Ip Address Scheme
 
Networking Challenges for the Next Decade
Networking Challenges for the Next DecadeNetworking Challenges for the Next Decade
Networking Challenges for the Next Decade
 
Mi0035 computer networks...
Mi0035  computer networks...Mi0035  computer networks...
Mi0035 computer networks...
 
2018 FRSecure CISSP Mentor Program- Session 7
2018 FRSecure CISSP Mentor Program- Session 72018 FRSecure CISSP Mentor Program- Session 7
2018 FRSecure CISSP Mentor Program- Session 7
 
Feedback on Big Compute & HPC on Windows Azure
Feedback on Big Compute & HPC on Windows AzureFeedback on Big Compute & HPC on Windows Azure
Feedback on Big Compute & HPC on Windows Azure
 
High Performance Communication for Oracle using InfiniBand
High Performance Communication for Oracle using InfiniBandHigh Performance Communication for Oracle using InfiniBand
High Performance Communication for Oracle using InfiniBand
 
Ceph Day Berlin: Deploying Flash Storage for Ceph without Compromising Perfor...
Ceph Day Berlin: Deploying Flash Storage for Ceph without Compromising Perfor...Ceph Day Berlin: Deploying Flash Storage for Ceph without Compromising Perfor...
Ceph Day Berlin: Deploying Flash Storage for Ceph without Compromising Perfor...
 

More from Förderverein Technische Fakultät

The Digital Transformation of Education: A Hyper-Disruptive Era through Block...
The Digital Transformation of Education: A Hyper-Disruptive Era through Block...The Digital Transformation of Education: A Hyper-Disruptive Era through Block...
The Digital Transformation of Education: A Hyper-Disruptive Era through Block...
Förderverein Technische Fakultät
 
Don't Treat the Symptom, Find the Cause!.pptx
Don't Treat the Symptom, Find the Cause!.pptxDon't Treat the Symptom, Find the Cause!.pptx
Don't Treat the Symptom, Find the Cause!.pptx
Förderverein Technische Fakultät
 

More from Förderverein Technische Fakultät (20)

Supervisory control of business processes
Supervisory control of business processesSupervisory control of business processes
Supervisory control of business processes
 
The Digital Transformation of Education: A Hyper-Disruptive Era through Block...
The Digital Transformation of Education: A Hyper-Disruptive Era through Block...The Digital Transformation of Education: A Hyper-Disruptive Era through Block...
The Digital Transformation of Education: A Hyper-Disruptive Era through Block...
 
A Game of Chess is Like a Swordfight.pdf
A Game of Chess is Like a Swordfight.pdfA Game of Chess is Like a Swordfight.pdf
A Game of Chess is Like a Swordfight.pdf
 
From Mind to Meta.pdf
From Mind to Meta.pdfFrom Mind to Meta.pdf
From Mind to Meta.pdf
 
Miniatures Design for Tabletop Games.pdf
Miniatures Design for Tabletop Games.pdfMiniatures Design for Tabletop Games.pdf
Miniatures Design for Tabletop Games.pdf
 
Distributed Systems in the Post-Moore Era.pptx
Distributed Systems in the Post-Moore Era.pptxDistributed Systems in the Post-Moore Era.pptx
Distributed Systems in the Post-Moore Era.pptx
 
Don't Treat the Symptom, Find the Cause!.pptx
Don't Treat the Symptom, Find the Cause!.pptxDon't Treat the Symptom, Find the Cause!.pptx
Don't Treat the Symptom, Find the Cause!.pptx
 
Engineering Serverless Workflow Applications in Federated FaaS.pdf
Engineering Serverless Workflow Applications in Federated FaaS.pdfEngineering Serverless Workflow Applications in Federated FaaS.pdf
Engineering Serverless Workflow Applications in Federated FaaS.pdf
 
The Role of Machine Learning in Fluid Network Control and Data Planes.pdf
The Role of Machine Learning in Fluid Network Control and Data Planes.pdfThe Role of Machine Learning in Fluid Network Control and Data Planes.pdf
The Role of Machine Learning in Fluid Network Control and Data Planes.pdf
 
Nonequilibrium Network Dynamics_Inference, Fluctuation-Respones & Tipping Poi...
Nonequilibrium Network Dynamics_Inference, Fluctuation-Respones & Tipping Poi...Nonequilibrium Network Dynamics_Inference, Fluctuation-Respones & Tipping Poi...
Nonequilibrium Network Dynamics_Inference, Fluctuation-Respones & Tipping Poi...
 
Towards a data driven identification of teaching patterns.pdf
Towards a data driven identification of teaching patterns.pdfTowards a data driven identification of teaching patterns.pdf
Towards a data driven identification of teaching patterns.pdf
 
Förderverein Technische Fakultät.pptx
Förderverein Technische Fakultät.pptxFörderverein Technische Fakultät.pptx
Förderverein Technische Fakultät.pptx
 
East-west oriented photovoltaic power systems: model, benefits and technical ...
East-west oriented photovoltaic power systems: model, benefits and technical ...East-west oriented photovoltaic power systems: model, benefits and technical ...
East-west oriented photovoltaic power systems: model, benefits and technical ...
 
Machine Learning in Finance via Randomization
Machine Learning in Finance via RandomizationMachine Learning in Finance via Randomization
Machine Learning in Finance via Randomization
 
IT does not stop
IT does not stopIT does not stop
IT does not stop
 
Advances in Visual Quality Restoration with Generative Adversarial Networks
Advances in Visual Quality Restoration with Generative Adversarial NetworksAdvances in Visual Quality Restoration with Generative Adversarial Networks
Advances in Visual Quality Restoration with Generative Adversarial Networks
 
Recent Trends in Personalization at Netflix
Recent Trends in Personalization at NetflixRecent Trends in Personalization at Netflix
Recent Trends in Personalization at Netflix
 
Industriepraktikum_ Unterstützung bei Projekten in der Automatisierung.pdf
Industriepraktikum_ Unterstützung bei Projekten in der Automatisierung.pdfIndustriepraktikum_ Unterstützung bei Projekten in der Automatisierung.pdf
Industriepraktikum_ Unterstützung bei Projekten in der Automatisierung.pdf
 
Introduction to 5G from radio perspective
Introduction to 5G from radio perspectiveIntroduction to 5G from radio perspective
Introduction to 5G from radio perspective
 
Förderverein Technische Fakultät
Förderverein Technische Fakultät Förderverein Technische Fakultät
Förderverein Technische Fakultät
 

Recently uploaded

Heat Units in plant physiology and the importance of Growing Degree days
Heat Units in plant physiology and the importance of Growing Degree daysHeat Units in plant physiology and the importance of Growing Degree days
Heat Units in plant physiology and the importance of Growing Degree days
Brahmesh Reddy B R
 
Nanoparticles for the Treatment of Alzheimer’s Disease_102718.pptx
Nanoparticles for the Treatment of Alzheimer’s Disease_102718.pptxNanoparticles for the Treatment of Alzheimer’s Disease_102718.pptx
Nanoparticles for the Treatment of Alzheimer’s Disease_102718.pptx
ssusera4ec7b
 
GENETICALLY MODIFIED ORGANISM'S PRESENTATION.ppt
GENETICALLY MODIFIED ORGANISM'S PRESENTATION.pptGENETICALLY MODIFIED ORGANISM'S PRESENTATION.ppt
GENETICALLY MODIFIED ORGANISM'S PRESENTATION.ppt
SyedArifMalki
 

Recently uploaded (20)

Vital Signs of Animals Presentation By Aftab Ahmed Rahimoon
Vital Signs of Animals Presentation By Aftab Ahmed RahimoonVital Signs of Animals Presentation By Aftab Ahmed Rahimoon
Vital Signs of Animals Presentation By Aftab Ahmed Rahimoon
 
Heat Units in plant physiology and the importance of Growing Degree days
Heat Units in plant physiology and the importance of Growing Degree daysHeat Units in plant physiology and the importance of Growing Degree days
Heat Units in plant physiology and the importance of Growing Degree days
 
Nanoparticles for the Treatment of Alzheimer’s Disease_102718.pptx
Nanoparticles for the Treatment of Alzheimer’s Disease_102718.pptxNanoparticles for the Treatment of Alzheimer’s Disease_102718.pptx
Nanoparticles for the Treatment of Alzheimer’s Disease_102718.pptx
 
Taphonomy and Quality of the Fossil Record
Taphonomy and Quality of the  Fossil RecordTaphonomy and Quality of the  Fossil Record
Taphonomy and Quality of the Fossil Record
 
Vital Signs of Animals Presentation By Aftab Ahmed Rahimoon
Vital Signs of Animals Presentation By Aftab Ahmed RahimoonVital Signs of Animals Presentation By Aftab Ahmed Rahimoon
Vital Signs of Animals Presentation By Aftab Ahmed Rahimoon
 
GBSN - Biochemistry (Unit 8) Enzymology
GBSN - Biochemistry (Unit 8) EnzymologyGBSN - Biochemistry (Unit 8) Enzymology
GBSN - Biochemistry (Unit 8) Enzymology
 
MSCII_ FCT UNIT 5 TOXICOLOGY.pdf
MSCII_              FCT UNIT 5 TOXICOLOGY.pdfMSCII_              FCT UNIT 5 TOXICOLOGY.pdf
MSCII_ FCT UNIT 5 TOXICOLOGY.pdf
 
Manganese‐RichSandstonesasanIndicatorofAncientOxic LakeWaterConditionsinGale...
Manganese‐RichSandstonesasanIndicatorofAncientOxic  LakeWaterConditionsinGale...Manganese‐RichSandstonesasanIndicatorofAncientOxic  LakeWaterConditionsinGale...
Manganese‐RichSandstonesasanIndicatorofAncientOxic LakeWaterConditionsinGale...
 
GBSN - Biochemistry (Unit 3) Metabolism
GBSN - Biochemistry (Unit 3) MetabolismGBSN - Biochemistry (Unit 3) Metabolism
GBSN - Biochemistry (Unit 3) Metabolism
 
Terpineol and it's characterization pptx
Terpineol and it's characterization pptxTerpineol and it's characterization pptx
Terpineol and it's characterization pptx
 
Efficient spin-up of Earth System Models usingsequence acceleration
Efficient spin-up of Earth System Models usingsequence accelerationEfficient spin-up of Earth System Models usingsequence acceleration
Efficient spin-up of Earth System Models usingsequence acceleration
 
GENETICALLY MODIFIED ORGANISM'S PRESENTATION.ppt
GENETICALLY MODIFIED ORGANISM'S PRESENTATION.pptGENETICALLY MODIFIED ORGANISM'S PRESENTATION.ppt
GENETICALLY MODIFIED ORGANISM'S PRESENTATION.ppt
 
Towards a revolution in the social sciences FINAL FINAL FINAL FINAL FINAL.pdf
Towards a revolution in the social sciences FINAL FINAL FINAL FINAL FINAL.pdfTowards a revolution in the social sciences FINAL FINAL FINAL FINAL FINAL.pdf
Towards a revolution in the social sciences FINAL FINAL FINAL FINAL FINAL.pdf
 
Precision Farming in Fruit Crops presentation
Precision Farming in Fruit Crops presentationPrecision Farming in Fruit Crops presentation
Precision Farming in Fruit Crops presentation
 
Adaptive Restore algorithm & importance Monte Carlo
Adaptive Restore algorithm & importance Monte CarloAdaptive Restore algorithm & importance Monte Carlo
Adaptive Restore algorithm & importance Monte Carlo
 
An Overview of Active and Passive Targeting Strategies to Improve the Nano-Ca...
An Overview of Active and Passive Targeting Strategies to Improve the Nano-Ca...An Overview of Active and Passive Targeting Strategies to Improve the Nano-Ca...
An Overview of Active and Passive Targeting Strategies to Improve the Nano-Ca...
 
TransientOffsetin14CAftertheCarringtonEventRecordedbyPolarTreeRings
TransientOffsetin14CAftertheCarringtonEventRecordedbyPolarTreeRingsTransientOffsetin14CAftertheCarringtonEventRecordedbyPolarTreeRings
TransientOffsetin14CAftertheCarringtonEventRecordedbyPolarTreeRings
 
X-rays from a Central “Exhaust Vent” of the Galactic Center Chimney
X-rays from a Central “Exhaust Vent” of the Galactic Center ChimneyX-rays from a Central “Exhaust Vent” of the Galactic Center Chimney
X-rays from a Central “Exhaust Vent” of the Galactic Center Chimney
 
FORENSIC CHEMISTRY ARSON INVESTIGATION.pdf
FORENSIC CHEMISTRY ARSON INVESTIGATION.pdfFORENSIC CHEMISTRY ARSON INVESTIGATION.pdf
FORENSIC CHEMISTRY ARSON INVESTIGATION.pdf
 
Soil and Water Conservation Engineering (SWCE) is a specialized field of stud...
Soil and Water Conservation Engineering (SWCE) is a specialized field of stud...Soil and Water Conservation Engineering (SWCE) is a specialized field of stud...
Soil and Water Conservation Engineering (SWCE) is a specialized field of stud...
 

The Computing Continuum.pdf

  • 1. The Computing Continuum: Beyond the Cloud Data Centers Dragi Kimovski Pre-submission Habilitation Talk Klagenfurt University 30.06.2022
  • 2. About me Dragi Kimovski Postdoc assistant with “Zielvereinbarung” Previous positions: • 2016-2018 Senior Researcher and Lecturer, University of Innsbruck, Austria • 2013-2019 Assistant Professor, University of Information Science and Technology, Macedonia • 2009-2013 Teaching Assistant, University of Information Science and Technology, Macedonia Visiting positions: • University of Utrecht, Netherlands (December 2022) • University of Michigan - Ann Arbor, US • University of Bologna, Italy • University of Granada, Spain Project experience: • H2020 ASPIDE (2018-2021), Scientific coordinator • H2020 Entice project (2016-2018), WP leader and integration manager • H2020 DataCloud (2021-2023), WP leader • FFG KärntnerFog (2022-2024), WP Leader • OeAD AtomicFog (2018-2020), Coordinator Publications: Over 50 publications in Journals and Conferences 2
  • 3. Dragi Kimovski Postdoc assistant with “Zielvereinbarung” Teaching experience: • Distributed systems, Distributed computing infrastructures, Cloud computing and IoT, Advanced programming in C++ @ University of Klagenfurt, Austria • Parallel Systems, Distributed Systems@ University of Innsbruck, Austria • Parallel computing, High performance computing, Computing organization, Computer networks, Computing systems configuration, Programming @ University of Information Science and Technology, Macedonia • Parallel processing @ Technical University of Sofia, Bulgaria Supervision: • 13 Bachelor thesis (2 in progress) • 3 Master thesis (5 thesis in progress) • 2 PhD thesis (Co-supervision) 3 About me
  • 5. Cloud computing and Internet of Things 5
  • 6. The computing continuum and Internet of Things Jetson Nano 6
  • 7. Added value of the computing continuum Reduction of the amount of data being sent to the Cloud Faster response times Support for new applications (Smart cities, e-health, …) 7 Improved data security Reduced CO2 emissions
  • 8. Is the computing continuum “magical”? 8 • Can the computing continuum solve the computational issues related to the emerging Internet of Things application? • The answer is: Na ja.
  • 9. Issues (At least some of them) Heterogeneity of devices Devices can move Application distribution 9 Various control domains Data management and distribution
  • 10. 10 Open problems and questions How to predict the mobility and the behavior of the resources? How to optimize storage repositories? How to parallelize and distribute monolithic applications? How to characterize the resources and the computing continuum architecture? How to adaptively place and schedule IoT applications? Resources characterization Placement and scheduling Mobility patterns prediction Application distribution Storage optimization
  • 12. The heterogenity of the computing continuum • The heterogeneity of the computing continuum raises multiple application management challenges: – where to offload an application from the cloud to the fog or to the edge. • Large diversity of the devices: – single-board computers such as Raspberry Pis; – powerful multi-processor servers. 12
  • 13. Performance characterisation • To answer this question it is essential to characterize the performance of the resources across the computing continuum. • We present an analysis of: • computational and network performance; • carbon emissions. • The main goal is to support the decision process for offloading an application.
  • 14. The Carinthian Computing Continuum – C3 Table 1: Description of the resources available in the C3 testbed. Conceptual layer Device / Instance type Architecture (v)CPU Memory [GiB] Storage [GiB] Network Physical processor Clock [GHz] Operating system Cloud layer AWS t2.micro 64-bit x86 1 1 32 Moderate Intel Xeon  3.1 Ubuntu 18.04 AWS c5.large 2 4  10 Gbps Intel Xeon Platinum 8000 series  3.6 AWS m5a.xlarge 4 16 AMD EPYC 7000 series  2.5 Fog layer Exoscale Tiny 64-bit x86 1 1 32  10 Gbps Intel Xeon  3.6 Ubuntu 18.04 Exoscale Medium 2 4 Exoscale Large 4 8 ITEC Cloud Instance 4 8 Intel Xeon Platinum 8000  3.1 Edge layer Edge Gateway System 64-bit x86 12 32 32  10 Gbps AMD Ryzen Threadripper 2920X  3.5 Ubuntu 18.04 Raspberry Pi 3B 64-bit ARM 4 1 64  1 Gbps Cortex - A53  1.4 Pi OS Buster Raspberry Pi 4 4 Cortex - A72  1.5 Jetson Nano 4 Tegra X1 and Cortex - A57  1.43 Linux for Tegra R28.2.1 2.2 Fog layer 112 The fog layer comprises computing infras- 113 tructures consolidated in small data-centers 114 in close vicinity to the data sources. This layer 115 comprises resources from two providers in 116 the C3 testbed [4]: Exoscale and University of 117 Klagenfurt. We allocate these providers in the 118 fog layer as a result of the low round-trip com- 119 munication latency ( 7 ms) and high band- 120 width ( 10 Gbps). The Exoscale cloud com- 121 prises data centers in Vienna and Klagenfurt 122 (Austria). We selected three computing opti- 123 mized x86-64 instances from the Exoscale 124 cloud offering: Tiny, Medium and Large. 125 University of Klagenfurt provides a private 126 cloud infrastructure operated by OpenStack 127 3 Benchmark applications 150 We selected three representative appli- 151 cation classes with complementary require- 152 ments to evaluate the computational perfor- 153 mance and the CO2 emissions of the com- 154 puting continuum. 155 3.1 Video encoding 156 Video encoding allows transmission of 157 video content with different qualities over 158 limited and heterogeneous communication 159 channels. It compresses an original raw video 160 to reduce its effective bandwidth consump- 161 tion, while maintaining a subjective high qual- 162 ity for viewers. Video encoding has wide fields 163 of applications, including content delivery (live 164 and on-demand video streams), traffic control 165 14
  • 15. Video encoding • Ffmpeg version 3.4.6 with the most popular H.264/MPEG-4 video encoder. • Raw video segment with length of 4 second and size of 514 MB. rge tion nce Fm- ular by We eg- MB, deo HD- ates ding urce achieved the lowest encoding and transfer 233 time due to the low utilization rate and its high 234 computing and networking capabilities. R P i 3 B R P i 4 J e t s o n E G S E S T i n y E S M e d i u m E S L a r g e A W S t 2 . m i c r o A W S c 5 . l a r g e A W S m 5 a . x l a r g e 0 10 20 30 40 30.6 4.8 3.6 0.4 1 0.68 0.75 4.7 0.7 0.6 32.3 5.5 4 0.5 1.4 0.89 0.93 4.7 0.8 0.7 36.3 8.2 6.4 0.9 3.1 1.4 1.2 5.2 1.4 1.3 Execution time [s] HD-Ready (720p) Full HD (1080p) Quad HD (1440p) (a) Average encoding time. 200 7.5 170.6 63.8 4 Performance evaluation 191 4.1 Video encoding 192 We evaluate the encoding performance 193 of the computing continuum using FFm- 194 peg version 3.4.6 with the most popular 195 H.264/MPEG-4 video encoder4 deployed by 196 more than 90% of the video industry5 . We 197 perform the encoding on a raw video seg- 198 ment with length of 4 s and size of 514 MB, 199 available in the Sintel6 video-set. The video 200 segment is encoded in three resolutions (HD- 201 ready, Full HD and Quad HD) with data rates 202 of 1500, 3000, and 6500 kbps. 203 Figure 2 depicts the average encoding 204 time and transfer time, from the video source 205 (located at the University of Klagenfurt) to 206 the encoding device or instance, for a single 207 raw video segment in the three resolutions. 208 The standard deviation ranges from 1.3% 209 for the AWS m5a.xlarge instance to 3.6% 210 for the Raspberry Pi 3B devices. We ob- 211 serve that the older generation single-board 212 computers (Raspberry Pi 3B) have a signif- 213 icantly higher encoding time than the other 214 resources. However, the Raspberry Pi 3B 215 devices provide lower transfer times than the 216 cloud instances and are suitable for video-on- 217 demand services employing offline encoding. 218 The Raspberry Pi 4 and the Jetson Nano de- 219 R P i 3 B R P i 4 J e t s o n E G S E S T i n y E S M e d i u m E S L a r g e A W S t 2 . m i c r o A W S c 5 . l a r g e A W S m 5 a . x l a r g e 0 10 20 30 40 30.6 4.8 3.6 0.4 1 0.68 0.75 4.7 0.7 0.6 32.3 5.5 4 0.5 1.4 0.89 0.93 4.7 0.8 0.7 36.3 8.2 6.4 0.9 3.1 1.4 1.2 5.2 1.4 1.3 Execution time [s] HD-Ready (720p) Full HD (1080p) Quad HD (1440p) (a) Average encoding time. R P i 3 B R P i 4 J e t s o n E G S E S T i n y E S M e d i u m E S L a r g e A W S t 2 . m i c r o A W S c 5 . l a r g e A W S m 5 a . x l a r g e 0 50 100 150 200 12.5 5.1 9.2 5.1 74.5 63.1 67.1 157.5 170.6 163.8 Transfer time [s] (b) Average raw video segment transfer time. Figure 2: Average encoding performance of a 4 s long video segment with the x264 codec and FFmpeg 3.4.6. 15
  • 16. Machine learning • Tensor Flow training: – A quantum neural network using the MNIST data-set limited to 20000 samples with a size of 3.3MB with 90% accuracy; – A convolutional neural network using the Kaggle data-set with a size of 218MB with 80% accuracy. enarios ages: ng the amples rio cre- ers and r to the each a 0%. ing the 18 MB. s 80%. e layers er uses e range we use tization nsions. execu- network e train- the de- raining. m 1.2% 4% for aluation neural is significantly higher for the convolutional 296 neural network, the cloud and fog resources 297 outperform the edge devices, except EGS. 298 Recommendation. We recommend the 299 model training with large data-sets and 300 multiple layers in the cloud or on dedicated 301 systems (such as EGS), whenever possible. 302 We recommend offloading to the edge only 303 when the training data is of limited size, or 304 when the neural network has few layers. R P i 3 B R P i 4 J e t s o n E G S E S T i n y E S M e d i u m E S L a r g e A W S t 2 . m i c r o A W S c 5 . l a r g e A W S m 5 a . x l a r g e 0 100 200 300 400 500 54.1 35.6 40.1 6.2 8.4 8.7 8.4 5.3 6.2 8.6 1,630 1,050 432 65.2 210.2 192.1 134.26 220.1 178.83 180.3 Execution time [s] Quantum neural network Convolutional neural network (a) Average training time. 80 .3 1 The convolutional network has three layers 262 with a kernel size of three. Each layer uses 263 increasingly higher filter sizes in the range 264 [32, 64, 128]. After each layer, we use 265 a max-pooling sample-based discretization 266 process to reduce the spatial dimensions. 267 We repeat the training five times. 268 Figure 3 analyzes the average execu- 269 tion time for training the two neural network 270 types and the transfer times of the train- 271 ing data from centralized storage to the de- 272 vice or instance that performs the training. 273 The standard deviation ranges from 1.2% 274 for the Raspberry Pi 4 devices to 5.4% for 275 the AWS t2.micro instance. The evaluation 276 shows that the less complex quantum neural 277 network requires a relatively lower training 278 time across all resources. The old generation 279 single-board computers show again a lower 280 performance, and their suitability for training 281 heavily depends on the size of the training 282 data and the model. The other fog and edge 283 devices provide similar performance to the 284 cloud resources. The single-board computers 285 provide lower training performance for the 286 convolutional network. The only exception are 287 the Jetson Nano devices able to train the 288 convolutional network up to four times faster 289 than the Raspberry Pi devices. In general, 290 the EGS provides the lowest training time 291 R P i 3 B R P i 4 J e t s o n E G S E S T i n y E S M e d i u m E S L a r g e A W S t 2 . m i c r o A W S c 5 . l a r g e A W S m 5 a . x l a r g e 0 100 200 300 400 500 54.1 35.6 40.1 6.2 8.4 8.7 8.4 5.3 6.2 8.6 1,6 1,0 432 65.2 210.2 192.1 134.26 220.1 178.83 180.3 Execution time [s] Quantum neural network Convolutional neural network (a) Average training time. R P i 3 B R P i 4 J e t s o n E G S E S T i n y E S M e d i u m E S L a r g e A W S t 2 . m i c r o A W S c 5 . l a r g e A W S m 5 a . x l a r g e 0 20 40 60 80 0.1 0.1 0.1 0.1 0.4 0.4 0.4 1 1 1 5.4 2.2 3.9 2.1 32.2 27.3 29.1 68.3 65.1 68 Transfer time [s] Data-set (Quantum neural network) Data-set (Convolutional neural network) (b) Average training data transfer time. Figure 3: Average training and data transfer 16
  • 17. Carbon emissions analysis • We evaluate the power consumption of the physical devices used for the convolutional neural network training in TensorFlow. – We use a digital multimeter to physically measure the average electrical current; – We rely on an AWS research report to approximate the power consumption of the fog devices and cloud instances. S E S T i n y E S M e d i u m E S L a r g e A W S t 2 . m i c r o A W S c 5 . l a r g e A W S m 5 a . x l a r g e 55.1 65.3 61.2 26.9 24.8 25.2 0.94 7.1 7 7 22.1 20.7 20.1 R P i 3 B R P i 4 J e t s o n E G S E S T i n y E S M e d i u m E S L a r g e A W S t 2 . m i c r o A W S c 5 . l a r g e A W S m 5 a . x l a r g e 0 1 2 3 4 5 6 1 0.7 0.71 1.5 2.3 4.1 3.9 2.4 3.8 5.4 Carbon emission [g] Carbon emissions Figure 6: Carbon footprint for training a neural 17
  • 18. What we learned • We compiled a set of recommendations for practitioners on where to offload their applications across the computing continuum. • However, is this enough for proper application management? Recommendations for application offloading across the computing co Application Requirement Low network load Low execution time Low CO2 emissions Video encoding Edge/Fog Cloud Edge Machine learning Edge Cloud/Fog Edge In-memory analytic Cloud/Fog Cloud Edge ional Conference on the Internet of Things Prodan, R., Barrionuevo, J. J. D., Fahringer, ay). A multi-objective approach for workflow n heterogeneous environments. In 2012 12th International Symposium on Cluster, Cloud puting, and communication in UAV swa Radu Prodan is professor in distribute ITEC, Klagenfurt University. He receive gree in 2004 from the Vienna University and was Associate Professor until 201 versity of Innsbruck (Austria). His rese Research papers: 1. Dragi Kimovski, Josef Hammer, Narges Mehran, Hermann Hellwagner and Radu Prodan, “Cloud, Fog or Edge: Where to Compute”, IEEE Computing Magazine, 2021. 2. Roland Matha, Dragi Kimovski, Anatoliy Zabrovsky, Christian Timmerer and Radu Prodan, “Where to Encode: A Performance Analysis of x86and Arm-based Amazon EC2 Instances”, eScience 2021. 18
  • 20. Placement and scheduling • To efficiently place and schedule complex distributed applications’ workflows in heterogeneous environment, with limited computing and storage capacity. 20
  • 21. Approach • To cope with the complexity of the problem we apply multi-objective approach. • Searching for a set of non- dominated scheduling/placements of applications on the continuum. • An automated decision-making module to select an appropriate solution. 21
  • 22. Approach • Objectives: • Time à lower completion time; • Energy à reduce energy consumption; • Cost à reduce monetary cost. • Constrained on devices in the computing continuum that tend to move (roam) less. 22
  • 23. Objectives • Time objective: • The computation time; • The time required for transferring data among components. Computation time rk rj mi pred (mi) 23
  • 24. Objectives • Energy objective: • Energy for executing the component on a device; • Energy for receiving data; • Static energy consumption for maintaining the device active. 24
  • 25. Objectives • Cost objective: • Processing the application on CPUj • Storing the data on STORj • Communication cost between resources 25
  • 26. The scheduling and placement problem i | i 2 N, 0  i   }, where |M|= . Each decision vari- ble i is the placement of one component mi onto a source: i = plc (mi). The goal is to find a placement c(A) for an application A that assigns all its components the set R of resources that minimizes the three objectives: 8 > > > < > > > : f1(T) = min plc(A)=R T(A,R); f2(E) = min plc(A)=R E(A,R); f3(C) = min plc(A)=R C(A,R). (11) Searching an optimal placement plc(A) results in a set solutions, which must satisfy the processing, memory nd storage constraints on device rj = (CPUj, MEMj, STORj) signed to each component mj, and the movement proba- lity of a device rj within a given time window P W rj (s): to the set R of resources that minimizes the three objectives: 8 > > > < > > > : f1(T) = min plc(A)=R T(A,R); f2(E) = min plc(A)=R E(A,R); f3(C) = min plc(A)=R C(A,R). (11) Searching an optimal placement plc(A) results in a set of solutions, which must satisfy the processing, memory and storage constraints on device rj = (CPUj, MEMj, STORj) assigned to each component mj, and the movement proba- bility of a device rj within a given time window P W rj (s): 8 > > < > > : CPU (mi) < CPUj; MEM (mi) < MEMj; STOR (mi) < STORj; P W rj (s) < km. (12) where k is a mobility constraint coefficient defined by • We utilize NSGA-II to tackle this NP-complete optimization problem 26
  • 27. Mobility constraint • Improve application scheduling by addressing the mobility characteristics of the Fog/Edge devices in the computing continuum. • Prediction of the mobility allows to optimize: • Application placement: select the device having lowest mobility; • Priority scheduling: assign „harder“ tasks to less mobile devices and vice versa. 27
  • 28. Mobility characterization • By modeling the devices in the continuum 𝑟 ! through (first order) discrete Markov chains (MC). • Calculates the probability of a system to reach a particular state in future. • Consists of (already specialized): • Finite set of states, i.e. {𝑆", 𝑆#, 𝑆$}. • 𝑆" − 𝐷𝑖𝑠𝑐𝑜𝑛𝑛𝑒𝑐𝑡𝑒𝑑; • 𝑆# − 𝐶𝑜𝑛𝑛𝑒𝑐𝑡𝑒𝑑; • 𝑆$ − 𝑅𝑜𝑎𝑚𝑒𝑑. 𝑆! 𝑆" 𝑆# " 1 3 0 " 2 3 0 1 " 3 4 0 0 " 1 4 28
  • 29. Markov chain mobility prediction • Given a MC for a (𝑤, 𝑑) – tuple and the functions: – 𝑖𝑛𝑑𝑒𝑥 𝑟 ≔ 𝑅𝑒𝑡𝑢𝑟𝑛𝑠 𝑡ℎ𝑒 𝑙𝑜𝑤𝑒𝑠𝑡 𝑖𝑛𝑑𝑒𝑥 𝑐𝑜𝑛𝑡𝑎𝑖𝑛𝑖𝑛𝑔 𝑡ℎ𝑒 𝑚𝑎𝑥𝑖𝑚𝑢𝑚 𝑜𝑓 𝑡ℎ𝑒 𝑣𝑒𝑐𝑡𝑜𝑟 𝑟 ∈ 0, 1 ! × # – 𝑠𝑡𝑎𝑡𝑒 𝑖𝑛𝑑𝑒𝑥 ≔ ; 𝑖𝑛𝑑𝑒𝑥 = 1 → 𝑆$ 𝑖𝑛𝑑𝑒𝑥 = 2 → 𝑆% 𝑖𝑛𝑑𝑒𝑥 = 3 → 𝑆& • We can derive the next state that is most likely to occur by: 𝑠$%& = 𝑠𝑡𝑎𝑡𝑒 𝑖𝑛𝑑𝑒𝑥 𝜋 ⋅ (𝑃!! '( )$ / 𝑖 ∈ ℕ 𝑖𝑠 𝑡ℎ𝑒 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑡𝑟𝑎𝑛𝑠𝑖𝑡𝑖𝑜𝑛𝑠 = 𝜋 ⋅ 𝑃!) "# ⋅ … ⋅ 𝑃!) "# = 𝑖 𝑡𝑖𝑚𝑒𝑠 29
  • 30. Case studies Mental health care Insulin pump 7: end if 8: end for 9: return True . Constraints fulfilled 10: end function Algorithm 3 mMAPO automated decision making 1: function DECISION_MAKING(Y ) 2: Input: ! OPV . Objective priority vector 3: IC initiate_centroids( ~ OPV ) 4: CP cluster_pareto(Y, IC) 5: returnselect_pareto_solution(CP) 6: end function IoT micro-sensors embedded in the patient body [33]. The sensors send the blood sugar information to the resources executing machine learning algorithms to create a model that identifies the patient state variation and computes the proper level of insulin upon abnormal state detection. Afterwards, the pump controller receives the information through eight components interacting as in Fig. 4: • Compute blood sugar level of the patient; • Compute insulin level and store it in a remote database; • Retrieve patient records from the database; • Review values of a patient for taking proper decisions; • Send to doctor the blood sugar for review of insulin intake; • Send review results back with the proper insulin dose based on the patient history. • Compute pump command and adjust miniaturized pump pressure to avoid the risk of falling into coma; • Control insulin pump needle for delivering the correct dose. 6.2 Mental healthcare This application manages near real-time information of pa- tients who suffer from mental disorders [33] in a number of UK hospitals (Fig. 5). Due to privacy concerns, the patients may not always attend the same clinic and need support through appointments and emergency services: • Determine mental state for a specific patient’s record; • Decompose the safety concern for the patient to prevent Compute insulin level doctor Compute pump command insulin pump Log insulin dose patient records  sensor pump Review values blood   sugar Figure 4. Insulin pump application. Decom- pose the safety concern Mental health act Find the closest clinic Generate record for medical staff  Smart wearable device  Emergency services Determine  mental states Summarize View patient history Figure 5. Mental healthcare application. 7 EXPERIMENTAL SIMULATION We implemented the mMAPO Pareto analysis algorithm in the jMetal [34] framework and integrated within the Sched- uler of the ASKALON environment. We created elaborate simulation scenarios using iFogSim [14], which considers the computational and storage characteristics of both the Edge devices and the Cloud virtual machine instances. 7.1 Experimental design We evaluated the benefits of mMAPO for application place- ment compared to three state-of-the-art methods: 1) Fog Service Placement Problem (FSPP) [11] based on linear inte- ger programming model focused on reducing the economic cost and improving resources utilization; 2) Edge-ward de- lay-priority (EW-DP) [8] that implements a hierarchical best fit algorithm to cope with users mobility; and 3) Best-fit Queue (BQ) [12] as a queuing algorithm that reduces the completion time by primarily using Edge devices. We con- sidered completion time, energy consumption and economic cost for executing a request from the IoT sensors until the final data collection at another device or end-user. 6 nents ri) _ filled filled ector The urces model putes ction. ation ase; ns; sulin Table 1 Resource requirements per component. Application CPU [MI] MEM [MB] Storage [MB] Insulin pump 200 – 2000 10 – 60 256 – 1024 Mental healthcare 200 – 2000 10 – 50 256 – 512 Compute insulin level Send to doctor Compute pump command Control insulin pump Log insulin dose Retrieve patient records Blood  sensor Insulin pump Review values Compute blood   sugar Figure 4. Insulin pump application. Decom- pose the safety concern Mental health act Find the closest clinic Generate record for medical staff  Smart wearable device  Emergency services Determine  mental states Summarize View patient history Figure 5. Mental healthcare application. 7 EXPERIMENTAL SIMULATION We implemented the mMAPO Pareto analysis algorithm in the jMetal [34] framework and integrated within the Sched- uler of the ASKALON environment. We created elaborate simulation scenarios using iFogSim [14], which considers the computational and storage characteristics of both the 6 Table 1 Resource requirements per component. Application CPU [MI] MEM [MB] Storage [MB] Insulin pump 200 – 2000 10 – 60 256 – 1024 Mental healthcare 200 – 2000 10 – 50 256 – 512 Send to doctor Control insulin pump Retrieve patient records Blood  sensor Insulin pump Compute blood   sugar 30
  • 31. Evaluation (placement and scheduling) Figure 3: Insulin pump application completion time, energy consumption, and economic cost for different data size Figure 4: Mental health care application completion time, energy consumption, and economic cost for different CPU load 31
  • 32. Evaluation (mobility prediction) Figure 5: Experimental evaluation of the Markov chain single-transition mobility prediction model Figure 6: Average request probability failure 32 1,000 2,000 4,000 0 50 INSTR [MI] Co 1,000 2,000 4,000 0 1,000 INSTR [MI] Energ 1,000 2,000 4,000 0.5 1 INSTR [MI] Ec Figure 11. Mental healthcare application time, energy, and cost for different CPU workloads. 0 25 50 100 200 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 Number of prediction samples per device Execution time [ s ] 25 50 100 200 80 90 100 Number of prediction samples per device Accuracy [%] 0 25 50 100 80 90 100 Number of single-step predictions per device Accuracy [%] DPM IDV Figure 12. Experimental evaluation of the Markov chain single-transition mobility prediction model. 9.4 Request failure probability This section evaluates the effect of the mobility on the request failure probability for executing the mental health application. We performed a series-based reliability analysis [39] that identifies the average time spent by the Edge devices in a connected Sc or roamed Sr state in the four ime windows W defined in Section 9.2: Morning (MO), Forenoon (FN), Afternoon (AN) and Night (NI). The empir- cal analysis shows that the average connected or roamed ime T for each time window W is 2790 s, 2888 s, 3322 s and 2442 s, respectively. We therefore utilize this informa- ion to create probability function for a request failure f in failure rate. In contrast, FSPP primarily relies on the Cloud infrastructures with limited use of Edge devices, which results in a relatively low failure probability of around 35%. The introduction of the mobility prediction reduced the failure probability of mMAPO to less than 10%. The high probability of a request failure in EW-DP, BQ and FSPP indirectly increases the energy and execution costs by a factor of two to six compared to mMAPO. 9.5 Complexity and quality analysis We investigate the ability of mMAPO to provide optimized MO FN AN NI 0 20 40 60 80 100 Window W Requests probability failure [%] FSPP mMAPO EW-DP BQ Figure 13. Average request probability failure for mental healthcare application. Cloud. Moreover, the mMA Edge devices can reduce th up to 80%. The results also s is more energy efficient for require high performance r munication latency has a l time than the data size. L devices can have large impa proper consideration durin REFERENCES [1] What edge computing me
  • 33. 04 Storage optimization and distribution
  • 34. IoT application storage repositories • The modern methods for IoT applications delivery utilize virtualization as an efficient tool for software packaging. • This is usually done using virtual machine images (VMI) or containers. • The VMIs and containers are stored in either centralized or distributed storage repositories. 34
  • 35. IoT application storage repositories • Unfortunately, these repositories are not optimized and are not able to transparently distribute VMIs based on the IoT application requirements and usage history. • Therefore, we present a novel multi-objective middleware for the management of VMIs in federated computing continuum repositories with replication support. 35
  • 36. The ENTICE optimization middleware • The ENTICE middleware provides easy to use interface capable of receiving unmodified and functionally complete VM images from its users. • It can transparently distribute the VMIs to a specific infrastructure in a federation concerning their size, configuration, and geographical distribution, such that they are loaded, delivered, and executed faster and with improved QoS compared to their current behavior. 36 Multi-objective Middleware for Distributed VMI Repositories in Federated Cloud Environment 305 Fig. 5.1. Top level view of the Multi-objective Optimization Framework for VM Image distribution
  • 37. The ENTICE middleware data flow 37 .1 VMI cost objective model the cost objective, we use the notion of the financial resources required to store particular VMI in a given repository site Cstorage and the t for transferring the data from the initial to the new repository in the federation Ctransfer. For each VMI, we calculate the cost objective by addin two components C = Cstorage + Ctransfer. URE 5 Virtual machine image redistribution framework flowchart
  • 38. Evaluation (Repository optimization) 38 13 of 16 1 0.8 0.6 0.4 0.2 0 0 200 400 600 800 1000 1200 1400 1600 Value of replication coeficient − K Execution time (ms) hm execution time for different values of k hm execution time for different numbers of individual evaluations n framework with replication support has been evaluated on the bases of the quality of the Pareto optimal solutions 1 0.8 0.6 0.4 0.2 0 0 200 Value of replication coeficient − K FIGURE 8 Optimization algorithm execution time for different values of k FIGURE 9 Optimization algorithm execution time for different numbers of individual evaluations Furthermore, the optimization framework with replication support has been evaluated on the bases of the quality of the Pareto optimal s fordifferentvaluesofthegeneticparameters,suchasnumberofindividualsandnumberofevaluations/generations.Theassessmentwasco for a specific scenario enclosing the redistribution of 100 VMIs with replication coefficient k = 1. The hypervolume indicator24 has been compare the quality of the separate solutions provided during the experiments. Figure 10 presents a comparison of the mean value and deviation of the quality of the solutions in contrast to the number of utilized individuals and performed evaluations per experiment. By a the results, it can be concluded that in the cases when low computational time is required, it is essential to reduce both the number of in and performed evolutions, thus guaranteeing best computational performance to quality ratio. Contrary, when the computational time issue, like in the case of off-line VMI redistribution, higher populations sizes with increased number of evolutions should be used. For ex the case when 100 individuals are being utilized, we can expect best quality of the solutions when less then 5000 separate individual eva are performed. Above this threshold, the low number of individuals can easily lead to low diversity and reduced search capabilities, thus p solutions with limited hypervolume values. In the case of ENTICE, the redistribution and replication are performed off-line, thus requi population size and increased number of evolutions. T o better illustrate the difference in quality among the solutions, on Figure 11, we p comparison between the best solutions gathered from the experiments with 100 and 500 individuals. Lastly, in T able 3, we provide a comprehensive review of the exact objective values for the optimal trade-off distribution solutions calcu the optimization framework. Moreover, a comparison has been presented with a set of mapping solutions determined by using nonoptimize robin” mapping model for storing VMIs, and a multi-objective redistribution algorithm without replications support.17 The cost objecti been calculated based on the publicly provided price list for storing data in the Cloud by public companies, such as Amazon S3 and Microso The delivery time (performance) objective has been modeled based on the reported communication performance measures for 10 Gbit an KIMOVSKI ET AL. imal solutions in contrast with the number of individuals 14 of 16 KIMOVSKI ET AL. FIGURE 10 Quality of the optimal solutions in contrast with the number of individuals FIGURE 11 Visualized comparison of the best and worst solutions provided by the optimization framework TABLE 3 Comparison between different virtual machine image redistribution strategies Figure 7: Optimization algorithm scalability for different replication coefficients Figure 8: Optimization algorithm scalability with and without replication Figure 9: Quality of the repository optimization solutions Figure 10: Analysis of the optimization solutions
  • 39. 39 Summary and future directions
  • 40. Summary and future work • We proposed a new resource characterisation approach with pollutants emissions analysis. • We researched and developed a multi-objective scheduling approach with a Markov-chain based model for predicting when an edge device might move (roam) within the computing continuum. • We introduced a novel middleware for optimisation of the storage distribution of the IoT applications across the computing continuum. • In future we plan to merge the developed software in a single toolset for management of IoT applications across the computing continuum. 40
  • 41. References 41 Research papers: 1. Dragi Kimovski, Sasko Ristov and Radu Prodan, “Decentralized Machine Learning for Intelligent Health Care Systems on the Computing Continuum”, IEEE Computer Magazine, 2022. 2. Dragi Kimovski, Josef Hammer, Narges Mehran, Hermann Hellwagner and Radu Prodan, “Cloud, Fog or Edge: Where to Compute”, IEEE Internet Computing Magazine, 2021. 3. Roland Matha, Dragi Kimovski, Anatoliy Zabrovsky, Christian Timmerer and Radu Prodan, “Where to Encode: A Performance Analysis of x86and Arm-based Amazon EC2 Instances”, eScience 2021. 4. Vincenzo De Maio and Dragi Kimovski, “Multi-objective scheduling of extreme data scientific workflows in Fog”, Future Generation Computer Systems, Volume 106, 2020, pp. 171-184. 5. Narges Mehran, Dragi Kimovski and Radu Prodan, “MAPO: A Multi-Objective Model for IoT Application Placement in a Fog Environment”, Proceedings of the 9th International Conference on the Internet of Things, 2019, pp. 1-8. 6. Dragi Kimovski, Narges Mehran, Christopher Kerth and Radu Prodan, , “Mobility-Aware IoT Application Placement in the Cloud -- Edge Continuum”, IEEE Transactions on Services Computing, 2021. 7. Dragi Kimovski, Julio Ortega, Andres Ortiz and Raul Banos, “Parallel alternatives for evolutionary multi-objective optimization in unsupervised feature selection”, Elsevier Expert Systems with Applications No.9/Vol.42, 2015 8. Dragi Kimovski, Julio Ortega, Andres Ortiz and Raul Banos, “Leveraging cooperation for parallel multi-objective feature selection in high-dimensional EEG data”, Concurrency and Computation: Practice and Experience No.18/Vol.27, 2015 9. Dragi Kimovski, Julio Ortega, Andres Ortiz and Raul Banos “Feature selection in high-dimensional EEG data by parallel multi- objective optimization”, 2014 IEEE International Conference on Cluster Computing, 2014 10. Nishant Saurabh, Dragi Kimovski, Francesco Gaetano and Radu Prodan, ”A Two-Stage Multi-Objective Optimization of Erasure Coding in Overlay Networks”, CCGrid 2017, Madrid, Spain 2017 11. Dragi Kimovski, Attila Marosi, Sandi Gec, Nishant Saurabh, Atilla Kertezs, Gabor Kecskemeti, Vlado Stankovski and Radu Prodan “Distributed Environment for Efficient Virtual Machine Image Management”, Concurrency and Computation: Practice and Experience 12. Sandi Gec, Dragi Kimovski, Uros Pascinski, Radu Prodan and Vlado Stankovski “Semantic approach for multi-objective optimisation of the ENTICE distributed Virtual Machine and container images repository”, Concurrency and Computation: Practice and Experience 13. Dragi Kimovski, Nishant Saurabh, Vlado Stankovski, Radu Prodan, “Multi-Objective Middleware for Distributed VMI Repositories in Federated Cloud Environment”, Scalable Computing: Practice and Experience, No.4/Vol.17, 2016 14. Dragi Kimovski, Nishant Saurabh, Sandi Gec, Polona Stefancic, Gabor Kecskemeti, Vlado Stankovski, Radu Prodan, Thomas Fahringer, “Towards Decentralized Repository Services for Efficient and Transparent Virtual Machine Operations: The ENTICE Approach”, IEEE International Conference on Cloud Networking, CloudNet 2016, Pisa, Italy, October 2016