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

[kano]

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

[1714179118]

1714179118

[1714179118]

1714179118

[1714179118]

1714179118

[1714179118]

1714179118

[1714179118]

1714179118

[1714179118]

1714179118

[Luke-Jr]

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.

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.

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.

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?

Another is the usb API stats
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

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

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

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

[Luke-Jr]

While I agree that using direct USB is probably better overall,

Then we have no argument here! You're agreeing with kano!

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!

By the way, and this is totally unrelated, is it possible to use Eloipool to run a TRC pool?

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

[ocminer]

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

[CrazyGuy]

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

[Luke-Jr]

By the way, and this is totally unrelated, is it possible to use Eloipool to run a TRC pool?

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

Honestly, I don't really know how to set up a pool. I'm a programmer, but I haven't found much information out there. If you could point me to a resource, that'd be awesome.

https://bitcointalk.org/index.php?topic=158105.0

[nathanrees19]

You mean the current, supported, standard interface, instead of bypassing it to use a low-level interface that has no benefit whatsoever.

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.

It's like writing your own TCP/IP stack instead of using the one included in the OS.

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.

you've lost support, driver updates

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

ease of use

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.

forward compatibility with new hardware

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

and regular-user-mode access.

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.

[crazyates]

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

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.

[kano]

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

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

[kano]

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

http://s16.postimg.org/kpvvw1v6d/Bildschirmfoto_2013_03_30_um_01_24_34.png

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

[CrazyGuy]

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

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

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

[juhakall]

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

http://s16.postimg.org/kpvvw1v6d/Bildschirmfoto_2013_03_30_um_01_24_34.png

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

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.

[Luke-Jr]

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

http://s16.postimg.org/kpvvw1v6d/Bildschirmfoto_2013_03_30_um_01_24_34.png

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

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.

I intentionally did not merge this regression into BFGMiner.

[crazyates]

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.

[Luke-Jr]

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.

Cool story bro.

[SkyNet]

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?

[PatMan]

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?

Linux or windoze?

If Linux, try: sudo aticonfig --adapter=all -f --initial

Reboot.

[SkyNet]

Win-doze

[PatMan]

Win-doze

There's yer problem.

I used to use windoze for mining - too many problems like you're having. I seem to remember having to completely uninstall & reinstall driver + sdk to get rid of that, but I can't really remember TBH - I kind of erased it from my memory deliberately sort of thing....

[SkyNet]

damn thanks anyway
I am not really accustomed to the linux environment so I haven't tried it yet