Author

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

-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
There's not enough to warrant a new release, but if anyone's keen to try the new poclbm kernel you can download the latest version of the file directly here:
https://raw.github.com/ckolivas/cgminer/master/poclbm121016.cl

Remember to delete any .bin files. Seems to work best with SDK 2.7. Even my NVIDIA cards seem to prefer this kernel.

I see no difference in speed for a rig with 5870+6990 cards (SDK 2.4).
But there is a notable difference for a rig with 7970 cards (SDK 2.6), from 2524Mh/s to 2543Mh/s.

Maybe you should keep one 7970 for a little while though?...I smell another scrypt bounty in the air...
Not necessarily a LTC fan, but like many GPU miners I'll resort to any option available to keep the rigs working on something.
Yah well I did test the code on a 7970... however if you're on 5x or 6x with SDK2.4, it won't even be using this kernel so of course you won't see a difference. My poclbm kernel is optimised for sdk 2.6+ and cgminer usually chooses phatk for other cards on SDK 2.4. You'd have to install SDK 2.7 and manually select -k poclbm to try it on those other cards, and I really don't know how it will perform. I suspect the 6x will perform well, but the 5x are legendary for much preferring phatk with older SDKs.

EDIT: Oh and I've made some minor updates to the scrypt kernel too...
hero member
Activity: 700
Merit: 500
There's not enough to warrant a new release, but if anyone's keen to try the new poclbm kernel you can download the latest version of the file directly here:
https://raw.github.com/ckolivas/cgminer/master/poclbm121016.cl

Remember to delete any .bin files. Seems to work best with SDK 2.7. Even my NVIDIA cards seem to prefer this kernel.

I see no difference in speed for a rig with 5870+6990 cards (SDK 2.4).
But there is a notable difference for a rig with 7970 cards (SDK 2.6), from 2524Mh/s to 2543Mh/s.

Maybe you should keep one 7970 for a little while though?...I smell another scrypt bounty in the air...
Not necessarily a LTC fan, but like many GPU miners I'll resort to any option available to keep the rigs working on something.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I recently experience a problem with cgminer, when it should recreate it's .bin files, e.g. phatk121016Cypressv4w128l4.bin

debug version of cgminer says:
Code:
cgminer_d.exe caused an Access Violation at location 0042e08c in module cgminer_d.exe Reading from location 04b4e41b.

Registers:
eax=04b4e417 ebx=01e79de0 ecx=ffb5c74d edx=00000008 esi=01e5fd58 edi=01e79f1f
eip=0042e08c esp=0028f4e0 ebp=0028f548 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202

Call stack:
0042E08C  cgminer_d.exe:0042E08C
0043027F  cgminer_d.exe:0043027F
0042D020  cgminer_d.exe:0042D020
00416F8A  cgminer_d.exe:00416F8A
004010B9  cgminer_d.exe:004010B9  __mingw_CRTStartup  crt1.c:244

00401284  cgminer_d.exe:00401284  WinMainCRTStartup  crt1.c:274

750433AA  kernel32.dll:750433AA  BaseThreadInitThunk
77219EF2  ntdll.dll:77219EF2  RtlInitializeExceptionChain
77219EC5  ntdll.dll:77219EC5  RtlInitializeExceptionChain

Trying to compile the new poclbm121016.cl .bin file would then result with this error:
Code:
cgminer_d.exe caused an Access Violation at location 0042e08c in module cgminer_d.exe Reading from location 00aba637.

Registers:
eax=00aba633 ebx=0058a700 ecx=ffb5c44d edx=00000008 esi=0056fd40 edi=0058a83f
eip=0042e08c esp=0028f4e0 ebp=0028f548 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202

Call stack:
0042E08C  cgminer_d.exe:0042E08C
0043027F  cgminer_d.exe:0043027F
0042D020  cgminer_d.exe:0042D020
00416F8A  cgminer_d.exe:00416F8A
004010B9  cgminer_d.exe:004010B9  __mingw_CRTStartup  crt1.c:244

00401284  cgminer_d.exe:00401284  WinMainCRTStartup  crt1.c:274

750433AA  kernel32.dll:750433AA  BaseThreadInitThunk
77219EF2  ntdll.dll:77219EF2  RtlInitializeExceptionChain
77219EC5  ntdll.dll:77219EC5  RtlInitializeExceptionChain
This looks completely unrelated to the code and suggests some driver +/- SDK fuckage. I suggest trying a different driver, if you can.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
There's not enough to warrant a new release, but if anyone's keen to try the new poclbm kernel you can download the latest version of the file directly here:
https://raw.github.com/ckolivas/cgminer/master/poclbm121016.cl

Remember to delete any .bin files. Seems to work best with SDK 2.7. Even my NVIDIA cards seem to prefer this kernel.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Ironically I've made some tiny improvements to the OpenCL kernel and will be squeezing a few tiny drops more out of them in the next cgminer release. I feel it's my last chance to do anything with OpenCL and bitcoin mining and I'm gonna miss it.

Don't worry Con, you'll still have scrypt to optimize.    Cheesy

Thanks in advance for the tiny extra drops!  They'll add up when BTC reaches parity with gold.
You say that to mock me don't you  Wink Scrypt is very low (read virtually non-existent) on my priority list.
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
Ironically I've made some tiny improvements to the OpenCL kernel and will be squeezing a few tiny drops more out of them in the next cgminer release. I feel it's my last chance to do anything with OpenCL and bitcoin mining and I'm gonna miss it.

Don't worry Con, you'll still have scrypt to optimize.    Cheesy

Thanks in advance for the tiny extra drops!  They'll add up when BTC reaches parity with gold.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Here are some photos from Kanoi on his trip to BFL to inspect their ASIC progress. He returns this weekend, and the chips have not yet arrived to be assembled, as they're still in the bumping facility - BFL couldn't manage to make the bumping facility work any faster, but they're poised and ready to assemble when they do.

http://198.245.60.111/Pix/

Meanwhile myself and him have made some progress generically on preparing for ASIC support in cgminer, but the real driver won't be written until there's some hardware to actually test it on.

If anyone's in Australia and interested in buying the 7970s used by me in developing cgminer, now's your chance to buy one Smiley

http://www.ebay.com.au/itm/SAPPHIRE-HD-7970-3GB-GDDR5-/321074334615

Ironically I've made some tiny improvements to the OpenCL kernel and will be squeezing a few tiny drops more out of them in the next cgminer release. I feel it's my last chance to do anything with OpenCL and bitcoin mining and I'm gonna miss it.
hero member
Activity: 924
Merit: 1000
Watch out for the "Neg-Rep-Dogie-Police".....
You're welcome.

The issue is some disconnects are impossible to detect, apart from noticing the pool has gone silent for an extended time. During that sort of outage, cgminer continues mining until it times out, not getting a response. The timeout needs to be long enough to be sure the pool is no longer sending info, and not too long to waste ages mining. So yes, it keeps mining. Anyway hopefully this should be better since the next version will include support for the new mining.resume function. This is already built into the git version, but only rEligius currently supports it. Hopefully other pools will follow suit.

Maybe related: during recent ozco.in server reorganization I noticed that if your primary pool is a stratum one and it is down when cgminer starts, it just hangs there and does nothing (beside of searching for active pools).

cgminer used was commit 0b833131616 from three days ago.

Sorry if this has already been reported, didn't follow cgminer discussion since it is working rock-solid Wink

I also found this to be the case, I too am mining with ozcoin ATM. Wasn't sure if it was due to the server or my miner though.
legendary
Activity: 896
Merit: 1000

Onto a new issue. I want to beable to control remotely what pool is selected. Since I have 9 rigs I want to do this programatically. I am very knowledable of VB and linux, but am new to JSON/RPC. I would like to be able to send such a command via the network interface using RPC via VBA.net. From looking at the cgminer source RPC/JSON commands are accepted through the use of port 4028. What would be the simpliest way to send an RPC packet from VBA.net to switch to pool 2 and viceversa switch to pool 0.

Any help would be appreciated. I have exhausted the third party addons for JSON serialization and RPC protocal and have not come accross a viable solution.

Thanks,
Mark 
 


Mark,
 There are php tools out there.. kanos miner.php i think does it. and i use my own that shows aggregated fans speeds and other stuff>

https://bitcointalksearch.org/topic/cgminer-web-monitor-beta-v08-58834

I haven't updated it in a long time,  my current version is only different as it shows highest share and blocks found fields.

It is not actually RPC, it is just a JSON formatted packet into a raw socket and a JSON packet read out.

I have an example of how to use the interface to change pools though, I use it in MinePeon ( http://mineforeman.com/minepeon/ )
so users can change their mining pool from the WebUI.

You can either download MinePeon and grab the code for yourself or if you can wait I will post the code here in about 8 hours.
legendary
Activity: 1876
Merit: 1000

Onto a new issue. I want to beable to control remotely what pool is selected. Since I have 9 rigs I want to do this programatically. I am very knowledable of VB and linux, but am new to JSON/RPC. I would like to be able to send such a command via the network interface using RPC via VBA.net. From looking at the cgminer source RPC/JSON commands are accepted through the use of port 4028. What would be the simpliest way to send an RPC packet from VBA.net to switch to pool 2 and viceversa switch to pool 0.

Any help would be appreciated. I have exhausted the third party addons for JSON serialization and RPC protocal and have not come accross a viable solution.

Thanks,
Mark 
 


Mark,
 There are php tools out there.. kanos miner.php i think does it. and i use my own that shows aggregated fans speeds and other stuff>

https://bitcointalksearch.org/topic/cgminer-web-monitor-beta-v08-58834

I haven't updated it in a long time,  my current version is only different as it shows highest share and blocks found fields.
donator
Activity: 919
Merit: 1000
You're welcome.

The issue is some disconnects are impossible to detect, apart from noticing the pool has gone silent for an extended time. During that sort of outage, cgminer continues mining until it times out, not getting a response. The timeout needs to be long enough to be sure the pool is no longer sending info, and not too long to waste ages mining. So yes, it keeps mining. Anyway hopefully this should be better since the next version will include support for the new mining.resume function. This is already built into the git version, but only rEligius currently supports it. Hopefully other pools will follow suit.

Maybe related: during recent ozco.in server reorganization I noticed that if your primary pool is a stratum one and it is down when cgminer starts, it just hangs there and does nothing (beside of searching for active pools).

cgminer used was commit 0b833131616 from three days ago.

Sorry if this has already been reported, didn't follow cgminer discussion since it is working rock-solid Wink
hero member
Activity: 981
Merit: 500
DIV - Your "Virtual Life" Secured and Decentralize
Thats great news!
I am glad the resume function is being added (actually that it even got added to the spcification). That will help alleviate the last few shares that seem to go unpaid execpt for a lost in transmission packet.
Thank You for all your hard work!
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
You're welcome.

The issue is some disconnects are impossible to detect, apart from noticing the pool has gone silent for an extended time. During that sort of outage, cgminer continues mining until it times out, not getting a response. The timeout needs to be long enough to be sure the pool is no longer sending info, and not too long to waste ages mining. So yes, it keeps mining. Anyway hopefully this should be better since the next version will include support for the new mining.resume function. This is already built into the git version, but only rEligius currently supports it. Hopefully other pools will follow suit.
hero member
Activity: 981
Merit: 500
DIV - Your "Virtual Life" Secured and Decentralize
I noticed with 2.10.4 and in 2.10.5 that when the stratum pool disconnects CGMiner keeps working on that pool's work. At least it appears that is what it does. I get a disconnect and eventually a number of shares discarded last time I noticed it was 17. Of course this seems like too many to me with 1 BFL single currently running on Eclipse 1 at a WU of 12.

The reasons I think it keeps working on the disconnected pool for 2 reason. Both may be faulty and I don't want to alarm anyone. Firstly the discarded shares are usually 60-90 seconds after the disconnect. Expiry would account for that much but not why I had 90 seconds backlog at disconnect. If the pool hadn't taken 90 seconds worth of work it was already sick or dying. Secondly although the BFL single keeps hashing I see no mention of swiching pools (it could be a cosmetic issue). This is substantiated by bad luck notwithstanding 0 shares being delivered to 3 backup pools (eclipse 2 diff1, Eclipse 3 diff1 and a local bitpenny Diff8). I am sure that in 60 seconds I wouldn't expect to see a share everytime for difficulty 8 bitpenny. Aside from a work unit being used from getwork while switching to a stratum server on a change I would expect 1 work unit to bitpenny, then (in 60 seconds) ~11 to eclipse 2 (the next pool in order). I also have never noticed the pool at the top Connected to (blah blah blah) change when this happens. Again that could be cosmetic.

Running windows 7, 1 BFL single, and stratum to Eclipse (three different servers) and a backup bitpenny using getwork.

Also I am pretty sure even factoring in discards as rejects my reject rate is lower using stratum. Thank You for the stratum support.
legendary
Activity: 1610
Merit: 1000
Kon,

There is a potential memleak introduced with latest commit:
Add timestamps to stratum_share structs as they're generated and copy
https://github.com/ckolivas/cgminer/commit/1bf1f4a2174c28a3ae358c6a8b9544e93f35bfac

work->sessionid = strdup(pool->sessionid);

However work->sessionid has been never freed.

Probably the right place to free it is:

void clean_work(struct work *work) {
  if(work->sessionid)
      free(work->sessionid);
....

}

More over it might be a memleak here also even though i am not quite sure about it

https://github.com/ckolivas/cgminer/commit/c851f3959894379b213cd81ecbf8317b2ad4f313

pool->sessionid = json_array_string(res_val, 3);

if json_array_string returns a copy pool->sessionid shall be freed also somewhere right?


PS: probably this is not an issue as long as  json_array_string - > json_array_get returns  Borrowed reference and there is no need to be freed

Thank you Kon! it has been fixed:
https://github.com/ckolivas/cgminer/commit/16c7c983ae9e5ce03a2adc2c573a0c62bfdfefde


 
legendary
Activity: 952
Merit: 1000
I built latest from git this morning on CentOS 6.3 with the latest 13.1 drivers from AMD as well as the APP SDK 2.8, so it's all up to date.
13.1 is fucked.
Would it be possible to update the first post with the optimal driver/sdk config for CGMiner? Not knowing this, I just defaulted to latest Wink
It keeps changing as AMD skillfully keeps releasing broken shit... plus GPUs are going the way of the dodos shortly for BTC, so our attention to GPU issues is dropping off to almost zero. Try driver 12.8
Is it the driver that keeps mucking things up, or the ocl runtime that gets updated every month?
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I built latest from git this morning on CentOS 6.3 with the latest 13.1 drivers from AMD as well as the APP SDK 2.8, so it's all up to date.
13.1 is fucked.

Would it be possible to update the first post with the optimal driver/sdk config for CGMiner? Not knowing this, I just defaulted to latest Wink
It keeps changing as AMD skillfully keeps releasing broken shit... plus GPUs are going the way of the dodos shortly for BTC, so our attention to GPU issues is dropping off to almost zero. Try driver 12.8
hero member
Activity: 914
Merit: 500
I built latest from git this morning on CentOS 6.3 with the latest 13.1 drivers from AMD as well as the APP SDK 2.8, so it's all up to date.
13.1 is fucked.

Would it be possible to update the first post with the optimal driver/sdk config for CGMiner? Not knowing this, I just defaulted to latest Wink
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I built latest from git this morning on CentOS 6.3 with the latest 13.1 drivers from AMD as well as the APP SDK 2.8, so it's all up to date.
13.1 is fucked.
hero member
Activity: 914
Merit: 500
why do I have only max. 48.5 K cgminer with --scrypt option on a 5870?

Code:
cgminer version 2.10.5 - Started: [2013-02-13 16:45:46]
--------------------------------------------------------------------------------
 (5s):61.56K (avg):43.25Kh/s | Q:158  A:13  R:0  HW:0  E:8%  U:0.8/m
 ST: 9  SS: 0  DW: 42  NB: 5  LW: 0  GF: 0  RF: 0
 Connected to coinotron.com diff 48 with LP as user xxx
 Block: 7c340708660d1ac0...  Diff:484K  Started: [17:01:38]  Best share: 330
...
 GPU 0:  66.5C 1754RPM | 12.55K/11.33Kh/s | A:1 R:0 HW:0 U:0.07/m I: 7
 GPU 1:  57.5C  25%    | 48.53K/28.00Kh/s | A:9 R:0 HW:0 U:0.65/m I: 9
TIA

Although your post lacks info, I'm also having performance issues with a 5870 on the latest build of CGMiner doing Scrypt, so perhaps our symptoms are related.

I built latest from git this morning on CentOS 6.3 with the latest 13.1 drivers from AMD as well as the APP SDK 2.8, so it's all up to date. The command line I'm using is:

Code:
./cgminer --scrypt -o http://pool:9332 -u username -p password --worksize 256 --shaders 1600 --intensity 11 -g 1

I'm currently only geting about 150Khash/sec on this card and unable to push past intensity 11 without getting GPU errors such as:
                 
Code:
 [2013-02-13 08:44:46] GPU 1 found something?                    
 [2013-02-13 08:44:46] OCL NONCE 3247859 found in slot 0                   
 [2013-02-13 08:44:46] Scrypt error, review settings                   
 [2013-02-13 08:44:47] GPU 1 found something?                   
 [2013-02-13 08:44:47] OCL NONCE 3608809 found in slot 0                   
 [2013-02-13 08:44:47] Scrypt error, review settings                   
 [2013-02-13 08:44:48] GPU 1 found something?                   
 [2013-02-13 08:44:48] OCL NONCE 3788290 found in slot 0                   
 [2013-02-13 08:44:48] Scrypt error, review settings                   
 [2013-02-13 08:44:48] GPU 1 found something?           

Using the same card with CGMiner in Windows I'm able to get 300Khash/sec no problem with a higher intensity (19) and no hardware errors.

Curious if anyone else is having this issue! Thanks in advance! Smiley
Jump to: