From 2ea7ab73c6da08bb18e1c2b114b0db0ce6ba08a3 Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Sat, 14 Dec 2024 21:02:17 +0200 Subject: [PATCH 1/4] typos metrics.md --- docs/src/clusters/metrics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/src/clusters/metrics.md b/docs/src/clusters/metrics.md index c162ed50117ca4..7315f25bb014e7 100644 --- a/docs/src/clusters/metrics.md +++ b/docs/src/clusters/metrics.md @@ -10,7 +10,7 @@ Each cluster node maintains various counters that are incremented on certain eve ## TPS -Each node's bank runtime maintains a count of transactions that it has processed. The dashboard first calculates the median count of transactions across all metrics enabled nodes in the cluster. The median cluster transaction count is then averaged over a 2 second period and displayed in the TPS time series graph. The dashboard also shows the Mean TPS, Max TPS and Total Transaction Count stats which are all calculated from the median transaction count. +Each node's bank runtime maintains a count of transactions that it has processed. The dashboard first calculates the median count of transactions across all metrics enabled nodes in the cluster. The median cluster transaction count is then averaged over a 2-second period and displayed in the TPS time series graph. The dashboard also shows the Mean TPS, Max TPS and Total Transaction Count stats which are all calculated from the median transaction count. ## Confirmation Time From 90687b007d8e5abf90e16aabd4e8a1dc5093264d Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Sat, 14 Dec 2024 21:03:24 +0200 Subject: [PATCH 2/4] typos metrics.md --- docs/src/clusters/metrics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/src/clusters/metrics.md b/docs/src/clusters/metrics.md index 7315f25bb014e7..3405fab4001677 100644 --- a/docs/src/clusters/metrics.md +++ b/docs/src/clusters/metrics.md @@ -24,4 +24,4 @@ The validator software is deployed to GCP n1-standard-16 instances with 1TB pd-s solana-bench-tps is started after the network converges from a client machine with n1-standard-16 CPU-only instance with the following arguments: `--tx\_count=50000 --thread-batch-sleep 1000` -TPS and confirmation metrics are captured from the dashboard numbers over a 5 minute average of when the bench-tps transfer stage begins. +TPS and confirmation metrics are captured from the dashboard numbers over a 5-minute average of when the bench-tps transfer stage begins. From de2b0a379ab40282e782c204ebe545c261944dbc Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Sat, 14 Dec 2024 21:04:02 +0200 Subject: [PATCH 3/4] typos leader-rotation.md --- docs/src/consensus/leader-rotation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/src/consensus/leader-rotation.md b/docs/src/consensus/leader-rotation.md index c65d91c7306176..8e6088e397f196 100644 --- a/docs/src/consensus/leader-rotation.md +++ b/docs/src/consensus/leader-rotation.md @@ -38,7 +38,7 @@ In this unstable scenario, multiple valid leader schedules exist. - A leader schedule is generated for every fork whose direct parent is in the previous epoch. - The leader schedule is valid after the start of the next epoch for descendant forks until it is updated. -Each partition's schedule will diverge after the partition lasts more than an epoch. For this reason, the epoch duration should be selected to be much much larger then slot time and the expected length for a fork to be committed to root. +Each partition's schedule will diverge after the partition lasts more than an epoch. For this reason, the epoch duration should be selected to be much larger then slot time and the expected length for a fork to be committed to root. After observing the cluster for a sufficient amount of time, the leader schedule offset can be selected based on the median partition duration and its standard deviation. For example, an offset longer then the median partition duration plus six standard deviations would reduce the likelihood of an inconsistent ledger schedule in the cluster to 1 in 1 million. From 51868967e250be9547a2f2f2e646fa2384dc068a Mon Sep 17 00:00:00 2001 From: Dmytrol <46675332+Dimitrolito@users.noreply.github.com> Date: Sat, 14 Dec 2024 21:04:36 +0200 Subject: [PATCH 4/4] typos rpc-transaction-history.md --- docs/src/implemented-proposals/rpc-transaction-history.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/src/implemented-proposals/rpc-transaction-history.md b/docs/src/implemented-proposals/rpc-transaction-history.md index 54288ad9659bd7..0d2e75ad7c1ced 100644 --- a/docs/src/implemented-proposals/rpc-transaction-history.md +++ b/docs/src/implemented-proposals/rpc-transaction-history.md @@ -42,7 +42,7 @@ different tables for quick searching. New data may be copied into the instance at anytime without affecting the existing data, and all data is immutable. Generally the expectation is that new -data will be uploaded once an current epoch completes but there is no limitation +data will be uploaded once a current epoch completes but there is no limitation on the frequency of data dumps. Cleanup of old data is automatic by configuring the data retention policy of the