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

[kano]

...
I can see why members of this community refused to work with you.

As long as that includes you - I am indeed thankful.

[Kuma]

Hi Kano,
I'd like to thank you, I tried your GIT version and it solved my problems with BFL and ZTEX devices connected to the same machine.
Under latest 2.10.4 and many previous versions I have seen many comm errors from BFL devices as well as errors with ZTEXes (when BFLs were removed no such errors appeared) leading to the seqfault in cgminer. I'm guessing the problem was solved by using libusb for BFL?
Currently it runs for 48 hours without any problem. Will be your branch merged completely to the cgminer?

[kano]

Hi Kano,
I'd like to thank you, I tried your GIT version and it solved my problems with BFL and ZTEX devices connected to the same machine.
Under latest 2.10.4 and many previous versions I have seen many comm errors from BFL devices as well as errors with ZTEXes (when BFLs were removed no such errors appeared) leading to the seqfault in cgminer. I'm guessing the problem was solved by using libusb for BFL?
Currently it runs for 48 hours without any problem. Will be your branch merged completely to the cgminer?

Very likely to all be pulled into ckolivas' git, unless I've messed something up somewhere, it should go in when ckolivas gets back.
https://bitcointalk.org/index.php?topic=28402.msg1427509#msg1427509
I have a pull request that everything moves into as I work on it while he is away, and I have a list of things I want to get done also.

One of the 2 main reasons behind the USB changes is the upcoming ASIC, coz I'm sure there will be problems with ASIC and serial-USB
the other reason is as I've said a few times in the past to a few people, serial-USB sux - direct USB - using libusb - is way better.
With direct USB the interface is almost as simple as serial-USB (once you understand it) but you optionally have more control over it if you want and you can access anything extra the device allows that serial-USB may not allow.

Once all devices are working through the same library (and working the same on both windows and linux) I was hoping ... as you are suggesting ... that there should be fewer problems.
Thanks for the feedback!

The only one left is Icarus, but I'm not sure when I'll get around to that (it's a different USB device pl2303 - and I'm not expecting any ASIC's to use that - so I'm in no rush to redo that code)
I'm running all my FPGAs on a single cgminer at the moment - 2xIcarus, 1xBFL and 1xMMQ and they are behaving well together.
It's summer here also - so a good test of handling heat problems.

Edit: there is one issue I know of, and that is when a device is lost (by libusb or disappears off the USB bus) that cgminer can crash after it gets a USB error -99 or -6 (which means the device has disappeared) coz it keeps talking to libusb and libusb doesn't like that (and crashes)
I'll add a way to deal with that properly soon - but it should be very rare to happen.

--

And if anyone was interested, in my master git (and the git pull to ckolivas) I've updated miner.php to optionally allow (very simple) password protection - the change is documented in the new API-README with it

Edit: my git: https://github.com/kanoi/cgminer/commits/master

[mining4fun11]

Is there any support for the x6500 with cgminer?  I know bfgminer has it but I really prefer cgminer. 

[Luke-Jr]

Is there any support for the x6500 with cgminer?  I know bfgminer has it but I really prefer cgminer.

Why do you prefer cgminer?

[mining4fun11]

Is there any support for the x6500 with cgminer?  I know bfgminer has it but I really prefer cgminer.

Why do you prefer cgminer?

I have been using it since I started mining. 

[Luke-Jr]

Is there any support for the x6500 with cgminer?  I know bfgminer has it but I really prefer cgminer.

Why do you prefer cgminer?

I have been using it since I started mining.

I don't follow; why is that a reason to prefer it? If there is something cgminer does that BFGMiner doesn't, that you find value in, I'd prefer to add it to BFGMiner.

[crazyates]

Is there any support for the x6500 with cgminer?  I know bfgminer has it but I really prefer cgminer.

Why do you prefer cgminer?

I have been using it since I started mining.

I don't follow; why is that a reason to prefer it? If there is something cgminer does that BFGMiner doesn't, that you find value in, I'd prefer to add it to BFGMiner.

You can't just "add" what CGMiner has into BFGminer, as hard as you might try.

[sharky112065]

Is there any support for the x6500 with cgminer?  I know bfgminer has it but I really prefer cgminer.

Why do you prefer cgminer?

I don't know about him or her, but for me and probably others, the reason I will never switch to the hostile fork called bfgminer is because the original cgminer is still actively maintained. Requested changes get addressed in a timely manner and improvements continue to be added along the way. Why would people want to use your hostile fork of cgminer just because you did not have the paitience to work with the cgminer team and work with them to get your changes in?

So I and probably others see you as wah wah wah, I don't get my changes in fast enough so I'll fork it and lure the noobs over to it and continually try to poach cgminer users over to it.

Grow the fuck up already.

[Luke-Jr]

you did not have the paitience to work with the cgminer team and work with them to get your changes in?

It's not a matter of patience or working with, it's a matter of Con demanding I pay to get even bugfixes merged, and Kano undoing even bugfixes because he's too incompetent to use git and Con doesn't care.

[mining4fun11]

Ok so back to my question.  Does cgminer offer support for x6500.

[marke74.miner]

Had a problem with all versions of CGMiner not enabling the devices (GPUs) from the configuration file. IE
if the config file contains the following

"Device" : "0",
"Device" : "1",
"Device" : "2"

only the last entry GPU 2 would be enabled.
I fixed this by editing the source and adding Device0, Device1......Device7 to the configuration tables.
Now the lines in the config file would look like this

"Device0" : "0",
"Device1" : "1",
"Device2" : "2"

 Works great! All 3 devices are enabled on startup. I know it's not fixes the real issue but more of a patch.
Anyone interested and I can send the changes to you.

Onto a new issue. I want to beable to control remotely what pool is selected. Since I have 9 rigs I want to do this programatically. I am very knowledable of VB and linux, but am new to JSON/RPC. I would like to be able to send such a command via the network interface using RPC via VBA.net. From looking at the cgminer source RPC/JSON commands are accepted through the use of port 4028. What would be the simpliest way to send an RPC packet from VBA.net to switch to pool 2 and viceversa switch to pool 0.

Any help would be appreciated. I have exhausted the third party addons for JSON serialization and RPC protocal and have not come accross a viable solution.

Thanks,
Mark   
 
 

[kano]

you did not have the paitience to work with the cgminer team and work with them to get your changes in?

It's not a matter of patience or working with, it's a matter of Con demanding I pay to get even bugfixes merged, and Kano undoing even bugfixes because he's too incompetent to use git and Con doesn't care.

WTF are you talking about.

Luke you are completely delusional.
WTF is that red part I have highlighted? What drugs have you been taking that have turned your brain to mush? (a long time ago ...)

The undo, that you said was the cause of you making a fork, you have even admitted you were wrong about and offered to pay me BTC for the trouble (hours) I had spent to get the full details about that, that proved I was correct (which of course I rejected any payment)
https://bitcointalk.org/index.php?topic=90656.msg1003391#msg1003391

On more than one occasion you have put up pull requests that were detrimental to cgminer - as you well knew - and of course those were rejected.
The most recent example of that was your Stratum commit that is still there for all to see how stupid it is, that would make cgminer get the transaction list multiple times from the pool even though each time it would get exactly the same transaction list - due to the fact that new work was not sent by the pool (should I also including the issue about the waste of time getting the actual transaction list? ... since no code anywhere, even in your crappy clone, does anything of use with it?)

[kano]

...
Onto a new issue. I want to beable to control remotely what pool is selected.
...

Thanks,
Mark

The API is a simple send one command and get a reply (and close) TCP/IP socket.
The command can be sent in JSON or simple text.

The text to send a pool switch (to pool 2) is:
'switchpool|2'
 or
'{"command":"switchpool","parameter":"2"}'

The documentation of the API is in API-README

There are 3 sample programs that will talk to the API
API.java
api-example.c
api-example.php

The API has a level of IP address security - that groups commands based on:
 non-priviliged: that report information
 priviliged: that change cgminer
Read more about that in API-README and the options required to allow access and priviliged access.

[kano]

Ok so back to my question.  Does cgminer offer support for x6500.

No, neither of us have an x6500 so we have not written an x6500 driver and no one else has done so for cgminer.

For me, I work on (or rewrite) drivers for the devices I have - I currently have: 2xIcarus, 1xBFL and 1xMMQ
(and of course I wrote the API and have done other changes here and there ... and I posted above yesterday)
I also wrote all the original changes to the Icarus driver to support other Icarus devices ... like Lancelot and Carinsmore1
(--icarus-timing and --icarus-options)

The ZTex support in cgminer was written by nelisky and thus why it is there.
Unfortunately nelisky decided he didn't have time and dropped the ball on that one.
However Dennis2342 has recently taken up the work on that with the help of the developer who wrote libusb and thus ZTex support is still there for cgminer

[Bigal]

Onto a new issue. I want to beable to control remotely what pool is selected. Since I have 9 rigs I want to do this programatically. I am very knowledable of VB and linux, but am new to JSON/RPC. I would like to be able to send such a command via the network interface using RPC via VBA.net. From looking at the cgminer source RPC/JSON commands are accepted through the use of port 4028. What would be the simpliest way to send an RPC packet from VBA.net to switch to pool 2 and viceversa switch to pool 0.

Any help would be appreciated. I have exhausted the third party addons for JSON serialization and RPC protocal and have not come accross a viable solution.

Thanks,
Mark    

Here's how to do it in C# (there are probably other ways as well)

Code:

private void sendCommand(string command)
        {
            try
            {
                System.Net.Sockets.TcpClient clientSocket = new System.Net.Sockets.TcpClient();
                clientSocket.Connect("192.168.10.2", 4028);
                NetworkStream serverStream = clientSocket.GetStream();
                byte[] outStream = System.Text.Encoding.ASCII.GetBytes(command);
                serverStream.Write(outStream, 0, outStream.Length);
                serverStream.Flush();

                byte[] inStream = new byte[65536];
                serverStream.Read(inStream, 0, (int)clientSocket.ReceiveBufferSize);
                string returnData = System.Text.Encoding.ASCII.GetString(inStream);
                displayMessage(returnData);
                clientSocket.Close();
            }
            catch (Exception exc)
            {
            }
        }

and in VB.net

Code:

Private Sub sendCommand(command As String)
	Try
		Dim clientSocket As New System.Net.Sockets.TcpClient()
		clientSocket.Connect("192.168.10.2", 4028)
		Dim serverStream As NetworkStream = clientSocket.GetStream()
		Dim outStream As Byte() = System.Text.Encoding.ASCII.GetBytes(command)
		serverStream.Write(outStream, 0, outStream.Length)
		serverStream.Flush()

		Dim inStream As Byte() = New Byte(65536) {}
		serverStream.Read(inStream, 0, CInt(clientSocket.ReceiveBufferSize))
		Dim returnData As String = System.Text.Encoding.ASCII.GetString(inStream)
		displayMessage(returnData)
		clientSocket.Close()
	Catch exc As Exception
	End Try
End Sub

Here's a quick little gui exe in the bin folder and the source to send some commands either simple text or json formatted no need for any added library.
Cgminer_RPC

[marke74.miner]

Here's a quick little gui exe in the bin folder and the source to send some commands either simple text or json formatted no need for any added library.
Cgminer_RPC

Thanks, the biggest hurdle was trying to establish a connection. The windows api sockets didn't want to establish one. But I now know why after reading the APIReadme (you have to tell cgminer to listen). Who would have guessed there would be seperate readme for the API.....daaaaahhh on me.

I will play with this tonight. Thanks Kano / Bigal!!

I didn't even see the API-README because I've been brainwashed for windows for so many years that it didn't register in my small brain of mine that linux doesn't need the .txt on the end. I did find the standard readme though. Got to have atleast one point for reading it first before posting right?

I welcome you to hit me on top of the head with a frying pan and wake me up.


Thanks guys, much appreaciated,
Mark

[kano]

2.10.4f
An Xubuntu 11.04 x86_64 executable is in my github called cgminer-2.10.4f
https://github.com/kanoi/cgminer-binaries
(it also works on Fedora 16 and 17)

This includes all the pull request changes I've made since 2.10.4

oldest first:

   Kano    BFL libusb driver    cbf6c71
   Kano    BFL USB build changes    040ec58
   Kano    BFL report USB device numbers for init errors and allow faster 'reinit'    b099615
   Kano    BFL USB - README and FPGA-README    70b47a7
   Kano    BFL include all USB requirements    03c2cab
   Kano    BFL USB api.c usbstats    07db1ed
   Kano    BFL USB longer timeout    211b0f4
   Kano    Remember best share per pool and return in API pools    03f626e
   Kano    Correct API version to match docs    abaaf93
   Kano    zero (most) API stats    4c2f26e
   Kano    BFL USB correct usb stats id    44ec755
   Kano    miner.php optional user/pass login restrictions    910764d
   Kano    miner.php user/pass fix 'usr' is readonly    aaddf5b
   Kano    diffexactone pool diff1 used for share value calculation is ffffffff.… …    6382b0c
   Kano    rename device_api -> device_drv and all related api -> drv and add a … …    fe508ba
   Kano    device_drv missing drv for cpu and incorrect test    774944c
   Kano    device_drv - allow .name to be changed before add_cgpu()    f9b0751
   Kano    increase device status string length    400dc17
   Kano    api.c pgaenable not re-enabling the device - plus related debug    8b078fc
   Kano    API zero - zero statistics - all or bestshare - with optional on scre… …    8d59ab5
   Kano    BFL minimise first initialisation failure delay since it is common    72253d2
   Kano    2.10.4f


English version of the most notable of the above:
New BFL USB driver that only uses libusb (and autodetects all BFLs)
miner.php optional password security
Best Share also recorded per pool and available from the API
API pgaenable fix (didn't work for multiple devices)
API zero statistics

My git contains the updated API-README, FPGA-README and README
https://github.com/kanoi/cgminer

Now some important information about the BFL USB driver.
On linux, if you wish to switch back to the old verison, you'll need to reboot your rig.
On windows (as described in FPGA-README) you'll need to update your windows USB driver
I've tested it on linux and windows with a BFL FPGA Single and also on linux had someone test with a BFL FPGA MiniRig
The 2nd MiniRig run worked fine, the first 1st didn't find all the devices but there was no debug running at the time.
I've asked Josh for access to a MiniRig for at least a few hours to track this down, but not got that access yet.
If it doesn't see all your MiniRig boards, a debug log would be much appreciated (and rerunning cgminer may then find them all)


To get the binary simply:
wget https://github.com/kanoi/cgminer-binaries/raw/master/cgminer-2.10.4f
chmod +x cgminer-2.10.4f
md5sum cgminer-2.10.4f
0ecc59cd7cfbc4a5a56031b8123edf65  cgminer-2.10.4f

For anyone who didn't realise, it's just the executable file to put in place of 'cgminer'
Nothing else needs changing
First get and extract the full binary release from ckolivas and then copy my file in place of 'cgminer'
(however, as I mentioned above, there are new *README files in my git)

No problems so far on my GPU, 'BFL+MMQ+2xICA'

Since I'm no longer GPU mining, I just run it for a while on my single 6950 to see what happens

BFL+MMQ+ICAs (2.4GH/s) on OzCoin Stratum with fixed 8 diff

The same configure options as cvolivas' binary version
In case anyone was wondering:
CFLAGS="-O2 -W -Wall" ./autogen.sh --enable-icarus --enable-bitforce --enable-ztex --enable-modminer --enable-scrypt
make clean
make

[loshia]

Kano,
When mining with icarus + Stratum and diff> 1 following happens to stats

Utility is lowed by difficulty. What i mean is that when diff equals to one (getwork) utility shows 6.4. When Diff is equal to 8 (staratum) Utility shows 0.8. Same happens to HW erros i got about 16% of HW errors when mining with diff 8. Usually when i mine with get work they are about 2%.
I know that there is some kind of stats for shares below difficulty and proper calculations can be made. Can some sort of patch to be applied, so that cgminer counts U and HW errors  for every valid share like it was diff=1 (even share was below the target. And every share to be calculated with diff 1 when speaking of the stats) when mining with startum. Having this we will be able to see our stats like we used to when minig with diff=1 .
It is good to have because lancelot stats are messed up and all uf us are using U to measure the performance. Probably other FPGA folks can benefit from it also

As stated here in log term there will be almost zero variation in stats both ways

The problem is that we can apply some math and calculate proper U and HW errors but diff is not constant when using stratum. For instance i am mining 70% of the time with diff 8 but sometimes it drops to 4 and so on. Actually i do not know  how many shares at what diff i have submited to the pool so that i can hack miner.php to show stats like i like
What about it?

Or if you can provide some sorts of formula how to calculate utility (based on api stats) for all valid shares (Difficulty accepted and the ones below target + time since cgminer is up) will be great
10X

[kano]

From the screen
U: is shares per minute, independent of their difficulty.

WU: is diff1 work done per minute. but includes all work done (even if it was stale or rejected)

HW: is currently reported at diff1 (since all current devices work at diff1)
- once cgminer supports hardware that effectively reports errors at higher than 1 difficulty, I'll add a "Difficulty Hardware Errors" to the API

From the API
The summary "Difficulty Accepted" is the equivalent amount of diff1 shares the pools have accepted.
The screen doesn't show that.
"Accepted" is just the share count ignoring difficulty.
There is of course also "Difficulty Rejected" and "Difficulty Stale" (and "Rejected" and "Stale")
In the API WU: is "Work Utility"

Anyway
To get the HW % it is currently: "Hardware Errors" / ("Hardware Errors" + "Difficulty Accepted" + "Difficulty Rejected" + "Difficulty Stale")
To get DU ("Diff1 Utility"): 60 * "Difficulty Accepted" / "Elapsed"

miner.php
I recently added more complex SQL style grouping to miner.php custompages
The next thing (probably be a while before I do it) will be to add calculations to create new fields in custompages
So then you could create a custom page with a summary field called HW% what was:
 100 * "Hardware Errors" / ("Hardware Errors" + "Difficulty Accepted" + "Difficulty Rejected" + "Difficulty Stale")
Might be a while before I do it