Thanks ! & Thanks for all the new versions lately, Really appreciate all the effort you are making ! Makes life much easier !
(Sent some coins)
And I received them, much appreciated, thanks (Sent some coins)
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 578. (Read 5805728 times)
May 07, 2012, 05:58:06 AM
May 07, 2012, 05:54:12 AM
Thanks ! & Thanks for all the new versions lately, Really appreciate all the effort you are making ! Makes life much easier !
(Sent some coins)
(Sent some coins)
May 07, 2012, 05:46:51 AM
Hi Ckolivas,
I'm running 2.4.1. on all my miners, all have the same primary pool, all without (--no-pool-disable) as that is no longer necessary if I understand correctly
One of the miners keeps my primary pool (Clipse) as rejecting even as the others are mining on his pool
I am sure LPs from the Bonuspool are working again, so I don't see why it should act like this
Thanks,
Brat
It has to actually *accept* a share from the work generated from a longpoll which only happens once every 10 minutes on average, and you may not actually get a share if you're unlucky, especially with only one device. Unfortunately the code is also only tested in artificial situations, so I can't say with 100% certainty it will work in all situations either. In this scenario, it appears not to have. I'm running 2.4.1. on all my miners, all have the same primary pool, all without (--no-pool-disable) as that is no longer necessary if I understand correctly
One of the miners keeps my primary pool (Clipse) as rejecting even as the others are mining on his pool
Code:
cgminer version 2.4.1 - Started: [2012-05-06 16:00:06]
--------------------------------------------------------------------------------
(5s):406.3 (avg):323.6 Mh/s | Q:10820 A:5465 R:123 HW:0 E:51% U:4.5/m
TQ: 1 ST: 4 SS: 11 DW: 1425 NB: 139 LW: 8011 GF: 9 RF: 18
Connected to http://pool.ABCPool.co:8332 with LP as user XXXXX
Block: 000005d5bcd29c2c9a7c10e7c64c7ea1... Started: [12:20:52]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 76.5C 3462RPM | 324.9/323.6Mh/s | A:5465 R:123 HW:0 U:4.47/m I: 5
--------------------------------------------------------------------------------
0: Rejecting Alive Priority 0: http://pool.bonuspool.co.cc:80 User:XXXX
1: Enabled Alive Priority 1: http://pool.ABCPool.co:8332 User:XXXXX
2: Enabled Alive Priority 2: http://pit.deepbit.net:8332 User:XXXX
3: Enabled Alive Priority 3: http://mine2.btcguild.com:8332 User:XXXXX
Current pool management strategy: Failover
[A]dd pool [R]emove pool [D]isable pool [E]nable pool
[C]hange management strategy [S]witch pool [I]nformation
Or press any other key to continue
I am sure LPs from the Bonuspool are working again, so I don't see why it should act like this
Thanks,
Brat
May 07, 2012, 05:27:49 AM
Hi Ckolivas,
I'm running 2.4.1. on all my miners, all have the same primary pool, all without (--no-pool-disable) as that is no longer necessary if I understand correctly
One of the miners keeps my primary pool (Clipse) as rejecting even as the others are mining on his pool
I am sure LPs from the Bonuspool are working again, so I don't see why it should act like this
Thanks,
Brat
I'm running 2.4.1. on all my miners, all have the same primary pool, all without (--no-pool-disable) as that is no longer necessary if I understand correctly
One of the miners keeps my primary pool (Clipse) as rejecting even as the others are mining on his pool
Code:
cgminer version 2.4.1 - Started: [2012-05-06 16:00:06]
--------------------------------------------------------------------------------
(5s):406.3 (avg):323.6 Mh/s | Q:10820 A:5465 R:123 HW:0 E:51% U:4.5/m
TQ: 1 ST: 4 SS: 11 DW: 1425 NB: 139 LW: 8011 GF: 9 RF: 18
Connected to http://pool.ABCPool.co:8332 with LP as user XXXXX
Block: 000005d5bcd29c2c9a7c10e7c64c7ea1... Started: [12:20:52]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 76.5C 3462RPM | 324.9/323.6Mh/s | A:5465 R:123 HW:0 U:4.47/m I: 5
--------------------------------------------------------------------------------
0: Rejecting Alive Priority 0: http://pool.bonuspool.co.cc:80 User:XXXX
1: Enabled Alive Priority 1: http://pool.ABCPool.co:8332 User:XXXXX
2: Enabled Alive Priority 2: http://pit.deepbit.net:8332 User:XXXX
3: Enabled Alive Priority 3: http://mine2.btcguild.com:8332 User:XXXXX
Current pool management strategy: Failover
[A]dd pool [R]emove pool [D]isable pool [E]nable pool
[C]hange management strategy [S]witch pool [I]nformation
Or press any other key to continue
I am sure LPs from the Bonuspool are working again, so I don't see why it should act like this
Thanks,
Brat
May 07, 2012, 05:01:40 AM
That double "," in there doesn't look too good ...
May 07, 2012, 03:37:35 AM
For some reason 2.4.0 and 2.4.1 will not properly save the configuration file for me. On restart after saving and having everything working I get this.
This isn't a tragedy per se but it makes it very hard to restart to try to reset my averages or change placement. I suppose I could start putting everything in the batch file assuming I can specify 2 pools. The Bitforce single was detected every time. My configuration file is as follows from this last start.
I am confused by the kernel-path line as I used the executable for windows and run Windows 7 64 bit. That line should be for linux I am unsure on Unix possibly in it as well. I know that removing that line does not make it load but my pre 2.4 version did not list it in the configuration file that I remember. Should I change that to somewhere else?
Thanks for the help.
Code:
[2012-05-07 02:24:42] Started cgminer 2.4.1
[2012-05-07 02:24:42] Started cgminer 2.4.1
[2012-05-07 02:24:42] Loaded configuration file cgminer.conf
[2012-05-07 02:24:42] Fatal JSON error in configuration file.
[2012-05-07 02:24:42] Configuration file could not be used.
[2012-05-07 02:24:42] Icarus Detect: Failed to open bitforce:COM3
[2012-05-07 02:24:43] Found 0 ztex board(s)
[2012-05-07 02:24:43] Need to specify at least one pool server.
Input server details.
URL:
This isn't a tragedy per se but it makes it very hard to restart to try to reset my averages or change placement. I suppose I could start putting everything in the batch file assuming I can specify 2 pools. The Bitforce single was detected every time. My configuration file is as follows from this last start.
Code:
{
"pools" : [
{
"url" : "http://pool.bitclockers.com:8332",
"user" : "UserName",
"pass" : "Password"
},
{
"url" : "http://localhost:8331",
"user" : "XXX",
"pass" : "xxx"
}
],
,
"api-port" : "4028",
"disable-gpu" : true,
"expiry" : "120",
"gpu-dyninterval" : "7",
"gpu-platform" : "0",
"gpu-threads" : "2",
"log" : "5",
"net-delay" : true,
"queue" : "2",
"retry-pause" : "5",
"scan-time" : "60",
"temp-hysteresis" : "3",
"shares" : "0",
"load-balance" : true,
"kernel-path" : "/usr/local/bin"
Thanks for the help.
May 06, 2012, 09:03:46 PM
No in fact that is totally unexpected, though I don't have 14GH in one machine to kick around so I'm not sure how much ram that would require. Unless you have some kind of low limit on number of threads, pid_max, some ulimit set, some cgroup limitation or otherwise, I've tried hard so far to keep resource usage low on cgminer.
It's actually a stock BAMT install.. I haven't dug into the configuration of BAMT itself, I had assumed it was stock Debian limits as far as system variables go.
cat /proc/sys/kernel/pid_max
cat /proc/sys/kernel/threads-max
cat /proc/sys/vm/max_map_count
ulimit
Limits all look normal to me.. thread_max is low, but shouldn't have caused a problem:
root@bfl-1:~# cat /proc/sys/kernel/pid_max
32768
root@bfl-1:~# cat /proc/sys/kernel/threads-max
28097
root@bfl-1:~# cat /proc/sys/vm/max_map_count
65530
root@bfl-1:~# ulimit
unlimited
May 06, 2012, 05:34:08 PM
You deserve more but, is what I have now... Thank you ckolivas!!
$ bitcoind sendtoaddress 148KkS2vgVi4VzUi4JcKzM2PMaMVPi3nnq 2.0
85063f3ec9d5a0836cfd7dedeff0c283f6c27c2c532593e4794dfb076f4b3b20
Best!
Thiago
Thank you kind sir! $ bitcoind sendtoaddress 148KkS2vgVi4VzUi4JcKzM2PMaMVPi3nnq 2.0
85063f3ec9d5a0836cfd7dedeff0c283f6c27c2c532593e4794dfb076f4b3b20
Best!
Thiago
May 06, 2012, 05:21:48 PM
May 06, 2012, 02:43:17 PM
Forgive my ignorance please, but wasn't the last version 3.6?
The last version was 2.4.0 and before that was 2.3.6.
Sam
May 06, 2012, 01:26:51 PM
Forgive my ignorance please, but wasn't the last version 3.6?
May 06, 2012, 06:07:45 AM
NEW VERSION - 2.4.1, MAY 6 2012
Human readable changelog:
--benchmark won't crash
A pool will only be disabled if it rejects shares for at least 3 minutes in a row. Then it will be checked every longpoll to see if it is accepting shares, and if so, will be re-enabled.
Should work when Icarus is combined with BFL
More accurate hashrate on Icarus
Ztex quad 1.15y support
Extra device stats in RPC API
Full changelog
- In the unlikely event of finding a block, display the block solved count with
the pool it came from for auditing.
- Display the device summary on exit even if a device has been disabled.
- Use correct pool enabled enums in api.c.
- Import Debian packaging configs
- Ensure we test for a pool recovering from idle so long as it's not set to
disabled.
- Fix pool number display.
- Give cgminer -T message only if curses is in use.
- Reinit_adl is no longer used.
- API 'stats' allow devices to add their own stats also for testing/debug
- API add getwork stats to cgminer - accesible from API 'stats'
- Don't initialise variables to zero when in global scope since they're already
initialised.
- Get rid of unitialised variable warning when it's false.
- Move a pool to POOL_REJECTING to be disabled only after 3 minutes of
continuous rejected shares.
- Some tweaks to reporting and logging.
- Change FPGA detection order since BFL hangs on an ICA
- API support new pool status
- Add a temporarily disabled state for enabled pools called POOL_REJECTING and
use the work from each longpoll to help determine when a rejecting pool has
started working again. Switch pools based on the multipool strategy once a pool
is re-enabled.
- Removing extra debug
- Fix the benchmark feature by bypassing the new networking code.
- Reset sequential reject counter after a pool is disabled for when it is
re-enabled.
- Icarus - correct MH/s and U: with work restart set at 8 seconds
- ztex updateFreq was always reporting on fpga 0
- Trying harder to get 1.15y working
- Specifying threads on multi fpga boards extra cgpu
- Missing the add cgpu per extra fpga on 1.15y boards
- API add last share time to each pool
- Don't try to reap curls if benchmarking is enabled.
Human readable changelog:
--benchmark won't crash
A pool will only be disabled if it rejects shares for at least 3 minutes in a row. Then it will be checked every longpoll to see if it is accepting shares, and if so, will be re-enabled.
Should work when Icarus is combined with BFL
More accurate hashrate on Icarus
Ztex quad 1.15y support
Extra device stats in RPC API
Full changelog
- In the unlikely event of finding a block, display the block solved count with
the pool it came from for auditing.
- Display the device summary on exit even if a device has been disabled.
- Use correct pool enabled enums in api.c.
- Import Debian packaging configs
- Ensure we test for a pool recovering from idle so long as it's not set to
disabled.
- Fix pool number display.
- Give cgminer -T message only if curses is in use.
- Reinit_adl is no longer used.
- API 'stats' allow devices to add their own stats also for testing/debug
- API add getwork stats to cgminer - accesible from API 'stats'
- Don't initialise variables to zero when in global scope since they're already
initialised.
- Get rid of unitialised variable warning when it's false.
- Move a pool to POOL_REJECTING to be disabled only after 3 minutes of
continuous rejected shares.
- Some tweaks to reporting and logging.
- Change FPGA detection order since BFL hangs on an ICA
- API support new pool status
- Add a temporarily disabled state for enabled pools called POOL_REJECTING and
use the work from each longpoll to help determine when a rejecting pool has
started working again. Switch pools based on the multipool strategy once a pool
is re-enabled.
- Removing extra debug
- Fix the benchmark feature by bypassing the new networking code.
- Reset sequential reject counter after a pool is disabled for when it is
re-enabled.
- Icarus - correct MH/s and U: with work restart set at 8 seconds
- ztex updateFreq was always reporting on fpga 0
- Trying harder to get 1.15y working
- Specifying threads on multi fpga boards extra cgpu
- Missing the add cgpu per extra fpga on 1.15y boards
- API add last share time to each pool
- Don't try to reap curls if benchmarking is enabled.
May 05, 2012, 11:45:12 PM
No in fact that is totally unexpected, though I don't have 14GH in one machine to kick around so I'm not sure how much ram that would require. Unless you have some kind of low limit on number of threads, pid_max, some ulimit set, some cgroup limitation or otherwise, I've tried hard so far to keep resource usage low on cgminer.
It's actually a stock BAMT install.. I haven't dug into the configuration of BAMT itself, I had assumed it was stock Debian limits as far as system variables go.
cat /proc/sys/kernel/pid_max
cat /proc/sys/kernel/threads-max
cat /proc/sys/vm/max_map_count
ulimit
Limits all look normal to me.. thread_max is low, but shouldn't have caused a problem:
root@bfl-1:~# cat /proc/sys/kernel/pid_max
32768
root@bfl-1:~# cat /proc/sys/kernel/threads-max
28097
root@bfl-1:~# cat /proc/sys/vm/max_map_count
65530
root@bfl-1:~# ulimit
unlimited
May 05, 2012, 11:01:29 PM
Is this deprecated then?
No, you can still load a config file from a different location; just make sure there isn't one in the default location if you do. That's what I do with my Dropbox folder.Code:
--config |-cLoad a configuration file
O.K.
Cheers
May 05, 2012, 08:34:56 PM
It's actually a stock BAMT install.. I haven't dug into the configuration of BAMT itself, I had assumed it was stock Debian limits as far as system variables go.
I have 14 singles and 2 5870s on one computer. This is a bamt install. Here is the results of free -m
Code:
total used free shared buffers cached
Mem: 2021 798 1223 0 93 414
-/+ buffers/cache: 291 1730
Swap: 0 0 0
May 05, 2012, 07:50:58 PM
It's actually a stock BAMT install.. I haven't dug into the configuration of BAMT itself, I had assumed it was stock Debian limits as far as system variables go.
I have 14 singles and 2 5870s on one computer. This is a bamt install. Here is the results of free -m
Code:
total used free shared buffers cached
Mem: 2021 798 1223 0 93 414
-/+ buffers/cache: 291 1730
Swap: 0 0 0
May 05, 2012, 07:44:21 PM
No in fact that is totally unexpected, though I don't have 14GH in one machine to kick around so I'm not sure how much ram that would require. Unless you have some kind of low limit on number of threads, pid_max, some ulimit set, some cgroup limitation or otherwise, I've tried hard so far to keep resource usage low on cgminer.
It's actually a stock BAMT install.. I haven't dug into the configuration of BAMT itself, I had assumed it was stock Debian limits as far as system variables go.
cat /proc/sys/kernel/pid_max
cat /proc/sys/kernel/threads-max
cat /proc/sys/vm/max_map_count
ulimit
May 05, 2012, 07:40:21 PM
CGminer keeps exiting with this error:
[2012-05-04 19:12:37] Failed to tq_push work in submit_work_sync
I have to restart it manually at this point.
Usually this would imply something drastically wrong like running out of resources to spawn a new thread such as out of memory or hitting some thread limit. Given that people have successfully run cgminer on openwrt routers, I can't really envision what sort of set up would hit those limits unless you had massive hashrates, lots of pools set up, and minimal memory on the machine.[2012-05-04 19:12:37] Failed to tq_push work in submit_work_sync
I have to restart it manually at this point.
edit: Certainly in older versions cgminer would spawn lots and lots of communication threads but that shouldn't be the case in 2.4.0+
It's version 2.4. 8 pools, hashrate of that machine is about 14 GH/s, it's got 2 gigs of RAM. Am I seriously coming up against a wall at only 14 GH/s? I had planned on adding another 20 - 30 GH/s to that machine.
It's actually a stock BAMT install.. I haven't dug into the configuration of BAMT itself, I had assumed it was stock Debian limits as far as system variables go.
May 05, 2012, 07:15:44 PM
Is this deprecated then?
No, you can still load a config file from a different location; just make sure there isn't one in the default location if you do. That's what I do with my Dropbox folder. Code:
--config |-cLoad a configuration file
May 05, 2012, 06:21:33 PM
It adds command line arguments after it has loaded the config file. So the config file was setting clock speed as you can see and your command line arguments were trying to set devices that don't exist.
Is this deprecated then?
Code:
--config |-cLoad a configuration file
Jump to: