doc: rename tc files. Separate Full from Light in Test-cases

celestiaorg · Aug 29, 2022 · 575707f · 575707f
1 parent cac2736
commit 575707f
Show file tree

Hide file tree

Showing 5 changed files with 42 additions and 19 deletions.
diff --git a/docs/test-plans/001-Big-Blocks/test-cases/tc-002-da-sync.md b/docs/test-plans/001-Big-Blocks/test-cases/tc-002-da-sync.md
@@ -28,7 +28,8 @@
    2. `J` milliseconds of network latency
 2. Bridge nodes connect to respective Validators
 3. Full / Light nodes connect to Bridge Nodes
-4. Check that the latest received height is the same as for the validators
+4. Starts syncing the chain
+5. Checks that the latest received height is the same as for the validators
 
 ## Data Set:
 

diff --git a/...-Blocks/test-cases/tc-003-da-sync-past.md → ...locks/test-cases/tc-003-full-sync-past.md b/...-Blocks/test-cases/tc-003-da-sync-past.md → ...locks/test-cases/tc-003-full-sync-past.md
@@ -1,4 +1,4 @@
-# Test-Case #003 - DA nodes are syncing past headers faster then validators produce new ones
+# Test-Case #003 - Full nodes are syncing past headers faster then validators produce new ones
 
 ## Pre-Requisites:
 
@@ -31,7 +31,16 @@
 4. Check that it is synced
 5. Broadcasts new blocks to the DA network
 
-## Steps for each of DA Full / Light nodes:
+## Steps for each of the DA Light nodes:
+
+1. Setups network with:
+   1. `I` mb of bandwidth
+   2. `J` milliseconds of network latency
+2. Receives the trusted genesis hash and ip from Bridge Nodes
+3. Starts syncing the chain
+4. Check that it is synced
+
+## Steps for each of DA Full nodes:
 
 1. Setups network with:
    1. `I` mb of bandwidth

diff --git a/...-Big-Blocks/test-cases/tc-005-das-past.md → ...ocks/test-cases/tc-004-full-light-past.md b/...-Big-Blocks/test-cases/tc-005-das-past.md → ...ocks/test-cases/tc-004-full-light-past.md
@@ -1,4 +1,4 @@
-# Test-Case #005 - DA nodes are DASing past headers faster then validators produce new ones
+# Test-Case #004 - Full and Light nodes are syncing past headers faster then validators produce new ones
 
 ## Pre-Requisites:
 
@@ -38,9 +38,11 @@
    2. `J` milliseconds of network latency
 2. Receives the trusted genesis hash and ip from Bridge Nodes
 3. Waits until `N` amount of block has been produced by the chain
-4. Starts DASing the chain afterwards
-5. Checks that it can:
+4. Starts syncing the chain afterwards
+5. Light checks that it can:
    1. DASes the past headers faster then new blocks are produced (\*)
+6. Full checks that it can:
+   1. Sync the past headers faster then new blocks are produced
 
 ## Data Set:
 

diff --git a/...g-Blocks/test-cases/tc-004-das-current.md → ...ig-Blocks/test-cases/tc-005-light-past.md b/...g-Blocks/test-cases/tc-004-das-current.md → ...ig-Blocks/test-cases/tc-005-light-past.md
@@ -1,4 +1,4 @@
-# Test-Case #004 - DASing of the latest header is faster then the block production time
+# Test-Case #005 - Light nodes are DASing past headers faster then validators produce new ones
 
 ## Pre-Requisites:
 
@@ -8,7 +8,7 @@
 4. Validators’ set is not changing during test execution
    1. All validators are created during genesis
 5. DA Nodes amount is not changing during the test execution
-   1. We gracefully add DA Nodes as the first block is produced
+   1. We add DA Nodes as the first block is produced
 
 ## Steps for each of the validators:
 
@@ -31,22 +31,33 @@
 4. Check that it is synced
 5. Broadcasts new blocks to the DA network
 
-## Steps for each of DA Full / Light nodes:
+## Steps for each of the DA Full nodes:
 
 1. Setups network with:
    1. `I` mb of bandwidth
    2. `J` milliseconds of network latency
 2. Receives the trusted genesis hash and ip from Bridge Nodes
-3. Starts syncing the chain afterwards
-4. DASes the latest header faster then `T` seconds (\*)
+3. Starts syncing the chain
+4. Check that it is synced
+
+## Steps for each of DA Light nodes:
+
+1. Setups network with:
+   1. `I` mb of bandwidth
+   2. `J` milliseconds of network latency
+2. Receives the trusted genesis hash and ip from Bridge Nodes
+3. Waits until `N` amount of block has been produced by the chain
+4. Starts DASing the chain afterwards
+5. Checks that it can:
+   1. DASes the past headers faster then new blocks are produced (\*)
 
 ## Data Set:
 
-| Number of Validators / Bridges / Fulls / Lights <br /> `I` |                                Bandwidth / Latency per v/b/f/l <br /> `J`                                | KB of random data <br /> `X` | Submit amount <br /> `Y` | Block Time in seconds <br /> `T` |
-| :--------------------------------------------------------: | :------------------------------------------------------------------------------------------------------: | :--------------------------: | :----------------------: | :------------------------------: |
-|                     40 / 40 / 20 / 100                     | 1. 256(v/b/f)-100(l)MiB / 0ms <br />2. 320(v/b/f)-100(l)MiB / 100ms<br />3. 320(v/b/f)-100(i)MiB / 200ms |             100              |            10            |                30                |
-|                   100 / 100 / 50 / 1000                    | 1. 320(v/b/f)-100(l)MiB / 0ms <br />2. 320(v/b/f)-100(l)MiB / 100ms<br />3. 320(v/b/f)-100(i)MiB / 200ms |              40              |            10            |                30                |
+| Number of Validators / Bridges / Fulls / Lights <br /> `I` |                                Bandwidth / Latency per v/b/f/l <br /> `J`                                | KB of random data <br />`X` | Submit amount <br />`Y` | Amount of Past Blocks <br />`N` |
+| :--------------------------------------------------------: | :------------------------------------------------------------------------------------------------------: | :-------------------------: | :---------------------: | :-----------------------------: |
+|                     40 / 40 / 20 / 100                     | 1. 256(v/b/f)-100(l)MiB / 0ms <br />2. 320(v/b/f)-100(l)MiB / 100ms<br />3. 320(v/b/f)-100(i)MiB / 200ms |             100             |           50            |               30                |
+|                   100 / 100 / 50 / 1000                    | 1. 320(v/b/f)-100(l)MiB / 0ms<br />2. 320(v/b/f)-100(l)MiB / 100ms<br />3. 320(v/b/f)-100(i)MiB / 200ms  |             40              |           100           |               50                |
 
 ## Notes:
 
-(\*) - We need to measure the DAS time to have a baseline for further benchmarking of the new p2p stack that is implemented
+(\*) - We need to measure the DAS of past headers time to have a baseline for further benchmarking of the new p2p stack that is implemented
diff --git a/docs/test-plans/001-Big-Blocks/tp-001-big-blocks-creation-sync.md b/docs/test-plans/001-Big-Blocks/tp-001-big-blocks-creation-sync.md
@@ -75,10 +75,10 @@ The motivation behind this plan is to test how our stack(celestia-core/celestia-
 
 [Test-Case #002 - DA nodes are in sync with validators’ ](test-cases/tc-002-da-sync.md)
 
-[Test-Case #003 - DA nodes are syncing past headers faster then validators produce new ones](test-cases/tc-003-da-sync-past.md)
+[Test-Case #003 - Full nodes are syncing past headers faster then validators produce new ones](test-cases/tc-003-full-sync-past.md)
 
-[Test-Case #004 - DASing of the latest header is faster then the block production time](test-cases/tc-004-das-current.md)
+[Test-Case #004 - Full and Light nodes are syncing past headers faster then validators produce new ones](test-cases/tc-004-full-light-past.md)
 
-[Test-Case #005 - DA nodes are DASing past headers faster then validators produce new ones](test-cases/tc-005-das-past.md)
+[Test-Case #005 - Light nodes are DASing past headers faster then validators produce new ones](test-cases/tc-005-light-past.md)
 
 [Test-Case #006 - All DA nodes can submit data ](test-cases/tc-006-da-node-pfd.md)