Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 548. (Read 5806088 times)

I can read perfectly fine, so a release that is not a release when it is customary to increment the number of the build to avoid confusion, yet somehow when I asked that question I knew I would get asshole responses to it as is customary around here...

Dude can't read.

I said it would be the new version. I didn't say it was the new version.

Looking forward to this. Mine has been acting pretty crazy.

+1

You sir, are the man!   

New release delayed

Sorry everyone, I was planning on releasing 2.4.4 literally today, but unfortunately I got the hardware for my new fancy main desktop on the same day, and after spending many hours trying over and over again, it did not boot so it ended up in the workshop. Given that it's likely yet another dead motherboard, it could actually be quite a while before the damn thing is back, and I really can't do much in the way of a satisfactory release with just my laptop and mining rig. So if you're willing to download and build from git, now is a good time because the tree is quite stable.

New changes:
Massive overhaul of the nrolltime mechanism now should cause a huge rise in efficiency on pools that support it. This allows much lower getwork bandwidth for much higher hashrates.
Support for the expire= feature. This works in concert with nrolltime when pools support it to allow more local generation of work.
Support for the x-mining-hashrate feature. I'm sure some pool somewhere cares about this, even though I'm not convinced, but it was trivial to add.
Better damping of GPU temperature changes should cause much less overshoot when temps rise or fall outside the optimal range in autofan mode.
Reinstated the application restart should adl fail - disabling this did not fix the crashes for those who had cgminer crash after 1 week of uptime in windows fail land when their ATI driver would fail, and disabled the advantage of it fixing the problem for those who simply lost their fanspeed.
API groups features - this is squarely aimed at grouping privileges for remote access for services like P4man's hopping puppetmaster service.
Support for unlimited devices
Support for unlimited pools
Massive fix for the "dynamic" feature for GPUs. Somehow in the many device abstractions it had gotten broken and wasn't really doing what it was intended. It should be much more dynamic now.
Lots of other things under the hood.

Enjoy.

2 Instances, that makes sense. Yes, I know. I need to get another ATI card. Man, I wish I would have found this earlier when the difficulty was lower. Could have paid for several cards really quickly. C'est la vie!

Thanks again for your help!

No. You need to run 2 instances of cgminer if you want to mine on nvidia and ati at the same time. Suggest you don't mine on the nvidia - you will lose 1 dollar in power costs for every 20 cents you earn in bitcoin. (No I don't care if you have free electricity, everyone uses the same counterargument and there's plenty about it on the forums already).

Thanks very much, ckolivas. That works for mining on the 5850. Is there any way to mine on both? I tried entering --gpu-platform 1 --gpu-platform 0 and it mined only on platform 0-back to only mining on the 460.

Thanks again for your help!

--gpu-platform 1

Hello,

I normally use GUIMiner on Windows 7 X64, but would really like to try using CGMiner since it has great backup server support and I'm wondering if I can squeeze a few more Hashes out of my hardware-GTX 460 and Radeon 5850.

However, when I run CGMiner -n it shows this output...

 [2012-06-28 00:13:47] CL Platform 0 vendor: NVIDIA Corporation
 [2012-06-28 00:13:47] CL Platform 0 name: NVIDIA CUDA
 [2012-06-28 00:13:47] CL Platform 0 version: OpenCL 1.1 CUDA 4.1.1
 [2012-06-28 00:13:47] Platform 0 devices: 1
 [2012-06-28 00:13:47]  0       GeForce GTX 460
 [2012-06-28 00:13:47] CL Platform 1 vendor: Advanced Micro Devices, Inc.
 [2012-06-28 00:13:47] CL Platform 1 name: AMD Accelerated Parallel Processing
 [2012-06-28 00:13:47] CL Platform 1 version: OpenCL 1.2 AMD-APP (923.1)
 [2012-06-28 00:13:47] Platform 1 devices: 1
 [2012-06-28 00:13:47]  0       Cypress
 [2012-06-28 00:13:47] Failed to ADL_Adapter_ID_Get. Error -1
 [2012-06-28 00:13:47] Failed to ADL_Adapter_ID_Get. Error -1
 [2012-06-28 00:13:47] GPU 0 ATI Radeon HD 5800 Series hardware monitoring enabled
 [2012-06-28 00:13:47] 1 GPU devices max detected

The Radeon 5850 shows up @ GPU0 and the NVIDIA GTX 460 @ GPU1 in MSI Afterburner. However, CGMiner shows them backwards.

My problem is that I cannot mine on the Radeon. As it shows in the last line, I can only mine on 1 GPU and that's the 460 @ ~76Mhash.

I did plenty of searching on that error: Failed to ADL_Adapter_ID_Get. Error -1 with no luck. Anyone got any ideas? Thanks!

My installs are based on BAMT at the moment, but I have none of the BAMT functionality enabled at this point.  So no, that's not it.  When libtorsocks has a connection issue, cgminer takes a dirt nap and I just have the script restart it.  Hasn't been a huge issue, and actually helps for the BFL units that fall asleep, since cgminer doesn't try to rescan and/or renable sleeping BFL units, so I haven't worried about it too much.

Actually - yes I've seen this before when someone had a problem with BAMT - where there was some reason why it was telling cgminer to shutdown via the API.
Are you using BAMT or some other such tool?

It shouldn't happen either way. Network failures shouldn't cause cgminer to shut down and neither should (some random other thing). I have no idea what the problem is in either of your cases, and especially since it's not actually crashing, but shutting down cleanly since it's giving a summary. It could be something else in your systems sending it a SIGTERM signal for whatever reason (some daemon or something?) or some outside thing talking to the API and telling it to shut down? There is nothing in the code that has a plan to terminate running automatically except for the --shares option, which is why I asked if there was a configuration file it was loading somewhere you didn't know about.

The network connections are fine.  All these computers have been running non-stop for months.  Something changed this past weekend.  It might be my router or my internet connection, but I don't understand how those things can cause this problem.

Anyway, I took your advice and wrapped cgminer in an infinite while loop so when it does stop it just starts up again.  The 11 computers have been running this way for 6 hours now.

The default latency was set at 32, but changes to 96 and 128 have no affect. The next step is probably going to be a complete reinstall of Win 7 x64 to see if it has any effect.

My cgminers stop a lot of times with what you are describing when there are network issues.  I have a script that starts it back up and it continues on it's merry way. 

You may want to check your network connection.

First miner stopped.  It lasted 12 minutes.  It ended after the line "Pool 1 communication failure, caching submissions".  The two miners that are still working do not have that line in their log file even though they are using the same pools.  Here is some of the output: