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

strange issue with cgminer.
Two cards one 5870 and one 5850
I have connected one monitor to the 5870
I am getting a message when starting cgminer which says that "ADL found less devices than opencl! There is possibly more than one display attached to a GPU. Use the gpu map feature to reliably map OpenCL to ADL"
Then if I take the cable and connect it to the 5850 and then to the 5870 everything works fine and I don't get the previous message.
In case I don't, I get the message above and cannot control the GPU settings.
I experimented with --gpu-map with no luck.
Any ideas?

Cool story bro.

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

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

Hi Kano,

I was trying to upgrade from 2.7.6 to 2.11.3

I followed your procedure to update BFL device driver to WinUSB.  Downloaded zadig (for Windows 7), run it as administrator.
I got an error installing WinUSB driver.  Here is the Zadig debug log:

http://www.petermoss.com/akbash/zadig_install_log

Can you add FTDI driver support as an option?  As it is now, I can only use 2.10.5 version.

I intentionally did not merge this regression into BFGMiner.

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

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

Correct, devices that hash ~5s or slower per nonce range indeed do not show a very reliable value for a 5s average ... since that really is what to expect if you think about the mathematics of it

To repeat what is written in the README, FPGA-README, in the NEWS file, in the posts here on the forum ...
BFL devices are USB direct and always autodetected unless you tell cgminer not to.
--scan-serial is ONLY used for Icarus now
The command related to restricting detection of BFL/MMQ is --usb as explained in detail (47 lines) in the README ...
e.g. --usb BFL:1 would only detect a single BFL and stop looking

It's posts like this that piss me off.

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

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

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


Awful analogy.

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

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


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


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


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


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

https://bitcointalksearch.org/topic/avalon-users-bitcoind-eloipool-configuration-158105

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

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

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

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