Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 386. (Read 5806015 times)

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!

I don't know what TRC is. Try it and see?

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.

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?

Yes, this is made possible using libusb. Too bad it's completely useless.

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

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

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

Right...
Even if you implement your own TCP/IP stack on top of it?

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

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

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.

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 missed the point. CGMiner is also deprecated software for deprecated technology (GPUs).

"Fork as BFGMiner"

Mmmmm ya Im gonna call Major Douche on this one

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

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

There's your problem.

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.

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

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.