Antminer U3 + 5 Antminer U2

MaxHedrm

The U3 has been running pretty stably lately. I haven't had to reset the device but once in the last 48 hours or so, & didn't have to restart the app at all.

FabulousPanda

That sounds like really good news! Can you please post a brief summary of how you've set them up, and their hash rates? It would be great if we could get them all running in just the ASIC window together

MaxHedrm

Remember my drive space issue? It seems to be a memory leak, the cache folder isn't huge. :-)

Right now I am still running in the 2 different versions of MacMiner. 

1.5.25:

5 U2s - usually around 8.5 - 10 GH/s (it depends on if one has zombied - this happens less now that I tweaked the clock back down a notch)

FPGA/ASIC: -S noauto -S antminer:/dev/cu.SLAB_USBtoUART -S antminer:/dev/cu.SLAB_USBtoUART1 -S antminer:/dev/cu.SLAB_USBtoUART2 -S antminer:/dev/cu.SLAB_USBtoUART3 -S antminer:/dev/cu.SLAB_USBtoUART4 --set antminer:clock=x0A81

1.5.25b:

1 U3 - Usually around 36+ GH/s - it restarts regularly & is still a bit moody, it will zombie repeatedly for a while, but then behave for a few days restarting on its own.

GPU: -S noauto -S antminer:/dev/cu.SLAB_USBtoUART13   (or whatever the number is up to)

MaxHedrm

That's interesting ... I just rebooted from the memory leak & 1.5.25b started up first, so it grabbed the U2s (the FPGA/ASIC window auto starts). It is getting 11+GH/s out of them. I guess I'll leave it running & see if it behaves.

MaxHedrm

Oh, here is a screenshot of the last several days...

https://www.dropbox.com/s/r1kj8xicaxhxa59/Screenshot 2015-03-29 01.22.59.png

FabulousPanda

Interesting that you get significantly better hash rate from the U2s with the latest bfgminer, perhaps you'd be better off running two instances of the beta version than one of each version? I fed your data back to luke at bfgminer, hopefully we'll see some improvements by the time 5.2 is released which will be the first official version with support. 

Is there any lineup between temperature and how often the U3 restarts? You could try pointing a fan at it or reducing the clock slightly. I haven't looked in to it THAT much but I did read that the HW has some issues. I realise it's not great having to under clock when you're already getting 50% the desired hash rate but that might keep it constant…

Thanks for the continued reports, I think you're right about the memory leak issue and having two instances open it'll be twice as bad, sorry about that! I unfortunately have some really tight deadlines coming up over the next couple of months so it's unlikely I'll be able to investigate it properly soon.

FabulousPanda

You could also use the GPU window and the FPGA window separately in the same instance of MacMiner seeing as you're using the both already, double the time between memory leak related crashes hopefully :S They both use the same version of bfgminer

MaxHedrm

That's actually what I decided to do once I found it seemed to be behaving with the U2s this time around.

What makes it so challenging is the inconsistency of it all. I just had the U3 spend a day & a half being grumpy, then a solid day doing just fine. It doesn't seem to correlate to temp or anything else I've noticed. Quite peculiar.

MaxHedrm

Interesting. I just had to do my occasional reboot & even though only one of the UART addresses matched, it fired up all five of the U2s (the U3 wasn't plugged in). I guess -noauto doesn't do much.

FabulousPanda

You were using 

-S noauto

not 

-noauto

right?

Another tidbit if information that could potentially make some difference is that when you use the 

-S [whatever]

format it's talking about where it scans for devices, but theoretically does not affect whether it start mining with them. There's another flag for that which would be the same but replace the -S with -d

-device|-d <arg>   Enable only devices matching pattern (default: all)

By using -d rather than -S you may have better luck as I think there have always been some unusual aspects to device scanning on Macs relative to other systems.

MaxHedrm

oops, yeah, I meant -s.

Maybe I'll play with -d then.

MaxHedrm

Hmmm ... what works:

-S noauto -S antminer:/dev/cu.SLAB_USBtoUART -S antminer:/dev/cu.SLAB_USBtoUART13 -S antminer:/dev/cu.SLAB_USBtoUART14 -S antminer:/dev/cu.SLAB_USBtoUART15 -S antminer:/dev/cu.SLAB_USBtoUART16 --set antminer:clock=x0A81

Other things I tried that didn't work:

-S noauto -d noauto -d antminer:/dev/cu.SLAB_USBtoUART -d antminer:/dev/cu.SLAB_USBtoUART3  -d antminer:/dev/cu.SLAB_USBtoUART4 -d antminer:/dev/cu.SLAB_USBtoUART5 -d antminer:/dev/cu.SLAB_USBtoUART6 --set antminer:clock=x0A81

-S noauto -d antminer:/dev/cu.SLAB_USBtoUART -d antminer:/dev/cu.SLAB_USBtoUART3  -d antminer:/dev/cu.SLAB_USBtoUART4 -d antminer:/dev/cu.SLAB_USBtoUART5 -d antminer:/dev/cu.SLAB_USBtoUART6 --set antminer:clock=x0A81

-S noauto -d /dev/cu.SLAB_USBtoUART -d /dev/cu.SLAB_USBtoUART3  -d /dev/cu.SLAB_USBtoUART4 -d /dev/cu.SLAB_USBtoUART5 -d /dev/cu.SLAB_USBtoUART6 --set antminer:clock=x0A81

(ignoring the #s of course, since things tend to change)

So, it certainly isn't a simple replace, and I have yet to find decent documentation for the various switches & arguments.

FabulousPanda

I suspect that without making bfgminer scan for the device (by calling -S noauto) the -d has no effect, so you'd need to allow for -S and -d for a given device, that's a shame but it makes sense that it scans for the device and then starts using it and that's what the different flags are for.

Are you able to set the clock fine across multiple generations of device in the same instance of bfgminer?

MaxHedrm

Well, that is all for U2 & the clock setting works. I haven't played with the clock on the U3 really.

MaxHedrm

Oh, I see what you were asking better now. I am still running the U3 in the GPU window. I haven't had time to mess around with it a lot to try the consolidated method again.