Database Reference
In-Depth Information
This simple experiment aims to show both 1) the seamless multi-protocol
management of the library, as well as 2) the possibility for the dispatcher, de-
scribed page 68, to perform a schedule: due to its priority matching combined
with its Round-Robin algorithm, the library uses the local data first if available.
Figure 4 clearly shows this behavior, the blue region showing the time spent
during each transfer when it occurs.
Comparison of data transfer time depending on locality
(transfering 512B matrices)
Comparison of data transfer and processin
g
time depending on t
r
ansfer concurency
(transfering and processing 32 Mb matrices)
Waiting time
Transfer time
Deserializing time
6
Remote/Remote
Remote/Local
Local/Remote
Local/Local
60
Waiting time
Transfer time
Deseriali
z
ing time
Computing time
Freeing time
Computing time
Freeing time
5
50
Limit 1
Limit 2
Limit 4
Limit
8
4
40
3
30
2
20
1
10
0
0
Comp
a
rison of data trans
f
er and processing time
depending on transfer concurrency (32MB matrices)
Compariso
n
of data tr
a
nsfer time de
p
ending on locality
(transferring 512B matrices)
Limit 1
Limit 2
Limit 4
Limit 8
Remote/Remote
Remote/Local
Local/Remote
Local/Local
Number of simultaneous allowed transfers
Fig. 5.
Results for Experiment 2
Fig. 4.
Results for Experiment 1
4.2 Asynchronous Transfers Management and Bounded Number of
Simultaneous Transfers
For this experiment, we designed the following scenario: a remote procedure call
isperformedtoaddagivennumberofmatrices which are available remotely
through
ssh
. Matrices are downloaded and added as soon as the operation is
possible,
i.e.,
at first when two of them are finished to be downloaded, then
every time a new one has been downloaded and the previous computation has
finished. We performed 4 tests, corresponding to the number of simultaneous
transfers that it is possible to make at a given instant, resp. 1 unique transfer,
2, 4 and 8 transfers maximum at a given time. The number of matrices is fixed
to 16, and one matrix is 32MB (
i.e.,
2000
2000 of 64bits integers).
We designed this experiment to validate the request controller behavior,
i.e.,
the implementation of the possibility to limit the number of simultaneous trans-
fers occurring in a transfer operation, and the possibility to use the waiting
functions, here with
grpc_data_transfer()
and the
GRPC_WAIT_ANY
parame-
ter, making the server able to perform an operation as soon as enough matrices
are present on the server side (the addition was chosen for the operation since
it requires less time than a transfer, which leads to show the wanted behavior.
Besides, it also makes sense conceptually since it's a commutative operation).
Figure 5 shows the activity of the service and its duration on the y-axis, related
to the progression over the number of matrices downloaded for each limit on the
x-axis. The same evolution by group of cardinal equal to the possible limit of
both the waiting time (non-active wait) and transfer time highlights that the
number of simultaneous transfers operated by the library is indeed configurable
×
Search WWH ::
Custom Search