Ok, could you try again with the setting "Masari"?
I just tried it myself. Somehow herominers.com's dashboard just gives me a blank page, but at least i get the messages "Result accepted by the pool" in the console of the VM -> so i am pretty sure that it should work with the setting "Masari".

If i understand this correctly, this coin should work with the setting "Generic cryptonight_superfast" (use the extended script-generator at https://azurecloudminingscript.github.io/Turn_your_Azure_Free_Credits_into_Cryptocurrency_detailed.html ).
Did you already try that?

Yeah, the F-instances (which are E5-2673 v3) indeed work better than the FsV2-instances, at least for monero.

(That's not true for all algos, btw. Nimiq-mining for example has better performance with the FsV2-type).

Yes, the new algo after the fork apparently is a bit more difficult to calculate. From what i have read also the GPU-Miners experienced some drop in hashrate (and also the hashrate of the whole network went down).
I will update the information in the first post in this thread accordingly.
 

here's a very rough guide how to set it up with the google cloud:

Create the instance template:
Settings:
Machine-type: 2vCPUs, 1.8Gb RAM  (i think 2vCPUs per Instance gives the best performance, but i have not yet tested it thoroughly)
Click on "Management, security, disks, networking, sole tenancy"   to open additional options
Preemptibility : On  (for less cost)

startup-script: -> insert here the generated script from my guide at https://azurecloudminingscript.github.io/Turn_your_Azure_Free_Credits_into_Cryptocurrency.html

Leave the other options at the default.


Create Instance group
Settings:
instance.template: select the previously generated template
Autoscaling: off
Number of instances: enter the number of desired instances

Conclusion
For the "number of instances" i chose 10, but apparently there's some quota relating to IP-addresses, so it would only create 8 instances for me.
* Choose "Multi-Zone" when creating the instance-group -> this should make it easier for google to find free resources for your VMs
* From my testing ivy-bridge and broadwell get the best hashrate. I recommend using the region asia-east1, because that has the ivy-bridge-cpu-type as the default.
* I heard that google will ban you very fast if you are using a free account. For my personal testing-account, i have upgraded right away to the paid-version (this won't make your free credits expire, so it's no problem). After some weeks of mining i have not been banned yet.

For 8 instances with 2 cores (i.e. 16 cores total) i get around 700 H/s.

Yeah, i know about this issue. Actually, when i originally setup the script i did a lot of benchmarking to find out the optimal settings for the VMs in the azure-cloud. This hugepages-setting did not make any noticeable difference, so i did not bother including it in the script. I think this setting is mostly useful if you are mining on a real machine (maybe then you get that +20% hashrate that is mentioned on some mining-guides). Since with azure we are always inside a VM the effect is not there.
But you are right, the messages in the log from xmr-stak do not look good... since the setting also did not have a negative effect, i will include it in the script.
Thanks for your suggestion!

So there was a bug in my autotune-feature for the thread-configuration. Apparently somehow this didn't have a noticeable effect with the pre-fork-algo, but since the fork the resulting hashrate is much worse.
So after fixing the bug the hashrate for 10 instances of F2 is back to around 1.4kH-1.6kH, and it does not seem to be dependent on the region so much anymore.

In order to activate the fix for your miners you can either restart your pool (scale to 0, then scale back to e.g. 10 instances) or you just wait for ca. 3 days (after running for 3 days the miners will fetch the latest version of the script from github).

From what i have seen with my miners i suspect that this issue is region-specific, i.e. some regions just don't work so well anymore. Can you confirm this? (unfortunately the regions you are using are not visible from your screenshot)

Have you tried changing to a different region? I.E. if you are using East US, try East US2 instead. Also, make sure that you are really using the "F2"-Type instance (the similar-looking "F2s V2"-instances will give you a lower hashrate),

Don't you have to enter a credit-card number at some point to upgrade to a paid-for-account? In my experience there's a high chance that your account will get banned if you are mining with a free account.

I'm sorry, but as far as i know the only sustainable way of doing this is if you have a legit MSDN-account with free credits.

Have you tried the instructions from my earlier post?
Link: https://bitcointalk.org/index.php?topic=3444898.msg46166083#msg46166083

Hi everybody,

so looking at things post-fork i can say that everything went mostly well.
However, If you are using moneroOcean, your miners probably stopped working... as it turned out, in order to keep mining at MoneroOcean you have to use the setting "cryptonight_v8" -> just exchange the string "export currency=cryptonight_v7" with "export currency=cryptonight_v8" in your startup-script (currently you'll have to make the change manually... i will update the script-generator at the weekend). After restarting your pool (i.e. scale to 0 and then scale to the number of desired instances) it will work again.

Otherwise, is any of you having trouble after the fork? Please post here (or contact me via PM or email) and i'll help you.

PSA: Monero will change its PoW on 18th of october (see https://np.reddit.com/r/Monero/comments/9lcdme/preliminary_information_thread_regarding_the/)

The good news: for most configurations you don't have to do anything, i will update everything so things will just continue running.

However, if you are mining some coin other than Monero but you chose the setting "Monero (cryptonightv7)" instead of "generic cryptonight" when creating the script you should re-create the script with the option "generic cryptonight". This is because after the fork the setting "Monero" will actually mean "cryptonightv8, which will probably not work with you altcoin.
Also, if you are using MoneroOcean you will probably have to do something (as far as i know Monero is the only coin to change to cryptonightv8 so far - MoneroOcean's concept of coin-switching obviously only works if there are multiple coins with the same algo available).

(So far i have not yet updated the script because i am still waiting for the official release of the new version of xmr-stak.)

FYI: i have updated the previous post on how to work with AWS.

I have not personally used my script with AWS, but one nice person has actually got it to work. He gave me these instructions:
Apparently there's some subtle difference in the way AWS and azure call the startup-scripts. So for now my script-generator won't work with AWS. However, you can use the template linked above to manually create your own script.

Note that i don't have a AWS-account (yet), so i can't really help you if you run into problems. But you can write a post here anyway, i'll do my best...

edit: added more detailed instructions and added information on how to use the startup-script

I don't know the details, but i can tell you that at least for mining Nimiq in Azure the Fv2-type (skylake) will give a lot more performance than the F-type (Haswell). On the other hand, mining Monero works better on the F-type -> That's why i think i think it's less a question of the cache, it probably has to do with the instruction set.

Hi impynick,

apparently azure has changed the default-quotas for new accounts.
Anyway, the number of batch-accounts and pools is not important, as long as the total number of instances adds up to your desired value (and you'll thus get the desired hashrate).
Basically, if azure does not let you increase the number of instances in a pool, just create an additional batch-account in another region and create the additional pool there (if i understand correctly you have already started doing this).
Typically maintaining everything is easier if you have fewer pools with many nodes instead of having lots of pools with fewer nodes, but the hashrate will be the same.

So to use up the starting credits you could use the following configuration:
Batch account "batch1" with pool "pool1" in region "East US" with 5 Nodes.
Batch account "batch2" with pool "pool2" in region "East US2" with 5 Nodes
Batch account "batch3" with pool "pool3" in region "West US2" with 5 Nodes.
This should give you a total of 30 cores, which should consume the 200$ within one month.

(you could also try creating an additional batch-account in North Central US, but i think there's also a limit of 3 batch-accounts. Anyway, even though this would increase your hashrate, you'll consume your credits faster - in the end the profit will be the same)

In my experience F2 will give the best hashrate per core (this is due to the way cryptonight works with the CPU-Cache - read my initial post to find out more about the autotune-feature of the script). In your case i would suggest setting up two pools (in different regions, e.g. "East" and "East 2") and using 10 instances of F2 each. Since you are just using the initial credit of 200$ you don't really care about the monthly cost, you just want to use it up within one month.

Don't worry. Just start following the guide, after that the words will make sense to you. Then  you can create your second pool.

I believe the 200$ starting credit is valid only for the first month. Maybe you could double-check the conditions. Anyway, the amount of generated cryptocurrency will be the same, whether you spend 200$ in a single month or over a longer time-period.