Author

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

-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I have some of your old windows binaries. Not sure if it would be any help for you.
I have 2.5.0, 2.6.2, 2.6.3, 2.6.4, 2.6.5 and the current 2.7.0 I didn't grab 2.6.0 or 2.6.1 because of BFL issues and since I only have a single to mine with it didn't seem helpful.

Thank You for making WU field. My backup pool uses difficulty 8 shares so I used to have to use just the average because U would be lower due to occasional work from backup pool. My Rejects are maybe 10% of what 2.6.5 had me at. I have had 0 hardware issues today all issues where throttling related and today was cooler, my average is so far 11 Mhash faster and my U is maybe lower but WU is at 12. Very short test so far only hours not days to fully break in the averages but still.

So far it works great for me, no pool slow to provide work, averge higher, shares bleeding to the backup so I get paid rather then a delay on working.
Great feedback, thanks. Please email me the old binaries [email protected] (one at a time or email will reject them), thanks!
hero member
Activity: 981
Merit: 500
DIV - Your "Virtual Life" Secured and Decentralize
I have some of your old windows binaries. Not sure if it would be any help for you.
I have 2.4.4, 2.5.0, 2.6.2, 2.6.3, 2.6.4, 2.6.5 and the current 2.7.0 I didn't grab 2.6.0 or 2.6.1 because of BFL issues and since I only have a single to mine with it didn't seem helpful.

Thank You for making WU field. My backup pool uses difficulty 8 shares so I used to have to use just the average because U would be lower due to occasional work from backup pool. My Rejects are maybe 10% of what 2.6.5 had me at. I have had 0 hardware issues today all issues where throttling related and today was cooler, my average is so far 11 Mhash faster and my U is maybe lower but WU is at 12. Very short test so far only hours not days to fully break in the averages but still.

So far it works great for me, no pool slow to provide work, averge higher, shares bleeding to the backup so I get paid rather then a delay on working.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Your crash is entirely within the AMD driver, so either you are having a hardware problem (dodgy card, too much overclocking, overheated vrms etc) or a driver problem. Can't see anything in the backtrace related to cgminer.
full member
Activity: 176
Merit: 100
Hi ckolivas,
I have an issue with one of the rigs (2 x 5850), no matter which version of cgminer I use. GPU1 dies in matter of a couple of hours, rig does not respond, sometimes a hard reset is inevitable.
The system runs:
CentOS 6.3
kernel 2.6.32-279.5.1.el6.x86_64
glibc-2.12-1.80.el6_3.4.x86_64
glib2-2.22.5-7.el6.x86_64
gcc-4.4.6-4.el6.x86_64
AMD-APP-SDK-v2.5-lnx64
ati-driver-installer-11-12-x86.x86_64

I tried the latest cgminer-2.7.0, not using any optimizations at all except intensity set to 2. The following is grabbed from /var/log/messages.
--------------------------------------------------------------------------------------------------------------------------------------
Aug 19 06:08:21 hostname kernel: [fglrx] ASIC hang happened
Aug 19 06:08:21 hostname kernel: Pid: 3430, comm: cgminer Tainted: P           ---------------    2.6.32-279.5.1.el6.x86_64 #1
Aug 19 06:08:21 hostname kernel: Call Trace:
Aug 19 06:08:21 hostname kernel: [] ? KCL_DEBUG_OsDump+0xe/0x10 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? firegl_hardwareHangRecovery+0x1c/0x50 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? _ZN4Asic9WaitUntil15ResetASICIfHungEv+0x9/0x10 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? _ZN4Asic9WaitUntil15WaitForCompleteEv+0x9c/0xf0 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? _ZN4Asic19PM4ElapsedTimeStampEj14_LARGE_INTEGER12_QS_CP_RING_+0xaf/0x170 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? firegl_trace+0x72/0x1e0 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? firegl_trace+0x72/0x1e0 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? _ZN15QS_PRIVATE_CORE27multiVpuPM4ElapsedTimeStampEj14_LARGE_INTEGER12_QS_CP_RIN G_+0x33/0x50 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? _Z19uQSTimeStampRetiredmjj14_LARGE_INTEGER+0x74/0x80 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? _Z8uCWDDEQCmjjPvjS_+0x54d/0x10c0 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? down+0x2e/0x50
Aug 19 06:08:21 hostname kernel: [] ? firegl_cmmqs_CWDDE_32+0x332/0x440 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? firegl_cmmqs_CWDDE32+0x70/0x100 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? firegl_cmmqs_CWDDE32+0x0/0x100 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? firegl_ioctl+0x1ed/0x250 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? __do_page_fault+0x1ec/0x480
Aug 19 06:08:21 hostname kernel: [] ? ip_firegl_unlocked_ioctl+0xe/0x20 [fglrx]
Aug 19 06:08:21 hostname kernel: [] ? vfs_ioctl+0x22/0xa0
Aug 19 06:08:21 hostname kernel: [] ? do_vfs_ioctl+0x84/0x580
Aug 19 06:08:21 hostname kernel: [] ? sys_ioctl+0x81/0xa0
Aug 19 06:08:21 hostname kernel: [] ? system_call_fastpath+0x16/0x1b
Aug 19 06:08:21 hostname kernel: pubdev:0xffffffffa049ed20, num of device:2 , name:fglrx, major 8, minor 92.
Aug 19 06:08:21 hostname kernel: device 0 : 0xffff88007a1b0000 .
Aug 19 06:08:21 hostname kernel: Asic ID:0x6899, revision:0x2, MMIOReg:0xffffc90000340000.
Aug 19 06:08:21 hostname kernel: FB phys addr: 0xd0000000, MC :0xf00000000, Total FB size :0x40000000.
Aug 19 06:08:21 hostname kernel: gart table MC:0xf0fb27000, Physical:0xdfb27000, size:0x1d8000.
Aug 19 06:08:21 hostname kernel: mc_node :FB, total 1 zones
Aug 19 06:08:21 hostname kernel:    MC start:0xf00000000, Physical:0xd0000000, size:0xfd00000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0xfb27000, reference count:21, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0x1000000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xfb27000, size:0x1d9000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel: mc_node :INV_FB, total 1 zones
Aug 19 06:08:21 hostname kernel:    MC start:0xf0fd00000, Physical:0xdfd00000, size:0x30300000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x302f4000, size:0xc000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel: mc_node :GART_USWC, total 2 zones
Aug 19 06:08:21 hostname kernel:    MC start:0x260c0000, Physical:0x0, size:0x24c00000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0x2000000, reference count:21, mapping count:0,
Aug 19 06:08:21 hostname kernel: mc_node :GART_CACHEABLE, total 3 zones
Aug 19 06:08:21 hostname kernel:    MC start:0x10400000, Physical:0x0, size:0x15cc0000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1500000, size:0x200000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1400000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1300000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1200000, size:0x100000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1100000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1000000, size:0x100000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xf00000, size:0x100000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xe00000, size:0x100000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xd00000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xb00000, size:0x200000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x800000, size:0x300000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x500000, size:0x300000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x200000, size:0x300000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0x200000, reference count:6, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xef000, size:0x11000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel: GRBM : 0xb0633828, SRBM : 0x20000ec0 .
Aug 19 06:08:21 hostname kernel: CP_RB_BASE : 0x260c00, CP_RB_RPTR : 0x1920 , CP_RB_WPTR :0x1920.
Aug 19 06:08:21 hostname kernel: CP_IB1_BUFSZ:0x0, CP_IB1_BASE_HI:0x0, CP_IB1_BASE_LO:0x2686f000.
Aug 19 06:08:21 hostname kernel: last submit IB buffer -- MC :0x2686f000,phys:0x7b4f5000.
Aug 19 06:08:21 hostname kernel: device 1 : 0xffff88003759c000 .
Aug 19 06:08:21 hostname kernel: Asic ID:0x6899, revision:0x2, MMIOReg:0xffffc90004980000.
Aug 19 06:08:21 hostname kernel: FB phys addr: 0xe0000000, MC :0xf00000000, Total FB size :0x40000000.
Aug 19 06:08:21 hostname kernel: gart table MC:0xf0fb27000, Physical:0xefb27000, size:0x1d8000.
Aug 19 06:08:21 hostname kernel: mc_node :FB, total 1 zones
Aug 19 06:08:21 hostname kernel:    MC start:0xf00000000, Physical:0xe0000000, size:0xfd00000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0xfb27000, reference count:20, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0x1000000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xfb27000, size:0x1d9000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel: mc_node :INV_FB, total 1 zones
Aug 19 06:08:21 hostname kernel:    MC start:0xf0fd00000, Physical:0xefd00000, size:0x30300000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x302f4000, size:0xc000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel: mc_node :GART_USWC, total 2 zones
Aug 19 06:08:21 hostname kernel:    MC start:0x260c0000, Physical:0x0, size:0x24c00000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0x2000000, reference count:21, mapping count:0,
Aug 19 06:08:21 hostname kernel: mc_node :GART_CACHEABLE, total 3 zones
Aug 19 06:08:21 hostname kernel:    MC start:0x10400000, Physical:0x0, size:0x15cc0000.
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x2c00000, size:0x200000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x2b00000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x2a00000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x2900000, size:0x100000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x2800000, size:0x100000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x2600000, size:0x200000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1d00000, size:0x900000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x1400000, size:0x900000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xb00000, size:0x900000, reference count:3, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x200000, size:0x900000, reference count:2, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0x0, size:0x200000, reference count:5, mapping count:0,
Aug 19 06:08:21 hostname kernel:    Mapped heap -- Offset:0xef000, size:0x11000, reference count:1, mapping count:0,
Aug 19 06:08:21 hostname kernel: GRBM : 0xb0633828, SRBM : 0x200006c0 .
Aug 19 06:08:21 hostname kernel: CP_RB_BASE : 0x260c00, CP_RB_RPTR : 0x6970 , CP_RB_WPTR :0x6990.
Aug 19 06:08:21 hostname kernel: CP_IB1_BUFSZ:0x0, CP_IB1_BASE_HI:0x0, CP_IB1_BASE_LO:0x262e7000.
Aug 19 06:08:21 hostname kernel: last submit IB buffer -- MC :0x262e7000,phys:0x693c3000.
Aug 19 06:08:21 hostname kernel: Dump the trace queue.
Aug 19 06:08:21 hostname kernel: End of dump
-----------------------------------------------------------------------------------------------------------------------------------

Can you see anything that causes the problem?
Thx in advance.
 
 
legendary
Activity: 2702
Merit: 1468
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Still getting intensity pegging down to -10 on dynamic threads on win 7 x64.  At the same time, when it drops to -10, cgminer starts eating up a whole core of CPU power.   Undecided

This change happened sometime after 2.6.1.  Probably related to to the change in how cgminer handles dynamic intensity that was in 2.6.5, not 100% sure though since my update path was 2.6.1, 2.6.5, 2.7.0.  First saw it in 2.6.5.  Does not happen in 2.6.1.

Any GPU set to dynamic intensity will eventually peg to -10.  Sometimes very shortly after starting, sometimes after running for a while.  I have not yet been able to figure out what the trigger is.

Tested with a clean copy of 2.7.0 with no prefs file after a cold system reboot.
I can confirm the same bug with intensity pegging down to -10 on dynamic but in my instance without the high CPU usage.
I upgraded from 2.6.4 which didn't have the problem.
Yes it's definitely a bug introduced in 2.6.5 when I tried to work around windows' timers. Why, I dunno cause I can only try it on a laptop with windows that does 9.5Mhash so it's not a very useful piece of hardware to test it on...
hero member
Activity: 927
Merit: 1000
฿itcoin ฿itcoin ฿itcoin
Still getting intensity pegging down to -10 on dynamic threads on win 7 x64.  At the same time, when it drops to -10, cgminer starts eating up a whole core of CPU power.   Undecided

This change happened sometime after 2.6.1.  Probably related to to the change in how cgminer handles dynamic intensity that was in 2.6.5, not 100% sure though since my update path was 2.6.1, 2.6.5, 2.7.0.  First saw it in 2.6.5.  Does not happen in 2.6.1.

Any GPU set to dynamic intensity will eventually peg to -10.  Sometimes very shortly after starting, sometimes after running for a while.  I have not yet been able to figure out what the trigger is.

Tested with a clean copy of 2.7.0 with no prefs file after a cold system reboot.
I can confirm the same bug with intensity pegging down to -10 on dynamic but in my instance without the high CPU usage.
I upgraded from 2.6.4 which didn't have the problem.
hero member
Activity: 896
Merit: 1000
Buy this account on March-2019. New Owner here!!
Looks like ck.kolivas.org is unreachable :

Code:
$ ping ck.kolivas.org
PING vds.kolivas.org (204.152.221.100) 56(84) bytes of data.
From 67.215.251.141: icmp_seq=1 Time to live exceeded
From 67.215.251.141: icmp_seq=2 Time to live exceeded
From 67.215.251.141: icmp_seq=3 Time to live exceeded
From 67.215.251.141: icmp_seq=4 Time to live exceeded
From 67.215.251.141: icmp_seq=5 Time to live exceeded
From 67.215.251.141: icmp_seq=6 Time to live exceeded

Verified on http://www.downforeveryoneorjustme.com/ck.kolivas.org


Server being relocated.
Server is back online. All the files were unintentionally lost by the host provider, so I have had to upload from backups. Thus there will only be a limited number of downloads available, and only binaries from the latest release. I'd apologise for the inconvenience, but the inconvenience to me is far greater...

ckvoilvas

I highly recommend you move your hosting to BTCWebHost.com, we are the oldest and most trusted Bitcoin accepting hosting provider in the world. You will never have to worry about anything like this happening again and best of all you can pay in Bitcoin.

-Tom
BTCWebHost.com
Bitcoinwebhost.com
Bitcoinwebhosting.com
BitcoinVPS.com
legendary
Activity: 2576
Merit: 1186
I looked into the "Switch User" hang reported originally in CGMiner.

It seems the hanging at least is the result of gpu_fanpercent (called by get_opencl_statline_before when updating the summary device status lines) is attempting to log warnings when ADL stops working (as it does in this situation). Logging warnings tries to lock the curses-UI to add it to the log, which just deadlocks since the same thread already has it locked for the general summary updates. There are a number of ways one might fix this, none of which are particularly elegant. Since this is pretty much just Con's domain, I'd appreciate it if someone could relay this information to him (he ignores me), and find out if he intends to fix it or not.

Thanks,

Luke
legendary
Activity: 2702
Merit: 1468
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.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Looks like ck.kolivas.org is unreachable :

Code:
$ ping ck.kolivas.org
PING vds.kolivas.org (204.152.221.100) 56(84) bytes of data.
From 67.215.251.141: icmp_seq=1 Time to live exceeded
From 67.215.251.141: icmp_seq=2 Time to live exceeded
From 67.215.251.141: icmp_seq=3 Time to live exceeded
From 67.215.251.141: icmp_seq=4 Time to live exceeded
From 67.215.251.141: icmp_seq=5 Time to live exceeded
From 67.215.251.141: icmp_seq=6 Time to live exceeded

Verified on http://www.downforeveryoneorjustme.com/ck.kolivas.org


Server being relocated.
Server is back online. All the files were unintentionally lost by the host provider, so I have had to upload from backups. Thus there will only be a limited number of downloads available, and only binaries from the latest release. I'd apologise for the inconvenience, but the inconvenience to me is far greater...
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
I am occasionally running into a lot of stale shares that are causing high numbers of rejects on certain pools.  Mining with a BFL Single farm.  It would be great if the load-balance option automatically switched away from any pool that was getting stale shares until the next block.
If a pool screws up somehow (and the proxy pools are the ones most likely to) and starts rejected *all* your shares, cgminer will disable it after 3 minutes and only re-enable it when it starts accepting shares again already.
legendary
Activity: 2702
Merit: 1468
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.
donator
Activity: 4760
Merit: 4323
Leading Crypto Sports Betting & Casino Platform
I am occasionally running into a lot of stale shares that are causing high numbers of rejects on certain pools.  Mining with a BFL Single farm.  It would be great if the load-balance option automatically switched away from any pool that was getting stale shares until the next block.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
Looks like ck.kolivas.org is unreachable :

Code:
$ ping ck.kolivas.org
PING vds.kolivas.org (204.152.221.100) 56(84) bytes of data.
From 67.215.251.141: icmp_seq=1 Time to live exceeded
From 67.215.251.141: icmp_seq=2 Time to live exceeded
From 67.215.251.141: icmp_seq=3 Time to live exceeded
From 67.215.251.141: icmp_seq=4 Time to live exceeded
From 67.215.251.141: icmp_seq=5 Time to live exceeded
From 67.215.251.141: icmp_seq=6 Time to live exceeded

Verified on http://www.downforeveryoneorjustme.com/ck.kolivas.org


Server being relocated.
hero member
Activity: 896
Merit: 1000
Looks like ck.kolivas.org is unreachable :

Code:
$ ping ck.kolivas.org
PING vds.kolivas.org (204.152.221.100) 56(84) bytes of data.
From 67.215.251.141: icmp_seq=1 Time to live exceeded
From 67.215.251.141: icmp_seq=2 Time to live exceeded
From 67.215.251.141: icmp_seq=3 Time to live exceeded
From 67.215.251.141: icmp_seq=4 Time to live exceeded
From 67.215.251.141: icmp_seq=5 Time to live exceeded
From 67.215.251.141: icmp_seq=6 Time to live exceeded

Verified on http://www.downforeveryoneorjustme.com/ck.kolivas.org

legendary
Activity: 4634
Merit: 1851
Linux since 1997 RedHat 4
...
Sort of related, I had a different question - is it possible for you guys to do the opposite of how you will grab long poll from a different pool that you have set up if the primary pool does not support it, so that you could add a local bitcoin client to check for blocks that could possibly find a new one before long poll does?

There's no way I'd be the first to think of this, so I just assumed it's not doable, or perhaps not worth doing? Just curious I guess.

edit: typo
Bitcoind doesn't have LP in it.
It does have an option to run a command on a block change that you can configure yourself.

I have thought of this before with the API - being able to send a message to the API when a block change occurs, however there is one more thing in an LP that would be missing:
The LP includes work on the new block.

Without this work, the LP is simply telling cgminer to go and do a request for work and thus there is the network delay of waiting for work from the pool.

I will skip certain specific details, to protect the innocent Smiley, but this process would probably be worse than waiting for the LP

... except when LP's are slow ... which has been happening more frequently in the last few months ... but only if the pool would actually return work during it's LP phase (which wouldn't make much sense since it will already be trying to send you work)

However, this could also lead to stalling the miner due to requesting work from the pool and waiting for it, but then simply getting a piece of work for the same 'previous' block if the pool doesn't already know about the new block.

LP design sux and always has since Deepbit came up with the idea (as I have mentioned before as well) - it needs to be faster (e.g. a simple UDP packet TO the miner might perform a lot better)
newbie
Activity: 63
Merit: 0
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
New release - 2.7.0, August 18th 2012

First time I've upgraded since 2.5.4 I think.

Everything is working as advertised.

Three things I noticed that I thought I'd mention:

- On both my miners, one with 4 GPUs, and one with 3, initially on startup the highest number one (lowest on the list) shows a massive amount of work done compared to the others, like 10x as much.  They eventually balance out, but on startup it is unbalanced.

- Failover is working much better.  I run two copies of p2pool on two different machines for backup purposes.  The backup would almost always get a very small amount of work from the miners.  Now the backup is getting zero, like its supposed to.

- Just for fun I tried changing the intensity to dynamic.  I normally run it at 8 for my 7970s.  Every GPU I tried it on, cgminer would change it to 7 and it wouldn't move from there.  Wouldn't say D, it would say 7.  I ended up changing them all to 9, which before caused problems, but now it works and increases output.  10 just jacks up CPU usage with no perceptible increase in hash rate.

As usual, great work.  I just send 2 long over due coins your way..
Thanks for feedback and much more for the donation Wink

Startup GPU difference is just luck variance showing up. Perfectly normal.

Glad to hear failover works better.

Dynamic will show the "chosen" current intensity, which for an awesome 7970 works out to about 7. Perfectly normal. (shame it only works properly on linux it seems).
legendary
Activity: 952
Merit: 1000
Jump to: