|
Thanks for testing. Still got a little bit more to squeeze out of it but the cpu usage will always look a little higher due to the driver cpu usage all being attributed to cgminer now instead of hidden in the operating system (since there is no driver with direct usb).
|
|
|
|
Guys, can you guys explain to me why CGminer use lots of CPU power while mining with BFL ASICs compared to BFGminer?
I'm using RPi as a host and the difference is absurd.
60GHs SC with BFG miner uses ~5% while CGminer uses 20%
Anyone please test to confirm this. I have tested with different rigs and setup. Same result.
2 things. In literally the very previous message to the one you just posted you'll see that I've committed changes that decrease CPU usage. Low power devices running asic hashrates is new so this issue has only recently showed up, and I've aggressively started optimising that now. The CPU usage is lower now and a new version will be noticeably so on these low power devices. The second is that because there is no driver between cgminer and the USB device, all the CPU usage that is normally attributed to the driver and/or hidden from the user is now all shown as cgminer CPU time - this won't go away but doesn't mean the system is using more resources, they're just attributed differently. |
|
|
|
|
Site maintenance is over, site is back online.
Git users may want to download the latest git version. There are some CPU usage improvements for both stratum and GBT that make a big difference when mining at ASIC hashrates on p2pool.
|
|
|
|
Not required on bfgminer 3.1.4 now - just use -S erupter:all instead.
+1. Forgot to add that bit. Though if using cgminer may still have to. Only if using the old cgminer (3.1.1). 3.3.2+ you don't specify anything. |
|
|
|
|
Well it is slightly more work initially, despite what kano says, but you run zadig as administrator, plug in ONE device, wait till windows finishes fscking around with it, then tell zadig to change that device to winusb (that's all the extra work there is). Then you don't need to specify any command line options for cgminer to recognise and use the device, and any time you plug in any other device of the same kind from then on forever more, it will run, including without restarting cgminer since it will hotplug them.
|
|
|
|
New release: 3.3.2, 10th August 2013 Cairnsmore1 (yeah. I know...): I have hold off to upgrade to 3.x from 2.11.3, but today the temptation was too big ;-) Upgrading etc. all went fine on Ubuntu 12.04.2, worked through the READMEs, did the libusb-1.0.16-rc10, disconnect USB, removed all --scan serial (ttyUSB*) from config file, restart everything, reconnect USB, did NOT issue the modprobe command... Out of the 6x CM1s, cgminer only detects CMR0, 1 and 2. I let them run for a while with no problems, but of course I'm missing the rest of the boards. Anyone tried the latest version with CM1s? Any other pointers? I've tried, bo no luck  On my rig i'm using cgminer for icarus, lancelot, AMU, and bfg for CM1. Sorry, neither of us developers own one and can't do anything about it, though we'd happily take patches from someone who does have one and wishes to update the code (so long as it doesn't break anything else). |
|
|
|
However, my point is that the screen average (or API "MHS av") will be affected by "luck" and the higher your work difficulty, the more obvious that effect will be.
That's not quite correct. The avalon hashmeter is indeed based on share return, but it's based on diff1 return so luck affects it, but difficulty does not. |
|
|
|
An Avalon mining on P2Pool with even 3 modules does indeed take its CPU to the limit. The only real difference between P2Pool and other pools is that P2Pool's generation transaction is much larger. I'm guessing that the bottleneck is hashing the generation transaction ~16 times per second (though that isn't much...). If that's true, perhaps cgminer could be optimized to compress everything before the Stratum nonce to a SHA-256 midstate?
There's an obvious optimisation there that I didn't spot and it's only now that we have hardware being outstripped by the work generation requirements that I've looked into it. Thanks for the pointer, I shall see what I can do. Yes, that did it. I've committed code to the cgminer git tree which dramatically reduces the cpu usage (confirmed on my avalon mining to p2pool). When my server comes back online I'll upload new avalon firmware. |
|
|
|
Did you guys update the internal version number?
./cgminer -V
cgminer 3.3.1
I just git pull'ed and compiled.
Neil
Usual error when building from git - you forgot ./autogen.sh |
|
|
|
An Avalon mining on P2Pool with even 3 modules does indeed take its CPU to the limit. The only real difference between P2Pool and other pools is that P2Pool's generation transaction is much larger. I'm guessing that the bottleneck is hashing the generation transaction ~16 times per second (though that isn't much...). If that's true, perhaps cgminer could be optimized to compress everything before the Stratum nonce to a SHA-256 midstate?
There's an obvious optimisation there that I didn't spot and it's only now that we have hardware being outstripped by the work generation requirements that I've looked into it. Thanks for the pointer, I shall see what I can do. |
|
|
|
|
A BFL little single is an asic device and you're describing cgminer trying to mine with the old BFL device for FPGA singles. It sounds like you have a very old version of cgminer. Try downloading the latest (3.3.2) and read carefully the ASIC-README file for how to set it up.
|
|
|
|
I'm confident ckolivas can fix this easily. I was actually surprised the GPU mining code is still being modified.
People still donate due to the (scrypt) gpu code being there so I'm still maintaining it and making small changes. |
|
|
|
Down for maintenance, be back tomorrow. |
|
|
|
|
It's not that big a deal, I only just heard of it and I'll fix it next version. Let the discussion go.
|
|
|
|
If lucrative, I would like to get in on it (duh).
It's not going to be. Like all investments, only high risk ones stand to potentially be lucrative (and potentially a scam). |
|
|
|
The difference is staggering. HW error rate dropped from 0.95% to 0.58%, and cpu usage while mining on p2pool went from 90% down to 8% max.
Are you mining directly with stratum to p2pool? |
|
|
|
I tried building the newest git version, and noticed that my linux scrypt miners no longer worked properly. Hashrates were minimal because intensity was only 8. cgminer was complaining about the config being broken, and after starting with -T I saw the error was "Invalid config option --intensity: Invalid value passed to set intensity". This was introduced in commit 2b171f7fae19a451abefd5189ecad64fbd08d8a0, everything still works fine with commit cb6d62de08995cb3ce2ae906dfa629f42d382c21. I'm using intensity 17 on the linux rigs, I don't have the problem on my Windows rigs with a lower intensity.
Try telling it --scrypt before setting the intensity? |
|
|
|
|
Show Posts
