From c006112e4f08f7ea8013a217564941180a4dbdfc Mon Sep 17 00:00:00 2001
From: Stephen C Phillips <steve@scphillips.com>
Date: Fri, 25 May 2018 12:03:40 +0100
Subject: [PATCH] Expands conclusion to include measurement and prediction
---
docs/total-service-request-delay.md | 38 ++++++++++++++++++++---------
1 file changed, 27 insertions(+), 11 deletions(-)
diff --git a/docs/total-service-request-delay.md b/docs/total-service-request-delay.md
index c597430..3502ece 100644
--- a/docs/total-service-request-delay.md
+++ b/docs/total-service-request-delay.md
@@ -175,28 +175,26 @@ The total delay is:
total_delay = forward_network_delay + service_delay + reverse_network_delay
```
-To measure or predict the `total_delay` we need:
+To *measure* the `total_delay` we need:
```
total_delay = forward_latency + forward_data_delay + service_delay + reverse_latency + reverse_data_delay
= forward_latency
+ {(8 / 1E6) * (request_size / bandwidth) * [packet_size / (packet_size - packet_header_size)]}
- + request_size * service_function_scaling_factor / cpus
+ + service_delay
+ reverse_latency
+ {(8 / 1E6) * (response_size / bandwidth) * [packet_size / (packet_size - packet_header_size)]}
```
With:
-* forward_latency / s
-* request_size / Bytes
-* bandwidth / Mb/s (b = bit)
-* packet_size / Bytes
-* packet_header_size / Bytes
-* service_function_scaling_factor / Mflops/Byte
-* cpus (unitless)
-* reverse_latency / s
-* response_size / Bytes
+* forward_latency / s (measured by network probe)
+* reverse_latency / s (measured by network probe)
+* request_size / Bytes (measured at service)
+* response_size / Bytes (measured at service)
+* bandwidth / Mb/s (b = bit) (assumed constant and known or measured)
+* packet_size / Bytes (constant and known)
+* packet_header_size / Bytes (constant and known)
This calculation assumes:
@@ -209,3 +207,21 @@ This calculation assumes:
* that the service delay is inversely proprtional to the number of CPUs (and all CPUs are equal)
* that the compute resource is invariable, 100% available and 100% reliable
* that the distribution of API calls is constant and that the workload can be represented sufficiently by the average request size
+
+To *predict* the `total_delay` we need:
+
+```
+total_delay = forward_latency + forward_data_delay + service_delay + reverse_latency + reverse_data_delay
+ = forward_latency
+ + {(8 / 1E6) * (request_size / bandwidth) * [packet_size / (packet_size - packet_header_size)]}
+ + request_size * service_function_scaling_factor / cpus
+ + reverse_latency
+ + {(8 / 1E6) * (response_size / bandwidth) * [packet_size / (packet_size - packet_header_size)]}
+```
+
+With:
+
+* service_function_scaling_factor / Mflops/Byte (known, somehow)
+* cpus (unitless) (known)
+
+As discussed above, you could also predict the latency if you know the length of a link but this seems a bit too theoretical.
\ No newline at end of file
--
GitLab