daserpent
|
|
October 11, 2017, 04:44:54 PM |
|
Can I participate from Windows?? Does it require GPU power or CPU power?
|
|
|
|
dcw312
Newbie
Offline
Activity: 12
Merit: 0
|
|
October 13, 2017, 03:25:55 AM |
|
GPU version of LBC usually works only on Linux, not on Windows. With your Dockerfile is it possibile to exploit GPU on Win?
A quick Google search indicates that Nvidia/Docker does not support Windows. For Linux, see this project here for Nvidia+Docker https://github.com/NVIDIA/nvidia-docker/tree/2.0
|
|
|
|
KeepingScore
Newbie
Offline
Activity: 18
Merit: 0
|
|
October 13, 2017, 09:50:53 AM |
|
No downloads available on site?
|
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
October 13, 2017, 11:34:07 AM |
|
Just to make it clear for everybody: Yes, the project is still on, I haven't abandoned it. I just happen to spend my energy currently on the BURST cryptocurrency, so there is not much time left for the LBC project at the moment. I feel the need to make that clarification here, as there are 1st "stalkers" who use Burst discussions on Reddit to ask me about LBC https://www.reddit.com/r/burstcoin/comments/75urgi/i_want_to_set_another_node_but_this_time_on_a_vps/dob21xk/Please don't do that. There is a nice Discord Channel at https://discord.gg/AyEfZrYWhere you can get more interactive support from the great LBC community. Also, there are at the moment some showstoppers that would need too much of my time to look into (like a broken blockparser, see https://github.com/znort987/blockparser/issues/65) if someone wants to give me a real nudge to update some things LBC (and I do have some pretty nice updates pending), fix that blockparser issue or find an alternative. Arulbero has sent me a new version of his ECC lib which may be (I haven't tested it yet, but I believe his tests/claims) 20% faster. I would want to include that too. So someone please look into the blockexplorer.
|
|
|
|
arulbero
Legendary
Offline
Activity: 1915
Merit: 2074
|
|
October 13, 2017, 06:30:54 PM Last edit: October 14, 2017, 12:12:19 PM by arulbero |
|
Arulbero has sent me a new version of his ECC lib which may be (I haven't tested it yet, but I believe his tests/claims) 20% faster.
A little explanation (and update) for the LBC users: LBC generator has 3 components: 1) ECC generator --> 2) sha256 + ripemd160 --> 3) bloom search 1) this component computes the generation from the private key of the corresponding public key. We have only a CPU version of this library. 2) each single public key produces 2 160-bit strings (addresses = hash of the public key), uncompressed and compressed addresses; Rico developed 2 optimized versions of this component, one for CPU and one for GPU. In the GPU case the output of the CPU is sent to the GPU. 3) check if the addresses generated in the step 2) are or not in the bloom filter (CPU version and GPU version). For the systems GPU limited (GPU used at 90% or more) it is crucial to improve the component 2). For the systems CPU limited (example: CPU used at 100% and GPU at 50%) it is important instead to improve the speed of the ECC generator, i.e. the rate at which the CPU feeds the GPU. ECC generator is the component I have been working on in the past months. I'm improving the ECC library as much as I can. At this moment the library is almost 30% faster than the current one. On my CPU Kabylake, it takes only 1,16 s to generate 16,7 M public keys against the 1,64 s of the latest release. For a system cpu limited, the new library could take a +30% speedup (exploiting completely the GPU's speed). In that case I think that the LBC generator will be faster than oclvanitygen on all GPUs (for now the LBC generator is faster only on middle/slow gpu, but not on fast gpu). For a system gpu limited, the only advantage is that you could use 3 cores to get (almost) the same performance as 4 cores now. For a system without GPU there is a small speedup, because in the CPU generator only a 10% of the cpu work is about the ECC arithmetic, about 65% is for the sha256/ripemd160 task and about 25% for the bloom search.
|
|
|
|
|
kknd
Jr. Member
Offline
Activity: 32
Merit: 11
|
|
October 14, 2017, 12:09:22 AM |
|
|
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
October 14, 2017, 09:00:50 AM |
|
For a system without GPU there is a small speedup, because in the CPU generator only a 10% of the cpu work is about the ECC arithmetic, about 65% is for the sha256/ripemed160 task and about 25% for the bloom search.
No, the bloom search (more precisely: bloom check) accounts for about 1% of the total work.
|
|
|
|
arulbero
Legendary
Offline
Activity: 1915
Merit: 2074
|
|
October 14, 2017, 12:03:19 PM Last edit: October 14, 2017, 12:28:25 PM by arulbero |
|
For a system without GPU there is a small speedup, because in the CPU generator only a 10% of the cpu work is about the ECC arithmetic, about 65% is for the sha256/ripemd160 task and about 25% for the bloom search.
No, the bloom search (more precisely: bloom check) accounts for about 1% of the total work. On the CPU generator the bloom check is only 1%? I made a little program with: 1) my aecc 2) sha256 and ripemd160 from supervanitygen 3) bloom check from brainflayer and I got: 1,16s for aecc, 12,4s for sha256+ripemd160, 4s for bloom check => total: 17,55s for 16,7 Mkeys Then: 6,6% for aecc, 70,6% for sha256 and 22,8% for bloom check. Maybe I'm not using the bloom check in the best way, but 23% against 1% is too much.
|
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
October 14, 2017, 03:25:54 PM |
|
On the CPU generator the bloom check is only 1%? I made a little program with:
1) my aecc 2) sha256 and ripemd160 from supervanitygen 3) bloom check from brainflayer
and I got: 1,16s for aecc, 12,4s for sha256+ripemd160, 4s for bloom check => total: 17,55s for 16,7 Mkeys
Then: 6,6% for aecc, 70,6% for sha256 and 22,8% for bloom check. Maybe I'm not using the bloom check in the best way, but 23% against 1% is too much.
Hard to say when I do not see the little program. On my machine the LBC generator takes like 0.2 s for both compressed and uncompressed checks of 16.7M keys. No - I do not use the code from brainflayer anymore, but I believe even the original code didn't take so long on my CPU (more like 0.4s instead of 4s)
On a different topic: I updated the views. The download link to the LBC Appliance is updated. Careful, it's a 1.8GB download. It has an updated Arch Linux, newest available BLF, client and a haswell generator. You will now see also a Crowdfunding page, which is merely there to stipulate a discussion about improving GPU performance (see what arulbero wrote above about GPU limited issues). By using an improved ECC lib and symmetries, we may run sooner into a GPU limited situation in the future.
|
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
October 16, 2017, 12:22:48 PM Last edit: October 16, 2017, 07:49:01 PM by rico666 |
|
Success! (25.99 Mkeys/s) on a machine (Skylake + M2000M) that gave me 22.7 Mkeys/s max with the previous generator. Thanks to the new Arulbero ECC library. A nice side effect of arulbero completely ditching the libgmp requirement (by providing his own tailored bignum math) is, that the generator binaries are now only half the size of the previous ones. 243184 Oct 16 14:20 kardashev-skylake 237KiB - we may cast that soon into a FPGA - just kidding... Or am I? Still, please do have patience before I push the new binaries on the server, I would like to get rid of the FTP server first and move all to a HTTPS communication. edit: with some newer versions I was able to squeeze 27.26 Mkeys/s out of my machine with around 95/96% GPU usage. Certainly more will be possible in the future. kardashev-skylake is now available in the new versions, those of you who have skylake machines with GPU, please test. (client should auto-update the generator upon restart). Generators for the other instruction sets will follow soon.
|
|
|
|
gizmoh
Legendary
Offline
Activity: 1428
Merit: 1000
|
|
October 18, 2017, 09:31:15 AM Last edit: October 18, 2017, 10:15:51 AM by gizmoh |
|
Hurrah! over 30% jump from ~31.5 Mkeys to ~41.6 Mkeys on a 7700k with 1080Ti Gpu usage from ~83% now to ~98% Thanks Arulbero for the optimizations and Rico for quick implementation
|
How Ripple Rips you: "The founders of Ripple Labs created 100 billion XRP at Ripple's inception. No more can be created according to the rules of the Ripple protocol. Of the 100 billion created, 20 billion XRP were retained by the creators, seeders, venture capital companies and other founders. The remaining 80 billion were given to Ripple Labs. Ripple Labs intends to distribute and sell 55 of that 80 billion XRP to users and strategic partners. Ripple Labs also had a giveaway of under 200 million XRP (0.002% of all XRP) via World Community Grid that was later discontinued.[29] Ripple Labs will retain the remaining 25 billion"
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
October 18, 2017, 11:29:20 AM |
|
Hurrah! over 30% jump from ~31.5 Mkeys to ~41.6 Mkeys on a 7700k with 1080Ti Gpu usage from ~83% now to ~98% Thanks Arulbero for the optimizations and Rico for quick implementation 28% for GPU clients that were not GPU limited - to be precise. Your observation is consistent with what is seen on these machines. i7-6700 CPU @ 3.40GHz + 1080 : 32.47 Mkeys/s -> 42.36 Mkeys/s That makes the overall collider speed an equivalent of 6 such machines. If we had 600 of these colliders, the next puzzle transaction privkey would be here in less than 24 hours - worst case.
|
|
|
|
arulbero
Legendary
Offline
Activity: 1915
Merit: 2074
|
|
October 18, 2017, 05:07:38 PM Last edit: October 18, 2017, 05:21:31 PM by arulbero |
|
Hurrah! over 30% jump from ~31.5 Mkeys to ~41.6 Mkeys on a 7700k with 1080Ti
If your system is more or less like this: https://bitcointalk.org/index.php?topic=1573035.msg18373053#msg18373053or like this https://bitcointalk.org/index.php?topic=1573035.msg18446472#msg18446472then we are now faster than oclvanitygen on fast GPUs too. Remember that 41.6 Mkeys/s means 41.6 M compressed keys + 41.6 M uncompressed keys per second, over 83 Maddresses/s!. Could you test oclvanitygen on your machine? Gpu usage from ~83% now to ~98%
I'm afraid that almost all systems are now GPU limited. Only multi GPU systems can take advantage from other ecc improvements (if there will be) and from n-k symmetry. I think that a GPU version of ECC library would be not very useful at the moment. We need above all to speedup sha256/ripemd160 on GPU.
|
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
October 18, 2017, 05:26:47 PM |
|
I'm afraid that almost all systems are now GPU limited.
Only multi GPU systems can take advantage from other ecc improvements (if there will be) and from n-k symmetry. I think that a GPU version of ECC library is not very useful at the moment. We need overall to speedup sha256/ripemd160 on GPU.
You are right: Multi-GPU systems are not GPU limited and the client has been tested already on Systems with as many as 16 GPUs. (currently the Amazon p16.xlarge delivers 175 Mkeys/s) I have already a n-k symmetry prototype running - in fact had this already May, 25th: https://twitter.com/LBC_collider/status/867657663987015680 The single showstopper to enable n-k symmetry is accounting work that has to be done on the server. In theory, with n-k symmetry and better hash160 OpenCL code (which I believe is possible - see also https://lbc.cryptoguru.org/crowdfunding), we may see 2x speedups on the same hardware.
|
|
|
|
KeepingScore
Newbie
Offline
Activity: 18
Merit: 0
|
|
October 19, 2017, 07:33:14 PM |
|
Solution to the VM's "loadable library and perl binaries are mismatched" bug when you run "./collider/LBC -x" is to run "cpan -r" and let it update everything.
|
|
|
|
CrytpSig
Newbie
Offline
Activity: 5
Merit: 0
|
|
October 20, 2017, 03:35:12 AM |
|
I'm afraid that almost all systems are now GPU limited.
Only multi GPU systems can take advantage from other ecc improvements (if there will be) and from n-k symmetry. I think that a GPU version of ECC library is not very useful at the moment. We need overall to speedup sha256/ripemd160 on GPU.
You are right: Multi-GPU systems are not GPU limited and the client has been tested already on Systems with as many as 16 GPUs. (currently the Amazon p16.xlarge delivers 175 Mkeys/s) I have already a n-k symmetry prototype running - in fact had this already May, 25th: https://twitter.com/LBC_collider/status/867657663987015680 The single showstopper to enable n-k symmetry is accounting work that has to be done on the server. In theory, with n-k symmetry and better hash160 OpenCL code (which I believe is possible - see also https://lbc.cryptoguru.org/crowdfunding), we may see 2x speedups on the same hardware. Hi I am having issues with the Arch Linux virtual machine on windows Problem connecting to server https://lbc.cryptoguru.org/static/client(status: 500 Can't connect to lbc.cryptoguru.org:443 (certificate verify failed). retries left 29
|
|
|
|
rico666 (OP)
Legendary
Offline
Activity: 1120
Merit: 1037
฿ → ∞
|
|
October 21, 2017, 09:12:57 AM Last edit: October 21, 2017, 11:44:06 AM by rico666 |
|
maybe a > pacman -S ca-certificates will help. I remember (faintly) that the ca-certificates package said something like "valid until 20.10" or something like that "next check 20.10" - not sure. Or you do a > pacman -Syu Which is the Arch Linux way of "apt-get update & apt-get upgrade" edit:Or you have a simple networking problem. Try a > ping 8.8.8.8 if that works. If yes, update as said above. If no, you have to get your VM networking right first. But that is a matter of the VM configuration, not of the OS running inside the VM.
|
|
|
|
CrytpSig
Newbie
Offline
Activity: 5
Merit: 0
|
|
October 22, 2017, 09:54:50 PM |
|
maybe a > pacman -S ca-certificates will help. I remember (faintly) that the ca-certificates package said something like "valid until 20.10" or something like that "next check 20.10" - not sure. Or you do a > pacman -Syu Which is the Arch Linux way of "apt-get update & apt-get upgrade" edit:Or you have a simple networking problem. Try a > ping 8.8.8.8 if that works. If yes, update as said above. If no, you have to get your VM networking right first. But that is a matter of the VM configuration, not of the OS running inside the VM. Ping came back fine updated on those commands previously still not working. I think this is an issue with the Perl certificate implementation. I had a similar issue running a perl script on windows with he same error that i could not fix.
|
|
|
|
Suzobo
Newbie
Offline
Activity: 46
Merit: 0
|
|
October 23, 2017, 01:29:14 AM |
|
Might be time to start up the server again and see what a nVidia Quadro card can do. I know I did around a million keys pr sec with the cpu alone.
|
|
|
|
|