OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 581.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: zefir on May 04, 2012, 05:16:40 AM

I see that connection got lost to bonuspool initially at 06:41:35, but the switch to the backup poo happens almost 40s later with GPUs and BFLs idling in between. This happens continuously and causes total hash-rate to be 20% worse with bonuspool than e.g. ABCpool. I was assuming that the pool scheduling assures that there is always some work available, i.e. it is pre-fetched and ready when a device needs fresh work.

Is this a bug or a feature? If it's a bug, would a more verbose log help you to isolate the problem? (cgminer is latest GIT source, BTW).

No, you are correct. It needs to see that a pool has been unresponsive for a full minute before switching pools. The problem with resorting to backup work is that it can't tell that it has completely utterly run out of work until nothing is coming in at all for a demonstrable amount of time. If it keeps getting work from the backup pools, it can't really tell that the primary pool has failed. There is some crossover, but it has to detect that things have truly gone idle with nothing to do before saying "fuck this pool, it's dead".

edit: if a pool is that unreliable, you really have to consider whether it's worth mining there or not.

zefir

donator

Activity: 919

Merit: 1000

Con, as you read in Clipse's thread, there are still problems with cgminer operating at bonuspool.

I don't understand how the pool scheduling works, but reviewing my log-files I noticed some issue:

Code:

 [2012-05-04 06:41:01] Accepted f1074f52.368b967a GPU 1 pool 0
 [2012-05-04 06:41:03] Accepted 12a02d09.919f7d23 BFL 4 pool 0
 [2012-05-04 06:41:03] Accepted 2f0b703d.373c52da BFL 4 pool 0
 [2012-05-04 06:41:04] Accepted c8bbcb1b.9f5698c8 BFL 3 pool 0
 [2012-05-04 06:41:05] Accepted d1ce7a88.c0efb3e8 BFL 2 pool 0
 [2012-05-04 06:41:05] Accepted a3f37c21.19c0f185 BFL 2 pool 0
 [2012-05-04 06:41:12] Accepted 06eaeb30.7ef6d0ce GPU 1 pool 0
 [2012-05-04 06:41:13] Pool 0 not providing work fast enough
 [2012-05-04 06:41:17] Accepted 211ee32c.87354a4b BFL 1 pool 0
 [2012-05-04 06:41:23] Accepted 2d7c9db2.6a02fbbe GPU 2 pool 0
 [2012-05-04 06:41:23] Accepted e0f755c5.b8a15153 GPU 1 pool 0
 [2012-05-04 06:41:34] Accepted 11fd8e56.2c088465 GPU 2 pool 0
 [2012-05-04 06:41:35] Pool 0 communication failure, caching submissions
 [2012-05-04 06:41:35] longpoll failed for http://pool.bonuspool.co.cc:80/LP, sleeping for 30s
 [2012-05-04 06:41:37] Pool 0 not providing work fast enough
 [2012-05-04 06:42:08] longpoll failed for http://pool.bonuspool.co.cc:80/LP, sleeping for 30s
 [2012-05-04 06:42:14] Pool 0 http://pool.bonuspool.co.cc:80 not responding!
 [2012-05-04 06:42:14] Switching to http://pool.ABCPool.co:8332
 [2012-05-04 06:42:21] Accepted 4fb4ba89.279b420a BFL 0 pool 1
 [2012-05-04 06:42:24] Accepted 6d6d108d.e73b79f4 GPU 1 pool 1
 [2012-05-04 06:42:24] Accepted e026ffbd.83b870ee BFL 1 pool 1

I see that connection got lost to bonuspool initially at 06:41:35, but the switch to the backup poo happens almost 40s later with GPUs and BFLs idling in between. This happens continuously and causes total hash-rate to be 20% worse with bonuspool than e.g. ABCpool. I was assuming that the pool scheduling assures that there is always some work available, i.e. it is pre-fetched and ready when a device needs fresh work.

Is this a bug or a feature? If it's a bug, would a more verbose log help you to isolate the problem? (cgminer is latest GIT source, BTW).

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: -ck on May 03, 2012, 10:45:42 PM

Quote from: jddebug on May 03, 2012, 10:33:58 PM

Thoughts: Never ditch the main pool completely.

Have it check if its alive again in 5 or even 10 minutes but if its set as main pool I would never want to ditch it entirely. I missed out on hours of public work at gpumax this morning. If I hadn't taken a look, quit cgminer and restarted it, I would have been on my secondary pool forever it seems. I think I understand the reasoning but at least have it check back occasionally to see if problems have been fixed.

I'll think about it but that would require quite a bit of extra code to deal with a temporarily disabled state. I guess it could stay disabled after just one reject on re-testing. This would mean you'd need to intermittently dedicate some potentially lost work from a pool that has already started misbehaving. From what I've seen, once a pool starts doing this, there is something horribly wrong with it and requires pool op intervention.

Updated the git tree for this issue:
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.

Basically this means a pool disabled for rejecting lots of shares in a row will be tested on each longpoll to see if it's started accepting shares again.

dlasher

sr. member

Activity: 467

Merit: 250

Quote from: xzion on May 03, 2012, 09:34:42 AM

the shit you go through for this software, man, i don't know how you do it.
have a couple more btc for your troubles.

^^^ What he said....

nelisky

legendary

Activity: 1540

Merit: 1002

I have a test branch with cgminer support for ZTEX 1.15y quad boards. Anyone willing to give it a try please grab the source at https://github.com/nelisky/cgminer/tree/ztex-120417

If you are unable to compile it yourself I might be able to provide binaries on some platforms.

zefir

donator

Activity: 919

Merit: 1000

Quote from: kano on May 04, 2012, 01:46:23 AM

...

Code:

sudo modprobe ftdi_sio vendor=0x0403 product=0x6014

Sh*t, spent half a day finding that out last week and didn't post (thought its my messed up Ubuntu 11.04 installation and didn't want to spam the thread). I appended

Code:

ftdi_sio vendor=0x0403 product=0x6014

to /etc/modules to be handled correctly at module loading time.

Now that you have some FPGA boards to play, you maybe came along the problem that they are not detected after a reboot when cgminer is executed from the autostart section. Every now and then I see that only some of the attached 5 BFLs are running after a machine restart, but work all when I manually restart cgminer. I guessed the USB initialization is not fully done yet when cgminer is started and added some additional delay of 30s before it is executed - but still some Singles are missing.

Is there some event that all USB initializations have been processed in Linux to check before cgminer is started? Other than grep-ing dmesg for ttyUSBx ?

kano

legendary

Activity: 4634

Merit: 1851

Linux since 1997 RedHat 4

OK after that post disappeared and also now my reply ...

Anyone who may have had trouble with BFL on Xubuntu 11.04?
Thanks to luke for supplying the solution to this.
When the BFL is plugged in:

Code:

sudo modprobe ftdi_sio vendor=0x0403 product=0x6014

Yeah apparently the problem is that the last 11.04 kernel (2.6.38-8) is only just after ftdi was added.

Note, of course, with Icarus it does just work under 11.04 so this now means you can GPU/ICA/BFL all at the same time.

Pretty much anything from 11.10 onwards should work.
I should add that to my USB install script ...

Also, anyone running the new 2.4.0 on Icarus will probably see an excessively high MH/s value

Around 480?
I've put in a pull request to fix that earlier today.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: jddebug on May 03, 2012, 10:33:58 PM

Thoughts: Never ditch the main pool completely.

Have it check if its alive again in 5 or even 10 minutes but if its set as main pool I would never want to ditch it entirely. I missed out on hours of public work at gpumax this morning. If I hadn't taken a look, quit cgminer and restarted it, I would have been on my secondary pool forever it seems. I think I understand the reasoning but at least have it check back occasionally to see if problems have been fixed.

I'll think about it but that would require quite a bit of extra code to deal with a temporarily disabled state. I guess it could stay disabled after just one reject on re-testing. This would mean you'd need to intermittently dedicate some potentially lost work from a pool that has already started misbehaving. From what I've seen, once a pool starts doing this, there is something horribly wrong with it and requires pool op intervention.

jddebug

sr. member

Activity: 446

Merit: 250

Quote from: -ck on May 03, 2012, 10:19:32 PM

Quote from: jddebug on May 03, 2012, 10:15:57 PM

Quote from: -ck on May 03, 2012, 09:49:57 PM

Quote from: DutchBrat on May 03, 2012, 04:24:12 PM

Quote from: -ck on May 03, 2012, 03:58:33 PM

Presumably that's the code that disables a pool if you get many sequential rejects in a row, suggesting something is wrong with the pool rather than at your end. You must have at least 10 shares rejected in a row and it must be more than your hashrate per minute and they must be sequential and all from the same pool for this to happen. So something bad must have happened for it to have shut it off. Note there is a -
--no-pool-disable Do not automatically disable pools that continually reject shares

Ah thanks, that explains it !

Indeed, and it may well be a perfect example of why I put it there since something funky happened there. At a utility of 4 on your machine, this would only have happened if the pool rejected every share submitted for a full 2.5 minutes in a row.

That would have been GPUMAX for me and it happened twice once with one rig and again with another. I think the terminal said something about 17 seconds or 17 rejects or something like that.

Right, it has to be at least one minute, so presumably your machine has a utility of about 17 hashes per minute. I could make it more lax, but greater than or equal to one minute of continuous rejects is not normal behaviour for a pool. At most for up to 10 seconds after a longpoll, worst case scenario. Perhaps in the next version I'll make it 5 minutes. Thoughts?

Thoughts: Never ditch the main pool completely.

Have it check if its alive again in 5 or even 10 minutes but if its set as main pool I would never want to ditch it entirely. I missed out on hours of public work at gpumax this morning. If I hadn't taken a look, quit cgminer and restarted it, I would have been on my secondary pool forever it seems. I think I understand the reasoning but at least have it check back occasionally to see if problems have been fixed.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: jddebug on May 03, 2012, 10:15:57 PM

Quote from: -ck on May 03, 2012, 09:49:57 PM

Quote from: DutchBrat on May 03, 2012, 04:24:12 PM

Quote from: -ck on May 03, 2012, 03:58:33 PM

Presumably that's the code that disables a pool if you get many sequential rejects in a row, suggesting something is wrong with the pool rather than at your end. You must have at least 10 shares rejected in a row and it must be more than your hashrate per minute and they must be sequential and all from the same pool for this to happen. So something bad must have happened for it to have shut it off. Note there is a -
--no-pool-disable Do not automatically disable pools that continually reject shares

Ah thanks, that explains it !

Indeed, and it may well be a perfect example of why I put it there since something funky happened there. At a utility of 4 on your machine, this would only have happened if the pool rejected every share submitted for a full 2.5 minutes in a row.

That would have been GPUMAX for me and it happened twice once with one rig and again with another. I think the terminal said something about 17 seconds or 17 rejects or something like that.

Right, it has to be at least one minute, so presumably your machine has a utility of about 17 hashes per minute. I could make it more lax, but greater than or equal to one minute of continuous rejects is not normal behaviour for a pool. At most for up to 10 seconds after a longpoll, worst case scenario. Perhaps in the next version I'll make it 5 minutes. Thoughts?

jddebug

sr. member

Activity: 446

Merit: 250

Quote from: -ck on May 03, 2012, 09:49:57 PM

Quote from: DutchBrat on May 03, 2012, 04:24:12 PM

Quote from: -ck on May 03, 2012, 03:58:33 PM

Presumably that's the code that disables a pool if you get many sequential rejects in a row, suggesting something is wrong with the pool rather than at your end. You must have at least 10 shares rejected in a row and it must be more than your hashrate per minute and they must be sequential and all from the same pool for this to happen. So something bad must have happened for it to have shut it off. Note there is a -
--no-pool-disable Do not automatically disable pools that continually reject shares

Ah thanks, that explains it !

Indeed, and it may well be a perfect example of why I put it there since something funky happened there. At a utility of 4 on your machine, this would only have happened if the pool rejected every share submitted for a full 2.5 minutes in a row.

That would have been GPUMAX for me and it happened twice once with one rig and again with another. I think the terminal said something about 17 seconds or 17 rejects or something like that.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: DutchBrat on May 03, 2012, 04:24:12 PM

Quote from: -ck on May 03, 2012, 03:58:33 PM

Presumably that's the code that disables a pool if you get many sequential rejects in a row, suggesting something is wrong with the pool rather than at your end. You must have at least 10 shares rejected in a row and it must be more than your hashrate per minute and they must be sequential and all from the same pool for this to happen. So something bad must have happened for it to have shut it off. Note there is a -
--no-pool-disable Do not automatically disable pools that continually reject shares

Ah thanks, that explains it !

Indeed, and it may well be a perfect example of why I put it there since something funky happened there. At a utility of 4 on your machine, this would only have happened if the pool rejected every share submitted for a full 2.5 minutes in a row.

DutchBrat

hero member

Activity: 868

Merit: 1000

Quote from: -ck on May 03, 2012, 03:58:33 PM

Quote from: DutchBrat on May 03, 2012, 01:42:07 PM

Just happened to another one of my rigs

My main pool shows as disabled, mining on my 1st backup pool, while the other rigs mine happily on my main pool

So second time today with 2 different rigs

Code:

 cgminer version 2.4.0 - Started: [2012-05-03 10:31:14]
--------------------------------------------------------------------------------
 (5s):312.0 (avg):302.1 Mh/s | Q:4804  A:2429  R:149  HW:0  E:51%  U:4.0/m
 TQ: 1  ST: 3  SS: 50  DW: 1276  NB: 77  LW: 5384  GF: 26  RF: 26
 Connected to http://pool.ABCPool.co:8332 with LP as user XXXXXX
 Block: 000004aaff274ef6bfc969765f953f1a...  Started: [20:33:38]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  73.0C 2391RPM | 311.8/302.1Mh/s | A:2429 R:149 HW:0 U: 4.00/m I: 6
--------------------------------------------------------------------------------

0: Disabled Alive Priority 0: http://pool.bonuspool.co.cc:80  User:XXXX
1: Enabled Alive Priority 1: http://pool.ABCPool.co:8332  User:XXX
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

Any idea what's causing this CKolivas ?

Presumably that's the code that disables a pool if you get many sequential rejects in a row, suggesting something is wrong with the pool rather than at your end. You must have at least 10 shares rejected in a row and it must be more than your hashrate per minute and they must be sequential and all from the same pool for this to happen. So something bad must have happened for it to have shut it off. Note there is a -
--no-pool-disable Do not automatically disable pools that continually reject shares

Ah thanks, that explains it !

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: xzion on May 03, 2012, 09:34:42 AM

Quote from: -ck on May 03, 2012, 05:29:13 AM

Quote from: OpytZabilParol on May 03, 2012, 05:27:20 AM

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

Maybe, you should pay attention to the new drivers and optimize a new version of CGMINER

Wrong, you should downgrade your driver and read the FAQ.

the shit you go through for this software, man, i don't know how you do it.
have a couple more btc for your troubles.

Thanks a lot.

So far the fallout for a fairly substantial version upgrade hasn't been too bad.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: DutchBrat on May 03, 2012, 01:42:07 PM

Just happened to another one of my rigs

My main pool shows as disabled, mining on my 1st backup pool, while the other rigs mine happily on my main pool

So second time today with 2 different rigs

Code:

 cgminer version 2.4.0 - Started: [2012-05-03 10:31:14]
--------------------------------------------------------------------------------
 (5s):312.0 (avg):302.1 Mh/s | Q:4804  A:2429  R:149  HW:0  E:51%  U:4.0/m
 TQ: 1  ST: 3  SS: 50  DW: 1276  NB: 77  LW: 5384  GF: 26  RF: 26
 Connected to http://pool.ABCPool.co:8332 with LP as user XXXXXX
 Block: 000004aaff274ef6bfc969765f953f1a...  Started: [20:33:38]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  73.0C 2391RPM | 311.8/302.1Mh/s | A:2429 R:149 HW:0 U: 4.00/m I: 6
--------------------------------------------------------------------------------

0: Disabled Alive Priority 0: http://pool.bonuspool.co.cc:80  User:XXXX
1: Enabled Alive Priority 1: http://pool.ABCPool.co:8332  User:XXX
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

Any idea what's causing this CKolivas ?

Presumably that's the code that disables a pool if you get many sequential rejects in a row, suggesting something is wrong with the pool rather than at your end. You must have at least 10 shares rejected in a row and it must be more than your hashrate per minute and they must be sequential and all from the same pool for this to happen. So something bad must have happened for it to have shut it off. Note there is a -
--no-pool-disable Do not automatically disable pools that continually reject shares

MrTeal

legendary

Activity: 1274

Merit: 1004

Would it be possible to get an option to reset the stats (queued/accepted/stales and all that) without having to restart CGMiner?

DutchBrat

hero member

Activity: 868

Merit: 1000

Just happened to another one of my rigs

My main pool shows as disabled, mining on my 1st backup pool, while the other rigs mine happily on my main pool

So second time today with 2 different rigs

Code:

 cgminer version 2.4.0 - Started: [2012-05-03 10:31:14]
--------------------------------------------------------------------------------
 (5s):312.0 (avg):302.1 Mh/s | Q:4804  A:2429  R:149  HW:0  E:51%  U:4.0/m
 TQ: 1  ST: 3  SS: 50  DW: 1276  NB: 77  LW: 5384  GF: 26  RF: 26
 Connected to http://pool.ABCPool.co:8332 with LP as user XXXXXX
 Block: 000004aaff274ef6bfc969765f953f1a...  Started: [20:33:38]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  73.0C 2391RPM | 311.8/302.1Mh/s | A:2429 R:149 HW:0 U: 4.00/m I: 6
--------------------------------------------------------------------------------

0: Disabled Alive Priority 0: http://pool.bonuspool.co.cc:80  User:XXXX
1: Enabled Alive Priority 1: http://pool.ABCPool.co:8332  User:XXX
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

Any idea what's causing this CKolivas ?

Cobra

sr. member

Activity: 289

Merit: 250

Very happy with 2.4 here.

For the longest time I had stuck to using 2.1.2 on a Win7 rig with (2) 5970's at 830/300. with -I 9, -w 256, -k phatk making 380 Mh/sec per core. It seemed as soon as I would upgrade past that version with no other changes it would drop me down to 330 Mh/sec per core. At first I thought it was because intensity of first gpu was dynamic (main daily driver PC) but changing to 9 on that had no effect.

On 2.4 simply using Diablo kernel instead I am up to 372/core which I am satisfied with. So many new changes since 2.1.2, if there are any holdouts out there I urge you to upgrade, it is worth it, you just may need to change kernels. On the old version BAMT would only see 1 of my cards via cgsnoop, that is now working properly and seeing both.

Time to donate again, 1BTC sent, keep up the great work.

af_newbie

legendary

Activity: 2702

Merit: 1468

Quote from: -ck on May 03, 2012, 06:59:24 AM

Quote from: af_newbie on May 03, 2012, 06:57:00 AM

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

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

Makes sense?

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

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

bulanula

hero member

Activity: 518

Merit: 500

Quote from: OpytZabilParol on May 03, 2012, 05:27:20 AM

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

Maybe, you should pay attention to the new drivers and optimize a new version of CGMINER

How the hell are you getting 460 MHash/s on a 5870 Shocked

?

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