Topic: [XMR] Monero Mining - page 34. (Read 264830 times)

Rates is easy: c3.8xlarge is around 0.3 USD/hour, g2.2xlarge around 0.1 USD/hour. Slightly lower in fact, but let's compare them by max rate.

Hashrate is more difficult. I don't know exactly how to read the miner logs, the hashrate values seems to change quite a bit over time.

Additional complication: when I opened a large number of concurrent c3.8xlarge instances in the same region, the per instance rate seemed to be lower than when I only had one or two instances in that region running.

What are the has rates on the c3.8xlarge and  g2.2xlarge, what are the costs?

Question for those more knowledgeable on mining / EC2 matters:

I don't have the exact numbers to support this claim, but by my estimations of the last few days, EC2 mining via GPU/g2.2xlarge instances seems to be more cost-efficient than EC2 mining via c3.8xlarge. Is that at all possible?

I had about 30 c3.8xlarge instances running yesterday, and replaced them with about 30 g2.2xlarge instances. The total hashrate seems to be lower (hard for me to add it up, but maybe about half of the CPU instances), but cost is closer to 1/3 of the CPU instances.

Just asking, hoping someone with more experience in this can maybe confirm this intuition, or tell me if I'm most likely wrong.

For some portion of the past 12 hours (including a time after my update message) there was a bad commit on github, so if you updated from there you should make sure you have the current version as of now.

 
Fast blockchain sync Linux for noobs :

First Install :

cd
mkdir ~/.bitmonero
cd ~/.bitmonero
wget http://monero.cc/downloads/blockchain/linux/blockchain.bin


Update :

cd
rm -r ~/.bitmonero
mkdir ~/.bitmonero
cd ~/.bitmonero
wget http://monero.cc/downloads/blockchain/linux/blockchain.bin

Important update (source code only)

We have a new update with additional precautionary checkpoints added to protect more of the existing blockchain. In addition this update adds the ability to read checkpoints from an external file. We will be distributing updated checkpoint files that will continue to protect the blockchain without the need for a full update of the daemon.

Although there has been no actual attack we consider the threat credible and are acting accordingly. We urge you to do the same.

We are however, continuing development and this update also contains some new features that will be included in the next official build. As such, dependencies have changed. For example Linux dependencies:


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

Plain 'git pull' wont work. Unless you are doing your own modifications to the code it is probably easiest to make a new clone. If you are doing your own modifications you should know how to use git.

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. If you are not a git expert it is probably better to just create a new clone. Likewise if you have AWS images, please rebuild them with the new version.

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

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.

XMR pool MONERO.RS statistics page has been updated to allow aggregate individual worker stats. You can now dedicate a worker id to every rig and monitor them all on one page.

This new feature is not available on any other pool that we know of and is perfect for legal botnets. More info on our official thread here : https://bitcointalksearch.org/topic/xmr-pool-monerors-2-pplns-anti-ddos-exchange-payments-workers-stats-791015

I don't even see the install script there any more, but maybe I'm looking in the wrong place.

I see

Here: http://monero.cc/getting-started/index.html#install_source

That is how I do it, except "make -j$(nproc)" goes much faster.


I find this is usually not a major concern. The reason being that you will end up needing to update your images (new version of node, etc.) and at that point I will just update the blockchain in the image as well. (I also grab any new OS updates.) The rest of the time, yes it syncs but it doesn't really take that long. Downloading the bootstrap would probably take longer (unless your image gets really old).

Another pitfall here is to make sure you have enough disk space for two copies of the blockchain. Because when it saves (every 12 hours) it stores the new one before deleting the old one. This can be an issue on some very small instance types.


Excellent! Thank you (and them) for both.

Its doesn't have a full node, yet. Does the install script point to the right sources?

The main issue I see with it is that the blockchain needs to be resynced every time the instance is launched.
Maybe it is possible to check the mod date of the blockchain and download the bootstrap automatically in case it is too old?

PS - I'm not linked to CryptonotepoolUK. I just used it in the AMIs because it had low hashrate and donates 100% to devs.

If it is 100% pool then you wouldn't even have a node in there at all, so no issue of upgrading.

My preferred way to use AWS is pool on the GPU and solo on the CPU, but I don't know if they are doing that.

Thanks for the answers re: EC2. I understand your point now, smooth. Some of my instances were outbid over night, not to return, so I guess the "persistent" setting is the way to go.

A question for the CryptonotepoolUK guys: Is the XMRminerToDevFund AWS upgraded to the latest version? Or doesn't that really matter because it's pooled mining?

Of course!

If you are able to update from source code (for most Linux users this is fairly easy) then please get the latest update as described above. If not please await a new version of the binaries soon.

I'd never heard of it. Sounds useful. Thanks for the recommendation!

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

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

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.

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

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.

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:


with this:


in the rc.local file.

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).