Bitcoin Forum
December 09, 2016, 09:42:26 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 [268] 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4825285 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
jddebug
Sr. Member
****
Offline Offline

Activity: 424



View Profile
May 04, 2012, 03:15:57 AM
 #5341

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.
1481319746
Hero Member
*
Offline Offline

Posts: 1481319746

View Profile Personal Message (Offline)

Ignore
1481319746
Reply with quote  #2

1481319746
Report to moderator
1481319746
Hero Member
*
Offline Offline

Posts: 1481319746

View Profile Personal Message (Offline)

Ignore
1481319746
Reply with quote  #2

1481319746
Report to moderator
1481319746
Hero Member
*
Offline Offline

Posts: 1481319746

View Profile Personal Message (Offline)

Ignore
1481319746
Reply with quote  #2

1481319746
Report to moderator
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin-Qt, but full nodes are more resource-heavy, and they must do a lengthy initial syncing process. As a result, lightweight clients with somewhat less security are commonly used.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
May 04, 2012, 03:19:32 AM
 #5342

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?

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
jddebug
Sr. Member
****
Offline Offline

Activity: 424



View Profile
May 04, 2012, 03:33:58 AM
 #5343

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
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
May 04, 2012, 03:45:42 AM
 #5344

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
kano
Legendary
*
Online Online

Activity: 1932


Linux since 1997 RedHat 4


View Profile
May 04, 2012, 06:46:23 AM
 #5345

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 Smiley
Around 480?
I've put in a pull request to fix that earlier today.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
May 04, 2012, 07:55:04 AM
 #5346

...
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
Legendary
*
Offline Offline

Activity: 1554


View Profile
May 04, 2012, 08:12:50 AM
 #5347

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
Sr. Member
****
Offline Offline

Activity: 468



View Profile WWW
May 04, 2012, 08:40:52 AM
 #5348

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
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
May 04, 2012, 10:15:10 AM
 #5349

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
May 04, 2012, 10:16:40 AM
 #5350

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
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
May 04, 2012, 10:19:09 AM
 #5351

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
May 04, 2012, 10:23:35 AM
 #5352

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
May 04, 2012, 11:02:05 AM
 #5353

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 Wink, 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
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
May 04, 2012, 11:19:42 AM
 #5354

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 Wink, 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".

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
BR0KK
Hero Member
*****
Offline Offline

Activity: 742



View Profile
May 04, 2012, 11:24:42 AM
 #5355

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

-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
May 04, 2012, 11:31:29 AM
 #5356

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  Smiley ?

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
nelisky
Legendary
*
Offline Offline

Activity: 1554


View Profile
May 04, 2012, 11:34:15 AM
 #5357

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  Smiley ?

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
Jr. Member
*
Offline Offline

Activity: 42


View Profile
May 04, 2012, 11:42:57 AM
 #5358

Can the "--no-pool-disable" option be set via the .conf file?
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2002


Ruu \o/


View Profile WWW
May 04, 2012, 11:44:19 AM
 #5359

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

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
zefir
Donator
Hero Member
*
Offline Offline

Activity: 917



View Profile
May 04, 2012, 11:59:22 AM
 #5360

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".
I see. But in the log I posted above there was obviously no attempt to get work from the secondary pool for 40s, even it was evident that main pool is inactive.

Anyhow, as you said, it's a pool issue and not up to cgminer to handle it. Thanks.

Pages: « 1 ... 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 [268] 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 ... 830 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!