diff --git a/docs/01_nodeos/03_plugins/producer_plugin/10_block-producing-explained.md b/docs/01_nodeos/03_plugins/producer_plugin/10_block-producing-explained.md
index 147785d519..b2bac29133 100644
--- a/docs/01_nodeos/03_plugins/producer_plugin/10_block-producing-explained.md
+++ b/docs/01_nodeos/03_plugins/producer_plugin/10_block-producing-explained.md
@@ -19,7 +19,7 @@ For simplicity of the explanation let's consider the following notations:
 
 Peer validation for similar hardware/version/config will be <= `m`
 
-**Let's consider for exemplification the following two BPs and their network topology as depicted in the below diagram**
+**Let's consider the example of the following two BPs and their network topology as depicted in the below diagram**
 
 ```
          +------+     +------+       +------+     +------+
@@ -40,25 +40,45 @@ Starting in Leap 4.0, blocks are propagated after block header validation. This
 
 Starting in Leap 5.0, blocks in a round are started immediately after the completion of the previous block. Before 5.0, blocks were always started on `w` intervals and a node would "sleep" between blocks if needed. In 5.0, the "sleeps" are all moved to the end of the block production round. 
 
-## Example 1: block arrives 110ms early (zero network latency between BP and immediate peer)
+## Example 1: block arrives 110ms early
+* Assuming zero network latency between BP and immediate BP peer.
+* Assuming blocks do not reach `m` and therefore take `w - a` time to produce.
+* Assume block completion including signing takes zero time.
 * `BP-A` has e = 120, n = 0ms, h = 5ms, a = 10ms
 * `BP-A` sends b1 at `t1-10ms` => `BP-A-Peer` processes `h=5ms`, sends at `t-5ms` => `BP-B-Peer` processes `h=5ms`, sends at `t-0ms` => arrives at `BP-B` at `t`.
 * `BP-A` starts b2 at `t1-10ms`, sends b2 at `t2-20ms` => `BP-A-Peer` processes `h=5ms`, sends at `t2-15ms` => `BP-B-Peer` processes `h=5ms`, sends at `t2-10ms` => arrives at `BP-B` at `t2-10ms`.
 * `BP-A` starts b3 at `t2-20ms`, ...
 * `BP-A` starts b12 at `t11-110ms`, sends b12 at `t12-120ms` => `BP-A-Peer` processes `h=5ms`, sends at `t12-115ms` => `BP-B-Peer` processes `h=5ms`, sends at `t12-110ms` => arrives at `BP-B` at `t12-110ms`
 
-## Example 2: block arrives 80ms early (zero network latency between BP and immediate peer)
+## Example 2: block arrives 80ms early
+* Assuming zero network latency between BP and immediate BP peer.
+* Assuming blocks do not reach `m` and therefore take `w - a` time to produce.
+* Assume block completion including signing takes zero time.
 * `BP-A` has e = 240, n = 150ms, h = 5ms, a = 20ms
 * `BP-A` sends b1 at `t1-20ms` => `BP-A-Peer` processes `h=5ms`, sends at `t-15ms` =(150ms)> `BP-B-Peer` processes `h=5ms`, sends at `t+140ms` => arrives at `BP-B` at `t+140ms`.
 * `BP-A` starts b2 at `t1-20ms`, sends b2 at `t2-40ms` => `BP-A-Peer` processes `h=5ms`, sends at `t2-35ms` =(150ms)> `BP-B-Peer` processes `h=5ms`, sends at `t2+120ms` => arrives at `BP-B` at `t2+120ms`.
 * `BP-A` starts b3 at `t2-40ms`, ...
 * `BP-A` starts b12 at `t11-220ms`, sends b12 at `t12-240ms` => `BP-A-Peer` processes `h=5ms`, sends at `t12-235ms` =(150ms)> `BP-B-Peer` processes `h=5ms`, sends at `t12-80ms` => arrives at `BP-B` at `t12-80ms`
 
-## Example 3: block arrives 16ms late and is dropped (zero network latency between BP and immediate peer)
+## Example 3: block arrives 16ms late and is dropped
+* Assuming zero network latency between BP and immediate BP peer.
+* Assuming blocks do not reach `m` and therefore take `w - a` time to produce.
+* Assume block completion including signing takes zero time.
 * `BP-A` has e = 204, n = 200ms, h = 10ms, a = 17ms
 * `BP-A` sends b1 at `t1-17ms` => `BP-A-Peer` processes `h=10ms`, sends at `t-7ms` =(200ms)> `BP-B-Peer` processes `h=10ms`, sends at `t+203ms` => arrives at `BP-B` at `t+203ms`.
 * `BP-A` starts b2 at `t1-17ms`, sends b2 at `t2-34ms` => `BP-A-Peer` processes `h=10ms`, sends at `t2-24ms` =(200ms)> `BP-B-Peer` processes `h=10ms`, sends at `t2+186ms` => arrives at `BP-B` at `t2+186ms`.
 * `BP-A` starts b3 at `t2-34ms`, ...
 * `BP-A` starts b12 at `t11-187ms`, sends b12 at `t12-204ms` => `BP-A-Peer` processes `h=10ms`, sends at `t12-194ms` =(200ms)> `BP-B-Peer` processes `h=10ms`, sends at `t12+16ms` => arrives at `BP-B` at `t12-16ms`
 
+## Example 4: full blocks are produced early
+* Assuming zero network latency between BP and immediate BP peer.
+* Assume all blocks are full as there are enough queued up unapplied transactions ready to fill all blocks.
+* Assume a block can be produced with 200ms worth of transactions in 225ms worth of time. There is overhead for producing the block.
+* `BP-A` has e = 120, n = 200ms, h = 10ms, a = 10ms
+* `BP-A` sends b1 at `t1-275s` => `BP-A-Peer` processes `h=10ms`, sends at `t-265ms` =(200ms)> `BP-B-Peer` processes `h=10ms`, sends at `t-55ms` => arrives at `BP-B` at `t-55ms`.
+* `BP-A` starts b2 at `t1-275ms`, sends b2 at `t2-550ms (t1-50ms)` => `BP-A-Peer` processes `h=10ms`, sends at `t2-540ms` => `BP-B-Peer` processes `h=10ms`, sends at `t2-530ms` => arrives at `BP-B` at `t2-530ms`.
+* `BP-A` starts b3 at `t2-550ms`, ...
+* `BP-A` starts b12 at `t11-3025ms`, sends b12 at `t12-3300ms` => `BP-A-Peer` processes `h=10ms`, sends at `t12-3290ms` => `BP-B-Peer` processes `h=10ms`, sends at `t12-3280ms` => arrives at `BP-B` at `t12-3280ms`
+
+
 Running wasm-runtime=eos-vm-jit eos-vm-oc-enable on relay node will reduce the validation time.