Ok, good to know. What I see is, I tried sending shares to dgbg.suprnova with 4 different versions of ccminer, all of them showed ~75% of reported hash rate disappearing somewhere. I tried sending shares to theblocksfactory with 2 versions of ccminer, and 1 of them worked as expected with miner reported hash rate and pool reported average effective hash rate being a close match.

I'm new to mining with NVidia GPUs and all the information I've found so far about Myriad-Groestl mining software for NVidia GPUs recommends some version of ccminer.  Can you recommend a version of ccminer that is known to work with dgbg.suprnova? Or alternatively, can you recommend some other non-ccminer Myriad-Groestl mining software for NVidia GPUs that you know works with dgbg.suprnova?  

I don't run a pool, so I won't pretend I understand what check a static diff can circumvent, or how using a static diff could lead to stolen shares. I'll take your word for it.

Good to know that static diff is permanently disabled on dgbg.suprnova. For me, static diff simplifies tuning, benchmarking, comparing mining rigs, or comparing different mining software. The rest of the time, I'm happy to let vardiff change the diff as needed.

I do have a couple of suggestions for improvements to the dgbg.suprnova dashboard.

• If static diff is permanently disabled, please remove the text above the example code and the text in the -p field of the example code that tells/shows how to enable static diff. Otherwise you risk confusing and frustrating miners who are interested in using a static diff.
• Since there are problems with at least 4 versions of ccminer when sending shares to dgbg.suprnova, you could help miners using NVidia GPUs who want to send shares to dgbg.suprnova by changing the beginning of the example code from ./ccminer... to ./[foldername-for-ccminer-version-known-to-work-with-dgbg.suprnova]/ccminer... or ./[non-ccminer-that-works-with-dgbg.suprnova]/[suprminer]...
• It would be easier to see how workers are doing if values in the Difficulty column of the workers table matched the values that suprnova is telling the mining software to use.

I'll be back to dgbg.suprnova if/when I find software that solves Myriad-Groestl shares on NVidia GPUs in a way that dgbg.suprnova accepts/recognizes. Till then, I'll have to submit those shares to a different pool.

Pointed my miners at theblocksfactory. Initially I was disappointed, effective hash rate for myr-gr with ccminer v8.11-klausT was the same 25% of the miner reported hashrate I had seen on suprnova.

After changing the bat file to use ccminer v2.1-tribus instead of v8.11-klausT, I'm seeing an average effective hash rate that matches the miner reported hash rate, yes!

I'll be back to dgbg.suprnova.cc if/when it and some version of ccminer myr-gr interact as expected.

Also, something appears to be wrong with the myr-gr algorithm in ccminer v8.11-klausT. If I let theblocksfactory vardiff do it's thing, sgminer, reporting 115MH/s, switches between diffs of .128 and .256. v2.1, reporting 152MH/s, switches between diffs of .128, .256, and .512. v8.11-klausT, running on the same two cards as v2.1 and reporting 163MH/s, switches between diffs of .032 and .064. Even at this lower diff, v8.11 submits many fewer shares in the same time and has an average effective hash rate of 25% of what is reported by the miner. This probably isn't a pool problem as it happens on more than one pool.  

Thank you for recommending theblocksfactory.

Can dgbg.suprnova.cc be fixed to correctly reward work being done with ccminer?

I have a rig with 3 older AMD cards and 2 new 1070s. I'm mining on the AMD cards with sgminer-x11mod, and on the NVidia cards with ccminer-8.11-KlausT. I have a separate worker on suprnova for each of the two sets of cards.

sgminer reports a hash rate of 115 MH/s. ccminer reports a hash rate of 160 MH/s. Both miners are running at difficulty 0.139 (sgminer reports accepted shares with Diff 0.201/0.139, ccminer's last line showing stratum diff change says "Stratum difficulty set to 0.139063") and diff appears to be stable once the miners reach 0.139. ccminer and sgminer get to this diff in about the same amount of time regardless of whether I use the worker password or the "d=0.139" diff setting in place of the password.

After both miners run for 30 minutes, the AMD cards have found 318 shares, 315 accepted, 3 rejected. The NVidia cards have only found 163 shares, 160 accpeted, 3 rejected. In other words, ccminer is hashing 140% faster than sgminer, and only finding half the shares at the same difficulty in the same length of time.

Worker stats on the dashboard look like this:
     Worker             Hashrate     Difficulty
****.***AMD      123,253.49      35.6
****.***CUDA       45,790.61     35.6

I have no idea how the dashboard difficulty of 35.6 relates to the miner reported difficulty of 0.139, at least the dashboard shows difficulty is the same for both miners.

The effective hashrate for the CUDA worker is the main problem on the dashboard. The AMD worker hash rate appears to be correct, it is most often centered around the miner hash rate of 115, + or - 10, with rare outliers as low as 75 or as high as 155.  The CUDA worker hash rate is never close to the miner reported hash rate, it is most often centered around 42 (26% of the miner reported hash rate!), + or - 10 with rare outliers as low as 22 or as high as 62.  

This degraded hash rate shows up on the suprnova pool when using any of the following versions of ccminer, v2.0-x86, v2.0-x64, v2.1-tribus, and v8.11-KlausT. Playing with ccminer's -f and -m options range from no effect with settings close to 1, an even lower acceptance rate with -m 2, or a >50% rejection rate with -f 2.

Until the problem with ccminer on dgbc.suprnova.cc can be fixed, what other pools are people pointing their miners to for DGB Myriad-Groestl?

Thanks for the response.
Added "diff-factor" : "2" to the config file and gave it a try.

8.11-Klaus-T quickly found 1 share which was rejected with a reason of "reject reason: low difficulty share of 0.23825932042784703" after which it apparently died. That is, it did nothing for the next 12 minutes, with task manager showing 0 CPU activity for the ccminer task.

The 2.1-tribus version ran with "diff-factor" : "2" in the config, and the effective hashrate in the pool was close to the 151.x hashrate shown by the miner. The problem with 2.1-tribus and the suggested option is the almost 50% rejection rate. After 1h 24m, tribus found 839 shares of which only 437 were accepted, the other 402 shares were rejected with the same "low difficulty share" message. During the same time, the amd cards had 548 accepted and 5 rejected shares.

The suggested option fixes the problem of the pool showing a very low effective hashrate for the nvidia worker, and increases the shares ccminer solves to a level that actually exceeds the % difference in hashrates reported by the two miners, but only at the cost of an unacceptably high rate of rejects.

I'll try a different pool tomorrow, and maybe the 2.0 x86 and x64 versions of ccminer if the pool switch doesn't help. Just out of curiosity, which version of ccminer would you recommend for mining myriad-groestl? I like the fact that 8.11-Klaus-T shows a 10Mh/s higher hashrate than the other miners, but that is only useful if the higher hashrate translates into more shares.

I'll post what I find tomorrow after the pool switch.

Hello everyone,

I'm looking for suggestions on how to increase acceptance rate and effective hash rate for myriad-groestl mining with ccminer.

I have a mining rig with 3 older AMD cards and 2 new GTX 1070s. According to ccminer, the 2 1070s are hashing myriad-groestl at 162.x Mh/s which is 140% of the 115.x hashrate of the 3 AMD cards as reported by sph-sgminer-x11mod running with an updated myriad-groestl kernel.

The pool reports that both miners are mining at the same difficulty in the following screenshot, so I would expect to see the 1070s getting somewhere around 140% of the shares of the AMD cards. I'd also expect to see the effective Hashrate reported by the pool for the cuda worker to be closer to 160, I've never seen it go above 60.
http://imgur.com/pPivYDh

Actually, the 1070s are getting less than half of the accepted shares of the amd cards. Here's a screenshot of both miners, started at the same time, after a 14h:42m run:
http://imgur.com/0i23gg9

I've tried ccminer 2.0 x86, x64, 2.1-tribus, and 811. All exhibit the problem of reporting a high hash rate but finding fewer shares than the slower AMD cards hashing at the same difficulty for the myriad-groestl algorithm.

What sort of tuning might be done to ccminer or the cards to increase the effective hashrate in the pool and/or increase the rate of share acceptance in the miner? Or, is this a problem with the pool?

I'm only seeing this problem with ccminer/myr-gr. When mining equihash with different mining software (EWBF), the 1070s are also hashing around 140% faster than the AMD cards, and the effective hashrate in the pool and the number of accepted shares reflect the higher hash rate.  

I'm seeing the same or similar issue with excl. I cashed out excl on Wed morning. My excl account balance has been showing 0 since then, even though we've mined many blocks. Ipominer, can you look into this?

Just fyi, the problem is definitely affecting the pools (at least the X11 pools) as well the website. Here's what I've been getting for the past hour or so...

[19:35:16] No servers were found that could be used to get work from.
[19:35:16] Please check the details from the list below of the servers you have input
[19:35:16] Most likely you have input the wrong URL, forgotten to add a port, or have not set up workers
[19:35:16] Pool: 0  URL: stratum+tcp://pool.ipominer.com:3335  User: --------------------------
[19:35:16] Pool: 1  URL: stratum+tcp://pool.ipominer.com:3626  User: --------------------------
[19:35:16] Pool: 2  URL: stratum+tcp://pool.ipominer.com:3601  User: --------------------------
[19:35:16] Press any key to exit, or sgminer will try again in 15s.

The new webpage sounds great, I'm looking forward to seeing it when the site is up again.
For now, a get request to www.ipominer.com returns an internal server error (500) and all I see is a blank page.
Can you take a look and post when the site is up again?
Thanks.

I'm seeing the same thing with NEOS. Mining most of the day, blocks being found and confirmed. Unconfirmed balance stays at 0. Confirmed, unconfirmed and per block estimates don't change. I'm suspecting there's a problem with the front end?

If all KORE payouts have been processed, what does that mean in regards to my unconfirmed balance of KORE coins? Will they be confirmed in the future, or are they gone?

I think it would have taken more than the last 120 orphaned blocks for me to have mined as many coins as are showing unconfirmed.

So, what's up with PIG withdrawals? Went to coinking.io, entered a new PIGGY address, and they issued a PIG deposit address. I entered the coinking PIG address on the ipominer account page and requested a withdrawal of PIG. The withdrawal has been hung in the requested state for a couple hours now.

Thanks.