Bitcoin Forum
December 09, 2016, 09:36:09 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 ... 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 [462] 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4825281 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.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
March 29, 2013, 02:14:25 PM
 #9221

Wait, you just said that it was the current, supported, standard interface, and libusb is low level. Then you said libusb adds a lot of abstraction and does the same things as the serial I/O libs, which would make it higher level. Which is it?
Both. For the network analogy, libusb would be libpcap - it adds some programmer-friendly abstractions on top of a raw socket. It's still working with low-level raw sockets, but in an abstracted way.

If we're using that analogy, then the serial I/O libs would be the regular TCP/IP stack.
Right...
And libpcap is still faster and offers more functionality than the TCP/IP stack, it doesn't reimplement too much.
Even if you implement your own TCP/IP stack on top of it?

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

Posts: 1481319369

View Profile Personal Message (Offline)

Ignore
1481319369
Reply with quote  #2

1481319369
Report to moderator
1481319369
Hero Member
*
Offline Offline

Posts: 1481319369

View Profile Personal Message (Offline)

Ignore
1481319369
Reply with quote  #2

1481319369
Report to moderator
Wolf0
Legendary
*
Offline Offline

Activity: 1400


Miner Developer


View Profile
March 29, 2013, 05:37:50 PM
 #9222

Wait, you just said that it was the current, supported, standard interface, and libusb is low level. Then you said libusb adds a lot of abstraction and does the same things as the serial I/O libs, which would make it higher level. Which is it?
Both. For the network analogy, libusb would be libpcap - it adds some programmer-friendly abstractions on top of a raw socket. It's still working with low-level raw sockets, but in an abstracted way.

If we're using that analogy, then the serial I/O libs would be the regular TCP/IP stack.
Right...
And libpcap is still faster and offers more functionality than the TCP/IP stack, it doesn't reimplement too much.
Even if you implement your own TCP/IP stack on top of it?
But it's nothing like that. USB provides a lot more than serial transfers, as kano said. So it's not a reimplementation.

Code:
Donations: BTC: 1Jp2R7dF9gYr872FkXiap2MaYaHNEfwWhZ -- XMR: 42QWoLF7pdwMcTXDviJvNkWEHJ4TXnMBh2Cx6HNkVAW57E48Zfw6wLwDUYFDYJAqY7PLJUTz9cHWB5C4wUA7UJPu5wPf4sZ -- GPG Key ID: 0x88CBE71ADD5FB10F
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
March 29, 2013, 07:36:44 PM
 #9223

Wait, you just said that it was the current, supported, standard interface, and libusb is low level. Then you said libusb adds a lot of abstraction and does the same things as the serial I/O libs, which would make it higher level. Which is it?
Both. For the network analogy, libusb would be libpcap - it adds some programmer-friendly abstractions on top of a raw socket. It's still working with low-level raw sockets, but in an abstracted way.

If we're using that analogy, then the serial I/O libs would be the regular TCP/IP stack.
Right...
And libpcap is still faster and offers more functionality than the TCP/IP stack, it doesn't reimplement too much.
Even if you implement your own TCP/IP stack on top of it?
But it's nothing like that. USB provides a lot more than serial transfers, as kano said. So it's not a reimplementation.
USB does, yes. But not the devices in question.

Wolf0
Legendary
*
Offline Offline

Activity: 1400


Miner Developer


View Profile
March 29, 2013, 08:58:46 PM
 #9224

USB does, yes. But not the devices in question.

If that's the case, then I suppose I see no real benefit to using libusb either.

Code:
Donations: BTC: 1Jp2R7dF9gYr872FkXiap2MaYaHNEfwWhZ -- XMR: 42QWoLF7pdwMcTXDviJvNkWEHJ4TXnMBh2Cx6HNkVAW57E48Zfw6wLwDUYFDYJAqY7PLJUTz9cHWB5C4wUA7UJPu5wPf4sZ -- GPG Key ID: 0x88CBE71ADD5FB10F
kano
Legendary
*
Online Online

Activity: 1932


Linux since 1997 RedHat 4


View Profile
March 29, 2013, 10:03:32 PM
 #9225

USB does, yes. But not the devices in question.

If that's the case, then I suppose I see no real benefit to using libusb either.
cgminer already implements functionality that uses the advantages of libusb

The most obvious one is hotplug.
I have implemented it within the main cgminer code and the usbutils code, without need for the drivers to handle it directly.
Thus all current usbutils drivers (MMQ and BFL) and all new drivers will already have hotplug.

Another is the 'cgminer -n' function - it will list all known libusb mining devices without each driver having to do any actual hashing on the devices or sending commands to the devices.

Another is the API usbstats
All devices have statistics recorded about all I/O to them, including the initial control transfers that the serial-USB code doesn't even know about

All device I/O also has a lot more information about errors and problems with libusb and thus drivers can use that to deal with problems in a much better way

To implement them in serial-USB, will require non serial-USB code specific to each device and specific to each driver, since it is not possible to do them sanely in serial-USB (especially hotplug)

... and of course, if any manufacturer does implement a much better device that uses the clear advantages of direct USB, cgminer will already have most of the code necessary to support it, tested and been run already for months right now.

--

To put it in the simplest words to understand, Luke-Jr is butthurt about not using his old code with all it's old restrictions and problems, but instead I wrote a whole new library for dealing with USB devices to get around all the problems that exist with serial-USB ... why else is he here posting over and over again in the main cgminer thread instead of his pissy clone thread Cheesy

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
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
March 29, 2013, 10:17:32 PM
 #9226

USB does, yes. But not the devices in question.

If that's the case, then I suppose I see no real benefit to using libusb either.
cgminer already implements functionality that uses the advantages of libusb

The most obvious one is hotplug.
I have implemented it within the main cgminer code and the usbutils code, without need for the drivers to handle it directly.
Thus all current usbutils drivers (MMQ and BFL) and all new drivers will already have hotplug.
This is not a libusb feature. In fact, libusb explicitly does not support hotplugging itself!
You are merely scanning all devices poll-style every so often. That can be done just as well with the standard serial interfaces (Ufasoft has done it since BitFORCE FPGAs were originally released), but is the wrong way to do hotplug and breaks a number of assumptions in the original code that BFG and cg today are based on.

Another is the 'cgminer -n' function - it will list all known libusb mining devices without each driver having to do any actual hashing on the devices or sending commands to the devices.
It does exactly what the -d? option has done since I created the device API interface in 2.2.0.
How is this redundancy somehow libusb-specific?

Another is the usb API stats
All devices have statistics recorded about all I/O to them, including the initial control transfers that the serial-USB code doesn't even know about
Yes, this is made possible using libusb. Too bad it's completely useless.

... and of course, if any manufacturer does implement a much better device that uses the clear advantages of direct USB, cgminer will already have most of the code necessary to support it, tested and been run already for months right now.
While I agree that using direct USB is probably better overall, there is nothing special about your libusb code in cgminer.
BFGMiner also uses libusb, just only when it's the right interface for the job. ZTEX and X6500 use direct USB interfaces.
The reality is, there isn't any generic "code necessary to support" direct USB (outside of what libusb itself provides) - just "Kano's pointless reinvention of the standard serial-USB interface".

Wolf0
Legendary
*
Offline Offline

Activity: 1400


Miner Developer


View Profile
March 29, 2013, 10:22:45 PM
 #9227

While I agree that using direct USB is probably better overall,

Then we have no argument here! You're agreeing with kano! By the way, and this is totally unrelated, is it possible to use Eloipool to run a TRC pool?

Code:
Donations: BTC: 1Jp2R7dF9gYr872FkXiap2MaYaHNEfwWhZ -- XMR: 42QWoLF7pdwMcTXDviJvNkWEHJ4TXnMBh2Cx6HNkVAW57E48Zfw6wLwDUYFDYJAqY7PLJUTz9cHWB5C4wUA7UJPu5wPf4sZ -- GPG Key ID: 0x88CBE71ADD5FB10F
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
March 29, 2013, 11:04:32 PM
 #9228

While I agree that using direct USB is probably better overall,
Then we have no argument here! You're agreeing with kano!
Come on, context! Devices talking to mining software with raw/direct USB, is probably better than using a serial interface.
But it's still more sensible to use the standard interface/drivers when they're implementing the protocol with serial!

By the way, and this is totally unrelated, is it possible to use Eloipool to run a TRC pool?
I don't know what TRC is. Try it and see?

ocminer
Legendary
*
Offline Offline

Activity: 1582



View Profile WWW
March 30, 2013, 12:28:07 AM
 #9229

Since 2.11.3 something with (5s) MH/s counting is really weird:


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

Activity: 1806



View Profile
March 30, 2013, 12:42:17 AM
 #9230

I decided to upgrade from 2.10.x today and it looks like you've killed my startup scripts. Why was scan-serial removed for BFL devices? I was running multiple instances of CGminer with each instance pointing to only one of my singles. This allowed me to tie one pool to one device(with all other pools set to failover only).

 Is there any other way I can replicate this functionality in 2.11.x or should I go back to 2.10.x or BFGminer? Do I need to build with icarus support, and if I do, will the switch still work with a BFL device? If you guys were to add the ability to tie a pool to a specific device in one instance, that would work too:)

ASICPuppy.net ASIC Mining Hardware and Accessories - GekkoScience DL580 Breakout Boards are In Stock!
Wolf0
Legendary
*
Offline Offline

Activity: 1400


Miner Developer


View Profile
March 30, 2013, 12:59:19 AM
 #9231

By the way, and this is totally unrelated, is it possible to use Eloipool to run a TRC pool?
I don't know what TRC is. Try it and see?

Honestly, I don't really know how to set up a pool. I'm a programmer, but I haven't found much information out there. If you could point me to a resource, that'd be awesome.

Code:
Donations: BTC: 1Jp2R7dF9gYr872FkXiap2MaYaHNEfwWhZ -- XMR: 42QWoLF7pdwMcTXDviJvNkWEHJ4TXnMBh2Cx6HNkVAW57E48Zfw6wLwDUYFDYJAqY7PLJUTz9cHWB5C4wUA7UJPu5wPf4sZ -- GPG Key ID: 0x88CBE71ADD5FB10F
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
March 30, 2013, 01:09:54 AM
 #9232

By the way, and this is totally unrelated, is it possible to use Eloipool to run a TRC pool?
I don't know what TRC is. Try it and see?

Honestly, I don't really know how to set up a pool. I'm a programmer, but I haven't found much information out there. If you could point me to a resource, that'd be awesome.
https://bitcointalk.org/index.php?topic=158105.0

nathanrees19
Full Member
***
Offline Offline

Activity: 196



View Profile
March 30, 2013, 01:47:15 AM
 #9233

You mean the current, supported, standard interface, instead of bypassing it to use a low-level interface that has no benefit whatsoever.

The "current, supported, standard interface" is an ancient unix terminal interface which conveniently doesn't exist on all platforms. A mining device is not a terminal where unpredictable buffering somewhere in the chain is not a big deal.

It's like writing your own TCP/IP stack instead of using the one included in the OS.

Awful analogy.

A TCP/IP stack is a complicated and generic stack used by many different parts of the system (and by remote systems). Replacing it would almost certainly compromise performance, reliability, security, etc.

A mining-device interface is much simpler and only used by a single application for a single purpose.

you've lost support, driver updates

For a usb serial driver? You've got to be fucking kidding me.

ease of use

For the end user? It "just works" on linux. Your point is partially valid on Windows, except that Windows is Windows, so it is not.

forward compatibility with new hardware

You're almost guaranteed to need to update the mining software for new hardware.

and regular-user-mode access.

You can replug the device on linux to get the normal driver back if you really want it. Again, there isn't much to say about Windows here.
crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
March 30, 2013, 01:50:46 AM
 #9234

That's no reason to continue using deprecated technology. CGMiner could also be a 16-bit binary.
You missed the point. CGMiner is also deprecated software for deprecated technology (GPUs).
It's posts like this that piss me off.

A) Doesn't BFG mine on GPUs? If it's so deprecated, I dare you to cut out the GPU portion of BFG, and see how many people care.
B) Don't a lot of people still mine on GPUs? I know I do.
C) If a software is still being maintained and actively developed, how can it be called deprecated?

The only obvious answer: You don't like CGMiner, and you will do everything in your power to defame it, and promote your fork.

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
kano
Legendary
*
Online Online

Activity: 1932


Linux since 1997 RedHat 4


View Profile
March 30, 2013, 02:45:52 AM
 #9235

I decided to upgrade from 2.10.x today and it looks like you've killed my startup scripts. Why was scan-serial removed for BFL devices? I was running multiple instances of CGminer with each instance pointing to only one of my singles. This allowed me to tie one pool to one device(with all other pools set to failover only).

 Is there any other way I can replicate this functionality in 2.11.x or should I go back to 2.10.x or BFGminer? Do I need to build with icarus support, and if I do, will the switch still work with a BFL device? If you guys were to add the ability to tie a pool to a specific device in one instance, that would work too:)
To repeat what is written in the README, FPGA-README, in the NEWS file, in the posts here on the forum ...
BFL devices are USB direct and always autodetected unless you tell cgminer not to.
--scan-serial is ONLY used for Icarus now
The command related to restricting detection of BFL/MMQ is --usb as explained in detail (47 lines) in the README ...
e.g. --usb BFL:1 would only detect a single BFL and stop looking

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
kano
Legendary
*
Online Online

Activity: 1932


Linux since 1997 RedHat 4


View Profile
March 30, 2013, 02:58:00 AM
 #9236

Since 2.11.3 something with (5s) MH/s counting is really weird:

http://s16.postimg.org/kpvvw1v6d/Bildschirmfoto_2013_03_30_um_01_24_34.png
Correct, devices that hash ~5s or slower per nonce range indeed do not show a very reliable value for a 5s average ... since that really is what to expect if you think about the mathematics of it Smiley

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

Activity: 1806



View Profile
March 30, 2013, 03:09:48 AM
 #9237

I decided to upgrade from 2.10.x today and it looks like you've killed my startup scripts. Why was scan-serial removed for BFL devices? I was running multiple instances of CGminer with each instance pointing to only one of my singles. This allowed me to tie one pool to one device(with all other pools set to failover only).

 Is there any other way I can replicate this functionality in 2.11.x or should I go back to 2.10.x or BFGminer? Do I need to build with icarus support, and if I do, will the switch still work with a BFL device? If you guys were to add the ability to tie a pool to a specific device in one instance, that would work too:)
To repeat what is written in the README, FPGA-README, in the NEWS file, in the posts here on the forum ...
BFL devices are USB direct and always autodetected unless you tell cgminer not to.
--scan-serial is ONLY used for Icarus now
The command related to restricting detection of BFL/MMQ is --usb as explained in detail (47 lines) in the README ...
e.g. --usb BFL:1 would only detect a single BFL and stop looking

Ah great, I'll give the USB switch a shot. I quickly scanned through the docs but was more interested in why -S was removed. Now that I've read serial-USB was removed that makes sense. Thanks

ASICPuppy.net ASIC Mining Hardware and Accessories - GekkoScience DL580 Breakout Boards are In Stock!
juhakall
Sr. Member
****
Offline Offline

Activity: 422



View Profile
March 30, 2013, 07:53:27 PM
 #9238

Since 2.11.3 something with (5s) MH/s counting is really weird:

http://s16.postimg.org/kpvvw1v6d/Bildschirmfoto_2013_03_30_um_01_24_34.png
Correct, devices that hash ~5s or slower per nonce range indeed do not show a very reliable value for a 5s average ... since that really is what to expect if you think about the mathematics of it Smiley

Your reasoning sounds valid, but this is a bug that didn't exist in a previous version. How is that not a regression? I am always using the latest git version, and at least for now, reverting commit 072ffbba424770afcbd2e1a10aead8a5035f80de returns the old (correct) 5s hashrate average for slow devices.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2100



View Profile
March 30, 2013, 08:06:14 PM
 #9239

Since 2.11.3 something with (5s) MH/s counting is really weird:

http://s16.postimg.org/kpvvw1v6d/Bildschirmfoto_2013_03_30_um_01_24_34.png
Correct, devices that hash ~5s or slower per nonce range indeed do not show a very reliable value for a 5s average ... since that really is what to expect if you think about the mathematics of it Smiley

Your reasoning sounds valid, but this is a bug that didn't exist in a previous version. How is that not a regression? I am always using the latest git version, and at least for now, reverting commit 072ffbba424770afcbd2e1a10aead8a5035f80de returns the old (correct) 5s hashrate average for slow devices.
I intentionally did not merge this regression into BFGMiner.

crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
March 30, 2013, 08:51:44 PM
 #9240

Alright enough. STFU. If any other miner software was posting in the CGMiner thread about how the author thought their software was better, they would get a shitstorm up the ass. If Diablo, ufasoft, M0mchil, or Jedi95 was in here saying their miner was better than CGMiner, they would get their posts removed. Yet somehow because your program was forked from CGMiner, you get these special privileges.

From now on, I will reporting any post by LJR in the CGMiner thread to the mods. I suggest everyone else to do the same.

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
Pages: « 1 ... 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 [462] 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 ... 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!