OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1

[-ck]

How lucky am I? Is this an easter present from our friendly local christian to come trolling my thread again? It seems the forum mods are even on your side and refuse to accept your posts as trolls, nice to see lack of impartiality there. Let's see how long this post lasts.

[kano]

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.

[-ck]

Well I'm outta here again, time to take a break from these forums for my sanity till something hardware happens and/or the trolling stops..

[Luke-Jr]

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.

[kano]

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

[Luke-Jr]

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]

Windows.

There's your problem.

[sharky112065]

Windows.

There's your problem.

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

[nathanrees19]

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]

No, you and Con decided to fork the project

[kano]

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

[crazyates]

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

"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

[Luke-Jr]

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]

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

[Luke-Jr]

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.

[Luke-Jr]

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.

[Luke-Jr]

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.

[kano]

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

[Luke-Jr]

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?

[Luke-Jr]

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.