Departamentul Inginerie Software și Automatică

Specializarea Securitate Informațională

RAPORT
la disciplina Aplicații Distribuite Avansate

A elaborat: Nicolae Panfilii,

masterand al gr. SI-210M, FCIM

Examinator: Eugeniu TORICĂ,

asistent universitar, FCIM

Chișinău – 2021
 Sarcina nr. 1

1) Compilați codul propus în mapa ”default”. Rulați aplicația. Logați timpii de executare
pentru diferite valori ai parametrului n. Ca exemplu puteți lua n egal cu 5, 6, 7.
2) Scrieți o aplicație care ar paraleliza codul propus cu ajutorul librăriei OpenMP.
Algoritmul de hash va rămâne neschimbat. Logați timpii de soluționare a crypto-
puzzle-ului pentru valorile lui n din punctul 1). Schimbați numărul de fire de execuție
pentru aplicația Dvs. Rulați codul și înregistrați rezultatele în tabela de mai jos.

Tabel 1. Timpii de execuție a aplicației scrise cu ajutorul OpenMP

Număr fire 1 2 4 8 16 32
Timp
execuție

3) Să se scrie o aplicație care va paraleliza codul propus cu ajutorul librăriei OpenMPI.

Ca și în cazul precedent algoritmul de soluționare a crypto-puzzle-ului trebuie să
rămână neschimbat. Completați tabela de mai jos:

Tabel 2. Timpii de execuție a aplicației scrise cu ajutorul OpenMPI

Număr
1 2 4 8 16 32
procese
Timp
execuție

4) Scrieți un raport unde veți prezenta rezultatele din punctele 1-3.

5) Completați raportul cu următoarele date:
a) Comentați utilitatea acestor librării și limitările din punct de vedere practic în
contextul experienței pe care o aveți. În cazul lipsei experienței de dezvoltare a sistemelor,
descrieți un sistem real unde sunt procese paralele și secvențiale. Faceți o analiza a gradului
de paralelism.
b) Comentați datele din tabele în contextul legii lui Amdahl
(https://en.wikipedia.org/wiki/Amdahl%27s_law)
c) În trecut se practica păstrarea hash-ului la parola. Se alegea un oricare algoritm, de
regula MD5. Acum această practică se consideră nesigură. Explicați care este atacul și care
sunt practicile curente în acest caz.

Suport:
Se presupune că aveți disponibil un calculator care are cel puțin două nuclee fizice (Multi
core CPU).
Sistemul Dvs. poate rula Docker. În mapele openmpi şi openmp veți găsi Dockerfile pentru a
construi imaginea docker și fișier pentru a rula containerul și a face build la aplicația
dezvoltată.

Descărcați directoriul atașat. În el veți găsi mai multe fișiere cu următoarele destinații:
• lab1.cpp - conține codul sursă care trebuie paralelizat.
• compile.sh - conține comanda de gcc care compilează codul C într-un fișier
executabil.
În directoriul rădăcină mai sunt alte două directorii care conțin fișiere pentru a seta mediul
de lucru. Pentru a începe utilizarea librăriei OpenMP treceți în directoriul openmp.
Dacă sistemul Dvs. suportă docker executați: sudo ./container_build.sh - pentru a construi
containerul cu dependențele de openmp.

Pentru a rula containerul executați: sudo ./container_start.sh

Dacă comanda se execută cu succes, veţi fi în interiorul container-ului cu toate dependenţele

setate.
Pentru a compila aplicația openmp trebuie să aveţi prezent fişierul lab1_openmp.cpp şi să
executaţi în container ./compile.sh

Directoriul openmpi are un set de fișiere asemănător cu ajutorul cărora puteți dezvolta
aplicația care face uz de librăria OpenMPI.

Întrebările pot fi adresate pe email-ul: eugeniu.torica@isa.utm.md

Cărți recomandate:
https://pages.tacc.utexas.edu/~eijkhout/pcse/html/
http://perimeterinstitute.ca/personal/wcunningham/parallel.pdf
http://www.archer.ac.uk/training/course-material/2019/06/AdvOpenMP-manch/L01-
OpenMPBasics.pdf
1. Running the program with difficulty 5:

Running the program with difficulty 6:

5. a) SETI@home
The SETI@Home project involves real-time analysis of “mountains of data.” To use an old
analogy, it would be difficult to find a needle in a haystack if you were working alone.
However, thousands of people going through the same haystack are more likely to find the
wayward needle. Because of the vast diversity and inherent weakness of potential signals,
SETI requires massive amounts of computational resources to accomplish the task of finding
an extraterrestrial transmission. For this reason, they rely on distributed computation. As
described above, the raw data is easily quantized according to the necessary restrictions,
and the problem becomes embarrassingly parallel. Clients are free from communicating with
each other, only sending and receiving data from the server when necessary. Redundancy
can be implemented to account for malicious or erroneous client results, and the trick lies in
systematically gathering and categorizing the data after it has been analyzed.

The SETI@Home project is inherently parallel in nature and has adapted to changes in
consumer computing potential. Users with NVIDIA GPUs can take advantage of their
processing power with a recent version that utilizes CUDA to improve computational
performance up to 10 times that of a standard CPU. The following analysis will focus on
SETI@Home’s use of the CUDA language to increase parallelism, as well as the potential
problems in their approach.

How the problem is parallelized

As discussed above, SETI analyzes a frequency range of 2.5 MHz. SETI@Home begins by
splitting up that band into 256 manageable chunks of 9766 Hz (or approximately 10 KHz),
each of which amounts to about 107 seconds of data. Sampling at the Nyquist rate of 20
kbps, each chunk occupies about 0.25 megabytes of memory. Each of these chunks is called
a “work-unit” that is then sent to the participating users for processing. This work-unit
contains the actual data and information about the necessary processing to be performed.
Each client will receive about 340 kilobytes of data in total for each work-unit they analyze.
As the Arecibo telescope remains fixed, the time it takes for a target to cross the beam is
about 12 seconds. Thus, the expected signal that the program is looking for is a Gaussian
that peaks around the 6-second mark, about halfway through the process. The work-units
also overlap by 20 to 30 seconds to accommodate a 12-second margin that is in the
transition.
After receiving a work-unit, a client performs various tests on the data sample to find any
possible signals that fit SETI’s search criteria of either continuous or discrete (pulsed)
Gaussians (Figures a and b). As any potential signals would be transmitted across vast
distances, they are subject to the Doppler effect, or “chirping” as SETI calls it (Figures c and
d). The program begins by “de-chirping” the data, negating the skew of the signal caused by
the Doppler effect. SETI describes this process as follows:

At the finest resolution, we have to do this a total of 20,000 times, from -10 Hz/sec to +10
Hz/sec in steps of .002 Hz/sec. At each chirp-rate, the 107 seconds of data is de-chirped and
then divided into 8 blocks of 13.375 seconds each. Each 13.375 second block is then
examined with a bandwidth of .07 Hz for peaks.

These de-chirping tests are then performed in the range of ±10 Hz/sec to ±50 Hz/sec to
ensure a clean signal. Once the data has been de-chirped, similar tests are conducted at
0.15, 0.3, 0.6, 1.2, 2.5, 5, 10, 20, 40, 75, 150, 300, 600, and 1200 Hz.

SETI uses two algorithms to find pulsed signals in the data. The first, called the triplet test,
looks for two pulses that are above a threshold value and seeks a similar pulse situated
exactly between the two. The second, called the fast folding algorithm, is a rather clever
solution for finding pulses. As these pulses may be very weak, SETI breaks up the data into
chunks that are analyzed with respect to time and power. Given the right period in a time-
slice, if all of the slices are summed, then the resulting summed power will grow and be
distinct from the background noise.

Due to the natural independence of frequencies in the electromagnetic spectrum, the

frequency ranges in a certain band are mutually exclusive when split into chunks.
Considering the details of the calculations that each client performs (10 to 50 hours of work,
as SETI estimates), it is apparent that a significant amount of parallelism can be achieved
within work-units. De-chirping the data, processing Fast Fourier Transform (FFT) calculations,
fitting Gaussians to the selected data, and finding pulses all yield opportunities for
parallelizing computation. Indeed, the CUDA version of SETI@Home takes advantage of
these opportunities, though there are a few potential improvements to be considered.

Different Architectures
One of the intriguing factors of SETI@Home is that it runs on top of BOINC, a distributed
parallel platform. MPI is an alternative distributed platform that operates in a similar
fashion, but the two are quite different. To begin with, the BOINC system communicates
through the HTTP protocol, as the programmers wanted to avoid conflicts with firewalls or
session interruptions. While they use different application-layer protocols, both paradigms
use TCP to send and receive data. However, BOINC is designed to handle dynamic nodes and
distributes the data as needed; there is no run-time accommodation for new or failed nodes
in MPI. Therefore, one could potentially use MPI with a set of clients, developing a complex
protocol to serve and collect data on a distributed network of workstations.

In such an implementation of MPI, it is apparent that the server (node 0) would distribute
and gather the data. Node failure can be accommodated by reassigning chunks to nodes that
are currently active and have finished their assigned computation. Another issue to consider
is the gathering and monitoring of finished work-units. In the BOINC implementation, a
work-unit is simply shipped out to a client for computation, and the client then returns the
results to the server. There is no time limit, nor is there any issue of monitoring the “end” of
all computation. However, this is quite the opposite in MPI, as one would need to actively
monitor the current state of all data gathered to effectively “end” the program.

b) Amdahl's law applies only to the cases where the problem size is fixed. In practice, as
more computing resources become available, they tend to get used on larger problems
(larger datasets), and the time spent in the parallelizable part often grows much faster than
the inherently serial work. In this case, Gustafson's law gives a less pessimistic and more
realistic assessment of the parallel performance. An implication of Amdahl's law is that to
speedup real applications which have both serial and parallel portions, heterogeneous
computing techniques are required.

c) Rainbow table is a precomputed table for caching the output of cryptographic hash
functions, usually for cracking password hashes. Tables are usually used in recovering a key
derivation function (or credit card numbers, etc.) up to a certain length consisting of a
limited set of characters. It is a practical example of a space–time tradeoff, using less
computer processing time and more storage than a brute-force attack which calculates a
hash on every attempt, but more processing time and less storage than a simple key
derivation function with one entry per hash. A rainbow table is ineffective against one-way
hashes that include large salts. Use of a key derivation that employs a salt makes this attack
infeasible.