Bitcoin Forum
December 07, 2016, 10:40:32 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 ... 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 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4821990 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: 2086



View Profile
March 29, 2013, 01:34:41 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.
However, please note that BFGMiner is well known to brick mining hardware. Avoid it.
As usual, this is a lie.

And just to completely and simply prove that Luke-Jr lies and knows he is lying but has no issue with posting lies on this forum as he does REGULARLY - here is a direct link and quoted copy of the post in his thread that he knows about that says it bricks, and even Luke-Jr's warning about his software possibly bricking ... which it does:
https://bitcointalk.org/index.php?topic=78192.msg1689104#msg1689104
Made a BFGMiner 2.99.0 + experimental Avalon driver firmware image in case any Avalon users want to give it a try.

Be careful! If this (or anything else) bricks your Avalon's controller, you will need to attach a serial port to recover!
...

tried it, bricks avalon. failsafe works. recovered to stock firmware.
I don't lie. Anyone with a clue can clearly see that an occurance of bricking a controller with a test build clearly marked as possibly having that effect, is not remotely the same thing as "BFGMiner ... brick mining hardware", nor does one person mentioning the result as such make it "well known". Too bad you're too busy trolling to have a clue.

1481150432
Hero Member
*
Offline Offline

Posts: 1481150432

View Profile Personal Message (Offline)

Ignore
1481150432
Reply with quote  #2

1481150432
Report to moderator
1481150432
Hero Member
*
Offline Offline

Posts: 1481150432

View Profile Personal Message (Offline)

Ignore
1481150432
Reply with quote  #2

1481150432
Report to moderator
1481150432
Hero Member
*
Offline Offline

Posts: 1481150432

View Profile Personal Message (Offline)

Ignore
1481150432
Reply with quote  #2

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

Posts: 1481150432

View Profile Personal Message (Offline)

Ignore
1481150432
Reply with quote  #2

1481150432
Report to moderator
1481150432
Hero Member
*
Offline Offline

Posts: 1481150432

View Profile Personal Message (Offline)

Ignore
1481150432
Reply with quote  #2

1481150432
Report to moderator
1481150432
Hero Member
*
Offline Offline

Posts: 1481150432

View Profile Personal Message (Offline)

Ignore
1481150432
Reply with quote  #2

1481150432
Report to moderator
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
March 29, 2013, 02:08:25 AM
 #9202

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.
However, please note that BFGMiner is well known to brick mining hardware. Avoid it.
As usual, this is a lie.

And just to completely and simply prove that Luke-Jr lies and knows he is lying but has no issue with posting lies on this forum as he does REGULARLY - here is a direct link and quoted copy of the post in his thread that he knows about that says it bricks, and even Luke-Jr's warning about his software possibly bricking ... which it does:
https://bitcointalk.org/index.php?topic=78192.msg1689104#msg1689104
Made a BFGMiner 2.99.0 + experimental Avalon driver firmware image in case any Avalon users want to give it a try.

Be careful! If this (or anything else) bricks your Avalon's controller, you will need to attach a serial port to recover!
...

tried it, bricks avalon. failsafe works. recovered to stock firmware.
I don't lie. Anyone with a clue can clearly see that an occurance of bricking a controller with a test build clearly marked as possibly having that effect, is not remotely the same thing as "BFGMiner ... brick mining hardware", nor does one person mentioning the result as such make it "well known". Too bad you're too busy trolling to have a clue.
That is software that you posted on the public (crappy) bitcoin wiki on the avalon page for people to use ...
You have also ALREADY got in your clone miner the software for the BFL ASIC hardware that is COMPLETELY UNTESTED.
The hardware doesn't exists yet.
Everyone using your crappy clone miner has that completely UNTESTED code in it.
Your complete lack of testing your crappy code was one of the main issues that you used as an excuse to clone cgminer - when you wrote crappy untested changes to the icarus code that you NEVER tested on window - and it didn't work at all - it locked up cgminer - and you ranted about me overwriting your code that didn;t work ... then decided to clone cgminer and change the names and the donation address:
https://github.com/luke-jr/bfgminer/commit/b9df56511c7bd1a2e1f075e9c184c1a4b0f1ba20

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: 2086



View Profile
March 29, 2013, 02:14:20 AM
 #9203

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.
However, please note that BFGMiner is well known to brick mining hardware. Avoid it.
As usual, this is a lie.

And just to completely and simply prove that Luke-Jr lies and knows he is lying but has no issue with posting lies on this forum as he does REGULARLY - here is a direct link and quoted copy of the post in his thread that he knows about that says it bricks, and even Luke-Jr's warning about his software possibly bricking ... which it does:
https://bitcointalk.org/index.php?topic=78192.msg1689104#msg1689104
Made a BFGMiner 2.99.0 + experimental Avalon driver firmware image in case any Avalon users want to give it a try.

Be careful! If this (or anything else) bricks your Avalon's controller, you will need to attach a serial port to recover!
...

tried it, bricks avalon. failsafe works. recovered to stock firmware.
I don't lie. Anyone with a clue can clearly see that an occurance of bricking a controller with a test build clearly marked as possibly having that effect, is not remotely the same thing as "BFGMiner ... brick mining hardware", nor does one person mentioning the result as such make it "well known". Too bad you're too busy trolling to have a clue.
That is software that you posted on the public (crappy) bitcoin wiki on the avalon page for people to use ...
You have also ALREADY got in your clone miner the software for the BFL ASIC hardware that is COMPLETELY UNTESTED.
The hardware doesn't exists yet.
Everyone using your crappy clone miner has that completely UNTESTED code in it.
Your complete lack of testing your crappy code was one of the main issues that you used as an excuse to clone cgminer - when you wrote crappy untested changes to the icarus code that you NEVER tested on window - and it didn't work at all - it locked up cgminer - and you ranted about me overwriting your code that didn;t work ... 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.
Yes, clearly-labelled alpha releases might be broken! That's to be expected. That's why they're alpha.

nathanrees19
Full Member
***
Offline Offline

Activity: 196



View Profile
March 29, 2013, 02:33:57 AM
 #9204

Windows.

There's your problem.
sharky112065
Sr. Member
****
Offline Offline

Activity: 383



View Profile
March 29, 2013, 02:36:19 AM
 #9205


No, I think he has way more problems than just Windows.  Wink

Donations welcome: 12KaKtrK52iQjPdtsJq7fJ7smC32tXWbWr
nathanrees19
Full Member
***
Offline Offline

Activity: 196



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

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.

nathanrees19
Full Member
***
Offline Offline

Activity: 196



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

No, you and Con decided to fork the project

kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


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

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

Activity: 938



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

...
... 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: 1400


Miner Developer


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

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: 1Jp2R7dF9gYr872FkXiap2MaYaHNEfwWhZ -- XMR: 42QWoLF7pdwMcTXDviJvNkWEHJ4TXnMBh2Cx6HNkVAW57E48Zfw6wLwDUYFDYJAqY7PLJUTz9cHWB5C4wUA7UJPu5wPf4sZ -- GPG Key ID: 0x88CBE71ADD5FB10F
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
March 29, 2013, 04:13:00 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).

kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
March 29, 2013, 04:30:00 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 ...

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

Activity: 1400


Miner Developer


View Profile
March 29, 2013, 04:38:40 AM
 #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).

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

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

Activity: 2086



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

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: 1400


Miner Developer


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

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: 1Jp2R7dF9gYr872FkXiap2MaYaHNEfwWhZ -- XMR: 42QWoLF7pdwMcTXDviJvNkWEHJ4TXnMBh2Cx6HNkVAW57E48Zfw6wLwDUYFDYJAqY7PLJUTz9cHWB5C4wUA7UJPu5wPf4sZ -- GPG Key ID: 0x88CBE71ADD5FB10F
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



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

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: 1400


Miner Developer


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

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: 1Jp2R7dF9gYr872FkXiap2MaYaHNEfwWhZ -- XMR: 42QWoLF7pdwMcTXDviJvNkWEHJ4TXnMBh2Cx6HNkVAW57E48Zfw6wLwDUYFDYJAqY7PLJUTz9cHWB5C4wUA7UJPu5wPf4sZ -- GPG Key ID: 0x88CBE71ADD5FB10F
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



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

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: 1400


Miner Developer


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

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: 1Jp2R7dF9gYr872FkXiap2MaYaHNEfwWhZ -- XMR: 42QWoLF7pdwMcTXDviJvNkWEHJ4TXnMBh2Cx6HNkVAW57E48Zfw6wLwDUYFDYJAqY7PLJUTz9cHWB5C4wUA7UJPu5wPf4sZ -- GPG Key ID: 0x88CBE71ADD5FB10F
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


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

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