Content uploaded by Michael Luby
Author content
All content in this area was uploaded by Michael Luby on Feb 07, 2019
Content may be subject to copyright.
Content uploaded by Michael Luby
Author content
All content in this area was uploaded by Michael Luby on Feb 07, 2019
Content may be subject to copyright.
Performance of CodornicesRq software package
(first release)
Michael Luby, Lorenz Minder, Pooja Aggarwal
International Computer Science Institute
February 5, 2019
1 Introduction
We provide performance results for the first release of the CodornicesRq soft-
ware package.1The test platform is an AMD Ryzen 5 2600 processor with a
nominal maximum frequency of 3.4 GHz. All tests are run sequentially using
the single threaded CodornicesRq library, and thus only one core is used. All
tests use a symbol size of 1,280 bytes = 10,240 bits, which is a typical payload
size for packets sent over the internet. For example, if K= 1,000 for a source
block, the source block size is 1,280,000 bytes = 10,240,000 bits.
We consider three different types of operations:
•Encode: generate Krepair symbols from a source block of Ksource sym-
bols.
–Input symbols: source symbols with identifiers h0, . . . , K −1i
–Output symbols: repair symbols with identifiers hK, . . . , 2K−1i
•Decode with no overhead: generate the Ksource symbols of a source block
from Krandom repair symbols for that source block.
–Input symbols: Krepair symbols with randomly chosen identifiers
–Output symbols: Ksource symbols
•Decode with 5% overhead: generate the Ksource symbols of a source block
from M= 1.05 ·Krandom repair symbols for that source block.
–Input symbols: Mrepair symbols with randomly chosen identifiers
–Output symbols: Ksource symbols
1We expect substantial performance improvements in future releases.
1
1 INTRODUCTION
Decode performance improves as the overhead increases. Performance also
improves as the amount of source symbols used to decode increases, as generally
it is somewhat faster to decode when source symbols are available (in particular,
there is no need to generate the already available source symbols). Thus, Decode
with no overhead results are essentially worst case, whereas Decode with 5%
overhead results are closer to what is expected in practice.
As expected, there are no decode failures in tests when decoding with 5%
overhead, and there are less than 1% decode failures in tests when decoding
with no overhead.
Compile time is defined as the time it takes to compile the program of
symbol operations that will be used to generate output symbols from the in-
put symbols for a source block. Thus, the compile time is the time to run
RqInterCompile plus the time to run RqOutCompile for the source block, where
RqInterCompile and RqOutCompile are described in [1]. (The time for the calls
to RqInterGetMemSizes,RqInterInit,RqInterAddIds,RqOutGetMemSizes,
RqOutInit, and RqOutAddIds, are essentially zero, and thus are not reported.)
Execute time is defined as the time is takes to execute the compiled program
of symbol operations to generate the output symbols from the input symbols for
a source block. Thus, the execute time is the time to run RqInterExecute plus
the time to run RqOutExecute for the source block, where RqInterExecute and
RqOutExecute are described in [1].
Execute speed, the ratio of the source block size to the execute time, is shown
in Figure 1 for various values of K. Execute speed provides an indication of
how much of the CPU is needed for execution on average, e.g., when a stream
of data arriving at 10 Mbps, less than 0.6% of the CPU is used on average for
encode execution if the stream is partitioned into source blocks using K= 1,000
and encoded to generate a 20 Mbps stream.
Execute speeds for Encode and Decode with no overhead are essentially iden-
tical, and execute speed for Decode with 5% overhead is somewhat faster. Gen-
erally, compile time is a small proportion of execute time, as shown in Figure 2.
Furthermore, in many use cases, a program can be compiled once and executed
multiple times on different source blocks, and thus the compile time can be
amortized over many executions.
Figure 3 shows the compile time and execute time raw data from which
Figure 1 and Figure 2 are derived. In Figure 3:
•The column labeled “Inter” in the “Compile Time” category is the time
to execute RqInterCompile per source block.
•The column labeled “Out” in the “Compile Time” category is the time to
execute RqOutCompile per source block.
•The column labeled “Inter” in the “Execute Time” category is the time
to execute RqInterExecute per source block.
•The column labeled “Out” in the “Execute Time” category is the time to
execute RqOutExecute per source block.
2
REFERENCES REFERENCES
References
[1] Michael Luby, Lorenz Minder, Pooja Aggarwal. How to use the Codor-
nicesRq software package. International Computer Science Institute, Febru-
ary 5, 2019.
3
LIST OF FIGURES LIST OF FIGURES
List of Figures
1 Execute speed for source blocks with Ksource symbols. The
symbol size is 1,280 bytes = 10,240 bits for each source block.
The test platform is AMD Ryzen 5 2600 @ 3.4 GHz. . . . . . . . 5
2 Compile time as a % of execute time for source blocks with K
source symbols. The symbol size is 1,280 bytes = 10,240 bits for
each source block. The test platform is AMD Ryzen 5 2600 @
3.4GHz................................. 6
3 Raw timing data (in milliseconds) from which the information in
Figure 1 and Figure 2 can be deduced. The symbol size is 1,280
bytes = 10,240 bits for each source block. The test platform is
AMD Ryzen 5 2600 @ 3.4 GHz. . . . . . . . . . . . . . . . . . . . 7
4
FIGURES FIGURES
Figure 1: Execute speed for source blocks with Ksource symbols. The symbol
size is 1,280 bytes = 10,240 bits for each source block. The test platform is
AMD Ryzen 5 2600 @ 3.4 GHz.
5
FIGURES FIGURES
Figure 2: Compile time as a % of execute time for source blocks with Ksource
symbols. The symbol size is 1,280 bytes = 10,240 bits for each source block.
The test platform is AMD Ryzen 5 2600 @ 3.4 GHz.
6