Bitcoin Forum
July 22, 2018, 03:52:44 AM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 411 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 ... 847 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.10.0  (Read 5756986 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.
nathanrees19
Full Member
***
Offline Offline

Activity: 196
Merit: 100



View Profile
March 29, 2013, 02:48:08 AM
 #9201

CGMiner has nanosleep and sleep declared, which fucks the build for x86_64-w64-mingw32. Also, pthreads are not listed in the dependencies, and there is no option in configure to specify the prefix for pthreads.
We don't support building for w64 since it serves no useful advantage over 32 bit builds.
BFGMiner has w64-related bugs fixed and officially supported.

1532231564
Hero Member
*
Offline Offline

Posts: 1532231564

View Profile Personal Message (Offline)

Ignore
1532231564
Reply with quote  #2

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

Activity: 196
Merit: 100



View Profile
March 29, 2013, 02:53:52 AM
 #9202

No, you and Con decided to fork the project

kano
Legendary
*
Offline Offline

Activity: 2520
Merit: 1045


Linux since 1997 RedHat 4


View Profile
March 29, 2013, 03:12:17 AM
 #9203

...
... then decided to clone cgminer and change the names and the donation address:
https://github.com/luke-jr/bfgminer/commit/b9df56511c7bd1a2e1f075e9c184c1a4b0f1ba20
No, you and Con decided to fork the project because he was upset over the announcement of ASICs.
...
You forgot to click on that link one line above your FUD where YOU committed the changes with the words you wrote:
"Fork as BFGMiner"

Come on, all these lies you keep posting are rotting your brain, at least try to not also include the proof it's a lie, one line above what you type Cheesy 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!
crazyates
Legendary
*
Offline Offline

Activity: 952
Merit: 1000



View Profile
March 29, 2013, 03:19:01 AM
 #9204

...
... then decided to clone cgminer and change the names and the donation address:
https://github.com/luke-jr/bfgminer/commit/b9df56511c7bd1a2e1f075e9c184c1a4b0f1ba20
No, you and Con decided to fork the project because he was upset over the announcement of ASICs.
...
You forgot to click on that link one line above your FUD where YOU committed the changes with the words you wrote:
"Fork as BFGMiner"

Come on, all these lies you keep posting are rotting your brain, at least try to not also include the proof it's a lie, one line above what you type Cheesy Cheesy

"Fork as BFGMiner"
Code:
@@ -7,26 +7,26 @@ This code is provided entirely free of charge by the programmer in his spare
 time so donations would be greatly appreciated. Please consider donating to the
 address below.
 
[b]-Con Kolivas <kernel@kolivas.org>
-15qSxP1SQcUX3o4nhkfdbgyoWEFMomJ4rZ
+Luke-Jr <luke-jr+bfgminer@utopios.org>
+1QATWksNFGeUJCWBrN4g6hGM178Lovm7Wh[/b]

Mmmmm ya Im gonna call Major Douche on this one



Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
Wolf0
Legendary
*
Offline Offline

Activity: 1834
Merit: 1002


Miner Developer


View Profile
March 29, 2013, 03:54:29 AM
 #9205

CGMiner has nanosleep and sleep declared, which fucks the build for x86_64-w64-mingw32. Also, pthreads are not listed in the dependencies, and there is no option in configure to specify the prefix for pthreads.
We don't support building for w64 since it serves no useful advantage over 32 bit builds.
BFGMiner has w64-related bugs fixed and officially supported.



That's no reason to continue using deprecated technology. CGMiner could also be a 16-bit binary.

Code:
Donations: BTC: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
Luke-Jr
Legendary
*
Offline Offline

Activity: 2394
Merit: 1001



View Profile
March 29, 2013, 04:13:00 AM
 #9206

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

kano
Legendary
*
Offline Offline

Activity: 2520
Merit: 1045


Linux since 1997 RedHat 4


View Profile
March 29, 2013, 04:30:00 AM
 #9207

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).
Well, if you consider the fact that shortly, when indeed GPU mining will be deprecated, that the crappy clone will ONLY be using the old termios serial IO libraries that were designed around 30 or more years ago, meanwhile, cgminer has been updated to use the libusb library to talk directly to the USB devices rather than via the old serial libraries that put an old interface in front of the USB devices and restrict access to most of the USB functionality ... yes it's quite clear that the clone is old technology and written using the serial library because the guy who wrote it was not only fail in programming ability he chose the simplest interface with the most restrictions coz he had no idea what he was doing ...

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

Activity: 1834
Merit: 1002


Miner Developer


View Profile
March 29, 2013, 04:38:40 AM
 #9208

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

Haha, as long as scrypt chains exist, I don't think GPUs are gonna be deprecated for a long time.

Code:
Donations: BTC: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
Luke-Jr
Legendary
*
Offline Offline

Activity: 2394
Merit: 1001



View Profile
March 29, 2013, 04:45:37 AM
 #9209

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).
Well, if you consider the fact that shortly, when indeed GPU mining will be deprecated, that the crappy clone will ONLY be using the old termios serial IO libraries that were designed around 30 or more years ago, meanwhile, cgminer has been updated to use the libusb library to talk directly to the USB devices rather than via the old serial libraries that put an old interface in front of the USB devices and restrict access to most of the USB functionality ... yes it's quite clear that the clone is old technology and written using the serial library because the guy who wrote it was not only fail in programming ability he chose the simplest interface with the most restrictions coz he had no idea what he was doing ...
You mean the current, supported, standard interface, instead of bypassing it to use a low-level interface that has no benefit whatsoever.

It's like writing your own TCP/IP stack instead of using the one included in the OS. Not only is it stupidly redundant, it also means you've lost support, driver updates, ease of use, forward compatibility with new hardware, and regular-user-mode access.

Wolf0
Legendary
*
Offline Offline

Activity: 1834
Merit: 1002


Miner Developer


View Profile
March 29, 2013, 04:48:56 AM
 #9210

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).
Well, if you consider the fact that shortly, when indeed GPU mining will be deprecated, that the crappy clone will ONLY be using the old termios serial IO libraries that were designed around 30 or more years ago, meanwhile, cgminer has been updated to use the libusb library to talk directly to the USB devices rather than via the old serial libraries that put an old interface in front of the USB devices and restrict access to most of the USB functionality ... yes it's quite clear that the clone is old technology and written using the serial library because the guy who wrote it was not only fail in programming ability he chose the simplest interface with the most restrictions coz he had no idea what he was doing ...
You mean the current, supported, standard interface, instead of bypassing it to use a low-level interface that has no benefit whatsoever.

It's like writing your own TCP/IP stack instead of using the one included in the OS. Not only is it stupidly redundant, it also means you've lost support, driver updates, ease of use, forward compatibility with new hardware, and regular-user-mode access.

Speed might be a reason to use libusb rather than 30 year old serial I/O libs... Just saying...

Code:
Donations: BTC: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
Luke-Jr
Legendary
*
Offline Offline

Activity: 2394
Merit: 1001



View Profile
March 29, 2013, 04:57:25 AM
 #9211

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).
Well, if you consider the fact that shortly, when indeed GPU mining will be deprecated, that the crappy clone will ONLY be using the old termios serial IO libraries that were designed around 30 or more years ago, meanwhile, cgminer has been updated to use the libusb library to talk directly to the USB devices rather than via the old serial libraries that put an old interface in front of the USB devices and restrict access to most of the USB functionality ... yes it's quite clear that the clone is old technology and written using the serial library because the guy who wrote it was not only fail in programming ability he chose the simplest interface with the most restrictions coz he had no idea what he was doing ...
You mean the current, supported, standard interface, instead of bypassing it to use a low-level interface that has no benefit whatsoever.

It's like writing your own TCP/IP stack instead of using the one included in the OS. Not only is it stupidly redundant, it also means you've lost support, driver updates, ease of use, forward compatibility with new hardware, and regular-user-mode access.

Speed might be a reason to use libusb rather than 30 year old serial I/O libs... Just saying...
If Kano's lies were true, perhaps. But "30 year old serial I/O libs" is not quite right. While the interface may be 30 years old, the code behind it certainly isn't. Nor is there any need for a new interface. It's also a "library" builtin to the OS itself, so pretty much as little overhead as you can get.
On the other hand, libusb is designed for raw USB access, and non-native on at least Windows. But it does add a lot of abstraction which theoretically harms performance. It then goes and does the same things as the "30 year old serial I/O libs" using a non-standard interface. libusb is nice when there are no existing drivers, but totally the wrong tool for these specific devices. Unfortunately, libusb also lacks any support for asynchronous access on Windows too, which makes some device API improvements impractical - before I can move BFGMiner to a completely asynchronous model, I would need to first do some major improvements to the underlying libusb library itself.

Edit: Disclosure... there is one reason I can see using libusb could be beneficial: unfixed bugs in the OS/official OS drivers, or workarounds for buggy hardware. This is the case with Windows's ACM driver (used by ModMiner) - but easily worked around in software (as BFGMiner has done for a while). The chip used in the Icarus also had a bug that prevented it from working with certain USB hosts - this too, was easily worked around in software. But those are the only reasons I can see using libusb would make sense for a device using a serial interface, and they're already managed just fine without it.

Wolf0
Legendary
*
Offline Offline

Activity: 1834
Merit: 1002


Miner Developer


View Profile
March 29, 2013, 10:03:58 AM
 #9212

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).
Well, if you consider the fact that shortly, when indeed GPU mining will be deprecated, that the crappy clone will ONLY be using the old termios serial IO libraries that were designed around 30 or more years ago, meanwhile, cgminer has been updated to use the libusb library to talk directly to the USB devices rather than via the old serial libraries that put an old interface in front of the USB devices and restrict access to most of the USB functionality ... yes it's quite clear that the clone is old technology and written using the serial library because the guy who wrote it was not only fail in programming ability he chose the simplest interface with the most restrictions coz he had no idea what he was doing ...
You mean the current, supported, standard interface, instead of bypassing it to use a low-level interface that has no benefit whatsoever.

It's like writing your own TCP/IP stack instead of using the one included in the OS. Not only is it stupidly redundant, it also means you've lost support, driver updates, ease of use, forward compatibility with new hardware, and regular-user-mode access.

Speed might be a reason to use libusb rather than 30 year old serial I/O libs... Just saying...
If Kano's lies were true, perhaps. But "30 year old serial I/O libs" is not quite right. While the interface may be 30 years old, the code behind it certainly isn't. Nor is there any need for a new interface. It's also a "library" builtin to the OS itself, so pretty much as little overhead as you can get.
On the other hand, libusb is designed for raw USB access, and non-native on at least Windows. But it does add a lot of abstraction which theoretically harms performance. It then goes and does the same things as the "30 year old serial I/O libs" using a non-standard interface. libusb is nice when there are no existing drivers, but totally the wrong tool for these specific devices. Unfortunately, libusb also lacks any support for asynchronous access on Windows too, which makes some device API improvements impractical - before I can move BFGMiner to a completely asynchronous model, I would need to first do some major improvements to the underlying libusb library itself.

Edit: Disclosure... there is one reason I can see using libusb could be beneficial: unfixed bugs in the OS/official OS drivers, or workarounds for buggy hardware. This is the case with Windows's ACM driver (used by ModMiner) - but easily worked around in software (as BFGMiner has done for a while). The chip used in the Icarus also had a bug that prevented it from working with certain USB hosts - this too, was easily worked around in software. But those are the only reasons I can see using libusb would make sense for a device using a serial interface, and they're already managed just fine without it.

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?

Code:
Donations: BTC: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
Luke-Jr
Legendary
*
Offline Offline

Activity: 2394
Merit: 1001



View Profile
March 29, 2013, 01:37:24 PM
 #9213

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).
Well, if you consider the fact that shortly, when indeed GPU mining will be deprecated, that the crappy clone will ONLY be using the old termios serial IO libraries that were designed around 30 or more years ago, meanwhile, cgminer has been updated to use the libusb library to talk directly to the USB devices rather than via the old serial libraries that put an old interface in front of the USB devices and restrict access to most of the USB functionality ... yes it's quite clear that the clone is old technology and written using the serial library because the guy who wrote it was not only fail in programming ability he chose the simplest interface with the most restrictions coz he had no idea what he was doing ...
You mean the current, supported, standard interface, instead of bypassing it to use a low-level interface that has no benefit whatsoever.

It's like writing your own TCP/IP stack instead of using the one included in the OS. Not only is it stupidly redundant, it also means you've lost support, driver updates, ease of use, forward compatibility with new hardware, and regular-user-mode access.

Speed might be a reason to use libusb rather than 30 year old serial I/O libs... Just saying...
If Kano's lies were true, perhaps. But "30 year old serial I/O libs" is not quite right. While the interface may be 30 years old, the code behind it certainly isn't. Nor is there any need for a new interface. It's also a "library" builtin to the OS itself, so pretty much as little overhead as you can get.
On the other hand, libusb is designed for raw USB access, and non-native on at least Windows. But it does add a lot of abstraction which theoretically harms performance. It then goes and does the same things as the "30 year old serial I/O libs" using a non-standard interface. libusb is nice when there are no existing drivers, but totally the wrong tool for these specific devices. Unfortunately, libusb also lacks any support for asynchronous access on Windows too, which makes some device API improvements impractical - before I can move BFGMiner to a completely asynchronous model, I would need to first do some major improvements to the underlying libusb library itself.

Edit: Disclosure... there is one reason I can see using libusb could be beneficial: unfixed bugs in the OS/official OS drivers, or workarounds for buggy hardware. This is the case with Windows's ACM driver (used by ModMiner) - but easily worked around in software (as BFGMiner has done for a while). The chip used in the Icarus also had a bug that prevented it from working with certain USB hosts - this too, was easily worked around in software. But those are the only reasons I can see using libusb would make sense for a device using a serial interface, and they're already managed just fine without it.

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.

Wolf0
Legendary
*
Offline Offline

Activity: 1834
Merit: 1002


Miner Developer


View Profile
March 29, 2013, 02:00:15 PM
 #9214

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. And libpcap is still faster and offers more functionality than the TCP/IP stack, it doesn't reimplement too much.

Code:
Donations: BTC: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
kano
Legendary
*
Offline Offline

Activity: 2520
Merit: 1045


Linux since 1997 RedHat 4


View Profile
March 29, 2013, 02:06:17 PM
 #9215

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

Your crappy serial-USB removes access to the USB functions that are available with the chips and limits your crappy software clone to only ever be able to use simple sequential text data transfers - a small subset of USB functionality.

To take this directly to the result of your short sightedness using serial-USB, the current ASIC manufacturers are not implementing well designed USB interfaces, they are implementing crappy simple serial interfaces that do not allow for multiple end points or asynchronous transfers or any other of the OLD usb advances available with usb devices over the VERY OLD dated COM serial ports ... let alone anything new with USB in the last ... 10 years

Yes your lack of understanding of USB will of course mean you'll come up with more foolish arguments and mind numbingly stupid comments
... but at least everyone can be glad of the fact that you are the cause of this failure of ASIC manufacturers to utilise USB even to a fraction of it's potential and instead use crappy FTDI chips (both BFL and Avalon) and expect software to only implement simple serial data transfers over serial-USB

Or to correctly put it yet another way: you are using a default driver limitation in some versions of windows (that can easily be worked around) to define your level of device support for mining devices.

With cgminer, in linux it is easy for me to overcome this in the code, in windows it is overcome by using the WinUSB driver for any USB mining device that exhibits the USB control restriction

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: 2394
Merit: 1001



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

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?

Wolf0
Legendary
*
Offline Offline

Activity: 1834
Merit: 1002


Miner Developer


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

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: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
Luke-Jr
Legendary
*
Offline Offline

Activity: 2394
Merit: 1001



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

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: 1834
Merit: 1002


Miner Developer


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

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: 1WoLFdwcfNEg64fTYsX1P25KUzzSjtEZC -- XMR: 45SLUTzk7UXYHmzJ7bFN6FPfzTusdUVAZjPRgmEDw7G3SeimWM2kCdnDQXwDBYGUWaBtZNgjYtEYA22aMQT4t8KfU3vHLHG
kano
Legendary
*
Offline Offline

Activity: 2520
Merit: 1045


Linux since 1997 RedHat 4


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

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