Antminer U3 + 5 Antminer U2

MaxHedrm

Weird. Now I just have the U2s plugged in. It seems to be detecting 4 at most, and the ones it doesn't detect vary. Then it stops again. *sigh* <wahhhhhhh>Why does this have to be so hard.</wahhhhhhh>

FabulousPanda

by checking the antminer box? I'm not sure that's necessary any more, things have changed a bit since that was coded, I'd uncheck them all - it detects my BFL now regardless of whether it's set to in options, though that's not true for Block eruptors - probably because they were considered redundant before this change was made.

Best way to make sure it's only loading your device is to uncheck all the boxes and set the manual flags

-S noauto -S /dev/cu.SLAB_USBtoUART

I wonder whether the antminer flag is specific to the U1 and 2 revisions (though I doubt it looking at the code revision on github), which could potentially mess up what's going on here. But if you've no luck with the previous, try

-S noauto -S antminer:/dev/cu.SLAB_USBtoUART

-S noauto sets it not to look for extra devices or use any you haven't specified in the flags

FabulousPanda

If I were you I'd set up the ASIC window to use your U2s by flags like

-S noauto -S antminer:/dev/cu.SLAB_USBtoUART -S antminer:/dev/cu.SLAB_USBtoUART1 -S antminer:/dev/cu.SLAB_USBtoUART2

etc.

Then work with the GPU window trying to get the U3 running properly. Just set the Intensity in the GPU window to minimum so it doesn't heat up your GPU

FabulousPanda

Also, if you're using all of these in the beta version with antminer U3 support I'd check whether the U2 behaviour changes in the standard version, but please note down all the behaviours you notice and the differences in behaviour with the new version as luke-jr needs feedback on how the driver is working for Macs

N.B. you can run as many versions of MacMiner simultaneously as you like

MaxHedrm

Yeah, I just had antminer checked. With it unchecked nothing detects.

-S noauto -S antminer:/dev/cu.SLAB_USBtoUART gives me one U2 (which makes sense). Amusingly, it was the one that was most often having issues detecting on auto. Then it stops again. Maybe I'll unplug it.

FabulousPanda

Aha! Rinse and repeat with another unit, if it behaves leave the dodgy one out till troubleshooting is though…

MaxHedrm

Oddly, I tried:

-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

It still fired up only 1 of the U2s. But it was a different one. I guess whichever one says "I'm here!" first?

MaxHedrm

Hahah. So, that's why it only picked one of them. I turned auto back on & it detected:

 [2015-03-21 20:55:43] AMU 0: Opened /dev/cu.SLAB_USBtoUART37

 [2015-03-21 20:55:43] AMU 2: Opened /dev/cu.SLAB_USBtoUART36

 [2015-03-21 20:55:43] AMU 1: Opened /dev/cu.SLAB_USBtoUART34

 [2015-03-21 20:55:43] AMU 3: Opened /dev/cu.SLAB_USBtoUART

 [2015-03-21 20:55:43] AMU 4: Opened /dev/cu.SLAB_USBtoUART38

34, 36, 37, 38.

FabulousPanda

haha, must be the result of replugging them. To get a list of currently connected miners (among other things) type this in to the Terminal app:

ls -la /dev/cu*

MaxHedrm

But before it was [null], 1, 2, 3, 4, 5. Dynamic stuff is annoying.

FabulousPanda

Another option is to set the U3 up like 

-S noauto -S antminer:/dev/cu.SLAB_USBtoUART

(assuming you can identify it…)

then in the second miner window use 

-S antminer:all

and it'll load the rest, but mention that the other is in use. Not sure whether this will cause any problems however, at your own risk…

MaxHedrm

That would also mean I'd have to make sure they started in the right order. I guess that'd only be an issue for power outages. (And my biweekly reboots when something about MacMiner fills up my tiny hard drive. :-( Not as bad as it once was though.)

MaxHedrm

I decided to try it this way...

start MacMiner 1.5.25 with -S antminer:all

then

start MacMiner 1.5.25b with -S antminer:/dev/cu.SLAB_USBtoUART44

(I tried using :all first, but it even said 44 was in use.)

That seems stable.

MaxHedrm

Oh, I forgot to mention that the U3 was unplugged from the USB when I started the 1.5.25. That's important.

FabulousPanda

Oooh, what are the hash rates you're getting in this setup? Maybe the bfgminer beta is currently too U3 focused!

If your machine has just started up the miners should be from 

/dev/cu.SLAB_USBtoUART

to

/dev/cu.SLAB_USBtoUART6

so you should be able to use 

-S noauto -S /dev/cu.SLAB_USBtoUART -S /dev/cu.SLAB_USBtoUART1  -S /dev/cu.SLAB_USBtoUART2  -S /dev/cu.SLAB_USBtoUART3  -S /dev/cu.SLAB_USBtoUART4  -S /dev/cu.SLAB_USBtoUART5

Then to make sure 1.5.25b starts later, you can use an automator script like so:

I don't suppose you know whether the full hard drive issue is related to swap space (a result of a memory leak) or perhaps the ~/Library/Caches/com.fabulouspanda.macminer folder is getting overloaded with error logs?

MaxHedrm

I never really investigated it, I just know rebooting fixes it. I'll take a look next time they run for a few days.

I may have spoke too soon, as soon as one of them glitched, the -all stole 44. So it looks like I'd need to key them all manually.

MaxHedrm

I get ~33Gh on the U3, plus ~10Gh on the 5 U2s. I think that's about 50% of what the U3 is rated at, so I'll have to look at those switches again once things seems to be behaving.

FabulousPanda

I'd definitely recommend specifying the devices one by one, as long as they're no unplugged and replugged they should keep the original numbers - then maybe you can use all for the U3 in the second instance of MacMiner, or if we're lucky and they always take the same number (order possibly based on USB port it's connected to?) avoid using all completely

U3 should get ~45 on stock bfgminer settings so maybe it needs to warm up, I know bfgminer added support for voltage but I don't know whether the pre-existing frequency setting would work properly with the U3 - not sure they use the same values. In any case, best to get it stable before overclocking!

N.B. if you have a problem U2, try setting the voltage for it higher and/or the frequency lower. Even Intel chips have fairly random capabilities - so if you get an Intel i7 clocked at 2.6GHz it's been produced exactly the same way as the i7 clocked at 2GHz but the quality of the chips varies and they sell the under performing chips for less. You don't get that kind of grade separation with bitcoin ASICs, for the most part

MaxHedrm

Could I use the serial numbers for the -S as well or does it have to use the /dev?

MaxHedrm

So, the problem with running 2 MacMiner instances, is that they both use the same prefs and ASIC Miner options. So, when .25b restarted, it used the long list of miners, missing 44. Is there a way to separate the prefs?

FabulousPanda

I haven't looked in to the serial issue, the serial is set by the manufacturer so there's a good chance all units of the same model have the same serial in which case you'd need to get a bit hands on to work around that.

If you're using two MacMiner instances I'd recommend setting one up in the ASIC window and one in the GPU window, again making sure to set Intensity to the lowest possible value so as not to put any significant strain on resources or increase power consumption.

MaxHedrm

I guess that would only be a problem at start-up then because of the windows being told to open at start up. That should be manageable.

FabulousPanda

You mean because the GPU and ASIC windows would start at the same time? I'm pretty sure that's not an issue if you use -S noauto in each followed by the devices to be used in each window

MaxHedrm

Because the GPU & ASIC windows would start at the same time in both instances. Same prefs, remember?

FabulousPanda

yeah, but you could get it all going in a single instance of MacMiner if ASIC flags (with correct devices listed) are 

-S noauto -S antminer:/dev/cu.SLAB_USBtoUART -S antminer:/dev/cu.SLAB_USBtoUART1 -S antminer:/dev/cu.SLAB_USBtoUART2

and the GPU set up like 

-S noauto -S antminer:/dev/cu.SLAB_USBtoUART6

where the device is the U3

in order to get the serials, start either GPU or ASIC window flags to 

-S all -d?

The output will be akin to 

[2015-03-22 04:15:39] Started bfgminer 5.1.0-34-ga0fb134

 [2015-03-22 04:15:40] Devices detected:

 [2015-03-22 04:15:40]  CP2102 USB to UART Bridge Controller by Silicon Labs (driver=erupter; procs=1; serial=0001; path=/dev/cu.SLAB_USBtoUART)

 [2015-03-22 04:15:40]  BitForce SHA256 SC 1.0 (driver=bitforce_queue; procs=1; serial=FTWP5BMQ; path=/dev/cu.usbserial-FTWP5BMQ)

2 devices listed

My concern is that the serial for the erupter which uses the same driver as the antminers is displayed as 0001 which leads me to believe each antminer would have the same serial so you're better off using the path instead

MaxHedrm

Except that the 1.5.25b seems unreliable with the U2s.

FabulousPanda

Ah, wasn't sure sure whether that was due to a problem unit. In that case same applies but you'll have to use the multiple instances of MacMiner - at least you can skip the applescript portion! I'll post back here when bfgminer is updated…

FabulousPanda

BTW extra thanks for your report on the MobileMiner issue, I believe I've sorted that bug properly (devices in mobile miner are displayed much more accurately when multiple instances are monitored in API Output) and once bfg 5.2 is out which should fix up the antminer issue API Output will be revamped slightly:

FabulousPanda

Except that the 1.5.25b seems unreliable with the U2s.

In that the miner frequently restarts itself in .25b whereas it didn't before, and if so is that the case with ONLY U2s connected or it happens only when both types are connected? Sorry to pester for details, need to send luke-jr an accurate report of the problem

MaxHedrm

I may have to play with them again to see, I've slept with them. I think it was more that they weren't detected & wouldn't start up. I can't recall for sure if I tried it with only them connected. That should be testable tomorrow though.