MIME-Version: 1.0
In-Reply-To: <CANEZrP3s9SpBWxLYMvF5cLK4UeKS2SdKOLpNr40NKGoAzh=3nw@mail.gmail.com>
References: <CAC1+kJMrpx0tyE8d0wkwjBthhSPMCdr=9LrJHQFTF4G1vg4MAg@mail.gmail.com>
	<CABsx9T1HGwozy8pY+iStGZPmjenu0RQBVdtOy5ibiWG0BM4mZw@mail.gmail.com>
	<CAC1+kJPvzxsSDg3joraZbv_r1RroK9d6-v9O_15g6S7B46TwQg@mail.gmail.com>
	<CANEZrP3s9SpBWxLYMvF5cLK4UeKS2SdKOLpNr40NKGoAzh=3nw@mail.gmail.com>
Date: Thu, 17 Apr 2014 18:09:45 +0200
Message-ID: <CAC1+kJMxjNReSMxm=vDB-iYyXTqBvXq5_aw0Z3onds0zF-Oq=w@mail.gmail.com>
From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= <jtimon@monetize.io>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Timed testing
Precedence: list

On 4/17/14, Mike Hearn <mike@plan99.net> wrote:
>>
>> 2) If I wanted to measure validation performance, to get the number of
>> peak tps that could be processed without taking block sides or network
>> latency into account, how would I do that? Has anybody tried this
>> before?
>
>
> You can just reindex/replay the chain. It's been done many times.

Yes, thank you. I guess that's what everybody is doing to measure
validation performance.
So I guess the timedtest mode doesn't make much sense, at most only as
the blocktime parameter defaulting to zero. If bool
MineBlocksOnDemand() gets refactored out of ChainParams into a
parameter (maybe just use genproclimit ?), you can have the periodic
block generation and the generation on demand reusing the same regtest
mode.

So it seems a new mode only makes sense if the -private mode makes
sense, which in turn only makes sense to include in bitcoind if it's
useful enough for the network attack simulations, which remains the
open question.