I'm running Ultramix 3.1 with Samsung memory and just a strap copy with the Hynix ... 1750 to 2000. All are at 2000MHz.  They really clip along fairly well.  I just can't reliably stop them.

I suppose it could be worse.

Claymore 11.7 has been running well for me with only the occasional slowdown of card for a couple of minutes only to pick back up to speed.

My only problem is that I can't reliably STOP the program.  I get a BSD from a driver fault whenever I try to stop.  I've tried most of this year's drivers from the 18.2 in Feb to the one before the latest.  I'm in no hurry to be current on my driver under Win10 but I am looking for that stability.  No memory errors and nothing crazy in the overclocking realm.  I'm about 28.5MHs on each of my 580s.

I do use DDU in Safe Mode when I switch drivers to get the cleanest possible install.

Any thoughts about where to look?

Why all of the extraneous spaces?  I can't imagine that will parse properly.

These are 1050ti's right?  Not regular 1050's?

Oh, I see it now.  I missed the reported hashrate line in the graph.  You think someone is in between him and the pool feeding him jobs but only giving him partial credit?  Perhaps flipping some of his shares?

It looks like you're seeing the effect of the command lines working somewhat differently between the two programs.  Claymore is obviously only running one card.  I see you are mostly only supplying parameters for one card on the Claymore command line.  For example -cvddc 980 instead of -cvddc 980,980,980 ... etc.  I don't think you have to do it that way but it always helps remind me that I'm working with multiple cards.

I think from reports, it was the MEW DNS servers that were hacked and they, of course, report their addresses out to the public DNS servers since they are authoritative for the MEW domain.  So many people use Google DNS that they just placed the blame there as that's the system they see giving them the bad address.  But it was the MEW DNS servers pushing the bad address up to the public DNS system.

So your real issue is that you can't hack the DevFee due to the move to SSL for those connections.  Sad.

Yes, run Claymore twice.  Once for the single card, then the second instance for the other cards. 

Anyone able to mine Musicoin (current DAG 1.61GB) in a 2GB card in Win10?  This is just a card on the bus with no display attached and comes up with 71MB pre-allocated ... by Win10 I assume.  I would have thought that Claymore v11.6 would be able to build the DAG and install it in the remaining space but apparently not.  I would understand if this were a card also running a display in Windows but as a non-display card it's showing 2MB Dedicated and 0MB Dynamic allocated in GPU-Z at idle.  HWiNFO shows 71MB allocated total.

Does the on-GPU code from Claymore take up the other 350+ MB when run and prevents the DAG from allocating?  I'm -eres 0 and -allcoins 1 on the CL.

You're right of course.  I'm not sure why my brain settled on 4x when 180/30 is clearly 6x.  The only thing close to 4x would have been Vega64's.

They don't ... they have DDR3 memory attached to the ASICs / FPGAs.  If you look on the Bitmain site, you can see that the device is a) twice the size of their other miners and b) is about the hash equivalent of 4x 580's.  If you consider the 800 watts of draw, it uses more Watts/MH than a rig with 4x 580s.  About the only attractive thing about it is the price ... $800.

The only decent way to attack the Ethash mechanism is to take advantage of the 64 DAG lookup steps in the algorithm.  If you broke your DAG storage into 64 or 128 or 256 separately accessible pieces, you could pipeline the 64 lookup's and take advantage of the random nature of the lookup addresses.  The point is to do 64 lookup's at the same time taking advantage of their being in separate pieces of memory ... usually.  In this way you could pipeline the Ethash and have 64 going on at the same time with each at one point along the 64 step process ... ignoring the pre and post processing.  Occasionally, you would have a collision when two or more lookup's needed the same DAG section and so you'd stall for that step.  It's difficult to get all of that address and data bus space hooked into an ASIC or FPGA.  So it's still a hard problem ... not impossible though.

V11.6 has eliminated the "incorrect shares" that I was getting in prior versions.  Was running just over 1% ... now none.  No other changes than moving from 11.5 to 11.6.  Thanks Claymore.

It looks like NLPOOL has been rejecting my connection attempts over the last couple of hours.  Is the pool oversubscibed for Verge perhaps?  I've also switched to the LITECOIN wallet as described in the instructions on the site which worked fine at first I believe.

Once I switch back to the Verge wallet, it works fine.  I think their examples of how to mine on the Litecoin wallet are not correct for Claymore.

When I was first able to run it, it showed I was mining on something like LITEX16R even though I had "-dpsw c=XVG" as their example shows.  Perhaps @Mine_phun will chime in.

Edit: This is now fixed on the site.  Thanks for addressing so quickly.

Because you're only overclocking one of them?  Is that a rhetorical question?  Perhaps try -cclock 1240,1240,1240,1240,1240,1240 to overclock all 6 at the same level.

I see the same behavior, though GPUz shows the frequencies that I intended to set, the miner hashes about 10% low.  I stop and start again and it's back where it should be.  This happens when using the older Blockchain drivers or the newest Adrenalin drivers.  I thought I was losing my mind.  Glad to see I'm not the only one.  I've just learned to start twice after any re-boot.

I saw something similar and then changed from "-asm 2" back to "-asm 1" and the single mining went back up where it should have been.

I had to re-tune with v11.2 but afterward, I'm seeing a 1.2% increase in hash (580/8GB cards) ... nicely done.  It's like getting the dev fee back.

That's ETH + Blake2s.  I would imagine ETH only would require a re-tune via -dcri as well to find the sweet spot.

Dear @Mine_Phun, NLPool.NL seems to be clipping along well since the hardware upgrade.  I see there are nearly 1000 Verge miners on it now.

I think there's some confusion on the payout increments and you may be able to clear up some of this by editing your Home page.  You list the min payouts as 0.001 and 0.0001, the second I assume is on Sundays.   I think you mean to express that these are in BTC equivalents and not in XVG.

On the miner page for specific accounts, I see that you DO list the wallet payout increment but I'm not sure everyone has seen this.  Also, it seems that the wallet pays out under this amount on Sundays as one might expect just to clear out accounts.

Perhaps you can clarify.  Still, seems to be running very well since the re-build / upgrade.  My payments are processing just fine but I've seen some comments that lead me to believe there is confusion.

Agreed, working well now.