On 03/14/2017 12:57 AM, P Perazim wrote:
> BS V3 setup and ran quite easily taking 2.5 days to sync on an
> Intel NUC5 i3 with M.2 SSD.

Great/ I'm working on server configuration documentation presently.
There are a number of configuration settings that can dramatically
speed up initial block download. Currently IBD is blocks-first, so it
is not very efficient.

> Some question:
>
> 1) Please define what a checkpoint is in your usage of the term
> with BS.

A checkpoint is an optional/configurable hash/height tuple that the
main chain is required to pass through. Blocks that are below the
highest checkpoint are minimally validated, so they also server to
speed up initial block download. Once you have performed a full
validation on the chain, recording a high checkpoint in config can
save you time on subsequent IBD runs.

> 2) When adjusting the configuration, do any changes require
> resetting the database and resyncing from block 0?

Only a restart is required for configuration changes, with the
exception of these database bucket settings. If these are changed the
database must be rebuilt.

[database]
block_table_buckets = 650000
transaction_table_buckets = 110000000
spend_table_buckets = 250000000
history_table_buckets = 107000000

> 3) Initially, I used a 256GB M.2 SSD and when this filled up,

FYI, you can reduce the run-time size of the store by changing the
default:

[database]
file_growth_rate = 50

to a lower value, such as 10. This is the percentage over the actual
data size that the store reserves when the file becomes full. This
number should be higher (e.g. 50) at lower block heights in order to
limit resizing.

> I stopped BS, moved the database to a 2.5 SSD in a USB-3 case
> plugged into a USB-3 port. This configuration has run well in the
> past approaching the design speed of the SSD in other applications.
> Restarting BS, I observed a reduction in block processing speed. I
> then reinitialized the database and started BS from block 0. It ran
> very slow appearing to be 'throttled' achieving only about 2 % of
> the speed when using the M.2 SSD. It may be that there is some kind
> of resource management and limitations. Why is this?

BS is not like most other applications. It is a set of memory-mapped
files. Paging costs are high if you have low available RAM or if disk
I/O is slow. Low RAM can be mitigated using the unspent output cache,
such as:

[database]
cache_capacity = 10000

But if you have slow I/O IBD performance will be significantly
affected. It is also very possible that you got unlucky and connected
slower peers and/or are running a suboptimal IBD configuration.

> Thanks for all the effort being placed into this project. I
> appreciate it.

No problem, thanks for the feedback.

e

> Thanks,
>
> Perazim