OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[-ck]

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.

[1714062810]

1714062810

[1714062810]

1714062810

[1714062810]

1714062810

[jddebug]

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]

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]

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]

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.

[kano]

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.

[zefir]

...

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 ?

[nelisky]

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.

[dlasher]

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....

[-ck]

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.

[zefir]

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]

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.

[-ck]

By the way, your longpoll error message is pre 2.4.0
"longpoll failed for XXX, retrying every 30s"
is the current 2.4.0 message and should only appear once until it starts working again, so I'm not convinced you're running the latest git.

[zefir]

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.

Would it be too aggressive towards pools to request more work than you actually work on? My layman approach would be: I know I have e.g. 4GH power and will need new work once a second. As soon as work is given to a device, immediately ask primary pool for more (instead of waiting for a device to do so) and if that one does not respond within 600ms, ask backup pool(s). The cost for such an pro-active approach would be that you ask for more work than you can handle, but you would not have to wait that long to see some pool is dead.

As for my cgminer version: you're just too fast/active , it is from 24h ago and includes the pool scheduling improvements you added for 2.4.0. Can't catch up pulling with the speed of improvements you add.

[-ck]

Would it be too aggressive towards pools to request more work than you actually work on? My layman approach would be: I know I have e.g. 4GH power and will need new work once a second. As soon as work is given to a device, immediately ask primary pool for more (instead of waiting for a device to do so) and if that one does not respond within 600ms, ask backup pool(s). The cost for such an pro-active approach would be that you ask for more work than you can handle, but you would not have to wait that long to see some pool is dead.

As for my cgminer version: you're just too fast/active , it is from 24h ago and includes the pool scheduling improvements you added for 2.4.0. Can't catch up pulling with the speed of improvements you add.

Well, we already ask for work from backup pools when the primary pool can't keep up. But there's a difference between asking for extra work cause you can't keep your queue full, and running out entirely. As I said, the distinction needs to be made or you can't flag the primary pool as "officially fucked".

[BR0KK]

Hasng since yesterday thanks to nelski:
Quad Ztex ans Singles:

[-ck]

Hasng since yesterday thanks to nelski:
Quad Ztex ans Singles:

I take it this means his quad code is working? Nelisky, do you mind pushing a git pull for your updated code  ?

[nelisky]

Hasng since yesterday thanks to nelski:
Quad Ztex ans Singles:

I take it this means his quad code is working? Nelisky, do you mind pushing a git pull for your updated code  ?

Working? yes. Thoroughly tested? well...

Let me go through the code to check for any obvious blooper and I'll do the PR afterwards.

[leveer]

Can the "--no-pool-disable" option be set via the .conf file?

[-ck]

Can the "--no-pool-disable" option be set via the .conf file?

"no-pool-disable" : true,