Bitcoin Forum
December 08, 2016, 04:22:58 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 [39] 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4822305 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
Internet151
Full Member
***
Offline Offline

Activity: 174



View Profile
August 09, 2011, 05:01:45 AM
 #761

Just ran into a serious bug with cgminer tonight. I noticed when you only mine at one pool, and it goes down temporarily the miner will open over 4,000 connections (with a TCP timeout of 120 set on my router!) to attempt to reconnect.

Having multiple machines doing this just brought my router to its knees and it couldn't do shit until I unplugged all my rigs and waited for cgminer to close itself, which is another bug that occurs if internet access is temporarily lost.

This happened in Windows 7 SP1 32-bit with cgminer 1.5.1.
1481170978
Hero Member
*
Offline Offline

Posts: 1481170978

View Profile Personal Message (Offline)

Ignore
1481170978
Reply with quote  #2

1481170978
Report to moderator
1481170978
Hero Member
*
Offline Offline

Posts: 1481170978

View Profile Personal Message (Offline)

Ignore
1481170978
Reply with quote  #2

1481170978
Report to moderator
1481170978
Hero Member
*
Offline Offline

Posts: 1481170978

View Profile Personal Message (Offline)

Ignore
1481170978
Reply with quote  #2

1481170978
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
tysat
Legendary
*
Offline Offline

Activity: 952


Keep it real


View Profile
August 09, 2011, 01:55:27 PM
 #762

I was looking through the code, but I'm a little tired right now and can't figure out if this would be an easy change or not...

I want to set it so that it will do a pool rotation, but start it over at the beginning when a new block is detected via LP.
dlasher
Sr. Member
****
Offline Offline

Activity: 468



View Profile WWW
August 09, 2011, 05:16:51 PM
 #763

I tried cgminer on a couple of my boxes last night and woke up to find 3/4 GPU marked as DEAD on one and 2/4 DEAD on another. Trying to restart the DEAD GPU doesnt seem to do anything on either machine (restarting the ones still running did seem to restart them OK). Both boxes have been running for weeks using poclbm without errors. Running the 1.5.3 binary on Ubuntu (3xHD5870 and HD6310).

Anyone else seeing problems with DEAD GPU that won't recover unless cgminer is restarted?

BB.

Restart dead GPUs does not work for me too. Win7 64bit, Catalyst 11.7
Me too. LinuxCoin beta final

In my testing, under Fedora14, SDK2.4, restart GPU works in 100% of my 5xxx series cards, and 0% of my 6xxx series cards.
EskimoBob
Legendary
*
Offline Offline

Activity: 910


Quality Printing Services by Federal Reserve Bank


View Profile
August 09, 2011, 05:54:18 PM
 #764

I was looking through the code, but I'm a little tired right now and can't figure out if this would be an easy change or not...

I want to set it so that it will do a pool rotation, but start it over at the beginning when a new block is detected via LP.

+1
But this is not that easy. You probably need to add a way to pull in JSON stats from pools and let the miner make decisions based on that information.




While reading what I wrote, use the most friendliest and relaxing voice in your head.
BTW, Things in BTC bubble universes are getting ugly....
boss cat
Newbie
*
Offline Offline

Activity: 29


View Profile
August 09, 2011, 08:39:02 PM
 #765

I tried cgminer on a couple of my boxes last night and woke up to find 3/4 GPU marked as DEAD on one and 2/4 DEAD on another. Trying to restart the DEAD GPU doesnt seem to do anything on either machine (restarting the ones still running did seem to restart them OK). Both boxes have been running for weeks using poclbm without errors. Running the 1.5.3 binary on Ubuntu (3xHD5870 and HD6310).

Anyone else seeing problems with DEAD GPU that won't recover unless cgminer is restarted?

BB.

Restart dead GPUs does not work for me too. Win7 64bit, Catalyst 11.7
Me too. LinuxCoin beta final

In my testing, under Fedora14, SDK2.4, restart GPU works in 100% of my 5xxx series cards, and 0% of my 6xxx series cards.

Not for me. It won't restart either gpu on my 5970.
cirz8
Jr. Member
*
Offline Offline

Activity: 42


View Profile
August 09, 2011, 08:45:58 PM
 #766

I tried cgminer on a couple of my boxes last night and woke up to find 3/4 GPU marked as DEAD on one and 2/4 DEAD on another. Trying to restart the DEAD GPU doesnt seem to do anything on either machine (restarting the ones still running did seem to restart them OK). Both boxes have been running for weeks using poclbm without errors. Running the 1.5.3 binary on Ubuntu (3xHD5870 and HD6310).

Anyone else seeing problems with DEAD GPU that won't recover unless cgminer is restarted?

BB.

Restart dead GPUs does not work for me too. Win7 64bit, Catalyst 11.7
Me too. LinuxCoin beta final

In my testing, under Fedora14, SDK2.4, restart GPU works in 100% of my 5xxx series cards, and 0% of my 6xxx series cards.

restart GPU works even if the GPU is hung due to things like overheat-lockup?  Shocked

I simply have a monitoring script that checks for serious lockups and coldreboots the rig if it is triggered, not pretty, but all GPU are at least up and mining again within a minute.
Will probably add that corespeed controlled by temperature levels script(it down clocks the core if temperature gets too high) I saw in some thread on the forum a few days ago.

Summertime is a bitch when it comes to mining   Cool

Mandatory?  123ABCcirz8CcieVh9UwThEX2vkoJF33Te
d3m0n1q_733rz
Sr. Member
****
Offline Offline

Activity: 378



View Profile WWW
August 10, 2011, 01:45:58 AM
 #767

I was just thinking, how about instead of restarting on lockups, we work to throttle the work load once the temp. reaches a preset value?  Most of these cores have an internal temperature sensor.  We just have to monitor it and throttle back to let it cool so as to let it continue mining.  However, it would be a good idea to let the user know when the temperature is being reached so as to allow for user intervention to fix the cooling issue that it is having.

Funroll_Loops, the theoretically quicker breakfast cereal!
Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq
miscreanity
Legendary
*
Offline Offline

Activity: 1078


View Profile
August 10, 2011, 02:25:04 AM
 #768

The problem I've noticed is that there are occasional lock-ups even with the temperature steady. My 69xx cards won't start again even if cgminer is restarted. They don't respond to anything and require a cold boot.
tigereye
Member
**
Offline Offline

Activity: 78



View Profile
August 10, 2011, 04:04:38 AM
 #769

I apologize for repeating the question but it's been about 6 pages and it appears to have been overlooked.

I'm getting the following error when trying to run the latest version of cgminer (compiled from git checkout) on linuxcoin.
Code:
[2011-08-09 23:57:10] Error: Getting program info CL_PROGRAM_BINARY_SIZES. (clGetPlatformInfo)
[2011-08-09 23:57:10] Failed to init GPU thread 0
[2011-08-09 23:57:15] Error: Getting program info CL_PROGRAM_BINARY_SIZES. (clGetPlatformInfo)
[2011-08-09 23:57:15] Failed to init GPU thread 0
When trying to get it to compile I had to first APT-GET a few packages including pkg-config, libcurl4-gnutls-dev, curl, libncurses5-dev and autoconf.

But I managed to get it to compile successfully with the following:
Code:
./autogen.sh
./configure
./make

Unfortunately, after it compiled I get the above error.
After configuring, it reports that OpenCL is enabled. When I do "./cgminer --ndevs" it properly reports my number of GPUs.

Has anyone else run into this problem on their machines?
It works perfectly on another linuxcoin install, but not on this one rig...but I don't know what separates this rig from the others. I must have missed installing some package? or other prerequisite?

Thanks for any help you can provide!

If my posts have helped, consider leaving a tip! 1AE5e56ivvaGMJJmLrZoLgiZXPx93CddyA
Endeavour79
Full Member
***
Offline Offline

Activity: 169



View Profile WWW
August 10, 2011, 05:46:36 AM
 #770

I tried cgminer on a couple of my boxes last night and woke up to find 3/4 GPU marked as DEAD on one and 2/4 DEAD on another. Trying to restart the DEAD GPU doesnt seem to do anything on either machine (restarting the ones still running did seem to restart them OK). Both boxes have been running for weeks using poclbm without errors. Running the 1.5.3 binary on Ubuntu (3xHD5870 and HD6310).

Anyone else seeing problems with DEAD GPU that won't recover unless cgminer is restarted?

BB.

Restart dead GPUs does not work for me too. Win7 64bit, Catalyst 11.7
Me too. LinuxCoin beta final

In my testing, under Fedora14, SDK2.4, restart GPU works in 100% of my 5xxx series cards, and 0% of my 6xxx series cards.

Not for me. It won't restart either gpu on my 5970.

Does not work in Win 7 x64 on HD69xx and HD58xx for me.

NSW, Australia - Rigs, Mining, Pools - Local help needed? Send me a message!
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
August 10, 2011, 11:06:14 AM
 #771

...

Another possibility: did you do the following :


Code:
cd /; tar zxpvf /opt/AMD-APP-SDK-v2.4-lnx64/icd-registration.tgz

Without the above, things are very likely to behave according to
what you describe.

...
Yes that's in the README file but some people (I did the very first time also) accidentally skip it.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
August 10, 2011, 03:19:11 PM
 #772

Since Con is away...

I thought I'd take a try at integrating some of the recent changes in both phatk kernel threads. (here and here)
I've also changed the method used to specify various #defines for the kernels by simply specifying the defines as build options for clBuildProgram() instead of editing the .cl text on the fly. (so much simpler!)

Compared to the current kernel in cgminer 1.5.3, this does benefit from reduced ALU OPs, although not as much as either of the other phatk kernels:

1.5.3:
VLIW4: 1699 ALU OPs
VLIW5: 1376 ALU OPs

Mine:
VLIW4: 1694 ALU OPs
VLIW5: 1368 ALU OPs

My changes are here at github, but it's all in one big ugly commit, and not broken out by the individual changes, so i don't feel comfortable in the slightest offering a pull request to CK for it.
Don't be scared. You're doing good work. I'll play with your changes and see if they break anything Smiley

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
ah42
Newbie
*
Offline Offline

Activity: 14


View Profile
August 10, 2011, 10:20:57 PM
 #773

Don't be scared. You're doing good work. I'll play with your changes and see if they break anything Smiley
Welcome back!
It's not so much about being scared; More that I didn't do a bunch of little commits and comment the specific changes. I would have liked to have done that...at least so they could be submitted as separate changesets/patches for you to look at.

I *have* done that for the next couple commits Smiley

Was I helpful? 12Xqb8oETmUkGQ1WrcQ9GYK9CvDxXWb8fU
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
August 11, 2011, 10:46:42 AM
 #774

I have incorporated his changes into the main git tree now.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
d3m0n1q_733rz
Sr. Member
****
Offline Offline

Activity: 378



View Profile WWW
August 11, 2011, 11:14:03 AM
 #775

Random question about the SHA-256 hash so I know if I can maybe make a small change to speed up hashing in cgminer:
I've noticed the 8 trailing 0's at the end of the hashes.  Why do these 0's occur and are they computed/always going to be 0's no matter what?  If there will always be those 8 trailing 0's regardless of what block number we're at, it could be possible to simply keep them a constant in the code if we haven't already and speed up hashing by a slight margin.

Funroll_Loops, the theoretically quicker breakfast cereal!
Check out http://www.facebook.com/JupiterICT for all of your computing needs.  If you need it, we can get it.  We have solutions for your computing conundrums.  BTC accepted!  12HWUSguWXRCQKfkPeJygVR1ex5wbg3hAq
Diapolo
Hero Member
*****
Offline Offline

Activity: 769



View Profile WWW
August 11, 2011, 12:43:05 PM
 #776

Current 110810 kernel on git has 1368 ALU OPs for 58XX and 1696 for 69XX, that's neither phatk 2.2 nor my latest result (which is 1364 / 1688), but a bit faster than the last official CGMINER kernel. I mailed my latest version to Con for review Wink.

The added __attribute__((vec_type_hint(u))) is unknown to the compiler and throws a warning, but IS mentioned in the OpenCL 1.1 manual ... strange.

Dia

Liked my former work for Bitcoin Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
August 11, 2011, 01:00:37 PM
 #777

ALUs are not the only way to judge performance.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Diapolo
Hero Member
*****
Offline Offline

Activity: 769



View Profile WWW
August 11, 2011, 01:13:20 PM
 #778

ALUs are not the only way to judge performance.

Correct, that's what I wrote in the Phatk thread, too. We also have to look at other factors, I only wanted to point out, that current git seems like a new hybrid version, whose performance is not clear Wink.

Dia

Liked my former work for Bitcoin Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
Diapolo
Hero Member
*****
Offline Offline

Activity: 769



View Profile WWW
August 11, 2011, 01:15:38 PM
 #779

ALUs are not the only way to judge performance.

Agreed: actual wall time MH/s is.

However, in this specific instance the two seem to be strongly correlated (which
isn't much of a surprise: execution units on GPU aren't anywhere as smart as
those on CPU).

Point in case: Diapolo's diagnostic turns out to be correct, I ran a parallel experiment
this morning between phoenix+phatk 2.2 and the latest git tree cgminer
(9df379ecc793b6266853 with phatk110810.cl).

Bottom line: cgminer is slower by ~3Mh/s per GPU core.

Also ... I started to look at how to integrate the phatk 2.2 into cgminer, but it's a
real headache: the original phatk code has been re-indented and changed all over
the place.

What would really be helpful is to somehow be able to drop in the latest phatk kernel
into cgminer without having to change it much. Barring that, having some sort of
script that can convert a pristine phatk kernel into a cgminer-compatible version
would be neat.

I will quote myself from the Phatk-thread Cheesy!

Quote
The last kernel releases show, that it is a bit of trial and error to find THE perfect kernel for a specific setup. Phaetus and I try to use the KernelAnalyzer and our Setups as a first measurement, if a new Kernel got "faster". But there are many different factors that come into play like OS, driver, SDK, miner-software and so on.

I would suggest that we should try to create a kernel which is based on the same kernel-parameters for phatk and phatk-Diapolo so that the users are free to chose which kernel is used. One thing is CGMINER kernel uses the switch VECTORS2, where Phoenix used only VECTORS (which I changed to VECTORS2 in my last kernel releases). It doesn't even matter to use the same variable names in the kernel (in fact they are different sometimes) as long as the main miner software passes the awaited values in a defined sequence to the kernel.

Dia

Liked my former work for Bitcoin Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
Diapolo
Hero Member
*****
Offline Offline

Activity: 769



View Profile WWW
August 11, 2011, 01:29:39 PM
 #780


I would suggest that we should try to create a kernel which is based on the same kernel-parameters for phatk and phatk-Diapolo so that the users are free to chose which kernel is used. One thing is CGMINER kernel uses the switch VECTORS2, where Phoenix used only VECTORS (which I changed to VECTORS2 in my last kernel releases). It doesn't even matter to use the same variable names in the kernel (in fact they are different sometimes) as long as the main miner software passes the awaited values in a defined sequence to the kernel.

It must be way too early in the day, but this last sentence just confused
me utterly for the second time (read it first in your original post) Cheesy

I'll try again ^^! There is no need for the kernels to be equal inside (variable names and so on), but the parameters both kernels use (like base, PreVal0 and so on) and which are passed from the main miner software need to be the same in order to be compatible (use phatk, phatk-diapolo or whatever). Better now Cheesy?

Dia

Liked my former work for Bitcoin Core? Drop me a donation via:
1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x
bitcoin:1PwnvixzVAKnAqp8LCV8iuv7ohzX2pbn5x?label=Diapolo
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 [39] 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 ... 830 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!