Bitcoin Forum
December 08, 2016, 06:19:17 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 317 318 319 320 321 322 323 324 325 326 327 328 329 330 [331] 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4823392 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.
rav3n_pl
Legendary
*
Offline Offline

Activity: 1320


Don`t panic! Organize!


View Profile
August 16, 2012, 06:28:19 AM
 #6601

On the 2.6.5 binary;
Seeing the same bug we had a while back again...  Undecided  (Well, may not be the same bug, but it's acting the same)

Intensity pegs to -10 when set to dynamic on a GPU with a display on it.
Hmm I think we had the discussion before, but are you sure the dynamic is set to the correct device?
Have only one GPU 6770, same thing there.
On LTC mining I have I=11, I change it to dynamic, it jumps to 9 for a second or two then falls to -10 and stays there.

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
My SatoshDice bot https://bitcointalk.org/index.php?topic=897685
1481221157
Hero Member
*
Offline Offline

Posts: 1481221157

View Profile Personal Message (Offline)

Ignore
1481221157
Reply with quote  #2

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

Posts: 1481221157

View Profile Personal Message (Offline)

Ignore
1481221157
Reply with quote  #2

1481221157
Report to moderator
1481221157
Hero Member
*
Offline Offline

Posts: 1481221157

View Profile Personal Message (Offline)

Ignore
1481221157
Reply with quote  #2

1481221157
Report to moderator
1481221157
Hero Member
*
Offline Offline

Posts: 1481221157

View Profile Personal Message (Offline)

Ignore
1481221157
Reply with quote  #2

1481221157
Report to moderator
punin
Hero Member
*****
Offline Offline

Activity: 559


View Profile WWW
August 16, 2012, 10:14:58 AM
 #6602

I have found a bug that is reproducible. It seems cgminer always declares 1 ztex board dead after a while (1h or so). Interestingly enough this does not happen on my other rigs that are x86 based, and have also GPU's connected to them. Very weird indeed. Reproducible also in BFGMiner.

Also, if 1 board is declared dead and is kept connected to the computer, no more boards will be decalred dead. If I disconnect the dead board, soon another one will get sick and dead.

System setup:
CGMiner 2.6.4 running on Raspberry Pi
14-18 ztex 1.15x

Head of Product Development
Bitfury Group
www.bitfury.com
crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
August 16, 2012, 01:34:05 PM
 #6603

Quick question: Can someone tell me why the fan output on my 2nd card looks all wonky? Top card is a Gigabyte 7970, and bottom card is a Gigabyte 7770.


Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
August 16, 2012, 01:36:53 PM
 #6604

Quick question: Can someone tell me why the fan output on my 2nd card looks all wonky? Top card is a Gigabyte 7970, and bottom card is a Gigabyte 7770.


Not all GPUs support fanspeed monitoring by RPM; only the set percentage. You can see that from status line at the top. cgminer shouldn't be trying to show you the rpm below as it's completely invalid.

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

Activity: 576


View Profile
August 16, 2012, 01:46:51 PM
 #6605

For some reason when I try to run cgminer with 2 GPUs and 4 BFLs it crashes. I have to run 2 separate instances, one with -S noauto for GPUs and other with all the BFLs. I can run 2 GPUs and 2 BFLs on same cgminer instance, but not all 6 at once. It happens on all versions of cgminer. Any idea why this is?

Not sure if this helps at all, but here is the windows log:
Problem signature:
  Problem Event Name:   APPCRASH
  Application Name:   cgminer.exe
  Application Version:   0.0.0.0
  Application Timestamp:   502b065b
  Fault Module Name:   cgminer.exe
  Fault Module Version:   0.0.0.0
  Fault Module Timestamp:   502b065b
  Exception Code:   c0000005
  Exception Offset:   0000a74d
  OS Version:   6.1.7601.2.1.0.256.4
  Locale ID:   1033
  Additional Information 1:   0a9e
  Additional Information 2:   0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:   0a9e
  Additional Information 4:   0a9e372d3b4ad19135b953a78882e789

Tips / Donations accepted: 1Morb18DsDHNEv6TeQXBdba872ZSpiK9fY
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
August 16, 2012, 01:49:20 PM
 #6606

For some reason when I try to run cgminer with 2 GPUs and 4 BFLs it crashes. I have to run 2 separate instances, one with -S noauto for GPUs and other with all the BFLs. I can run 2 GPUs and 2 BFLs on same cgminer instance, but not all 6 at once. It happens on all versions of cgminer. Any idea why this is?

Not sure if this helps at all, but here is the windows log:
Problem signature:
  Problem Event Name:   APPCRASH
  Application Name:   cgminer.exe
  Application Version:   0.0.0.0
  Application Timestamp:   502b065b
  Fault Module Name:   cgminer.exe
  Fault Module Version:   0.0.0.0
  Fault Module Timestamp:   502b065b
  Exception Code:   c0000005
  Exception Offset:   0000a74d
  OS Version:   6.1.7601.2.1.0.256.4
  Locale ID:   1033
  Additional Information 1:   0a9e
  Additional Information 2:   0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:   0a9e
  Additional Information 4:   0a9e372d3b4ad19135b953a78882e789
Make your msdos window bigger by default.

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

Activity: 576


View Profile
August 16, 2012, 01:54:09 PM
 #6607

Make your msdos window bigger by default.

still no luck, get the APPCRASH again

Tips / Donations accepted: 1Morb18DsDHNEv6TeQXBdba872ZSpiK9fY
af_newbie
Legendary
*
Offline Offline

Activity: 896



View Profile
August 16, 2012, 02:27:47 PM
 #6608

CGMINER crashes when using Switch User on Windows. This is the only miner that does this, all other miners continue happily mining in the background.
When the crash happens, the mining kernel continues to run on the gpus but no shares are submitted, and the cgminer interface just hangs and doesnt respond.

I tried all versions back to 2.0.4, they all crash when switching user.

My machine:
Windows 7 x64
Catalyst 12.6, APP 2.7
Radeon 7950 and 5850

Does the cgminer actually crash or continues running in ALIVE state and not submitting shares?

If cgminer actually crashes, post WER details.

If cgminer process is still running, check GPU/PGA and pool statuses using ANUBIS or other API status display tools.
niooron
Full Member
***
Offline Offline

Activity: 190


View Profile
August 16, 2012, 03:28:22 PM
 #6609

CGMINER crashes when using Switch User on Windows. This is the only miner that does this, all other miners continue happily mining in the background.
When the crash happens, the mining kernel continues to run on the gpus but no shares are submitted, and the cgminer interface just hangs and doesnt respond.

I tried all versions back to 2.0.4, they all crash when switching user.

My machine:
Windows 7 x64
Catalyst 12.6, APP 2.7
Radeon 7950 and 5850

Does the cgminer actually crash or continues running in ALIVE state and not submitting shares?

If cgminer actually crashes, post WER details.

If cgminer process is still running, check GPU/PGA and pool statuses using ANUBIS or other API status display tools.


I doesnt actually crash and exit, the interface just stops responding. Also it stops submitting shares, I use the 50btc.com pool and when the miner hangs the drop in mhash/s is seen quickly in the pools API. And GPU-Z shows the gpus continue running the kernels.

14dxwuQwkQiLbZjJFfciZ26xSGdRU5mKEp
af_newbie
Legendary
*
Offline Offline

Activity: 896



View Profile
August 16, 2012, 04:03:54 PM
 #6610

I doesnt actually crash and exit, the interface just stops responding. Also it stops submitting shares, I use the 50btc.com pool and when the miner hangs the drop in mhash/s is seen quickly in the pools API. And GPU-Z shows the gpus continue running the kernels.

What is the CGMINER GPU status and CGMINER pool status? Are your other network applications continue operating when you switch user?

Use cgminer API to read GPU and POOL status.
niooron
Full Member
***
Offline Offline

Activity: 190


View Profile
August 16, 2012, 06:56:20 PM
 #6611

I doesnt actually crash and exit, the interface just stops responding. Also it stops submitting shares, I use the 50btc.com pool and when the miner hangs the drop in mhash/s is seen quickly in the pools API. And GPU-Z shows the gpus continue running the kernels.

What is the CGMINER GPU status and CGMINER pool status? Are your other network applications continue operating when you switch user?

Use cgminer API to read GPU and POOL status.

This happens after switching user:

Code:
08/16/12 14:49:06 0x12e4 INF refreshADLInfo(): min GPU utilization: 0%, max GPU temperature: 75C

08/16/12 14:49:06 0x12e4 DBG adlPollingThread(): ADL H/W reading done, status: ADL_STATUS_CLOSED

08/16/12 14:49:10 0x0e28 INF listenForCommands(): new connection from: 127.0.0.1

08/16/12 14:49:11 0x0e28 SVR listenForCommands(): received invalid request

08/16/12 14:49:11 0x0e28 INF listenForCommands(): closing accepted connection.

08/16/12 14:49:11 0x0e28 INF listenForCommands(): new connection from: 127.0.0.1

08/16/12 14:49:12 0x0e28 DBG listenForCommands(): received 'status' command

08/16/12 14:49:12 0x0e28 DBG getWatchdogStatus(): status len: 927

08/16/12 14:49:12 0x0e28 INF listenForCommands(): closing accepted connection.

08/16/12 14:49:17 0x0e28 INF listenForCommands(): new connection from: 127.0.0.1

08/16/12 14:49:18 0x0e28 SVR listenForCommands(): received invalid request

08/16/12 14:49:18 0x0e28 INF listenForCommands(): closing accepted connection.

08/16/12 14:49:18 0x0e28 INF listenForCommands(): new connection from: 127.0.0.1

08/16/12 14:49:18 0x0e28 DBG listenForCommands(): received 'status' command

08/16/12 14:49:18 0x0e28 DBG getWatchdogStatus(): status len: 927

08/16/12 14:49:18 0x0e28 INF listenForCommands(): closing accepted connection.

08/16/12 14:49:21 0x12dc DBG monitorThread(): max gpu temperature (75C) stays below defined threshold (86C)

08/16/12 14:49:21 0x12dc DBG monitorThread(): all GPU fans appear to be functional

08/16/12 14:49:21 0x12dc SVR monitorThread(): GPU mining activity: 0% is lower than threshold: 20%, timeout of 80 seconds has been reached, will restart miner process after: 15 seconds...

08/16/12 14:49:21 0x12dc SVR restartMiner(): killing miner process: 1164

14dxwuQwkQiLbZjJFfciZ26xSGdRU5mKEp
BitMinerN8
Hero Member
*****
Offline Offline

Activity: 626


Mining since May 2011.


View Profile
August 16, 2012, 08:29:15 PM
 #6612

New version - 2.6.5, 15th August 2012

So far working great on Pi with multiple BFLs.

Well... I started having this issue: (Not bitching, just providing feedback)


I have two Pi, both configured identical except for hostname and IP. Both have two BFL Singles attached directly. I switched back to 2.5.0 on one of them and it has not crashed since, while on the other running 2.6.5 it has after 6-7 hours with the Comms error as shown above. I have also swapped which Pi was running 2.6.5 and this issue seems to follow it. (after 6+ hours) I have also swapped the BFL's around, it appears to be random as to which fails. Open for suggestions or let me know if there is a way I can help with configuring a log file or something that.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
August 16, 2012, 09:27:58 PM
 #6613

I doesnt actually crash and exit, the interface just stops responding. Also it stops submitting shares, I use the 50btc.com pool and when the miner hangs the drop in mhash/s is seen quickly in the pools API. And GPU-Z shows the gpus continue running the kernels.

What is the CGMINER GPU status and CGMINER pool status? Are your other network applications continue operating when you switch user?

Use cgminer API to read GPU and POOL status.

This happens after switching user:

Code:
08/16/12 14:49:06 0x12e4 INF refreshADLInfo(): min GPU utilization: 0%, max GPU temperature: 75C

...

08/16/12 14:49:21 0x12dc SVR monitorThread(): GPU mining activity: 0% is lower than threshold: 20%, timeout of 80 seconds has been reached, will restart miner process after: 15 seconds...

08/16/12 14:49:21 0x12dc SVR restartMiner(): killing miner process: 1164
I've no idea what creates that log ...

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
af_newbie
Legendary
*
Offline Offline

Activity: 896



View Profile
August 17, 2012, 12:42:43 AM
 #6614

I doesnt actually crash and exit, the interface just stops responding. Also it stops submitting shares, I use the 50btc.com pool and when the miner hangs the drop in mhash/s is seen quickly in the pools API. And GPU-Z shows the gpus continue running the kernels.

What is the CGMINER GPU status and CGMINER pool status? Are your other network applications continue operating when you switch user?

Use cgminer API to read GPU and POOL status.

This happens after switching user:

Code:
08/16/12 14:49:06 0x12e4 INF refreshADLInfo(): min GPU utilization: 0%, max GPU temperature: 75C

08/16/12 14:49:06 0x12e4 DBG adlPollingThread(): ADL H/W reading done, status: ADL_STATUS_CLOSED

08/16/12 14:49:10 0x0e28 INF listenForCommands(): new connection from: 127.0.0.1

08/16/12 14:49:11 0x0e28 SVR listenForCommands(): received invalid request

08/16/12 14:49:11 0x0e28 INF listenForCommands(): closing accepted connection.

08/16/12 14:49:11 0x0e28 INF listenForCommands(): new connection from: 127.0.0.1

08/16/12 14:49:12 0x0e28 DBG listenForCommands(): received 'status' command

08/16/12 14:49:12 0x0e28 DBG getWatchdogStatus(): status len: 927

08/16/12 14:49:12 0x0e28 INF listenForCommands(): closing accepted connection.

08/16/12 14:49:17 0x0e28 INF listenForCommands(): new connection from: 127.0.0.1

08/16/12 14:49:18 0x0e28 SVR listenForCommands(): received invalid request

08/16/12 14:49:18 0x0e28 INF listenForCommands(): closing accepted connection.

08/16/12 14:49:18 0x0e28 INF listenForCommands(): new connection from: 127.0.0.1

08/16/12 14:49:18 0x0e28 DBG listenForCommands(): received 'status' command

08/16/12 14:49:18 0x0e28 DBG getWatchdogStatus(): status len: 927

08/16/12 14:49:18 0x0e28 INF listenForCommands(): closing accepted connection.

08/16/12 14:49:21 0x12dc DBG monitorThread(): max gpu temperature (75C) stays below defined threshold (86C)

08/16/12 14:49:21 0x12dc DBG monitorThread(): all GPU fans appear to be functional

08/16/12 14:49:21 0x12dc SVR monitorThread(): GPU mining activity: 0% is lower than threshold: 20%, timeout of 80 seconds has been reached, will restart miner process after: 15 seconds...

08/16/12 14:49:21 0x12dc SVR restartMiner(): killing miner process: 1164

From your akbash logs, the network is working ok, but your GPU usage drops to 0%.  Are you mining on your display card?
If so, you'll not be able to mine using one user and then switch to another user and expect the mining to continue.

I don't think cgminer supports switching desktops like that.  AMD drivers run in user mode and if you allocate resources in one user context, and then switch that context, the display environment will be re-initialized and the handles that cgminer process was using become invalid.  The same physical card cannot mine in one user context and then display desktop (or mine) in another user context.

You could probably mine PGAs like that. 

Try to disable display GPU in cgminer and see if you can mine the other GPUs when you switch to another user.
I'd be surprised if you can, but maybe it will work.
stoppots
Sr. Member
****
Offline Offline

Activity: 271


View Profile
August 17, 2012, 11:35:02 AM
 #6615

When using the load balance feature between 2 pools, I always have more accepted shares on pool 0 than pool 1. If I switch the pools on my .conf file I get the same result. Pool 0 always has a considerably higher amount of accepted shares than pool 1.

I have noticed a similar behavior too, but with me pool 3 gets almost all of the shares and pools 0, 1 and 2 get starved.
Sam
This is simply that one pool has rolltime and the others do not. It's such an efficient option that it's really a waste of resources to not use it on the one pool since the others have not moved out of the dark ages. But I guess I could add more black magic to cope with that....

I have been able to get a better balance between 2 pools by using the rotate option. Get alot closer to having even shares on each pool. With the load balance at the times I had the biggest differences between pools, I would sometimes get as much as 2/3 at one pool and 1/3 at the other. Does that sound like a correct ratio that the rollntime could cause?

This all being to attempt to lower variance. At wat cost is my trying to split work evenly between 2 pools effecting efficiency versus just using the failover feature?
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
August 17, 2012, 12:01:49 PM
 #6616

I would sometimes get as much as 2/3 at one pool and 1/3 at the other. Does that sound like a correct ratio that the rollntime could cause?
Yes, and it is going to get MUCH worse on the next release as I clean up the queueing to make it as efficient as possible.

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

Activity: 345


View Profile
August 17, 2012, 12:11:18 PM
 #6617

Does anyone have experience with CGminer and configuration on Dropbox without dropbox windowsclient?

I provide a 1000Mbit+ Torrent-Seedbox in FR and a 500Mbit Box in NL for orginal Blockchain Bootstrap.dat download. and also for Armoryclient Torrent

Tips are welcome:  15MuGdPSXU62fEFE9XbBZN3UvJMHBDVBoy
Fiyasko
Legendary
*
Offline Offline

Activity: 1428


Okey Dokey Lokey


View Profile
August 18, 2012, 04:39:47 AM
 #6618

Hiiiyaaa, Experiancing crashes when playing a Specific game.
Raiderz (wich is in Beta) crashes seemingly Randomly while mining with CGminer (i am aware that versions 2.5+ are not so stable) The weird thing is that when the game was in Alpha, I did not experiance crashes.

So could it be newer CGminer's fault? Since CGminer crashes and Raiderz remains "ok"
Or could it be something like the fact that im now on a 7000 series and not a 6000 series anymore<- i doubt it tho..
Raiderz is what i expect to be the issue, since CGminer doesnt crash while running Aaany other game.

Im gonna test with cg miner 2.5 soon, Heres a windows error message

Code:
Log Name:      Application
Source:        Application Error
Date:          8/10/2012 10:07:33 AM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      DingoRabiit
Description:
Faulting application name: cgminer.exe, version: 0.0.0.0, time stamp: 0x5016082d
Faulting module name: aticaldd.dll, version: 6.14.10.1741, time stamp: 0x4fbc3bc1
Exception code: 0xc0000005
Fault offset: 0x0003b678
Faulting process id: 0x1510
Faulting application start time: 0x01cd76694352e295
Faulting application path: C:\cgminer-2.3.6-win32\cgminer-2.6.1-win32\cgminer-2.6.1-win32\cgminer.exe
Faulting module path: C:\Windows\system32\aticaldd.dll
Report Id: dffa8904-e30d-11e1-833f-bcaec5c2bfb6
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Error" />
    <EventID Qualifiers="0">1000</EventID>
    <Level>2</Level>
    <Task>100</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2012-08-10T17:07:33.000000000Z" />
    <EventRecordID>21845</EventRecordID>
    <Channel>Application</Channel>
    <Computer>DingoRabitt</Computer>
    <Security />
  </System>
  <EventData>
    <Data>cgminer.exe</Data>
    <Data>0.0.0.0</Data>
    <Data>5016082d</Data>
    <Data>aticaldd.dll</Data>
    <Data>6.14.10.1741</Data>
    <Data>4fbc3bc1</Data>
    <Data>c0000005</Data>
    <Data>0003b678</Data>
    <Data>1510</Data>
    <Data>01cd76694352e295</Data>
    <Data>C:\cgminer-2.3.6-win32\cgminer-2.6.1-win32\cgminer-2.6.1-win32\cgminer.exe</Data>
    <Data>C:\Windows\system32\aticaldd.dll</Data>
    <Data>dffa8904-e30d-11e1-833f-bcaec5c2bfb6</Data>
  </EventData>
</Event>

im wonder What is causing the crash Sad
Well i couldnt figure out whats causing the crashing, But running with -T fixes the crashing

http://bitcoin-otc.com/viewratingdetail.php?nick=DingoRabiit&sign=ANY&type=RECV <-My Ratings
https://bitcointalk.org/index.php?topic=857670.0 GAWminers and associated things are not to be trusted, Especially the "mineral" exchange
somenick
Legendary
*
Offline Offline

Activity: 1318


View Profile
August 18, 2012, 01:49:26 PM
 #6619

2.6.4 is woking good with 15 BFL Singles a week!
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
August 18, 2012, 01:57:21 PM
 #6620

New release - 2.7.0, August 18th 2012

Normally a minor version (2.6->2.7) update brings with it instability, but in fact this release includes some very heavily tested code that was a long time in the making and because of its magnitude and impact it warranted a version update.


Human readable changelog:

The main change in this version is a complete rewrite of the getwork requesting mechanism. I've been slowly hacking away at it for some time, but finally gave up in disgust and have rewritten it almost entirely. Previously mining threads would occasionally throw out a request for more work, some arbitrary test would be done on whether more work should be requested, and it handed off the message to another thread which spawned another thread and that then sent the request and ... anyway the mechanism was so asynchronous that the arse didn't know what its head was doing by the time it was deciding on what to do for work. Worse yet it was hard to find the right place to reuse work and so it was never reused to its utmost potential. This is mostly my fault for gradually hacking on more and more asynchronous threaded components to cgminer and the demands for getting work have been increasing sharply of late with new hardware. The rewrite involves scheduling a new request based on the rate the old work items get used up, and is much better at predicting when it needs to leak work to backup pools and less likely to throw a "pool is not providing work fast enough" message. Overall you should now see much more Local Work (LW), the efficiency will be higher on pools that support rolltime, less work will be discarded, any magnitude rig will be kept solidly busy - note this MAY mean your overclocks will become that much more stressed if you have set clocks very aggressively. Thanks to numerous people who tested this on IRC during its development phase. For many of you, you'll be wondering what the fuss is about cause it will just appear as business as usual.

New pool strategy: Balance.
--balance           Change multipool strategy from failover to even share balance
This is to differentiate itself from the existing pool strategy, Load balance:
--load-balance      Change multipool strategy from failover to efficiency based balance

With the change to queueing and more roll work being possible than ever before, the imbalance between pools that support rolltime and those that don't will now be extreme in load balance strategy. To offset that, and since the number of people using load balance has been increasing, the new strategy was added to try and give roughly the same number of shares to each pool. This required some code to estimate a rolling average work completion rate that was not dependent on difficulty, and would cope with dips and peaks as pools are enabled/disabled/fail. Otherwise you could end up mining 100% on solo since you would rarely be submitting only possible block solutions, and not shares.

New statistic: Work Utility. With higher difficulty share supporting pools in the testing phase, it is going to be hard to monitor overall work performance based on successful share submission. To counter this, work utility is a value based on the amount of difficulty 1 shares solved, whether they're accepted or rejected by the pool. This value will always be higher than the current "utility". (Note that difficulty 1 share counting on scrypt is not supported since the work is compared to the target on the GPU itself, but the total shares solved will be displayed).

Other minor bugfixes.


Full changelog:

- Introduce a new statistic, Work Utility, which is the number of difficulty 1
shares solved per minute. This is useful for measuring a relative rate of work
that is independent of reject rate and target difficulty.
- Implement a new pool strategy, BALANCE, which monitors work performed per pool
as a rolling average every 10 minutes to try and distribute work evenly over all
the pools. Do this by monitoring diff1 solutions to allow different difficulty
target pools to be treated equally, along with solo mining. Update the
documentation to describe this strategy and more accurately describe the
load-balance one.
- Getwork fail was not being detected. Remove a vast amount of unused variables
and functions used in the old queue request mechanism and redefine the getfail
testing.
- Don't try to start devices that don't support scrypt when scrypt mining.
- 0 is a valid return value for read so only break out if read returns -1.
- Consider us lagging only once our queue is almost full and no staged work.
- Simplify the enough work algorithm dramatically.
- Only queue from backup pools once we have nothing staged.
- Don't keep queueing work indefinitely if we're in opt failover mode.
- Make sure we don't opt out of queueing more work if all the queued work is
from one pool.
- Set lagging flag if we're on the last of our staged items.
- Reinstate clone on grabbing work.
- Grab clones from hashlist wherever possible first.
- Cull all the early queue requests since we request every time work is popped
now.
- Keep track of staged rollable work item counts to speed up clone_available.
- Make expiry on should_roll to 2/3 time instead of share duration since some
hardware will have very fast share times.
- Do the cheaper comparison first.
- Check that we'll get 1 shares' worth of work time by rolling before saying we
should roll the work.
- Simplify all those total_secs usages by initialising it to 1 second.
- Overlap queued decrementing with staged incrementing.
- Artificially set the pool lagging flag on pool switch in failover only mode as
well.
- Artificially set the pool lagging flag on work restart to avoid messages about
slow pools after every longpoll.
- Factor in opt_queue value into enough work queued or staged.
- Roll work whenever we can on getwork.
- Queue requests for getwork regardless and test whether we should send for a
getwork from the getwork thread itself.
- Get rid of age_work().
- 0 is a valid return value for read so only break out if read returns -1.
- Offset libusb reads/writes by length written as well in ztex.
- Cope with timeouts and partial reads in ztex code.
- fpga serial I/O extra debug (disabled by default)

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
Pages: « 1 ... 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 317 318 319 320 321 322 323 324 325 326 327 328 329 330 [331] 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 ... 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!