Bitcoin Forum
September 22, 2017, 12:07:42 PM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 [266] 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 ... 838 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.10.0  (Read 5477561 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.
OpytZabilParol
Member
**
Offline Offline

Activity: 63


View Profile
May 03, 2012, 10:27:20 AM
 #5301

I use cgminer-2.3.6 on my HD 5870 and received 460-462 Mh/s.
In the new version cgminer-2.4.0 was just 418 Mh/s.
Sys. Win7x64 + OpenCl from AMD Catalyst 12.5 Beta http://www.ngohq.com/home.php?page=Files&go=giveme&dwn_id=1624

Maybe, you should pay attention to the new drivers and optimize a new version of CGMINER
1506082062
Hero Member
*
Offline Offline

Posts: 1506082062

View Profile Personal Message (Offline)

Ignore
1506082062
Reply with quote  #2

1506082062
Report to moderator
1506082062
Hero Member
*
Offline Offline

Posts: 1506082062

View Profile Personal Message (Offline)

Ignore
1506082062
Reply with quote  #2

1506082062
Report to moderator
1506082062
Hero Member
*
Offline Offline

Posts: 1506082062

View Profile Personal Message (Offline)

Ignore
1506082062
Reply with quote  #2

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

Posts: 1506082062

View Profile Personal Message (Offline)

Ignore
1506082062
Reply with quote  #2

1506082062
Report to moderator
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2282


Ruu \o/


View Profile WWW
May 03, 2012, 10:29:13 AM
 #5302

I use cgminer-2.3.6 on my HD 5870 and received 460-462 Mh/s.
In the new version cgminer-2.4.0 was just 418 Mh/s.
Sys. Win7x64 + OpenCl from AMD Catalyst 12.5 Beta http://www.ngohq.com/home.php?page=Files&go=giveme&dwn_id=1624

Maybe, you should pay attention to the new drivers and optimize a new version of CGMINER
Wrong, you should downgrade your driver and read the FAQ.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
kano
Legendary
*
Offline Offline

Activity: 2212


Linux since 1997 RedHat 4


View Profile
May 03, 2012, 10:37:30 AM
 #5303

I use cgminer-2.3.6 on my HD 5870 and received 460-462 Mh/s.
In the new version cgminer-2.4.0 was just 418 Mh/s.
Sys. Win7x64 + OpenCl from AMD Catalyst 12.5 Beta http://www.ngohq.com/home.php?page=Files&go=giveme&dwn_id=1624

Maybe, you should pay attention to the new drivers and optimize a new version of CGMINER
WTF?
A download from a web site that includes an add to "Boost Your Internet Connection - Click Here"
Who would be fool enough to get stuff from there rather than ATI?

Edit: and the forum post says "leaked to the web" ...

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
OpytZabilParol
Member
**
Offline Offline

Activity: 63


View Profile
May 03, 2012, 10:43:48 AM
 #5304

I use cgminer-2.3.6 on my HD 5870 and received 460-462 Mh/s.
In the new version cgminer-2.4.0 was just 418 Mh/s.
Sys. Win7x64 + OpenCl from AMD Catalyst 12.5 Beta http://www.ngohq.com/home.php?page=Files&go=giveme&dwn_id=1624

Maybe, you should pay attention to the new drivers and optimize a new version of CGMINER
Wrong, you should downgrade your driver and read the FAQ.

If you mean that question,
Quote
Q: The CPU usage is high.
A: The ATI drivers after 11.6 have a bug that makes them consume 100% of one
CPU core unnecessarily so downgrade to 11.6. Binding cgminer to one CPU core on
windows can minimise it to 100% (instead of more than one core). Driver version
11.11 on linux and 11.12 on windows appear to have fixed this issue. Note that
later drivers may have an apparent return of high CPU usage. Try
'export GPU_USE_SYNC_OBJECTS=1' on Linux before starting cgminer.
I know about it.

The problem is:
cgminer-2.3.6 + OpenCl from AMD Catalyst 12.5 Beta = 462Mh/s
cgminer-2.4.0 + OpenCl from AMD Catalyst 12.5 Beta = 418Mh/s
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2282


Ruu \o/


View Profile WWW
May 03, 2012, 10:46:04 AM
 #5305

cgminer-2.3.6 + OpenCl from AMD Catalyst 12.5 Beta = 462Mh/s
cgminer-2.4.0 + OpenCl from AMD Catalyst 12.5 Beta = 418Mh/s
Considering none of the opencl, GPU or kernel code was changed between 2.3.6 and 2.4.0, I find that a little more than a little unlikely.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2282


Ruu \o/


View Profile WWW
May 03, 2012, 10:50:33 AM
 #5306

cgminer-2.3.6 + OpenCl from AMD Catalyst 12.5 Beta = 462Mh/s
cgminer-2.4.0 + OpenCl from AMD Catalyst 12.5 Beta = 418Mh/s
Considering none of the opencl, GPU or kernel code was changed between 2.3.6 and 2.4.0, I find that a little more than a little unlikely.
I guess you haven't deleted the .bin files between testing...

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
OpytZabilParol
Member
**
Offline Offline

Activity: 63


View Profile
May 03, 2012, 11:02:38 AM
 #5307

Quote
I guess you haven't deleted the .bin files between testing...

cgminer-2.3.6 and  cgminer-2.4.0 located in different folders. I copied config file from 2.3.6 to 2.4.0 and received result 418Mh/s
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2282


Ruu \o/


View Profile WWW
May 03, 2012, 11:06:23 AM
 #5308

Quote
I guess you haven't deleted the .bin files between testing...

cgminer-2.3.6 and  cgminer-2.4.0 located in different folders. I copied config file from 2.3.6 to 2.4.0 and received result 418Mh/s
Did you delete the .bin files in the 2.3.6 directory after upgrading your driver+sdk?

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
OpytZabilParol
Member
**
Offline Offline

Activity: 63


View Profile
May 03, 2012, 11:23:32 AM
 #5309

Quote
I guess you haven't deleted the .bin files between testing...

cgminer-2.3.6 and  cgminer-2.4.0 located in different folders. I copied config file from 2.3.6 to 2.4.0 and received result 418Mh/s
Did you delete the .bin files in the 2.3.6 directory after upgrading your driver+sdk?
No. Here are the contents of my folders:

-ck
Moderator
Legendary
*
Offline Offline

Activity: 2282


Ruu \o/


View Profile WWW
May 03, 2012, 11:27:27 AM
 #5310

Quote
I guess you haven't deleted the .bin files between testing...

cgminer-2.3.6 and  cgminer-2.4.0 located in different folders. I copied config file from 2.3.6 to 2.4.0 and received result 418Mh/s
Did you delete the .bin files in the 2.3.6 directory after upgrading your driver+sdk?
No. Here are the contents of my folders:

This is what I'm trying to say.. .that has been said many times and is in the FAQ. If you run cgminer, it caches the binary built from the SDK installed the very first time you run it, and then even if you upgrade driver+SDK, it still runs like the old SDK. However if you install a new cgminer, there are no cached .bin files (see the .bin files in each folder), so it generates a new .bin file from the current SDK installed. The only way to compare versions 2.3.6 and 2.4.0 with your current installation of driver+SDK combination is to delete the .bin files from both of them and start them both again.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
af_newbie
Legendary
*
Offline Offline

Activity: 1176



View Profile
May 03, 2012, 11:28:33 AM
 #5311

Quote
I guess you haven't deleted the .bin files between testing...

cgminer-2.3.6 and  cgminer-2.4.0 located in different folders. I copied config file from 2.3.6 to 2.4.0 and received result 418Mh/s
Did you delete the .bin files in the 2.3.6 directory after upgrading your driver+sdk?

Con, it might be worthwhile to put cgminer version in the bin file name so that you can detect upgrades and force recompiles on the fly.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2282


Ruu \o/


View Profile WWW
May 03, 2012, 11:33:01 AM
 #5312

Quote
I guess you haven't deleted the .bin files between testing...

cgminer-2.3.6 and  cgminer-2.4.0 located in different folders. I copied config file from 2.3.6 to 2.4.0 and received result 418Mh/s
Did you delete the .bin files in the 2.3.6 directory after upgrading your driver+sdk?

Con, it might be worthwhile to put cgminer version in the bin file name so that you can detect upgrades and force recompiles on the fly.

I cannot seem to win with this never ending SDK upgrade fail problem. At least people have the option of keeping around a .bin file from an older SDK installation and use it on the current cgminer provided the kernel hasn't changed in the interim. No solution seems optimal, and most of the problem seems to surround the optimisation cgminer does by caching the .bin file which speeds startup of cgminer significantly. If I forced it to build the kernel every single startup, there would never be this confusion, but startup would be butt slow if you had lots of GPUs whereas now it starts hashing in the blink of an eye after the very first startup.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
OpytZabilParol
Member
**
Offline Offline

Activity: 63


View Profile
May 03, 2012, 11:52:34 AM
 #5313

Thank you.
I cut a .bin file from cgminer-2.3.6 with the replacement and now I have 462Mh/s on new  2.4.0 version.
I have just a few days ago started using cgminer, before this was a phoenix.
Thanks again for your help.
af_newbie
Legendary
*
Offline Offline

Activity: 1176



View Profile
May 03, 2012, 11:57:00 AM
 #5314

Con, it might be worthwhile to put cgminer version in the bin file name so that you can detect upgrades and force recompiles on the fly.

I cannot seem to win with this never ending SDK upgrade fail problem. At least people have the option of keeping around a .bin file from an older SDK installation and use it on the current cgminer provided the kernel hasn't changed in the interim. No solution seems optimal, and most of the problem seems to surround the optimisation cgminer does by caching the .bin file which speeds startup of cgminer significantly. If I forced it to build the kernel every single startup, there would never be this confusion, but startup would be butt slow if you had lots of GPUs whereas now it starts hashing in the blink of an eye after the very first startup.

Con, sorry, maybe I was not clear.  Every time you startup, you look for bin files with "cgminer-version-bin-file-name.bin" bin names, if not found
create a bin and put current cgminer version in the file name.  When the user upgrades to next version of  cgminer, you'll not find the bin because you'll be looking for "my-current-cgminer-version-bin-file-name.bin", so you recreate.  When they run cgminer again, you already have a bin that does match your current cgminer version so you use it.

That way you don't recreate bins every time someone runs cgminer, only when they upgrade to new cgminer version.

Makes sense?
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2282


Ruu \o/


View Profile WWW
May 03, 2012, 11:59:24 AM
 #5315

Con, sorry, maybe I was not clear.  Every time you startup, you look for bin files with "cgminer-version-bin-file-name.bin" bin names, if not found
create a bin and put current cgminer version in the file name.  When the user upgrades to next version of  cgminer, you'll not find the bin because you'll be looking for "my-current-cgminer-version-bin-file-name.bin", so you recreate.  When they run cgminer again, you already have a bin that does match your current cgminer version so you use it.

That way you don't recreate bins every time someone runs cgminer, only when they upgrade to new cgminer version.

Makes sense?

Yes but then that would make it hard for someone to do what this user just did: copy over the bin files from 2.3.6 to get the benefit from before they fucked up their SDK installation.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
ancow
Sr. Member
****
Offline Offline

Activity: 373


View Profile WWW
May 03, 2012, 12:32:26 PM
 #5316

When running the latest cgminer with "cgminer -k poclbm --benchmark", it segfaults. Gdb says (bt with current master):
Code:
Program terminated with signal 11, Segmentation fault.
#0  0x000000000040a099 in reap_curl (pool=0xd5fab0) at cgminer.c:4036
4036            list_for_each_entry_safe(ent, iter, &pool->curlring, node) {
(gdb) bt
#0  0x000000000040a099 in reap_curl (pool=0xd5fab0) at cgminer.c:4036
#1  watchpool_thread (userdata=<optimized out>) at cgminer.c:4061
#2  0x00007f116e9edb50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#3  0x00007f116d9fc90d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#4  0x0000000000000000 in ?? ()

According to a quick git bisect, the following commit introduced a first segfault:
Code:
4cd973264f6426c9b3db73b420bb33768f1f3d90 is the first bad commit
commit 4cd973264f6426c9b3db73b420bb33768f1f3d90
Author: Con Kolivas <kernel@kolivas.org>
Date:   Thu Apr 26 23:29:21 2012 +1000

    Create discrete persistent submit and get work threads per pool, thus allowing all submitworks belonging to the same pool to reuse the same curl handle, and all getworks to reuse their own handle.
    Use separate handles for submission to not make getwork potentially delay share submission which is time critical.
    This will allow much more reusing of persistent connections instead of opening new ones which can flood routers.
    This mandated a rework of the extra longpoll support (for when pools are switched) and this is managed by restarting longpoll cleanly and waiting for a thread join.

However, that segfault has a different backtrace. According to git bisect, that exact backtrace was introduced by:
Code:
85008a78539f79bbec1f25fcffafe6a232e2597b is the first bad commit
commit 85008a78539f79bbec1f25fcffafe6a232e2597b
Author: ckolivas <kernel@kolivas.org>
Date:   Wed May 2 10:12:07 2012 +1000

    Reap curls that are unused for over a minute.
    This allows connections to be closed, thereby allowing the number of curl handles to always be the minimum necessary to not delay networking.

However, you should probably do some further testing... Wink

The backtrace produced by 4cd973264f6426c9b3db73b420bb33768f1f3d90 is:
Code:
Program terminated with signal 11, Segmentation fault.
#0  __pthread_mutex_lock (mutex=0x18) at pthread_mutex_lock.c:50
50      pthread_mutex_lock.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  __pthread_mutex_lock (mutex=0x18) at pthread_mutex_lock.c:50
#1  0x00000000004130e3 in mutex_lock (lock=0x18) at miner.h:410
#2  tq_push (tq=0x0, data=<optimized out>) at util.c:625
#3  0x0000000000409705 in workio_get_work (wc=0x3621ff0) at cgminer.c:2068
#4  workio_thread (userdata=0x17414c0) at cgminer.c:3105
#5  0x00007ff96d476b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#6  0x00007ff96c48590d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#7  0x0000000000000000 in ?? ()

BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2282


Ruu \o/


View Profile WWW
May 03, 2012, 12:35:00 PM
 #5317

Darn, didn't try benchmark. Presumably that b0rk with the networking upgrade.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
af_newbie
Legendary
*
Offline Offline

Activity: 1176



View Profile
May 03, 2012, 01:12:09 PM
 #5318

Con, sorry, maybe I was not clear.  Every time you startup, you look for bin files with "cgminer-version-bin-file-name.bin" bin names, if not found
create a bin and put current cgminer version in the file name.  When the user upgrades to next version of  cgminer, you'll not find the bin because you'll be looking for "my-current-cgminer-version-bin-file-name.bin", so you recreate.  When they run cgminer again, you already have a bin that does match your current cgminer version so you use it.

That way you don't recreate bins every time someone runs cgminer, only when they upgrade to new cgminer version.

Makes sense?

Yes but then that would make it hard for someone to do what this user just did: copy over the bin files from 2.3.6 to get the benefit from before they fucked up their SDK installation.

You're right.  You probably would need an SDK version in there as well.  Even then there might be people upgrading SDK and cgminer (without versioned bins) to one with versioned bins, and still get a mismatch.  But over time, SDK-cgminer versions in the bins might be the ticket.  Just an idea; might be worth implementing  it.

ancow
Sr. Member
****
Offline Offline

Activity: 373


View Profile WWW
May 03, 2012, 01:17:42 PM
 #5319

Yes but then that would make it hard for someone to do what this user just did: copy over the bin files from 2.3.6 to get the benefit from before they fucked up their SDK installation.

You're right.  You probably would need an SDK version in there as well.  Even then there might be people upgrading SDK and cgminer (without versioned bins) to one with versioned bins, and still get a mismatch.  But over time, SDK-cgminer versions in the bins might be the ticket.  Just an idea might be worth considering.

I don't think it is. After all, then you'd have an even harder time getting the precompiled bins ckolivas provides (assuming he still does) to run on a less optimal SDK version. This way, at least you can get a faster .bin without having to fuck up your system trying to install different SDKs.

BTC: 1GAHTMdBN4Yw3PU66sAmUBKSXy2qaq2SF4
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2282


Ruu \o/


View Profile WWW
May 03, 2012, 01:19:23 PM
 #5320

You're right.  You probably would need an SDK version in there as well.  Even then there might be people upgrading SDK and cgminer (without versioned bins) to one with versioned bins, and still get a mismatch.  But over time, SDK-cgminer versions in the bins might be the ticket.  Just an idea might be worth considering.
I've actually considered it in the past but the limitation was the way the SDK reported back its version: "OpenCL 1.1 AMD-APP (844.4)" for example. It's a rather long name to add to the filename and doesn't say anything about SDK 2.6, and each of linux, windows, 32, 64 bit have different versions as well (by the way cgminer tries to detect each of them but the list is getting longer every day). The only purpose it would serve is debugging for me on the forum when someone says their hashrate is slow. However, if their hashrate is slow, I can say with 101% certainty they're on SDK 2.6 or later.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
Pages: « 1 ... 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 [266] 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 ... 838 »
  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!