BALANCE
I'll give it a try, thanks. 
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 407. (Read 5805537 times)
February 23, 2013, 02:42:49 PM
February 23, 2013, 01:13:40 PM
Quote
LOAD BALANCE:
This strategy sends work to all the pools to maintain optimum load. The most
efficient pools will tend to get a lot more shares. If any pool falls idle, the
rest will tend to take up the slack keeping the miner busy.
BALANCE:
This strategy monitors the amount of difficulty 1 shares solved for each pool
and uses it to try to end up doing the same amount of work for all pools.
This strategy sends work to all the pools to maintain optimum load. The most
efficient pools will tend to get a lot more shares. If any pool falls idle, the
rest will tend to take up the slack keeping the miner busy.
BALANCE:
This strategy monitors the amount of difficulty 1 shares solved for each pool
and uses it to try to end up doing the same amount of work for all pools.
It's my understanding that while both of these options keep sending work to all available pools at all times, I don't think I've ever quite understood the practical differences between these two. If I'm looking to split my hashrate perfectly even across multiple stratum servers, which would be better? Does VarrDiff skew the results one way or the other?
February 23, 2013, 11:40:31 AM
Quote
LOAD BALANCE:
This strategy sends work to all the pools to maintain optimum load. The most
efficient pools will tend to get a lot more shares. If any pool falls idle, the
rest will tend to take up the slack keeping the miner busy.
BALANCE:
This strategy monitors the amount of difficulty 1 shares solved for each pool
and uses it to try to end up doing the same amount of work for all pools.
This strategy sends work to all the pools to maintain optimum load. The most
efficient pools will tend to get a lot more shares. If any pool falls idle, the
rest will tend to take up the slack keeping the miner busy.
BALANCE:
This strategy monitors the amount of difficulty 1 shares solved for each pool
and uses it to try to end up doing the same amount of work for all pools.
It's my understanding that while both of these options keep sending work to all available pools at all times, I don't think I've ever quite understood the practical differences between these two. If I'm looking to split my hashrate perfectly even across multiple stratum servers, which would be better? Does VarrDiff skew the results one way or the other?
I have tinkered around with these settings and theories of operation allot. It is impossible to split your hash rate perfectly across multiple servers. Stratum makes it more difficult to split hash rate than getwork with rollntime.
If you really want to split your hash rate between pools the rotate strategy would work better. Or set up multiple mining rigs that are as close to the same capabilities as possible and mine with a separate instance of CGminer for each to a different pool.
Sam
February 23, 2013, 06:21:54 AM
Quote
LOAD BALANCE:
This strategy sends work to all the pools to maintain optimum load. The most
efficient pools will tend to get a lot more shares. If any pool falls idle, the
rest will tend to take up the slack keeping the miner busy.
BALANCE:
This strategy monitors the amount of difficulty 1 shares solved for each pool
and uses it to try to end up doing the same amount of work for all pools.
This strategy sends work to all the pools to maintain optimum load. The most
efficient pools will tend to get a lot more shares. If any pool falls idle, the
rest will tend to take up the slack keeping the miner busy.
BALANCE:
This strategy monitors the amount of difficulty 1 shares solved for each pool
and uses it to try to end up doing the same amount of work for all pools.
It's my understanding that while both of these options keep sending work to all available pools at all times, I don't think I've ever quite understood the practical differences between these two. If I'm looking to split my hashrate perfectly even across multiple stratum servers, which would be better? Does VarrDiff skew the results one way or the other?
Load Balance example with 2 pools of different difficulty.
Pool a diff 1, 1 share submitted
Pool B Diff 8, 1 share submitted
Pool A Diff 1, 1 share submitted
Pool B diff 8 1 share submitted.
At the end of ~18 work units you have 2 shares to pool A and 2 shares to pool B. Pool A pays 1/8th about what Pool B pays so your hashrate and payout will be off by the difficulty
Balance
Pool A diff 1, 1 share
Pool B diff 2, 0 share
Pool A diff 1, 1 share
Pool B diff 2, 1 share
At the end of ~4 work units you will have 3 shares, Pool A paying for 2 shares and Pool B paying for 2 shares. Giving you the same or similarly split hashrate and payouts depending on fees.
Edit:
Thank You!
February 23, 2013, 04:14:05 AM
Quote
LOAD BALANCE:
This strategy sends work to all the pools to maintain optimum load. The most
efficient pools will tend to get a lot more shares. If any pool falls idle, the
rest will tend to take up the slack keeping the miner busy.
BALANCE:
This strategy monitors the amount of difficulty 1 shares solved for each pool
and uses it to try to end up doing the same amount of work for all pools.
This strategy sends work to all the pools to maintain optimum load. The most
efficient pools will tend to get a lot more shares. If any pool falls idle, the
rest will tend to take up the slack keeping the miner busy.
BALANCE:
This strategy monitors the amount of difficulty 1 shares solved for each pool
and uses it to try to end up doing the same amount of work for all pools.
It's my understanding that while both of these options keep sending work to all available pools at all times, I don't think I've ever quite understood the practical differences between these two. If I'm looking to split my hashrate perfectly even across multiple stratum servers, which would be better? Does VarrDiff skew the results one way or the other?
February 22, 2013, 06:11:16 PM
Just switched to 2.10.5 and cgminer.exe crashes when it tries connecting to the pool I'm using. 2.10.4 works fine.
Almost certainly you upgraded something else between changing from 2.10.4 to 2.10.5 and that is what's crashing it. Usual suspect: driver+/-SDK change. Cgminer caches the binary created so if you try move the .bin files out of your 2.10.4, you can recreate your crash there too. 
February 22, 2013, 05:41:29 PM
Just switched to 2.10.5 and cgminer.exe crashes when it tries connecting to the pool I'm using. 2.10.4 works fine.
February 22, 2013, 04:43:06 PM
EDIT: I ran 'sudo cgminer -c /usr/local/etc/cgminer.conf', (sudo to get around dialout privledgess).
Try sudo adduser your_user_name dialout logout then back in.
February 22, 2013, 03:36:55 PM
Sorry I forgot to share a directory list of /dev/, my system does, in fact, have /dev/ttyUSB0 through /dev/ttyUSB7 listed correctly. I tried the modprobe command earlier and it didn't change anything (because my system already recognized them). Thanks for the suggestion!
February 22, 2013, 03:12:53 PM
I switched mining hosts and now I'm having a bit of a problem with my BFL singles. Only 1 shows up in cgminer ("BFL 0"), although they all show up in lsusb (I am using USB hubs, but never in "series"). I'm on 32bit ubuntu and I just cloned cgminer 2.10.5
Thank you for any help with my noobish question!
Code:
alan@alan-Vostro-1500:~$ lsusb
Bus 002 Device 003: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 002 Device 004: ID 05a9:2640 OmniVision Technologies, Inc. OV2640 Webcam
Bus 003 Device 002: ID 413c:8126 Dell Computer Corp. Wireless 355 Bluetooth
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 015: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 002 Device 007: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 002 Device 008: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 002 Device 009: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 002 Device 010: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 002 Device 011: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 002 Device 012: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 002 Device 013: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Have you tried this from the readme.txt?
Q: How do I get my BFL/Icarus/Lancelot/Cairnsmore device to auto-recognise?
A: On linux, if the /dev/ttyUSB* devices don't automatically appear, the only thing that needs to be done is to load the driver for them:
BFL: sudo modprobe ftdi_sio vendor=0x0403 product=0x6014
February 22, 2013, 02:16:30 PM
I switched mining hosts and now I'm having a bit of a problem with my BFL singles. Only 1 shows up in cgminer ("BFL 0"), although they all show up in lsusb (I am using USB hubs, but never in "series"). I'm on 32bit ubuntu and I just cloned cgminer 2.10.5
Thank you for any help with my noobish question!
EDIT: I ran 'sudo cgminer -c /usr/local/etc/cgminer.conf', (sudo to get around dialout privledgess). I will try it with -S /dev/ttyUSB0 -S /dev/ttyUSB1 etc when I get home from work.
EDIT2: Including each device explicitly worked. Thanks for the help! cgminer -c /usr/local/etc/cgminer.conf -S /dev/ttyUSB0 -S /dev/ttyUSB1 -S /dev/ttyUSB2 -S /dev/ttyUSB3 -S /dev/ttyUSB4 -S /dev/ttyUSB5 -S /dev/ttyUSB6 -S /dev/ttyUSB7 -S /dev/ttyUSB8
EDIT3: Thanks for the dialout command, SAC!
Code:
alan@alan-Vostro-1500:~$ lsusb
Bus 002 Device 003: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 002 Device 004: ID 05a9:2640 OmniVision Technologies, Inc. OV2640 Webcam
Bus 003 Device 002: ID 413c:8126 Dell Computer Corp. Wireless 355 Bluetooth
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 015: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 002 Device 007: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 002 Device 008: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 002 Device 009: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 002 Device 010: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 002 Device 011: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 002 Device 012: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
Bus 002 Device 013: ID 0403:6014 Future Technology Devices International, Ltd FT232H Single HS USB-UART/FIFO IC
EDIT: I ran 'sudo cgminer -c /usr/local/etc/cgminer.conf', (sudo to get around dialout privledgess). I will try it with -S /dev/ttyUSB0 -S /dev/ttyUSB1 etc when I get home from work.
EDIT2: Including each device explicitly worked. Thanks for the help! cgminer -c /usr/local/etc/cgminer.conf -S /dev/ttyUSB0 -S /dev/ttyUSB1 -S /dev/ttyUSB2 -S /dev/ttyUSB3 -S /dev/ttyUSB4 -S /dev/ttyUSB5 -S /dev/ttyUSB6 -S /dev/ttyUSB7 -S /dev/ttyUSB8
EDIT3: Thanks for the dialout command, SAC!
February 22, 2013, 08:25:01 AM
Hello,
There might be potential Found block bug in cgminer 2.10.5. I had found about 5-10 blocks since i start mining. With old versions of cgminer (getwork) I was always able to see Found Blocks count > 0 from the cgminer api. Recently i Found a block and my pools says that is me who found it. But cgminer shows 0 under Found blocks menu. My question is follows: When mining with stratum and diff > 1 let say 8, is there any chance cgminer not to report to pool that block is found. In general what happens when we found a block, and our share matches to diff 1 which does not meet pool requirement for diff 4 for instance? Is there any chance found block to be wasted and never reported to the pool?
NoThere might be potential Found block bug in cgminer 2.10.5. I had found about 5-10 blocks since i start mining. With old versions of cgminer (getwork) I was always able to see Found Blocks count > 0 from the cgminer api. Recently i Found a block and my pools says that is me who found it. But cgminer shows 0 under Found blocks menu. My question is follows: When mining with stratum and diff > 1 let say 8, is there any chance cgminer not to report to pool that block is found. In general what happens when we found a block, and our share matches to diff 1 which does not meet pool requirement for diff 4 for instance? Is there any chance found block to be wasted and never reported to the pool?
10X!
But it is still misery for me why found blocks counts to zero when it should be 1?
For the record this share solved both NMC and BTC block:)
Anyway thank you for taking time to respond me Kon:)
February 22, 2013, 08:10:48 AM
Hello,
There might be potential Found block bug in cgminer 2.10.5. I had found about 5-10 blocks since i start mining. With old versions of cgminer (getwork) I was always able to see Found Blocks count > 0 from the cgminer api. Recently i Found a block and my pools says that is me who found it. But cgminer shows 0 under Found blocks menu. My question is follows: When mining with stratum and diff > 1 let say 8, is there any chance cgminer not to report to pool that block is found. In general what happens when we found a block, and our share matches to diff 1 which does not meet pool requirement for diff 4 for instance? Is there any chance found block to be wasted and never reported to the pool?
No There might be potential Found block bug in cgminer 2.10.5. I had found about 5-10 blocks since i start mining. With old versions of cgminer (getwork) I was always able to see Found Blocks count > 0 from the cgminer api. Recently i Found a block and my pools says that is me who found it. But cgminer shows 0 under Found blocks menu. My question is follows: When mining with stratum and diff > 1 let say 8, is there any chance cgminer not to report to pool that block is found. In general what happens when we found a block, and our share matches to diff 1 which does not meet pool requirement for diff 4 for instance? Is there any chance found block to be wasted and never reported to the pool?
February 22, 2013, 07:29:22 AM
Hello,
There might be potential Found block bug in cgminer 2.10.5. I had found about 5-10 blocks since i start mining. With old versions of cgminer (getwork) I was always able to see Found Blocks count > 0 from the cgminer api. Recently i Found a block and my pools says that is me who found it. But cgminer shows 0 under Found blocks menu. My question is follows: When mining with stratum and diff > 1 let say 8, is there any chance cgminer not to report to pool that block is found. In general what happens when we found a block, and our share matches to diff 1 which does not meet pool requirement for diff 4 for instance? Is there any chance found block to be wasted and never reported to the pool?
There might be potential Found block bug in cgminer 2.10.5. I had found about 5-10 blocks since i start mining. With old versions of cgminer (getwork) I was always able to see Found Blocks count > 0 from the cgminer api. Recently i Found a block and my pools says that is me who found it. But cgminer shows 0 under Found blocks menu. My question is follows: When mining with stratum and diff > 1 let say 8, is there any chance cgminer not to report to pool that block is found. In general what happens when we found a block, and our share matches to diff 1 which does not meet pool requirement for diff 4 for instance? Is there any chance found block to be wasted and never reported to the pool?
February 21, 2013, 05:42:38 PM
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.
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.
EDIT: Oh and I've made some minor updates to the scrypt kernel too...
February 21, 2013, 01:34:57 PM
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.
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.
February 21, 2013, 05:03:20 AM
I recently experience a problem with cgminer, when it should recreate it's .bin files, e.g. phatk121016Cypressv4w128l4.bin
debug version of cgminer says:
Trying to compile the new poclbm121016.cl .bin file would then result with this error:
This looks completely unrelated to the code and suggests some driver +/- SDK fuckage. I suggest trying a different driver, if you can. 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
February 21, 2013, 04:01:18 AM
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.
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.
February 20, 2013, 08:55:58 PM
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.
Thanks in advance for the tiny extra drops! They'll add up when BTC reaches parity with gold.
Scrypt is very low (read virtually non-existent) on my priority list. 
February 20, 2013, 02:52:31 PM
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.
Thanks in advance for the tiny extra drops! They'll add up when BTC reaches parity with gold.
Jump to: