nIcKeLbAcK: Top man!  Downloaded it, tweaked settings for 5 minutes and already got the performance I had with the two separate runners, but with one card slightly above, one slightly below (130 each vs 110, 150).  Will tweak more later, just going to let it run and see if it's happy.  The Raw Intensity setting seems to be a useful thing - I had no idea until reading that thread of the exponential increase that Intensity led to, no wonder I:12 was fine and I:13 was instant HW failure runs!  THanks again.

nIcKeLbAcK: I have made some progress - thought I'd share it with you, see if it's any use to you. It's a bit clunky (but TBH I'm pretty busy with actual work in the real world, so made a kludge to get it working), but it works.

I'm now running 2 instances of vertminer.exe, one uses GPU0, and one uses GPU1.  What's weird is I did a bit more testing after yesterday, and found that on either GPU if I turned the other off, then it performed better, and that my GPU0 prefers threads set to 1, and GPU1 to 2.  So, rather than spending forever sorting out why (if that's even possible, I suspect there may be something that's beyond a settings issue), I did the following:

a) Copied Vertminer folder and renamed it (I now have vertminer-GPU0 and vertminer-GPU1).
b) Inserted the following line into vertminer.conf:
"device" : "0" (into the one for GPU0)
"device" : "1" (into the one for GPU1)
c) ran each instance individually (with a different miner username/login for each setup).

Both run OK, on one GPU only.  I now get ~160k out of GPU1, and ~120k out of GPU0.  No idea why, technically, but as I said, there are pragmatic limits, I'd rather be mining and doing stuff in the real world than spending 7 hours testing settings that will maybe net me £0.50 a day...

JohnnyDaMitch: When I get some time I will have a look at that; I definitely saw different behaviour with 0.5.2 in terms of quitting; 0.5.2 hung on exit almost every time I used it.  As you say, it's weird that I only see it in vertminer, but one thing I've learned is that software can do unforeseen things, and unless I want to spend days testing it, I guess I have to leave it at that.

Hey Folks:

Spoetnik:  The same values are used for both cards - certainly that's the case with cgminer (which I believe vertminer is a fork of), and bfg; both cards I have have run happily using one set of values applied to both.  From the cgminer 3.7.2 readme: "The setting passed to cgminer is used by all GPUs unless separate values are specified".

JohnnyDaMitch:  Thanks - I know what you mean about % / RPM, but given that the cards work OK in other miners, I had largely ignored the differing reporting of the same setting (although I do acknowledge that I could represent a deeper problem).

Aurum:  A worksize of 256 works well with cgminer, but 64 gives better results in my testing than 256 for vertminer - with 256, I get around 100Kh/s, but with 64 (which I saw someone else had used on a 7850) then I get around 160Kh/s; that's why I put it in there.  I've re-tested at 256 this morning, and got the same results as yesterday.  Thanks for the link to GPU-Z; I wasn't aware of it, but it has confirmed that my cards are running at the speed I anticipated (1050/1250) - I get this whether I specify it explicitly in the .conf file, or I use "0" (which I believe uses the system-set parameter) - either way, I get the settings I would expect (and that have proven very reliable long-term with cgminer and indeed bfgminer).

I tried the settings you gave, and got some interesting results - the hashrate for GPU1 (which is the good one) was around 110k (similar to the settings I've seen with worksize of 256, so I assume it's down to that), but GPU0 (which usually gives 6k) rose to 11k.  Using your original intensity of 13 leads to HW errors on GPU1 (as I found in all the testing I've done so far), so I put it back down, but at lest it shows that vertminer responds to individual settings.  A bit more testing showed that the 11k on GPU0 came from setting gpu-threads to 1; this slows down GPU1.  Setting gpu-threads to 2 gives a faster rate on GPU1, but slows GPU0 to 6k. 

nIcKeLbAcK: Looks like we're in the same boat then - again, I have GPU0 running at 6k, and GPU1 running as expected.  And as you say, this is the only miner I've experienced this with; I've run lots of versions of cgminer without issue, and usually use bfgminer now (as it works with MultiMiner), and neither has this issue.  

Can anyone give me any ideas as to why this is happening?



Two Sapphire 7850s, which in cgminer and bfgminer mining scrypt give pretty much identical results (been running them since August).

Running vertminer with the settings below, one card gives about 6Kh/sec, the other gives 170 or so.  From what I've read, 170 is about what I should expect... so why is the other card doing almost nothing?

I'm using the .conf file, and here are the relevant settings:


All suggestions appreciated.

OK, thanks, just seems a bit non-intuitive that the hash rate still shows up in that page.

Had a bit of a disaster with my network miner, so it's now offline.

It's not showing up in Multiminer, but in MobileMiner it still does:



When I tap it, it shows that it's offline, but still shows 2.31Gh/s, although that number isn't part of the total on the main screen of MM.

Any clues?

The actual command specified will depend if you're on Windows or Linux as the way the ports are addressed is different.

For instance, on my Windows miner, my three ant miners appear as COM14, COM5 and COM6, so my multiminer startup script looks like this:


If you find out the port addresses for your miners, you should be able to run them using a similar command to above, with appropriate clock settings on each with the first argument.

You'd have two commands like this, so for instance, if your "slow" ones are COM 1, 2 and 3, and your fast ones are COM 4,5 and 6:

I'd like an update on this too - with the proviso that the pool is on the right fork, there shouldn't be a problem, and it's for the clients to have the right wallet?

I've been on 1.5 and the correct fork for a while - from what I've briefly read, this isn't anything new, it's just that it would appear to have become a problem with some people (I guess because of Doge's status?) and they're taking a belt-and-braces approach. 

Still a bit annoyed as I've got 7000 in there I'd like to exchange (I've been mining doge and exchanging), which I cant and the price has dropped 10% while this has been on hold.

FTR - coinotron is generally fast and efficient; other pools I've been on are nowhere near as good, this is the first time I've had an issue.

It's definitely possible - you'd need to set the ports correctly on each bfgminer that you run, but it definitely will work, just take a bit of working out which port the good/bad antminers are on, and then writing a startup script for each one with the appropriate settings.  MultiMiner runs multiple bfgminers (to allow it to mine scrypt/sha, and indeed to mine different coins on different GPUs, etc) without issue, so starting it 'manually' shouldn't be a problem providing you specify the ports on each instance.

Are you on Windows? I'm assuming you're talking about the Antminer U1

If you are, make sure you have the right drivers installed (The Silicon Labs CP210x ones) so that your ant miners appear as a COM port to Windows.  If this isn't right, bfgminer won't be able to access the antminers.

Then you need to launch bfgminer with all the right command line switches for your pool, etc., but importantly add

-S antminer:all

and I think that should do it.  

Having said that, if you are on Windows, I'd recommend nwools' excellent multiminer as it makes life a lot easier , giving you a GUI to work with, and allowing swapping coins/pools a piece of cake.   It'll download bfgminer for you and takes a lot of the hard work out of getting things up and running.

I've just re-installed 2.7.0 and run it, and did a hardware scan (although there are no changes and 2.6.3 worked with the same settings) and this time, (typically!) it's run OK.  It took a -long- time for the Antminers to start working; for the record (not sure if I was clear) they appeared OK in MM - I could see all 3, but mining didn't start (I left it for a couple of minutes and nothing happened).

So, it appears to be OK - sorry about that, not sure what happened.  Oddly the restart issue I described earlier also doesn't appear to be happening now, which is good!

Just tested the network restart of my network miner - that worked fine.  I've only got one pool set up on it and I'm away from it at the moment (I can't SSH into it), but I'll set up another pool and see if that works when I get back, probably tomorrow.

I've just downloaded that and tried it, but have hit a problem.

I've got three groups in there - GPU, ASIC (all Antminer U1s) and my network bfg setup.  With 2.7.0 when I run it, the network setup works fine, and starting mining gets the GPUs working properly, but the Antminers never start up.  I've tried re-starting the app several times to no avail.

I was going to post a question related to this; while on 2.6.x everything starts fine when you start the app, sometimes when I use restart (if I've changed coin on the scrypt miners), it doesn't re-start the U1s; nothing appears in the stats columns, and there's no mining being done by them.  If I hit stop, leave it for 20 seconds or so and then start, it works fine.  Not sure if this is related, but it appears on the face of it that 2.7 always does this regardless of being 'start'ed or 'restart'ed.

HTH?

IIRC some people were overclocking these by using a pencil to deposit carbon/pencil lead on one of the resistors to alter its value.  It's possible it's been done by replacing a resistor using the proper tools, and then it would look no different.

My first ASICs were BE, and they 'just worked' - once I had the driver in them, they worked without issue at the stock 333MHz speed, with 0 HW errors.  As stated above, they don't need extra cooling to work (and mine ran without for months), so you shouldn't have a problem with them.

The U1s work well - again, once the driver is installed (with the standard Silicon Labs driver, not using the Zadig nightmare), they work well.  If I were you, I would use nwools' excellent MultiMiner to control bfgminer as it makes life a lot easier; you can add your scanning command line to find the miners, and then do all your setup from there.  Much easier (to my mind) than using lots of config files.

OK, well, here goes:

I'd like an "if ... then ... else" system, I think... but with some timing built in - again now that someone's asked me it's time to go away from the "nebulous idea" stage, so I'm just roughing this out:

If [DGC difficulty < 8] then mine [DGC] for [8 hours/day]
else if [DOGE coins/day > 5000] AND [DOGE/BTC > 0.0000176] then mine [DOGE] for [16 hours/day]
else mine [LTC]

something like that - with the time being counted by multiminer and reset every 24h - one of the "time" options would be 'constantly' allowing that option to be mined all the time until the condition is no longer true.  That my two timed options add up to 24 hours is a coincidence BTW.

I realise this is probably either OTT or full of holes, but that was what I was thinking would make doing this (on admittedly a toy shop scale) easier.

Hi

Yes, I'd like to do it for only one coin, but also realise that's probably not what most people would do!  I had envisaged a "do a if condition a is true, otherwise do b" type setup, but appreciate this could become somewhat complex?

I've reverted to the release version of bfgminer as I was getting a lot of rejects with the current snapshot as listed above, and also it wasn't reporting current hashrate (but did have accurate effective hashrates in contrast with the release version) - again, not sure if that feedback is helpful, but I understand from reading the bfgminer thread that you're the maintainer of the scrypt code (although the snapshot didn't report current hashrate for bitcoin miners either).

Thanks - just got in from work and set it up, and it now works fine for Effective hashrate, although the current hashrate column is now empty?  Having said that, I'd prefer it if the fix worked the other way and actually gave me 140Mh/s of hashing power, but I guess even you have limits!

Top app, by the way; I have to say that the update isn't of "Apple quality", it's way better than that.  Works flawlessly every time, and the app itself is great, having simplified my (admittedly not that complex) mining setup this week.  

Are there any plans to make the mining strategies more complex?  Reason being that I'd like to mine a certain coin occasionally when the difficulty drops to a sane level, but I don't want to spend all my spare time checking dustcoin.com and then remoting into my mining rig; I also seem to miss the low difficulty boat when doing this as within half an hour everyone else seems to have done the same!  

I'd like to add to the calls for a peek at the road map, if only to save asking you questions that you may already have answered, but appreciate that you don't want to make any more work for yourself.

I have a question, which may be a problem. 

Until today I've not been using MultiMiner for both scrypt and SHA-256, but after the excellent 2.6 release I decided to bite the bullet and ditch CGwatcher (which I was running in parallel without too many issues), and use MultiMiner to monitor both.  I got it up and running pretty easily, but have a query - the effective mining rate of the scrypt coins is shown as far higher than I'm actually getting:



I'd love to be getting 69Mh/s and 74Mh/s from my two cards, but alas it's not the case.

Am I missing something, or is this a bug?

But that's the thing - I am OCing the U1s - they're running at 2GHz (they were originally at 1.6), but only giving effective rates of 1.6 - so that appears to be the work that is being done. 

I've got a couple of setups running bfgminer 3.10.0.  One has three Antminer U1s on it, the other has a Red Fury.  Both work fine, but I've noticed something and am wondering if anyone can offer an explanation.

The Red Fury has a raw hashrate of 2.34GHz, and an effective one of 2.25GHz - an efficiency of about 96%.

The U1s have a raw hashrate of 1.97GHz, and an effective rate of 1.57GHz - 79%.

Is this something that I'm just stuck with, or is there some way to improve on this?  Both are mining in the same pool (btcguild).

Once more, the 2.6 PR4 is working fine (although I had to delete the entire folder I'd put 2.6 PR3 in rather than just paste everything in, it
wouldn't start bfgminer successfully until I deleted everything and 'started from scratch' with it downloading bfgminer for me).

As before, 2.6 PR4 detect my networked bfgminer 3.10.0 installation very quickly.

One other issue - on Chrome when downloading the zip file I get the warning "Multiminer 2.6.0 is not commonly downloaded and could be dangerous" - I know this isn't your fault, just thought I'd let you know.

Are there any plans to make the network-visible miners viewable via the MobileMiner app?