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.
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
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)
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.
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.
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
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.
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.
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.
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?
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.
Comments