Bitcoin Forum
August 14, 2018, 09:19:37 PM *
News: Latest stable version of Bitcoin Core: 0.16.2  [Torrent].
 
   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 ... 847 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.10.0  (Read 5760317 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.
zefir
Donator
Hero Member
*
Offline Offline

Activity: 919
Merit: 1000



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

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

1534281577
Hero Member
*
Offline Offline

Posts: 1534281577

View Profile Personal Message (Offline)

Ignore
1534281577
Reply with quote  #2

1534281577
Report to moderator
1534281577
Hero Member
*
Offline Offline

Posts: 1534281577

View Profile Personal Message (Offline)

Ignore
1534281577
Reply with quote  #2

1534281577
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1534281577
Hero Member
*
Offline Offline

Posts: 1534281577

View Profile Personal Message (Offline)

Ignore
1534281577
Reply with quote  #2

1534281577
Report to moderator
1534281577
Hero Member
*
Offline Offline

Posts: 1534281577

View Profile Personal Message (Offline)

Ignore
1534281577
Reply with quote  #2

1534281577
Report to moderator
nelisky
Legendary
*
Offline Offline

Activity: 1540
Merit: 1000


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

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: 466
Merit: 250



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

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: 2604
Merit: 1121


Ruu \o/


View Profile WWW
May 04, 2012, 10:15:10 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.
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.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
zefir
Donator
Hero Member
*
Offline Offline

Activity: 919
Merit: 1000



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

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: 2604
Merit: 1121


Ruu \o/


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

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.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
-ck
Moderator
Legendary
*
Offline Offline

Activity: 2604
Merit: 1121


Ruu \o/


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

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.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
zefir
Donator
Hero Member
*
Offline Offline

Activity: 919
Merit: 1000



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

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: 2604
Merit: 1121


Ruu \o/


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

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.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
BR0KK
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500



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

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

-ck
Moderator
Legendary
*
Offline Offline

Activity: 2604
Merit: 1121


Ruu \o/


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

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.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
nelisky
Legendary
*
Offline Offline

Activity: 1540
Merit: 1000


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

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
Merit: 0


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

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

Activity: 2604
Merit: 1121


Ruu \o/


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

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

Primary developer/maintainer for cgminer and ckpool/ckproxy.
ZERO FEE Pooled mining at ckpool.org 1% Fee Solo mining at solo.ckpool.org
-ck
zefir
Donator
Hero Member
*
Offline Offline

Activity: 919
Merit: 1000



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

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.

antirack
Hero Member
*****
Offline Offline

Activity: 486
Merit: 500


Immersionist


View Profile
May 04, 2012, 12:06:12 PM
 #5356

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.

I have compiled cgminer with ztex support and created the 'bitstreams' folder in the cgminer directory.

Do I have to specify the USB ports somehow? I get this:

Code:
[2012-05-04 20:04:25] Started cgminer 2.4.0
[2012-05-04 20:04:25] Ztex check device: Failed to open handle with error -12
[2012-05-04 20:04:25] prepare device: -12
[2012-05-04 20:04:25] Ztex check device: Failed to open handle with error -12
[2012-05-04 20:04:25] prepare device: -12
[2012-05-04 20:04:25] Ztex check device: Failed to open handle with error -12
[2012-05-04 20:04:25] prepare device: -12
[2012-05-04 20:04:25] Ztex check device: Failed to open handle with error -12
[2012-05-04 20:04:25] prepare device: -12
[2012-05-04 20:04:25] Ztex check device: Failed to open handle with error -12
[2012-05-04 20:04:25] prepare device: -12
[2012-05-04 20:04:25] Found 0 ztex board(s)
roomservice
Full Member
***
Offline Offline

Activity: 199
Merit: 100



View Profile
May 04, 2012, 12:38:53 PM
 #5357

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.

when i try to
ztex-120417 branch doesn't ./configure --enable-ztex

i got
WARNING: unrecognized options: --enable-ztex

Sad

"Tonight's the night. And it's going to happen again, and again. It has to happen. Nice night."
BR0KK
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500



View Profile
May 04, 2012, 12:57:16 PM
 #5358

I had that error too and i think it has sonething to do with the Driver u use for BTC miner.

Nelski installed a program called zdiaq (dont have the right name for that programm in my mind)
That changes the lib usb- to the win usb driver.

He can propably explaon better Wink

kano
Legendary
*
Offline Offline

Activity: 2534
Merit: 1046


Linux since 1997 RedHat 4


View Profile
May 04, 2012, 01:20:11 PM
 #5359

...
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 ?
That actually sounds like a good idea Tongue
Save the time, keep checking dmesg, then delay a few seconds and run cgminer
If it takes longer that some limit then you know it's failed and can do some manual interference

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
FreeNode IRC: irc.freenode.net channel #kano.is Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
Luke-Jr
Legendary
*
Offline Offline

Activity: 2408
Merit: 1001



View Profile
May 04, 2012, 01:34:55 PM
 #5360

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 ?
Code:
udevadm settle

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 ... 847 »
  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!