From 796bf1d096aad71d6571db58246835153e5cbfb1 Mon Sep 17 00:00:00 2001 From: Prati28 Date: Sat, 16 Nov 2024 13:07:45 +0530 Subject: [PATCH 1/3] record rate changes Signed-off-by: Prati28 --- docs/source/concepts/rate-controllers.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/docs/source/concepts/rate-controllers.md b/docs/source/concepts/rate-controllers.md index 59f809040..0c994c0e8 100644 --- a/docs/source/concepts/rate-controllers.md +++ b/docs/source/concepts/rate-controllers.md @@ -292,6 +292,26 @@ Offset: |0 |4 |8 |12 |16 |... Data: |length |1st |2nd |3rd |4th |... ``` +- The first entry (length) indicates the number of transactions recorded so far. +- If no transactions have been submitted yet (e.g., at the start), the first row will have a value of 0, indicating that no timings have been recorded. +- Each subsequent entry in the array represents the timestamp of a transaction being enabled (submitted) by the rate controller. + +For example, if there are 3 transactions enabled, the binary format would look like: + +```sh +Offset: |0 |4 |8 |12 +Data: |length |1st |2nd |3rd + |3 |100 |200 |300 +``` + +If no transactions are submitted, it would look like: + +```sh +Offset: |0 +Data: |length + |0 +``` + ## Replay rate One of the most important aspect of a good benchmark is its repeatability, i.e., it can be re-executed in a deterministic way whenever necessary. However, some benchmarks define the workload (e.g., user behavior) as a function of probabilistic distribution(s). This presents two problems from a practical point of view: From 5d26c36dc8f62070afa7b8256905b3aaf95d0911 Mon Sep 17 00:00:00 2001 From: Prati28 Date: Sat, 16 Nov 2024 23:28:52 +0530 Subject: [PATCH 2/3] Changes Signed-off-by: Prati28 --- docs/source/concepts/rate-controllers.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/docs/source/concepts/rate-controllers.md b/docs/source/concepts/rate-controllers.md index 0c994c0e8..097adf622 100644 --- a/docs/source/concepts/rate-controllers.md +++ b/docs/source/concepts/rate-controllers.md @@ -276,7 +276,7 @@ The template can (**and should**) contain special “variables/placeholders” t **Template placeholders**: since Caliper provides a concise way to define multiple rounds and multiple workers with the same behavior, it is essential to differentiate between the recordings of the workers and rounds. Accordingly, the output file paths can contain placeholders for the round and worker indices that will be resolved automatically at each worker in each round. Otherwise, every worker would write the same file, resulting in a serious conflict between timings and transaction IDs. -**Text format**: the rate controller saves the recordings in the following format (assuming a constant 10 TPS rate and ignoring the noise in the actual timings), row `i` corresponding to the `i`th transaction: +**Text format**: the rate controller saves the recordings in the following format (assuming a constant 10 TPS rate and ignoring the noise in the actual timings), row `i` corresponding to the `i`th transaction: ```sh 100 @@ -285,6 +285,9 @@ The template can (**and should**) contain special “variables/placeholders” t ... ``` +The value of `i` starts at **0**, so the **first line** represents **0 transactions submitted**. +Each value in a line represents **time in milliseconds** from the start of the round. + **Binary format**: Both binary representations encode the `X` number of recordings as a series of `X+1` UInt32 numbers (1 number for the array length, the rest for the array elements), either in Little Endian or Big Endian encoding: ```sh @@ -292,9 +295,9 @@ Offset: |0 |4 |8 |12 |16 |... Data: |length |1st |2nd |3rd |4th |... ``` -- The first entry (length) indicates the number of transactions recorded so far. -- If no transactions have been submitted yet (e.g., at the start), the first row will have a value of 0, indicating that no timings have been recorded. +- The first entry (length) indicates the number of transactions submitted. - Each subsequent entry in the array represents the timestamp of a transaction being enabled (submitted) by the rate controller. +- The subsequent values (Uint32 values in Big Endian or Little Endian format) represent time in milliseconds from the start of the round. Each entry corresponds to the number of transactions submitted starting from 0 For example, if there are 3 transactions enabled, the binary format would look like: From e43d61f86e1d3f6ea8e69e70468ea2a6df321c6d Mon Sep 17 00:00:00 2001 From: Prati28 Date: Fri, 22 Nov 2024 22:40:54 +0530 Subject: [PATCH 3/3] changes Signed-off-by: Prati28 --- docs/source/concepts/rate-controllers.md | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/docs/source/concepts/rate-controllers.md b/docs/source/concepts/rate-controllers.md index 097adf622..2210fca97 100644 --- a/docs/source/concepts/rate-controllers.md +++ b/docs/source/concepts/rate-controllers.md @@ -296,23 +296,15 @@ Data: |length |1st |2nd |3rd |4th |... ``` - The first entry (length) indicates the number of transactions submitted. -- Each subsequent entry in the array represents the timestamp of a transaction being enabled (submitted) by the rate controller. +- Each subsequent entry in the array represents a timestamp of when that number of transactions were submitted from the start of the round. - The subsequent values (Uint32 values in Big Endian or Little Endian format) represent time in milliseconds from the start of the round. Each entry corresponds to the number of transactions submitted starting from 0 For example, if there are 3 transactions enabled, the binary format would look like: ```sh -Offset: |0 |4 |8 |12 -Data: |length |1st |2nd |3rd - |3 |100 |200 |300 -``` - -If no transactions are submitted, it would look like: - -```sh -Offset: |0 -Data: |length - |0 +Offset: |0 |4 |8 |12 |16 +Data: |length |0 tx |1 tx |2 tx |3 tx + |4 |100 |200 |300 |400 ``` ## Replay rate