Topic: Experimental pre-0.8 builds for testing - page 5. (Read 19841 times)

So it would seem:

(a bit outdated, but the trends are clear)

This is very unexpected and wrong. The size of the coins directory shouldn't exceed 150 MB or so (unless you increase -dbcache, in which case it may grow to something like 150 + dbcache/2 MB). Can you tell me which files (extensions) are the bulk of the data?

I decided to try out the low extreme, so I dug out a fossil and fired it up:

Windows XP SP3
Pentium M, 1.6 GHz
760 MB RAM
Disk space available initially: ~35 GB

Installed bitcoin-0.7.1-315-gfd95a8a-win32-setup.exe

bitcoin-qt.exe -connect=192.168.0.xxx -logtimestamps -benchmark

Started up fine, connected through LAN to the specified peer, started downloading. Typical CPU load (essentially no competing processes) was 20%-65%, rarely over 70%. Peak memory usage ~180 MB.

It took 4.5 hours to arrive to 5800 blocks left, when it ran out of disk space. It popped a small error window, with "ok" as the only option, when clicked the client closed. It turned out the "coins" folder grew to over 30 GB.  What is this?

I cleaned up some old files to make additional 7GB of space available, and started again as above. It continued downloading, then progress bar disappeared. The animated "sync" icon in the corner was still active, and downloading and verification was still going on fine. The CPU usage appeared somewhat lower then earlier, 20%-40% typically. Three hours into it, ran out of disk space again! The "coins" folder now grew to >37GB.

Cleaned up more GB, restarted the client, and two hours later and few hundreds of blocks before the end it ran out of disk space again! "Coins" folder now 40.1 GB, 21,734 files.

Cleaned up more space, but bitcoin-qt now crashes immediately after start. Rebooted, still the same. Windows crash report:

Debug.log:  http://www.filehosting.org/file/details/407213/debug.log

All in all, almost complete download via LAN and verification took ~10 hours.

I'm using the makefile generated by the qmake command.

The branch is the most up to date one in your github repository (sipa/bitcoin) head is:
fd95a8ac216b447f429409fde9f8eaef2ae4c339

The first was no longer necessary (else I could not habe posted the previous notice in THIS topic/board) and
thx for the later.

So, reindexing and the "-loadblock" option in 0.7.1 not only made a new blkindex.dat file but furthermore do a fully validation (including the expensive signature check). I think there is no secret option in 0.7.1 or 0.7.2 to disable the signature verification when using "-loadblock", isn't it?

Else a new bitcoin-client user could simple load a valid blockchain from a URL he trusted and simply load it to get this "blkindex.dat" to save MUCH real time -- this was my aim. For history: I deleted the only 6 orphan blocks form my personal blk00*.dat and thus wanted/needed  a new blkindex.dat.

This sounds well - I like this idea. I just checked: nearly exactly a 7.5-th of all deposits/txout-channels is not redeemed currently. And I believe this fraction will increase in the future further more. To check/validate a NEW block/transaction, the bitcoin-client gets only this data in RAM is sufficient, but sadly not for my blockparser.
Moreover the idea to keep the whole out-scripts in memory is very good because there is only a very small number of effectively different response-scripts - they mainly differ only in different RMD-160-bit hashes for their public key. So, I guess in > 99% a table-no and this 20 byte hash is sufficient data to store the script. I also looked at all the input- and output-scripts and there are only very few effectively different ones -- so your "encoding and decoding the txout data" should be done quick and you can keep the coding-table small -- as long as the number of different out-scripts stay small (as in the past).

The last point can only be critical, if CPU-usage tends to 100% not the waiting time of the bitcoin client. The only checking my blockparser doesn't do is the merkeltree-hash of each block (I was still too lazy to do the coding) and this OP_CHECKSIG (resp. OP_CHECKMULTISIG), but I had read and understood its detailed description on https://en.bitcoin.it/wiki/OP_CHECKSIG. Thus I can't judge how cpu-intensive this OP_CHECKSIG evaluation really is.

To be frank - I should add that I had hoped 0.8 would be released as a Christmas present and after this, once more as a New Years present, but my hope faded when I read more on the bitcoin forum. Thus I posted my proposal in the hope it could help to improve the 0.8 version.

Thank you for your explanation. Now we can only continue to hope that 0.8 with the new data-structure will be released as reasonable quick as possible.

smtp

Which makefile are you using? And which version of the branch (A recent change removed dbghelp altogether, also for windows).

Trying to compile the turbo build on linux I get these errors:
/usr/bin/ld: cannot find -lshlwapi
/usr/bin/ld: cannot find -ldbghelp

It seems to be complaining about windows only libraries being missing.

Hello there,

I can't take you out of the jail, but I can explain what we're doing in 0.8.

The old blkindex.dat file is a (very non-efficient, 12 bytes per txout) index that stores the disk position of all transactions in the blk00*.dat files, and for each transaction output whether and where it got spent. During block validation, this means that for every transaction that needs to be validated, we need to look up all input's previous transactions in the index, verify all inputs aren't spent yet, then read those transactions from disk, and then evaluate scripts, and finally update the index with spends and new transaction outputs created. This means the working set (the amount of data that needs to be readily available) is most of the block index, and part of the block data itself too (especially the recent/last part needs frequent access). This means fast access to gigabytes, and you're right to point out that this is slow. Too slow, because it is wasteful in two ways: 1) we need access to full transactions (even the parts that are already spent, or aren't necessary for validation of inputs) and 2) the index to search through contains all transactionsm even those that are already completely spent.

For 0.8, this is changed completely. There is no transaction index at all anymore. Instead, we keep - in addition to the block files - a database (LevelDB, not BDB) that contains just all unspent outputs (specifically, for every not-fully-spent transaction: its version, its height in the chain, and for all its unspent outputs: the value and the script) using an efficient encoding (so not pointers into the block files, the actual data itself). This database is right now (including all overhead and indexing structures) 146 MiB (126 MiB of which is actual data). This means this 146 MiB is the only thing that needs to be readily available during block validation, and it easily fits in caches in memory.

There is some overhead in maintaining a database, and encoding and decoding the txout data, but on my laptop, if I disable signature verification and increase the db cache size to 200 MB, reindexing to block 213769 (including all block and transaction validation, just not ECDSA verification) takes around 10 minutes (mostly at 100% CPU usage on one core). Using hash tables instead of trees for the cache, and increasing its size would further reduce that number. That's not the next limiting factor though. The bottlenecks are now the crappy block download mechanism (which sometimes stops for several minutes) and signature verification (which is needed in practice, and is several orders of magnitude slower than all the rest combined).

I do plan to make some improvements to the in-memory unspent-output-database-cache still, so that if made large enough, one shouldn't ever wait on disk, but I don't expect huge improvements there anymore. The most important changes for speeding up are reworking the block download mechanism, and parallellizing signature verification (which is already implemented, but not merged in mainline).

Hi

If you think this message is the wrong place, place shift it to the correct topic/thread:

    Please have a look at my posting at https://bitcointalksearch.org/topic/m.1422360  regarding "blkindex.dat" and "reindexing" real time speed of the bitcoin client.

And if you think it is appropriate, you are free to move it to this (or a better) board/thread.

BTW: Thank you for taking me out off the newbie-posting-restriction jail.

Regards
smtp

Error report:
After a crush, i can't start bitcoin-qt, so i installed the newest build, still can't.

Windows7 32bit   AMD CPU  4GB ram.

debug.txt

Here's my results from the 15th. I was syncing solely from a local peer and did not use block loading

Configuration
-------
Version: bitcoin-0.7.1-283-gf6aadb1-win32 (aka "turbo" build)
Flags: -connect=x.x.x.x -keypool=0
Hardware: VM w/full hw acceleration
vOS: Windows 7 64-bit latest
vCPU: AMD A8-3850 2 cores @ 2.9 GHz
vRAM: 4GB @ 1333 MHz
vDisk: 7200 rpm
vNetwork: 1 gigabit link

performance syncing up to block 193K
-----------
Duration: 56m23s
CPU Utilization: ~50%
CPU threads: ~32
Network Utilization: ~1% over gigabit link

RAM usage:
100MB @ ~130K blocks
110MB @ ~148K blocks
120MB @ ~157K blocks
130MB @ ~176K blocks
140MB @ ~190K blocks

performance for full sync up to network (212433)
-----------
Duration: 5h 15m total
CPU Utilization: up to 100%
Network Utilization: ~0.25% over gigabit link

bitcoin-qt.exe -reindex -par=4 -dbcche=500 -logtimestamps -benchmark

it took 37 minutes to reach 193000
and it took 2 hours 27 minutes to reach 211865
before 193000, CPU usage:  almost 50%
after 193000 , CPU usage:   85% ~ 95%

Laptop, intel core i3, 4GB ram

using 2012-12-13-turbo-ldb17
bitcoin-qt.exe -par=4 -connect=178.18.90.41 -dbcche=1536 -logtimestamps -benchmark
AMD Phenom II X4 @ 3.9 GHZ
4 GB RAM

Cpu usage starts off at 2%-25%, then goes down to 1%-5% about half way through block download.
Bitcoin-qt was downloading blocks at 540 kB/s.

debug.log:
http://www.4shared.com/archive/O3Jh456U/debug.html

Can you add a command line option for benchmarking that will cause the program to exit immediately after a successful synchronization?

I added yet another - and even more experimental - build (in the "-turbo-ldb17" directory here) with levelDB 1.7, and several Windows-only changes (new Windows LevelDB backend, Boost 1.52, newer compiler suite). Tests/benchmarks/comparison with the other turbo build are very welcome, particularly on Windows (there are very few changes for other systems).

M0mchil already reported some GUI problems, but I'm confident those can be fixed if necessary. The question is really whether it's stable and performant. Also things like testing whether it recovers from sudden power loss or forceful quits of the application are nice.

Again a disclaimer: Use at your own risk, I'm not responsible for overheating systems or stolen wallets.

PS: If you report synchronization benchmarks, please mention on what kind of system (CPU/RAM) and CPU usage (after block 193000). Also, don't just synchronize from arbitrary peers over the internet - the variation between hitting a good or a bad peer makes the timing completely unreliable.

I upgraded to the latest Jenkins build of bitcoin-qt ( pre-0.8 ) on windows.  I tried for a week and a half running -loadblock and -reindex, stopping restarting etc.. it was horribly slow, and going no where.

So I eventually downloaded the SIPA turbo build linked in the OP, deleted my existing blockchain, downloaded the bootstrap and let it run from scratch with an empty wallet..

Took about 6 hours to load in the bootstrap file while CPU sat at 30% and disk I/O not that high, so not sure what the bottleneck was there. then after block 190000 CPU jumped to 100% and it took about 10 hours to get back in sync to current block. Then I added my old wallet and rescanned that which went for maybe 10-20mins..

So significantly faster than the first time I sync'd 18 months ago.. but still quite frustrating.

I'm running a Atom CPU based nettop with windows 7, hence the slower than average speeds.

intel core i7 860 (4 physical, 8 logical cores)

bitcoin-qt built with gitian-builder from sipa/turbo rev 3ccb06f5ae538260817b6ef474f93029be41a64d


Ubuntu 12.04 64 bit, SSD A-DATA SX910 256 GB

64 bit, no -par (default), default cache

first 193000 blocks from bootstrap.dat - 11m:40s CPU time

real    9m50.565s
user    10m47.800s
sys     0m56.548s


64 bit, no -par (default), default cache

loading from blk000x.dat, up to arround block 211100

-loadblock=blk0001.dat -loadblock=blk0002.dat -loadblock=blk0003.dat

1 GB peak memory, ~80% average CPU usage, total CPU time 3h:16m

real    41m30.004s
user    196m43.378s
sys     2m47.834s

debug.log.ubuntu.12.04.x64.7z




Windows 7 Professional x64, two Seagate 512 GB HDD in RAID 0

-loadblock=blk0001.dat -loadblock=blk0002.dat -loadblock=blk0003.dat

default cache, with '-par 8', initially it seemed to run in single thread mode - first 193 000 blocks loaded significantly slower than on Ubuntu (same hardware), reason perhaps is slower storage.

After block 193000 the average CPU utilization rose to ~75%. Looking at threads, there were 16 threads executing same code of which 8 were actually active.

92 minutes real time, 6h:05m CPU time, 72% average CPU utilization, 235 MB peak memory working set

I then tried with '-par=4' and setting CPU affinity to physical cores only. Now there were initially 12 threads at transaction crunching, with again only one actively processing pre-SatoshiDice blocks.

debug.log.win32.7z

Clean setup in win7_x64
Still syncing the blockchain (over 15 hrs now)
Barely any CPU usage, but using 1.3GB memory. Also seems to have a lot of disk activity making the system a bit slow.

Hello,

Testing with bitcoin-0.7.1-244-g3ccb06f-win32-setup.exe and a bootstrap.dat from the torrent. All defaults, except using my server as the peer.
CPU is Win7 x64 Athlon II X4 2.8GHz (4 cores), 4GB RAM, HDD.

bootstrap.dat finished in 53 minutes at 25% CPU, ~120 MB RAM max. With no connection so its not downloading stuff in the background.
The rest of the blocks took 79 minutes. Download was constant at 350-450KBps (about 30% of my total DSL bandwidth.) 70-80% CPU the whole time, ~163 MB RAM max.

blocks dir is now 4.53 GB.

Went pretty smoothly. Much, much better than the previous days-long sync.

+1, Pieter has been doing the (majority?) of the Satoshi client heavy lifting.  He deserves lots of kudos and free beer.


Actually, we do!  We need to stabilize 0.8 as quickly as is reasonably possible, because people are beginning to avoid 0.7.x due to slowness, choosing instead less secure but faster bitcoin clients.

Any and all testing, on any and all platforms, is greatly appreciated.

Even posting "it works, my platform is [Ubuntu version X | Fedora version Y | Windows version Z]..." is helpful.