updated bench-tps.md

removed `$` as the copy didn't like it :-)

docs/src/cluster/bench-tps.md

@@ -9,22 +9,22 @@ For all four variations, you'd need the latest Rust toolchain and the Solana sou
 First, install Rust's package manager Cargo.
 
 ```bash
-$ curl https://sh.rustup.rs -sSf | sh
-$ source $HOME/.cargo/env
+curl https://sh.rustup.rs -sSf | sh
+source $HOME/.cargo/env
 ```
 
 Now checkout the code from github:
 
 ```bash
-$ git clone https://github.com/solana-labs/solana.git
-$ cd solana
+git clone https://github.com/solana-labs/solana.git
+cd solana
 ```
 
 The demo code is sometimes broken between releases as we add new low-level features, so if this is your first time running the demo, you'll improve your odds of success if you check out the [latest release](https://github.com/solana-labs/solana/releases) before proceeding:
 
 ```bash
-$ TAG=$(git describe --tags $(git rev-list --tags --max-count=1))
-$ git checkout $TAG
+TAG=$(git describe --tags $(git rev-list --tags --max-count=1))
+git checkout $TAG
 ```
 
 ### Configuration Setup
@@ -33,13 +33,13 @@ Ensure important programs such as the vote program are built before any nodes ar
 If you want the debug build, use just `cargo build` and omit the `NDEBUG=1` part of the command.
 
 ```bash
-$ cargo build --release
+cargo build --release
 ```
 
 The network is initialized with a genesis ledger generated by running the following script.
 
 ```bash
-$ NDEBUG=1 ./multinode-demo/setup.sh
+NDEBUG=1 ./multinode-demo/setup.sh
 ```
 
 ### Drone
@@ -49,7 +49,7 @@ In order for the validators and clients to work, we'll need to spin up a faucet
 Start the faucet with:
 
 ```bash
-$ NDEBUG=1 ./multinode-demo/faucet.sh
+NDEBUG=1 ./multinode-demo/faucet.sh
 ```
 
 ### Singlenode Testnet
@@ -59,7 +59,7 @@ Before you start a validator, make sure you know the IP address of the machine y
 Now start the bootstrap validator in a separate shell:
 
 ```bash
-$ NDEBUG=1 ./multinode-demo/bootstrap-validator.sh
+NDEBUG=1 ./multinode-demo/bootstrap-validator.sh
 ```
 
 Wait a few seconds for the server to initialize. It will print "leader ready..." when it's ready to receive transactions. The leader will request some tokens from the faucet if it doesn't have any. The faucet does not need to be running for subsequent leader starts.
@@ -69,15 +69,15 @@ Wait a few seconds for the server to initialize. It will print "leader ready..."
 To run a multinode testnet, after starting a leader node, spin up some additional validators in separate shells:
 
 ```bash
-$ NDEBUG=1 ./multinode-demo/validator-x.sh
+NDEBUG=1 ./multinode-demo/validator-x.sh
 ```
 
 To run a performance-enhanced validator on Linux, [CUDA 10.0](https://developer.nvidia.com/cuda-downloads) must be installed on your system:
 
 ```bash
-$ ./fetch-perf-libs.sh
-$ NDEBUG=1 SOLANA_CUDA=1 ./multinode-demo/bootstrap-validator.sh
-$ NDEBUG=1 SOLANA_CUDA=1 ./multinode-demo/validator.sh
+./fetch-perf-libs.sh
+NDEBUG=1 SOLANA_CUDA=1 ./multinode-demo/bootstrap-validator.sh
+NDEBUG=1 SOLANA_CUDA=1 ./multinode-demo/validator.sh
 ```
 
 ### Testnet Client Demo
@@ -87,7 +87,7 @@ Now that your singlenode or multinode testnet is up and running let's send it so
 In a separate shell start the client:
 
 ```bash
-$ NDEBUG=1 ./multinode-demo/bench-tps.sh # runs against localhost by default
+NDEBUG=1 ./multinode-demo/bench-tps.sh # runs against localhost by default
 ```
 
 What just happened? The client demo spins up several threads to send 500,000 transactions to the testnet as quickly as it can. The client then pings the testnet periodically to see how many transactions it processed in that time. Take note that the demo intentionally floods the network with UDP packets, such that the network will almost certainly drop a bunch of them. This ensures the testnet has an opportunity to reach 710k TPS. The client demo completes after it has convinced itself the testnet won't process any additional transactions. You should see several TPS measurements printed to the screen. In the multinode variation, you'll see TPS measurements for each validator node as well.
@@ -101,13 +101,13 @@ For example
 - To enable `info` everywhere and `debug` only in the solana::banking_stage module:
 
   ```bash
-  $ export RUST_LOG=solana=info,solana::banking_stage=debug
+export RUST_LOG=solana=info,solana::banking_stage=debug
   ```
 
 - To enable BPF program logging:
 
   ```bash
-  $ export RUST_LOG=solana_bpf_loader=trace
+export RUST_LOG=solana_bpf_loader=trace
   ```
 
 Generally we are using `debug` for infrequent debug messages, `trace` for potentially frequent messages and `info` for performance-related logging.
@@ -115,7 +115,7 @@ Generally we are using `debug` for infrequent debug messages, `trace` for potent
 You can also attach to a running process with GDB. The leader's process is named _solana-validator_:
 
 ```bash
-$ sudo gdb
+sudo gdb
 attach <PID>
 set logging on
 thread apply all bt
@@ -128,7 +128,7 @@ This will dump all the threads stack traces into gdb.txt
 In this example the client connects to our public testnet. To run validators on the testnet you would need to open udp ports `8000-10000`.
 
 ```bash
-$ NDEBUG=1 ./multinode-demo/bench-tps.sh --entrypoint devnet.solana.com:8001 --faucet devnet.solana.com:9900 --duration 60 --tx_count 50
+NDEBUG=1 ./multinode-demo/bench-tps.sh --entrypoint devnet.solana.com:8001 --faucet devnet.solana.com:9900 --duration 60 --tx_count 50
 ```
 
 You can observe the effects of your client's transactions on our [metrics dashboard](https://metrics.solana.com:3000/d/monitor/cluster-telemetry?var-testnet=devnet)