We were computing these functions incorrectly.
I'm not sure what distribution these numbers are, but it isn't the
normal exponential distribution. (We're making the probability of
getting a number of a particular bitlength equal, but the number in
that bitlength thats gets chosen is uniformly chosen)
We weren't using these functions anywhere in our codebase, and they
had a nomenclature error. (There aren't exponentially distributed
integers, instead they would be geometrically distributed)
The godocs fell out of sync with the code here. Additionally we had
warning that these randomness functions weren't for cryptographic
use on every function. However these warnings are confusing, since
there was no implication that they would be secure there, and a
single warning on the actual Rand type would suffice. (This is what
is done in golang's math/rand godoc)
Additionally we indicated that rand.Bytes() was reading OS randomness
but in fact that had been changed.
This commit switches all usage of math/rand to cmn's rand. The only
exceptions are within the random file itself, the tools package, and the
crypto package. In tools you don't want it to lock between the go-routines.
The crypto package doesn't use it so the crypto package have no other
dependencies within tendermint/tendermint for easier portability.
Crypto/rand usage is unadjusted.
Closes#1343
This PR moves statistics to its own file, seperates getBlockMetas
into its own function, and removes the timeEnd parameter from
calculate statistics. The ending time is now computed directly from
the start time and the duration, to enforce that we only collect
data for the provided duration.
* tools/tm-bench: Don't count the first block if its empty
* Try melekes suggestion
* Fix getting the start time so the first block is no longer empty
* Fix changelog entry
* Make code smell better
* tools/tmbench: Fix the end time being used for statistics calculation
Previously we were using the time at which all connections closed in statistics, not
the time after {duration} seconds.
* Use waitgroups for starting up
At larger tx sizes (e.g. > 10000) we were spending non-neglible
amounts of time in tx creation, due to making the final bytes random.
The slower the send loop, the less accurate it is at measuring the time
tendermint took. (As we can't reach the promised contract of the given rate)
There really isn't much need for that randomness, so this PR makes it
such that only the txNumber gets bumped between txs from the same
connection, thereby improving sendloop speed and accuracy.
