First off, welcome in the top30. Your GPUauth has been delivered. 

Nimbix looks like similar business to the https://www.leadergpu.com/ link arulbero posted. I wasn't aware of all the "smaller" cloud providers (or let's say: hardware-on-demand) and with these offering newer GPU systems it is my hope that Amazon and Google will not take much longer to offer these too.

LBC doesn't need any fast interconnect between the GPUs it's perfectly parallelizable without any such inter-GPU communication, so NVlink is not a must.


Rico

In the past hour we were 1107156445 keys/s
(at this speed we will have #51 in 2 days)

Rico

Don't take it personally  It's more like no (performant) client for K80. (yet)

I had a look if some cloud vendor offers any Maxwell (M60) or Pascal GPUs (P100). I'm pretty sure with these LBC would work and it would even mean a nice performance kick. Unfortunately so far only promises and plans:

https://blogs.nvidia.com/blog/2016/11/16/tesla-p100-on-google-cloud-platform/
observe how "now available" in the subject = "will be available" in the 1st line of the text

I checked today. Nada. Only K80 and only in some locations. 

I also am thinking about purchasing a dedicated 200 Mkeys/s machine...


Rico

Aktuelle Speed - Unknownhostname dreht am Rad...
Das Meiste mit CPUs - mal schauen ob er es für den 24h Schnitt durchhält.

edit: ok - mittlerweile dreht nicht nur Unknownhostname am Rad, sondern auch noch andere. 


Rico

Aktueller Patch ist von heute früh.

User SlarkBoy hat einige (etliche) Bounties im nahen LBC Suchraum plaziert.

Die aktuelle BLF Datei bzw. der Patch beinhaltet diese bereits. Beide werden bei einem LBC Neustart automatisch aktualisiert.

Der Umfang der Bounties übertrifft alles (beim LBC) Dagewesene und wir werden den Gesamtumfang zeigen sobald das Feuerwerk losgeht und die ersten User ihre Bounties finden (= hook-find oder FOUNDS.txt checken und das auch mal melden).

Rico

User SlarkBoy has generously deployed quite some free giveaways in the LBC search space here and there.

The new BLF file and patch available on FTP Server (auto-updated on LBC restart) does contain these already.

While I do not know the privkeys of these, I am aware of the total amount and it's the biggest bounty program of LBC by far!

We will reveal the complete extent of these freebies once the fireworks of discovering them has started.

Have fun and a big cheers to SlarkBoy!

Rico

The problem is not the LBC client itself (Perl script) - this should be pretty much multi-OS portable

The problem are the generator binaries
http://unix.stackexchange.com/questions/212754/is-there-a-way-to-run-a-linux-binary-on-os-x

I have no Darwin system - or even the Apple Hardware here.

If someone would send a vmware-able MacOSX image my way, I could try to compile the generator for that target-OS.

Rico

Not supported.

9 days to go - worst case. I take it all have their hook-finds or are controlling for presence of FOUND.txt at least daily.

If you give me access to the machine, I can have a look what's wrong.

@unknownhostname

-t 10 is ok. Actually on AWS I wouldn't change that. If you really were into optimizing, you could let the instances in Europe have -t 10 and the instances in US/Asia have -t 17 (bigger network lag)


Rico

I assume that's a m4.16xlarge with -t 10

The +1.3 Mkey/s you get compared to what I see right now is because of  the -t 10 (you) versus -t 5 (me)

Actually I would recommend everyone to set up something between -t 10 and -t 60 (*) at the moment - depending on how long you want LBC to let run (do not forget: a graceful shutdown can take 60 - 120 minutes if you have -t 60). Because starting from -t 10 the startup cost is pretty diminished.

Also, I'd recommend to not stick to the "boring" 5/10/20 numbers. Try 11/17/23/37 or so (not exactly these, just dice some number if you want). You'll help to spread client-server requests more evenly and also you set up for your client more "individual" block sizes, which can actually help your client to get block intervals assigned that are being left for redistribution otherwise (if someone ends their client ungracefully).

(*) and not more than 60 if you haven't enough memory, because the LBC client has a small memory leak currently (you can see it taking more and more space within a round). Nothing tragic, but it's there - I noticed when I started a client overnight with -t 420 which actually became critical on my 16GB machine.


Rico

Unknownhostname is right. Alternative? Own hardware.

What I observed at AWS:

You get what they call "vCPUs". I assume that stands for "virtual CPUs". In general, it looks like you get only 50% of the CPU power announced - or in other terms - only 50% of the number of CPUs as "real" CPUs. I.e. if you get an instance with 64 vCPUs you can assume you get only the performance that 32 physical CPUs would give you.

Most of the time you can assume that, but sometimes its even worse. While I got regulary 18 Mkeys/s out of the m4.16xlarge, some instances gave me only 16 Mkeys/s - I guess Amazon speculates their customers do not see the difference (which is understandable as most of the customers do not put a 100% CPU load on the machines).

Having said all that: I actually started up a m4.x16xlarge instance after your report and I get


with -t 5, so this is expected. You get that performance with any modern 4-core + GPU configuration.

If you get less than these 20+ Mkeys/s, something else is wrong.


Rico

AWS m4.4x vs m4.16x


What about -t ? LBC gets quite a penalty on startup, because it has to load the BLF file, it connects with the FTP server to see if there are updates. AWS machines have quite a bad IO. This startup penalty is even worse with the GPU version, because additionally, it has to compile the OpenCL program.

I was able to get 18 Mkeys (https://lbc.cryptoguru.org/man/admin#system-speed) from a m4.x16 instance with the old client (secp256k1 lib). My guess would be, that the new client with your ECC should be able to give at least 32 times the speed + 20% you see from the benchmark per CPU. So at least over 20 Mkeys/s I guess.

WIth the AWS instances anything smaller than -t 10 does not make sense.

Rico

Killjoy! Grinch! Spoilsport! 

I had hoped to cause more stirr - maybe even becoin to show up and hold some lectures.

April, 1st confirmed.


Rico

It is with regret that I have to inform you about ceasing pool operation.

User 599ed1ff71f0b9b3dd13e3b9c88ca6ab informed me about a find of 71 BTC and transferring
the funds to his address https://blockchain.info/de/address/14qAqvqQi4Lci3untZcjiDiiYpAuLDwCeS
he has evidently no intention of giving these funds back.

I can confirm that a block he got earlier today contained the privkey and I have the IP addresses
his client connected with. Of course the user id was blacklisted and I will offer full cooperation
with whoever can claim rightful ownership to the funds.

It seems - after all - that critical voices like becoin were right about this risk and I'm sad to
acknowledge their almost Cassandra-like prophecies.

So the pool will go down today 23:59 UTC for good as I simply cannot take the risk of this happening
ever again.


Rico

Both things are not new. You will see a new BLF patch about once every 14 days. This is to keep the addresses with funds you're searching against updated.

Also, ending the client means that the end-signal sent during the current round is being catched in the next round - which is then ended.

Say you have a -t 10 (10 minutes), time to real end is between 10 and 20 minutes.


Rico

Good to hear. Please before any "release" - send the download-links my way for review and shasum of the files - then release (I'm sure).
You certainly understand that without this I could not recommend anyone using these.
(Also I'm egoistically hoping to get a working AMD OpenCL ISO - did you get that working BTW?) 


Rico

Updates:

New BLF file (your LBC should auto-update upon startup)
ftp://ftp.cryptoguru.org/LBC/blf/170331-74d3f46939986f415bc2ebf02eeb2d8f.blf.bz2 or the patch
ftp://ftp.cryptoguru.org/LBC/blf/58afd82e681f19b2faf464851aee8541_74d3f46939986f415bc2ebf02eeb2d8f.xd3.bz2

Loaded 14937974 hashes, false positive rate: ~3.523e-24 (1 in ~2.839e+23)

New LBC Appliance:

ftp://ftp.cryptoguru.org/LBC/appliance/

It has a fat 1.6GB size, but it's still the No1 solution for Win-only users.
This version comes on an updated Arch Linux, updated LBC, BLF, installed open-vm-tools and upgraded most CPAN modules.
It's not suitable for GPU clients! -> CPU only

---

I certainly hope we will get a OpenCL capable Live-Boot for Nvidia (and maybe even AMD) soon. User Icanscript worked on it with very promising results, but I'm not sure how far progress is now.


Rico

Instant profit!

• Install pushbullet as above
• you get the API-key on pushbullet.com/account
• create this hook-find in your collider directory:

Done.

See how generic the hook-concept is? You could have done this without me since ... since when do we have hooks?
Ah! October 20th 2016   https://bitcointalk.org/index.php?topic=1573035.msg16626719#msg16626719
 

Rico