|
1 |
| -## @024-06-13 |
| 1 | +## 2024-06-17 |
| 2 | + |
| 3 | +### Network Simulation for Leios |
| 4 | + |
| 5 | +Discussing with researchers on some early simulations that are being worked on for Leios. |
| 6 | + |
| 7 | +* Constraint: Setup threshold on _egress_ bandwidth, then simulate diffusion of a block to downstream peers |
| 8 | + * upstream sends notificatoin (Eg. header) |
| 9 | + * downstream asks for block body if it does not have it |
| 10 | + * then it "validates" (simulated time) and advertises to neighbours |
| 11 | + * process is repeated until all peers have received the block |
| 12 | +* in the modeling of b/w limit, it does not multiplex connection bw |
| 13 | + with neighbours, e.g it send each block to one node at a time, |
| 14 | + consuming a fraction of the available b/w for each single |
| 15 | + transmission until maximum is reached |
| 16 | +* simulate 1000 nodes and then plot the number of nodes who have not received the block at time $t$ |
| 17 | + * send 500 blocks with different rates (from 1/s to 1/ms) |
| 18 | + * δ = 8 (4 inbound, 4 outbound) |
| 19 | + * b/w limit = 1Mb/s |
| 20 | + * block size ~ 1kB |
| 21 | +* when sending 10 blocks/s we observe more variation, a bit more contention as the _freshest first_ policy starts to kick in |
| 22 | +* at 1block/ms there's a much wider variation in time it takes to reach nodes |
| 23 | + * the first blocks take the longest as the queues are filling up with fresher blocks |
| 24 | + * latest blocks go faster, almost as fast as when rate is much slower, but this is also an artifact of the simulation (eg. time horizon means there's no block coming after which decreases contention) |
| 25 | +* some enhancements: |
| 26 | + * we want to model w/ larger blocks |
| 27 | + * need to notify neighbours when a block is received to stop waiting |
| 28 | + * validate results and clean-up model |
| 29 | + |
| 30 | +## 2024-06-13 |
2 | 31 |
|
3 | 32 | ### Weekly meeting
|
4 | 33 |
|
|
0 commit comments