[XMR] Monero Mining

[smooth]

I think I can see my impact on the pool website (http://cryptonotepool.org.uk/)...

I have 2 x g2.2xlarge and 2 x c3.8xlarge running, and it looks to me that the pool hashrate went up about 4 to 5 KH/s after I started those instances.

Does that approximately check out?

Sounds about right. Pretty good actually.

[smooth]

Important update (source code only)

If you are operating a pool or exchange or other important service, or if you are solo mining, and you compile your own node, please pull master from github and upgrade ASAP. If you have created AMI images for solo mining, please update them.

Additional precautionary checkpoints have been added to protect more of the existing blockchain.

https://github.com/monero-project/bitmonero

The only evidence of anomalous activity is what was reported by fluffypony.

The update is an important precaution.

Updated binaries will follow shortly.

Further measures will be taken as necessary.

[nioc]

I think I can see my impact on the pool website (http://cryptonotepool.org.uk/)...

I have 2 x g2.2xlarge and 2 x c3.8xlarge running, and it looks to me that the pool hashrate went up about 4 to 5 KH/s after I started those instances.

Does that approximately check out?

I think you meant 40 to 50 KH/s.  Even with no change in miners the HR can go up and down.  They are now at 76 KH/s so it seems that you and/or others are there now.

Thank you

[5w00p]

Ok, smooth.

But I can assure you that 23 threads on an 8-core Xeon is slower than 8 threads.

on the GPU instance:

Top is 8 threads: ~348 h/s all day, all night, consistent as fack
Middle is 23 threads: gets 343 h/s for that first submission, then drops to ~265 h/s [i stopped it, no need to waste my $]
Bottom is back to good ol' consistent 8 threads

[oda.krell]

I think I can see my impact on the pool website (http://cryptonotepool.org.uk/)...

I have 2 x g2.2xlarge and 2 x c3.8xlarge running, and it looks to me that the pool hashrate went up about 4 to 5 KH/s after I started those instances.

Does that approximately check out?

I think you meant 40 to 50 KH/s.  Even with no change in miners the HR can go up and down.  They are now at 76 KH/s so it seems that you and/or others are there now.

Thank you

Hm. Don't think so... I remember it being at mid-60 KH/s, and now it's at ~76.

I added a few more instances. Really wish I could see the actual hashrate inside the instance :/

[papa_lazzarou]

Maybe Do what smooth said:

sudo screen -r

will give you a list of process numbers. One is the cpu miner, one is the gpu.

Connect to one of these with:

sudo screen -r [put-process-number-here]

When you are done looking or interacting, press "control-a d" and it will disconnect you but leave the miner running in the background.

Sorry, should have said I already tried that

"There is no screen to be resumed"

Maybe just screen -r without the sudo?

It depends how the node was setup to run in the background.

Sorry guys wasn't watching this thread. You have a miner.log at ~/CudaMiner and ~/cpuminer-cryptonite (that's correct I changed it do cryptonight mining). just do a cat or tail of those files.

If you lookup the DEV FUND address you see that overall it has ~9KH/s at cryptonotepool

[papa_lazzarou]

Okay... minerd at 3100% CPU.

How can I see the hashrate I'm getting?

Also, whoever set up that image, you will get a better hash rate with a lower number of threads. Something like 23 I think is the best but I'm not sure if I remember that correctly.

I tried to keep it generic. It is meant for people who don't feel comfortable with linux. The idea was to launch and forget.

[smooth]

Ok, smooth.

But I can assure you that 23 threads on an 8-core Xeon is slower than 8 threads.

Of course. I was talking about a 32 core instance. The post I quoted stated minerd at 3100%, which indicates 32 active threads. If you reduce threads below cores you will usually get better performance.

The GPU instances are even a bit more weird, but I don't have time to get into that.

[oda.krell]

EC2 related question:

Will my instances get automatically "renewed" and keep running as long as my max price is high enough to beat the competition?

[smooth]

Okay... minerd at 3100% CPU.

How can I see the hashrate I'm getting?

Also, whoever set up that image, you will get a better hash rate with a lower number of threads. Something like 23 I think is the best but I'm not sure if I remember that correctly.

I tried to keep it generic. It is meant for people who don't feel comfortable with linux. The idea was to launch and forget.

Well you could do something like $[($(nproc)*3+2)/4] in your script. That's pretty close to the right number on most of the types.

[smooth]

EC2 related question:

Will my instances get automatically "renewed" and keep running as long as my max price is high enough to beat the competition?

There is a check box for "persistent" when you start them. If you check that, you get to rebid if you get outbid. Otherwise you don't.

[5w00p]

oda-krell: They won't go away/be terminated, so won't have to be "renewed."

smooth: cool

My observations:
For spot prices, I see best bang-for-buck at the 8-core instances, so I haven't bothered with "larger" instances.  Just doesn't compute in my mind-to-wallet al gore rhythm.

And with the GPU instances, you get a variance of which CPU you get, apparently. The screenshot I posted is the best CPU performance I have gotten from a GPU-instance CPU: ~350 h/s  

Worst I have seen is ~88 h/s ... doh!

[papa_lazzarou]

Ok, smooth.

But I can assure you that 23 threads on an 8-core Xeon is slower than 8 threads.

Of course. I was talking about a 32 core instance. The post I quoted stated minerd at 3100%, which indicates 32 active threads. If you reduce threads below cores you will usually get better performance.

The GPU instances are even a bit more weird, but I don't have time to get into that.

I used wolf's cpuminer without specifying the number of threads which automatically launches nproc - 1.
The only thing that's not variable is nr_hugepages which I left at 21.

For ccminer i went with 12x64. That gave me the best results.

Edit:
Smooth, just saw your sugestion above. It should also for for setting the nr_hugepages with sysctl.
With that I think it will have good performance in most instance types.

5w00p, you're right. I went with the 8 cores myself. The max I got from a 32 core was 850h/s.
The 8 core gives you about 100h/s more for less bucks. And there is less competition too.

[smooth]

Smooth, just saw your sugestion above. It should also for for setting the nr_hugepages with sysctl.

Yes definitely. But make sure you have as many hugepages as threads. If you are making a generic image just pick something more than the most. I used 64. Little harm there (just a bit of extra reserved memory).

[jwinterm]

EC2 related question:

Will my instances get automatically "renewed" and keep running as long as my max price is high enough to beat the competition?

Yes, as long as your spot bid is higher than the current price, your instances will keep running. Also, sorry about not being able to get the screen back up for each miner, I'll look into that and see if I can figure it out. I think it may be as simple as replacing this:

Code:

screen /home/ubuntu/start.sh

with this:

Code:

screen /home/ubuntu/cpustart.sh
screen /home/ubuntu/gpustart.sh

in the rc.local file.

[smooth]

EC2 related question:

Will my instances get automatically "renewed" and keep running as long as my max price is high enough to beat the competition?

Yes, as long as your spot bid is higher than the current price, your instances will keep running.

They will keep running indefinitely but if they ever lose the bid, even for a short time, they're gone forever.

Unless you check the persistent box when you start them. In that case if you lose your instance isn't gone forever, but it gets shut down and back into the bid queue to be restarted if the price drops back down.

[RentaMouse]

Thanks to everyone who has been sending some hashpower to cryptonotepool.org.uk, if you have any questions then @CryptonotepoolUK is regularly available on the #monero-pools IRC channel for a quick answer.

One thing I remember someone saying about the AWS instances is that the CPU cache is shared between several instances, but cpuminer will try and grab all of it for maximum performance. This works to your advantage if you are sharing with people who arent using much cpu, but if you end up with some other mining instances you will all get a lower hashrate. So it may be worth keeping an eye on it and if its well below what it should be then terminate the instance and start a new one - hopefully next time you'll get all the cache to yourself

[smooth]

Important update (source code only)

If you are operating a pool or other important service, or if you are solo mining, and you compile your own node, please pull master from github and upgrade ASAP. Likewise if you have AWS images, please rebuild them with the new version. Additional precautionary checkpoints have been added to protect more of the existing blockchain.

Our recommendation for exchange is to remain frozen for external transactions. If you are still running a node, please update.

https://github.com/monero-project/bitmonero

The only evidence of anomalous activity is what was reported by fluffypony. Nevertheless malicious activity may occur that is not visible until the moment of the attack.

The update is an important precaution.

Updated binaries will follow shortly.

Further measures will be taken as necessary.

[OrientA]

Important update (source code only)

If you are operating a pool or other important service, or if you are solo mining, and you compile your own node, please pull master from github and upgrade ASAP. Likewise if you have AWS images, please rebuild them with the new version. Additional precautionary checkpoints have been added to protect more of the existing blockchain.

Our recommendation for exchange is to remain frozen for external transactions. If you are still running a node, please update.

https://github.com/monero-project/bitmonero

The only evidence of anomalous activity is what was reported by fluffypony. Nevertheless malicious activity may occur that is not visible until the moment of the attack.

The update is an important precaution.

Updated binaries will follow shortly.

Further measures will be taken as necessary.

Can we small coin holder leave our wallet/daemon running to support the network?

[pallas]

I'm wondering why people still use "screen". Byobu is so much more powerful and easy to use.