https://bitcointalk.org/index.php?topic=1555043.msg16324187#msg16324187aaaaand 41bit! Did someone take time?
Anyway - regarding new client: progress is good, cleaning up the code, packaging process runs through smooth, just need more sanity checks and safeguards in the code. Here are your instructions after you have downloaded the package.
The package will be around 161M named
LBChrd-0.833_l64.tbz2 (probably some later version number).
1)
tar xf LBChrd-0.833_l64.tbz2 in some directory, you'll end up with the usual
LBC-client subdir.
2) LBC-client contains these files
md5sums
LBC
README.txt
gen-hrdcore-avx2-linux64
gen-hrdcore-westmere-linux64
funds_h160.blf
2a) You want to install libgmp-dev (or similar) to have the header files for the
GNU MP Library, else you will experience nuisance Math::BigInt::GMP messages.
2b) You need to be root, or do a
sudo ./LBC ... at least in the 1st call when LBC tries to install modules. When these are installed, LBC can of course run under regular user.
3) You simply do a ./LBC -h on your 1st call. This will install all packages needed. If you had LBC running before, you're set, as the new version doesn't need any additional modules.
3a) Therefore, if you are a Win-User with a new Linux VM installation, it doesn't hurt to install the Go-based LBC for Linux 64bit in there. Running this will prove you have prepared the environment correctly. Also, make sure your VM sees your current processor features and not just some kind of emulated CPU. Ideally, when doing a
grep avx2 /proc/cpuinfo you will get hits.
3b) If
LBC -h is ok, don't forget to do a
LBC -x (testing). You need to do this only once. It will also re-benchmark your computer. You should see this output (different factor - of course):
Testing mode. Using page 0, turning off looping.
Benchmark info not found - benchmarking... done.
Benchmarked factor 1.7556270625
o
Test ok. Your test results were stored in FOUND.txt.
Have a look and then you may want to remove the file.
2d17543d32448acc7a1c43c5f72cd5be459ab302:u:(hex)priv:000000000000000000000000000000000000000000000000000000000000005f
02e62151191a931d51cdc513a86d4bf5694f4e51:c:(hex)priv:0000000000000000000000000000000000000000000000000000000000000066
9d74ffdb31068ca2a1feb8e34830635c0647d714:u:(hex)priv:00000000000000000000000000000000000000000000000000000000000f9f8d
3d6871076780446bd46fc564b0c443e1fd415beb:c:(hex)priv:00000000000000000000000000000000000000000000000000000000000f9f8d
Ending test run.
Then your system works flawlessly. Do as it says with the FOUND.txt file and you're ready to go.
4) If you have an AVX2 capable CPU (Skylake, Xeon v4, Xeon v3), LBC will choose the gen-hrdcore-avx2-linux64 generator. This is currently your best possible ride. If it doesn't find avx2, it will use gen-hrdcore-westmere-linux64. This will
also run on anything between Westmere and Xeon v2. Maybe even Nehalem CPUs will run with this, but no guarantee. If your CPU is older - no gen at the moment.
The gen-hrdcore-westmere-linux64 will also run on AVX2 architectures, albeit slower. On my Skylake notebook, the gen-hrdcore-avx2-linux64 needs 28 seconds to search 16 mio PKs, the gen-hrdcore-westmere-linux64 works also on Skylake, but needs 36 seconds. So make sure, your cpuinfo shows avx2 if you have it.
5) Well - you're ready to go:
LBC -c 4 -t 1240 The HRD-version will probably disallow anything below -t 600, because - honestly - it doesn't make sense. If you look at the stats, we have already clients who gulp 25000 blocks an hour 24/7. (Which is good for the smaller clients, because these fatties take the pool "forefront" (and thus all of us) to greener pastures which start at 50/51 bit search space)
6) You should see something like this
# ./LBC -c 4 -t 1240
done.
Fetching adequate work... got block interval [1659184-1661667]
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
plusminus YMMV.
One more thing: The new generators use a bloom filter that is aware of all hash160 with funds on them. A bloom filter is a
probabilistic data structure, which will never overlook a hash160 with funds on it, but it may give out a false positive for a hash160 it sees. The error probability for this to happen is ~ 10
-27 with the current size and number of hash160 we have. So not a big deal, but be prepared to see a hit which is none. Also, there are no funds stored with the bloom filter - only the hash160. So if you get a hit and if this hit is not a false positive, you will have to look up the funds for the hash160 yourself (blockchain.info e.g.).
Rico
Show Posts
Maybe I only need faster machines?
