Bitcoin Forum
November 20, 2018, 08:55:21 PM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
 
   Home   Help Search Login Register More  
Pages: « 1 ... 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 [351] 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 ... 846 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5766387 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.
kano
Legendary
*
Offline Offline

Activity: 2632
Merit: 1059


Linux since 1997 RedHat 4


View Profile
September 10, 2012, 03:55:54 AM
 #7001

CGMINER recommendation / request....Not sure were the correct place is so I will just chuck the idea out there.

Is it possible to set a "rescan" function within cgminer? e.g. set the miner rescan ports every 30min in an effort to restart mining hardware that has gone offline..

Typical scenario.
As someone with a day job, I am AFK at least 10 hours per day. I watch my mining rates via my pool and sigh when I note a miner has dropped off (CM1 not GPUs typically). I then call my wife, hoping she is home, so she can reset the mining operations by closing cgminer and firing it up again. BUT, if we had a rescan / restart "OFF" mining hardware, then a lot of heart ache could be avoided.


I am prepared to chuck some coins towards someone whom can do this or point out that function if it already exists.

If you use miner.php ... and give it access to the restart button ... then just press restart.
My address is in my sig Cheesy

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!
1542747321
Hero Member
*
Offline Offline

Posts: 1542747321

View Profile Personal Message (Offline)

Ignore
1542747321
Reply with quote  #2

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

Posts: 1542747321

View Profile Personal Message (Offline)

Ignore
1542747321
Reply with quote  #2

1542747321
Report to moderator
Cranky4u
Hero Member
*****
Offline Offline

Activity: 809
Merit: 1000



View Profile WWW
September 10, 2012, 04:17:57 AM
 #7002

CGMINER recommendation / request....Not sure were the correct place is so I will just chuck the idea out there.

Is it possible to set a "rescan" function within cgminer? e.g. set the miner rescan ports every 30min in an effort to restart mining hardware that has gone offline..

Typical scenario.
As someone with a day job, I am AFK at least 10 hours per day. I watch my mining rates via my pool and sigh when I note a miner has dropped off (CM1 not GPUs typically). I then call my wife, hoping she is home, so she can reset the mining operations by closing cgminer and firing it up again. BUT, if we had a rescan / restart "OFF" mining hardware, then a lot of heart ache could be avoided.


I am prepared to chuck some coins towards someone whom can do this or point out that function if it already exists.

If you use miner.php ... and give it access to the restart button ... then just press restart.
My address is in my sig Cheesy

it sounds so simple...but...they said that about getting a CM1 board stable as well.

I will DL from GITHUB tonight and have a go at getting it running...if all goes well...a fee for service will becoming your way  Smiley

kano
Legendary
*
Offline Offline

Activity: 2632
Merit: 1059


Linux since 1997 RedHat 4


View Profile
September 10, 2012, 05:03:03 AM
 #7003

...
If you use miner.php ... and give it access to the restart button ... then just press restart.
My address is in my sig Cheesy

it sounds so simple...but...they said that about getting a CM1 board stable as well.

I will DL from GITHUB tonight and have a go at getting it running...if all goes well...a fee for service will becoming your way  Smiley
I wrote miner.php (and the API and API-README)
The file API-README includes a lot of details at the end about how to use miner.php
Those 2 files are in every release of cgminer.
Of course the latest 2 on GIT would, however, be best if you don't have the latest cgminer.

Edit: if you have trouble setting it up, come visit FreeNode IRC #cgminer
ckolivas and I are also in Aus (like you) so similar timezone also
(though ckolivas is absent at the moment as he mentioned already)

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!
ocminer
Legendary
*
Online Online

Activity: 2268
Merit: 1227



View Profile WWW
September 10, 2012, 08:03:21 AM
 #7004

CGMiner 2.7.5 fails to build under mac osx 10.8 with installed macports if I run ./configure with --enable-ztex
because of libusb, even though it is installed:


checking libudev.h usability... no
checking libudev.h presence... no
checking for libudev.h... no
checking for libusb_init in -lusb-1.0... no
configure: error: Could not find usb library - please install libusb


#port list libusb
libusb                         @1.0.9          devel/libusb


It builds fine without --enable-ztex though..

Any thoughts ?

suprnova pools - reliable mining pools - #suprnova on freenet
https://www.suprnova.cc - FOLLOW us @ Twitter ! twitter.com/SuprnovaPools
kano
Legendary
*
Offline Offline

Activity: 2632
Merit: 1059


Linux since 1997 RedHat 4


View Profile
September 10, 2012, 09:44:16 AM
 #7005

libudev-dev ... ?

and ... fyi
Code:
root@erio:~# apt-cache policy libudev-dev libusb-dev
libusb-dev:
  Installed: 2:0.1.12-17
  Candidate: 2:0.1.12-17
  Version table:
 *** 2:0.1.12-17 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty/main amd64 Packages
        100 /var/lib/dpkg/status
libudev-dev:
  Installed: 167-0ubuntu3
  Candidate: 167-0ubuntu3
  Version table:
 *** 167-0ubuntu3 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty/main amd64 Packages
        100 /var/lib/dpkg/status
root@erio:~#

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!
ocminer
Legendary
*
Online Online

Activity: 2268
Merit: 1227



View Profile WWW
September 10, 2012, 10:11:28 AM
 #7006

hey kano,

I'm talking about mac os x Smiley

suprnova pools - reliable mining pools - #suprnova on freenet
https://www.suprnova.cc - FOLLOW us @ Twitter ! twitter.com/SuprnovaPools
kano
Legendary
*
Offline Offline

Activity: 2632
Merit: 1059


Linux since 1997 RedHat 4


View Profile
September 10, 2012, 11:39:21 AM
 #7007

hey kano,

I'm talking about mac os x Smiley
... and I'm showing you the version numbers on linux.

OSX is VERY similar to linux.
If you ssh into an OSX box it's almost the same.
(and a lot of the software running the non-gui side of OSX comes from linux)
OSX is just unix with a window manager to make it look like an old mac ...

The libusb version number may be the issue.
As you can see, on linux it's 0.1.12 ... not 1.x

Also, you are missing libudev-dev

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!
ocminer
Legendary
*
Online Online

Activity: 2268
Merit: 1227



View Profile WWW
September 10, 2012, 12:03:38 PM
 #7008

I tried an older version of libusb but having the same trouble..

also there is no libudev for mac os x (at least in the macports repositories..):

sudo port search libudev
No match for libudev found

I'll try to google it this evening, maybe there is something special with the mac port of libusb..

Everything works fine btw if i do not use "--enable-ztex"... ztex uses libusb exclusively it seems

suprnova pools - reliable mining pools - #suprnova on freenet
https://www.suprnova.cc - FOLLOW us @ Twitter ! twitter.com/SuprnovaPools
tacotime
Legendary
*
Offline Offline

Activity: 1484
Merit: 1000



View Profile
September 10, 2012, 03:17:02 PM
 #7009

A bug exists for scrypt mining algorithm in which thread concurrencies of above 8192 (required to get better performance on 79xx cards) fail, preventing the GPU from using most of its memory.  This results in a -25% performance hit for 79xx cards mining the scrypt algorithm.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
cmg5461
Sr. Member
****
Offline Offline

Activity: 374
Merit: 250



View Profile
September 11, 2012, 04:39:54 PM
 #7010

how often does it check if the main pool is back up?

Is there an option?

If I've helped: 1CmguJhwW4sbtSMFsyaafikJ8jhYS61quz

Sold: 5850 to lepenguin. Quick, easy and trustworthy.
slush
Legendary
*
Offline Offline

Activity: 1372
Merit: 1021



View Profile WWW
September 11, 2012, 09:14:08 PM
 #7011

Hello ckolivas,

any chance to add native support for Stratum mining protocol?

http://mining.bitcoin.cz/stratum-mining

There're already two pools supporting it (me and BtcGuild) and I expect that others will join us soon. I have also support from Python miners developers (poclbm and Guiminer) so we will add native support to their code. Unfortunately I'm not a C++ programmer, so I can give you only some consultations about the protocol itself but I cannot provide you any code.

The major improvement in all this stuff is that miner can produce unique coinbases locally, so creating block headers is done locally, without asking the server. Also the network layer is improved significantly, so you need only up to 10kB/minute of bandwidth even for 18ExaHash/s (10**18) rigs.

Basically you can just bundle mining proxy (pure python) which I provide together with cgminer and run it on the demand, but it is quite ugly solution and native support would be much better.

Let me know what you think about it!

P_Shep
Legendary
*
Offline Offline

Activity: 1190
Merit: 1000


View Profile
September 11, 2012, 09:34:49 PM
 #7012

Hello ckolivas,

any chance to add native support for Stratum mining protocol?

http://mining.bitcoin.cz/stratum-mining

There're already two pools supporting it (me and BtcGuild) and I expect that others will join us soon. I have also support from Python miners developers (poclbm and Guiminer) so we will add native support to their code. Unfortunately I'm not a C++ programmer, so I can give you only some consultations about the protocol itself but I cannot provide you any code.

The major improvement in all this stuff is that miner can produce unique coinbases locally, so creating block headers is done locally, without asking the server. Also the network layer is improved significantly, so you need only up to 10kB/minute of bandwidth even for 18ExaHash/s (10**18) rigs.

Basically you can just bundle mining proxy (pure python) which I provide together with cgminer and run it on the demand, but it is quite ugly solution and native support would be much better.

Let me know what you think about it!

And while you're at it, change the mining API to event-driven Smiley
slush
Legendary
*
Offline Offline

Activity: 1372
Merit: 1021



View Profile WWW
September 11, 2012, 10:45:30 PM
 #7013

And while you're at it, change the mining API to event-driven Smiley

What do you mean exactly?

eleuthria
Legendary
*
Offline Offline

Activity: 1750
Merit: 1002



View Profile
September 11, 2012, 11:10:03 PM
 #7014

Hello ckolivas,

any chance to add native support for Stratum mining protocol?

http://mining.bitcoin.cz/stratum-mining

There're already two pools supporting it (me and BtcGuild) and I expect that others will join us soon. I have also support from Python miners developers (poclbm and Guiminer) so we will add native support to their code. Unfortunately I'm not a C++ programmer, so I can give you only some consultations about the protocol itself but I cannot provide you any code.

The major improvement in all this stuff is that miner can produce unique coinbases locally, so creating block headers is done locally, without asking the server. Also the network layer is improved significantly, so you need only up to 10kB/minute of bandwidth even for 18ExaHash/s (10**18) rigs.

Basically you can just bundle mining proxy (pure python) which I provide together with cgminer and run it on the demand, but it is quite ugly solution and native support would be much better.

Let me know what you think about it!

Just to build on slush's request:  I previously sent you a PM about a new protocol months ago, and another one just the other day because my protocol proposal was posted.  I've withdrawn that proposal and have backed slush's because they accomplish the same task in the same way, just different markup.

Also, the 18 ExaHash/s number slush is posting isn't a limit of the protocol.  It can easily go beyond that with a simple change in initial handshake message.  18 EH/s not enough?  How about 4.2 billion 18 EH/s farms with only an extra 8 bytes per share submission?  That would be 75,600,000,000,000,000 TH/s (pretty sure I calculated that right).  Also known as future proof Smiley.

RIP BTC Guild, April 2011 - June 2015
P_Shep
Legendary
*
Offline Offline

Activity: 1190
Merit: 1000


View Profile
September 11, 2012, 11:17:47 PM
 #7015

And while you're at it, change the mining API to event-driven Smiley

What do you mean exactly?

At the moment, hashing works in a loop... start work -> wait for results -> get results - > go back to start. The mining thread issues work, then collects it.

Where as each mining device could be asychronous. The device gets work from the queue when its idle, submits it when it's done. The device calls the shots... calls the routine to get work, calls the routine to submit work.
gyverlb
Hero Member
*****
Offline Offline

Activity: 896
Merit: 1000



View Profile
September 11, 2012, 11:28:00 PM
 #7016

At the moment, hashing works in a loop... start work -> wait for results -> get results - > go back to start. The mining thread issues work, then collects it.

Where as each mining device could be asychronous. The device gets work from the queue when its idle, submits it when it's done. The device calls the shots... calls the routine to get work, calls the routine to submit work.
@ckolivas could better answer this, but I think that a thread per mining device is not such a bad thing: a benefit is that in case of a GPU crashing, if the driver goes nuts it often doesn't bring all cards down but only one GPU.
With an event-based system, a single process will access all devices : a blocked syscall would freeze the entire process.
Usually I prefer event-based systems for handling asynchronous tasks, but here threads might well be the better option.

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
slush
Legendary
*
Offline Offline

Activity: 1372
Merit: 1021



View Profile WWW
September 11, 2012, 11:31:21 PM
 #7017

At the moment, hashing works in a loop... start work -> wait for results -> get results - > go back to start. The mining thread issues work, then collects it.

Great. I expected that it is related to the protocol proposal. I was surprised because actually it *is* event driven :-)

Quote from: eleuthria
That would be 75,600,000,000,000,000 TH/s (pretty sure I calculated that right).  Also known as future proof Smiley.
Quote

:-)

kano
Legendary
*
Offline Offline

Activity: 2632
Merit: 1059


Linux since 1997 RedHat 4


View Profile
September 11, 2012, 11:55:16 PM
 #7018

Hello ckolivas,

any chance to add native support for Stratum mining protocol?

http://mining.bitcoin.cz/stratum-mining

There're already two pools supporting it (me and BtcGuild) and I expect that others will join us soon. I have also support from Python miners developers (poclbm and Guiminer) so we will add native support to their code. Unfortunately I'm not a C++ programmer, so I can give you only some consultations about the protocol itself but I cannot provide you any code.

The major improvement in all this stuff is that miner can produce unique coinbases locally, so creating block headers is done locally, without asking the server. Also the network layer is improved significantly, so you need only up to 10kB/minute of bandwidth even for 18ExaHash/s (10**18) rigs.

Basically you can just bundle mining proxy (pure python) which I provide together with cgminer and run it on the demand, but it is quite ugly solution and native support would be much better.

Let me know what you think about it!
Until ckolivas returns and gives his opinion, which may be completely different to mine ...
As an aside ... I will repeat comments I've made (here and elsewhere) about this generic idea, and add to them:

Since the miner in now doing all the work except counting shares, if I were to implement such a protocol I would include a miner option to specify a fee in the coinbase to be paid directly to the miner - and probably also a donation option to the miner devs too - since the miner is now doing all the work of the pool other than counting shares.

This moves the miner into being a partial bitcoind that must fully process transactions, block changes, orphan blocks, orphan transactions, generate merkle trees and decide about transaction worthyness to be included in blocks and the risks involved with that also.

I'm certainly not saying yes or no about implementing getmemorypool (which is where your idea actually comes from) however, noting the implications of it, I've wondered if anyone has considered them in detail (I've also had a quick click on the web link and the very first item has an issue in my opinion - the pool deciding when the miner should be given work ...)

I will also make comment on performance:
There are a bunch on simple improvements to the getwork protocol that could easily extend the life of the current protocol.
Simplest one would be reference information so that a share returned only requires 3 things: reference, nonce, time
and the getwork would only need to send: reference, version, prevblk, merkle, time, diff
There is a LOT of blank space in the getwork data - so comparing sizes is rather meaningless unless the blanks were removed ...
LP sux due to it's design (was Tycho drunk that night he designed it?) - and there are other options already available.

The roll-n-time hack only exists coz the bitcoin devs are wimps and can't do a hard fork (since they can't even smoothly do a soft fork) and fix the MSDOS restriction of the nonce size.
A nonce size increase would mean that the timing of when the miner would talk to the pool (or the local "Stratum" program) would only be at a frequency decided necessary to include new transactions or maybe also via notification due to a large fee transaction.
The simple problem is that with any such protocol using the current nonce size, the miner MUST talk to the work source (be it part of the same program, a local "Stratum" program, or a pool) every ~4billion hashes - which is not a big number when the miner could EASILY have multiple TerraHash/second - i.e. plug in a few if BFL's so called soon to come 1TH/s devices
I seriously don't understand why anyone coming up with these similar 'Stratum' ideas doesn't spot the obvious problem there, that is directly caused by the nonce size.
Moving to using an extra-nonce in the coinbase transaction is again only needed since the block header nonce is too small - yet there is PLENTY of space to increase it's size in the sha256 empty space ... to 128 bits without any issue.
The miner would never run out of work, before it needs to consider a work change, with a 128bit nonce (well maybe not for a few years at least Smiley
Using the 'extra-nonce' idea also means that the mining software is spending a LOT of unnecessary effort talking to the work source (and the work source is doing way more work than necessary) that a larger nonce size would remove.

Just to put that into context:
a 1TH/s device can of course hash 1,000,000,000,000 hashes a second.
However, since the nonce size is 2^32, that means it will need to interact with the work source 232.8 times a second (without using roll-n-time)

Does anyone not one see that ANY change is a VERY short term solution ignoring fixing the size of the internal nonce?

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!
eleuthria
Legendary
*
Offline Offline

Activity: 1750
Merit: 1002



View Profile
September 12, 2012, 12:02:59 AM
 #7019

Since the miner in now doing all the work except counting shares, if I were to implement such a protocol I would include a miner option to specify a fee in the coinbase to be paid directly to the miner - and probably also a donation option to the miner devs too - since the miner is now doing all the work of the pool other than counting shares.

This moves the miner into being a partial bitcoind that must fully process transactions, block changes, orphan blocks, orphan transactions, generate merkle trees and decide about transaction worthyness to be included in blocks and the risks involved with that also.

I don't think you understand the protocol entirely.  The pool is still doing ALL of the bitcoind work.  It is creating the merkle branch list (picking the transactions and building the block essentially).  All it's doing is allowing the miner to adjust a piece of the coinbase transaction, which creates a new merkleroot, thus allowing it to continue hashing without interacting with the pool server once it runs out of nonce space or ntime rolling.


Just to put that into context:
a 1TH/s device can of course hash 1,000,000,000,000 hashes a second.
However, since the nonce size is 2^32, that means it will need to interact with the work source 232.8 times a second (without using roll-n-time)

Does anyone not one see that ANY change is a VERY short term solution ignoring fixing the size of the internal nonce?

That's why we're suggesting a new protocol which adds extremely light overhead.  The miner only needs to perform 1 extra hash per power of 2 transactions being included in the block.  There is no interacting with the work source if the miner supports it natively.  It can prepare the next piece of work in advance with CPU (on average this would be between 7 and 10 hashes, and it will likely never go beyond 12-14 (2^12 - 2^14 transactions in one block).

RIP BTC Guild, April 2011 - June 2015
kano
Legendary
*
Offline Offline

Activity: 2632
Merit: 1059


Linux since 1997 RedHat 4


View Profile
September 12, 2012, 12:03:52 AM
 #7020

And while you're at it, change the mining API to event-driven Smiley

What do you mean exactly?

At the moment, hashing works in a loop... start work -> wait for results -> get results - > go back to start. The mining thread issues work, then collects it.

Where as each mining device could be asychronous. The device gets work from the queue when its idle, submits it when it's done. The device calls the shots... calls the routine to get work, calls the routine to submit work.
I've already discussed this with ckolivas in the past.

cgminer C code being executed on a CPU is ... quite ... fast.

The delay is simply the verification of the share and the determination of the next getwork data (which is not a network getwork, cgminer already has the next piece of work necessary in most cases, and in the other cases it is not avoidable - getwork send and receive is already asynchronous)

The performance gain would be small and possibly not even noticeable at the scale of data reported by cgminer ... though on a slow old crappy CPU, that may or may not be the case.
To put that into context, if you have spent 10's of thousands of dollars on hashing hardware, get a normal CPU to run cgminer Tongue

My timing code already shows you information about that delay in the API stats command ...

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!
Pages: « 1 ... 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 [351] 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 ... 846 »
  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!