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

[Karin]

Unofficial Mac binaries updated to 3.3.4 at http://spaceman.ca/cgminer.

This directly relates to the whole libusb monologue I've been having in here over the last month
That specifically means your libusb on your mac is bugged - the timeout option when doing I/O isn't working
The README says how to build with a working libusb and it works on Linux and Windows - no idea about a Mac ...
Tell whoever Karin is to read the README ...

Karin, read the README 

I'm Karin!

I keep a very close eye on the readme's (even following their changes on github), and I've tried using rc10 but if I recall it had no effect on this bug on Macs, so I instead include the latest libusb in my builds.

Kano makes it sounds like the error confidently lies within libusb, so I'll do a full spectrum of tests with various libusb versions.  If I can find a version that works I will update cgminer for Mac OS X and Asteroid (my Mac GUI to cgminer) accordingly.

Otherwise, we'll have to dig deeper into libusb, and any errors generated from cgminer (and what the community can help with) would be our best bet in figuring out the issue with libusb + Macs.  I'll try and do these test builds tonight and will post back with what I find.

[ISAWHIM]

I have an issue with the latest CGMINER...

Instead of showing the number of "Accepted" and "Rejected" A: 2 R:1 HW: 0... it shows the "last diff" of the last accepted block for accepted and rejected, eg, for my scrypt-coins it shows...
A: 70687 R :68799 (Wow, great, 70687 accepted blocks and only 68799 rejects! From submitting two blocks!) lol

Those are the DIFFs of the coins I am mining, 70.7K and 68.8K were the two found.

Why did this change, and how do I get it back to show the NUMBER of accepted so I can see when ACCEPTED vs REJECTED, to gauge the effectiveness of the coins I am mining. Without knowing the number of accepted coins, that stat is useless. Why would we care what the DIFF was, in the stats?

This is not what it should be showing us... something is wrong... as per the readme and sample screen-shots...

Each column is as follows:
5s:  A 5 second exponentially decaying average hash rate
avg: An all time average hash rate
Q:   The number of requested (Queued) work items from the pools
A:   The number of Accepted shares
R:   The number of Rejected shares
HW:  The number of HardWare errors
E:   The Efficiency defined as number of shares returned / work item
U:   The Utility defined as the number of shares / minute

I also notice it is throwing-off other stats... hope this throw-off isn't going to change the way the program makes judgement about connections...

Note: This is the windows compiled version 3.3.4, mining bottlecaps at the moment version 1.4.1.

[Skitzzo]

I'm Karin!

I keep a very close eye on the readme's (even following their changes on github), and I've tried using rc10 but if I recall it had no effect on this bug on Macs, so I instead include the latest libusb in my builds.

Kano makes it sounds like the error confidently lies within libusb, so I'll do a full spectrum of tests with various libusb versions.  If I can find a version that works I will update cgminer for Mac OS X and Asteroid (my Mac GUI to cgminer) accordingly.

Otherwise, we'll have to dig deeper into libusb, and any errors generated from cgminer (and what the community can help with) would be our best bet in figuring out the issue with libusb + Macs.  I'll try and do these test builds tonight and will post back with what I find.

I appreciate it! Let me know if you figure anything out. I'd be happy to help in any way I can and/or send you a small tip for your time as I'm basically sitting dead in the water until I can get this sorted.

[kano]

Unofficial Mac binaries updated to 3.3.4 at http://spaceman.ca/cgminer.

This directly relates to the whole libusb monologue I've been having in here over the last month
That specifically means your libusb on your mac is bugged - the timeout option when doing I/O isn't working
The README says how to build with a working libusb and it works on Linux and Windows - no idea about a Mac ...
Tell whoever Karin is to read the README ...

Karin, read the README 

I'm Karin!

I keep a very close eye on the readme's (even following their changes on github), and I've tried using rc10 but if I recall it had no effect on this bug on Macs, so I instead include the latest libusb in my builds.

Kano makes it sounds like the error confidently lies within libusb, so I'll do a full spectrum of tests with various libusb versions.  If I can find a version that works I will update cgminer for Mac OS X and Asteroid (my Mac GUI to cgminer) accordingly.

Otherwise, we'll have to dig deeper into libusb, and any errors generated from cgminer (and what the community can help with) would be our best bet in figuring out the issue with libusb + Macs.  I'll try and do these test builds tonight and will post back with what I find.

Yes the problem is clearly libusb.
As I have already stated, I can run two different libusb versions on the same architecture and one works while the other doesn't.
The test problem that I've mentioned in here a few times is standalone code (bits and pieces of the code I've written in cgminer - but modified) and that shows if timeouts are working ... and if they are matching the expected values also.

https://bitcointalk.org/index.php?topic=28402.msg2817682;topicseen#msg2817682
https://bitcointalk.org/index.php?topic=28402.msg2846296;topicseen#msg2846296
https://bitcointalk.org/index.php?topic=28402.msg2938585;topicseen#msg2938585

That specific version - libusb-1.0.16-rc10 - works on Linux and Windows
I've seen other 1.0.16 versions that don't work ... thus using the 'latest' libusb is not guaranteed to solve it.
Also, libusb has 2 sources: libusb and libusbx, and some OSs provide libusbx instead of libusb

The README also states how to use the libusb mentioned

[Trongersoll]

There probably a simple answer to this, what do you do when the number of erupters you are running pushes the display off the bottom of the screen. So far I've been getting by with a smaller font, but that will only work so long.

[mdude77]

There probably a simple answer to this, what do you do when the number of erupters you are running pushes the display off the bottom of the screen. So far I've been getting by with a smaller font, but that will only work so long.

resize the window.  click on the box in top left, click properties.  go to layout and increase the window height.  you may need to restart it for it to take effect.  (I assume you're talking windows)

M

[Trongersoll]

There probably a simple answer to this, what do you do when the number of erupters you are running pushes the display off the bottom of the screen. So far I've been getting by with a smaller font, but that will only work so long.

resize the window.  click on the box in top left, click properties.  go to layout and increase the window height.  you may need to restart it for it to take effect.  (I assume you're talking windows)

M

actually, i'm using linux. I know how to resize the window, the question is how to cope when the biggest window that will fit on the screen doesn't have enough rows.

[easynote]

I cant put this program work on my Win 8 64bits... its strange!

it shutdown after I put the data of pool, user and pass...

[twmz]

There probably a simple answer to this, what do you do when the number of erupters you are running pushes the display off the bottom of the screen. So far I've been getting by with a smaller font, but that will only work so long.

resize the window.  click on the box in top left, click properties.  go to layout and increase the window height.  you may need to restart it for it to take effect.  (I assume you're talking windows)

M

actually, i'm using linux. I know how to resize the window, the question is how to cope when the biggest window that will fit on the screen doesn't have enough rows.

Use --compact mode and stop get per device statistics from the API (some kind of dashboard, etc) instead of by looking at the screen.

[ajw107]

Yeah, I use CGWatcher http://manotechnology.blogspot.co.uk/p/cgwatcher.html on windows, there are a few web based ones for Linux too.  the are very handy, and restart CGMiner when it gets a bit confused, or graphics/usb driver restarts, etc...

[Askit2]

There probably a simple answer to this, what do you do when the number of erupters you are running pushes the display off the bottom of the screen. So far I've been getting by with a smaller font, but that will only work so long.

resize the window.  click on the box in top left, click properties.  go to layout and increase the window height.  you may need to restart it for it to take effect.  (I assume you're talking windows)

M

actually, i'm using linux. I know how to resize the window, the question is how to cope when the biggest window that will fit on the screen doesn't have enough rows.

use --usb and the block erupter code : a number that fits, then make a terminal session alt+F1 to alt+F6 for additional units. Limits the number of erupters per window, keeps all stats and allows them all to work. It can be especially helpful for adding less variance. I don't bother running the hashing units with x running. less resources and all....

[-Redacted-]

You do know that the up and down arrows work to scroll the top section of the screen when there is more than fits, right?

[Trongersoll]

You do know that the up and down arrows work to scroll the top section of the screen when there is more than fits, right?

no i didn't, the top just keeps pushin' the bottom down.

[OtaconEmmerich]

I think I figured out what the problem I had with my Tablet setup, I think using the OTG cable adds an extra "hub" to introduce lag into the data pipeline causing errors. That's why it worked when I hooked the BE directly but not with the hub. So even if I DID get Serial-USB working(Android doesn't seem to have that in the stock kernel) I think I'd have the same problems happening. At least I've eliminated the fact it wasn't a LibUSB problem. Now the million dollar question is HOW can I fix this? I'll post specs for the "Linux Root Hub" (The OTG cable) Later. I think messing with that might fix the problem I'm having.

[OtaconEmmerich]

Nope, seems I was entirely wrong. It was a issue with Android not supporting USB Host mode out of the Box and I think I have the wrong OTG cable. I need to get a Y cable. So pretty much my Tablet was trying to run the BE's without taking in the extra power.

[ChiangYay]

HELP CGminer load only GPU 0.
LTC Mining.

I have 3 GPUs but at startup CGminer load only GPU 0, I have to add the other 2 manually.
Probably there is some mistake in my CGminer .bat and/or .conf.
I folloved the instruction from  Con Kolivas and wrote the conf file but something must be wrong.
Any help would be appreciated.

BAT FILE

timeout /t 30
"C:\CGminer\cgminer-3.3.4-windows\cgminer-3.3.4-windows\cgminer.exe" --gpu-platform 0 -d 0 -w 256 -v 1 -I 19 -g 1 -l 1  --thread-concurrency 21712
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1
  
CONF FILE

{
"pools" : [
   {
      "url" : "stratum+tcp://coinotron.com:3334",
      "user" : "xxxxxxxxxxx",
      "pass" : "xxxxx"
   },
   {
      "url" : "http://stratum.give-me-coins.com:3333",
      "user" : "xxxxxxxxxx",
      "pass" : "xxxxxx"
   }
]
,
"intensity" : "19,19,19",
"vectors" : "1,1,1",
"worksize" : "256,256,256",
"kernel" : "scrypt,scrypt,scrypt",
"lookup-gap" : "0,0,0",
"thread-concurrency" : "21712,21712,21712",
"shaders" : "1792,1792,1792",
"gpu-engine" : "0-0,0-0,0-0",
"gpu-fan" : "0-85,0-85,0-85",
"gpu-memclock" : "0,0,0",
"gpu-memdiff" : "0,0,0",
"gpu-powertune" : "0,0,0",
"gpu-vddc" : "0.000,0.000,0.000",
"temp-cutoff" : "95,95,95",
"temp-overheat" : "85,85,85",
"temp-target" : "75,75,75",
"api-port" : "4028",
"expiry" : "120",
"gpu-dyninterval" : "7",
"gpu-platform" : "0",
"gpu-threads" : "1",
"hotplug" : "5",
"log" : "1",
"no-pool-disable" : true,
"queue" : "1",
"scan-time" : "30",
"scrypt" : true,
"temp-hysteresis" : "3",
"shares" : "0",
"kernel-path" : "/usr/local/bin",
"device" : "0"
}

Software/HARDWARE

Catalyst Version 13.4
CGminer 3.3.4
Windows 7 64 bit
ASRock 970 Extreme4 MOBO
AMD Athlon II Processor  
3 x Sapphire Radeon Vapor-X HD 7950 OC with Boost 3 GB
Corsair Professional Series 860-Watt
3 x PCI-E riser cable
8 GB  DDR3 SDRAM (4 x 4GB)
Plastic Crate

 
Thanks.

ChiangYay

[-ck]

I have 3 GPUs but at startup CGminer load only GPU 0, I have to add the other 2 manually.

"C:\CGminer\cgminer-3.3.4-windows\cgminer-3.3.4-windows\cgminer.exe" --gpu-platform 0 -d 0 -w 256 -v 1 -I 19 -g 1 -l 1  --thread-concurrency 21712

-d 0 is telling it to only use GPU 0, so get rid of it

[Fiyasko]

I cant put this program work on my Win 8 64bits... its strange!

it shutdown after I put the data of pool, user and pass...

Make sure that the information that you are entering is correct, If there are any errors, the CGMiner cmd window will just close really fast.

[ksenter]

Sorry if this has been mentioned before.  I just wanted to let you know that ever since I got my little single late last week cgminer has stopped 3 times.  I just come back and the window for it isn't up anymore.  After the second time it happened I wrote a little batch file to check if the process is running and start it if it isn't and scheduled it to run every 5 minutes.  So it's not a big deal.  I just never saw that happen back with the GPUs.  My guess is that the little single is disconnecting or erroring or something and cgminer is seeing no device and closing.  But that is just a wild guess on my part.  Any thoughts?  I'm running the latest cgminer, with p2pool on windows 8 x64 (I know, I should probably switch to Linux, maybe eventually).

By the way, I just sent a small donation to Kano and ckolivas for all of your hard work.  You guys rock!

[xyzzy099]

I've been away for a while and decided to give 3.3 another shot since kano et al are singing its praises everywhere.

3.3.4 using libusb-1.0.16-rc10 compiled from sourceforge still shuts down half of my 4x AM USB eruptors when running on Debian amd64 with USB disconnects. If there's some sort of logs you would like let me to post, let me know what you would like to see, but compiling a newer libusb absolutely *does not* solve the problem.

Back to 3.1.1 where everything works fine.

I seem to be having a similar problem on Win7x64 with WinUSB (via Zadig).  I have 10 BEs, and every couple of hours, at least one will stop working with an error like this:

Code:

AMU0: Comms error (werr=-7 amt=0)

I tried using different hubs and tried using no more than 4 BEs in each 7-port HUB, in case it was a power issue, but nothing helps.

I have not tried using 3.1.1 yet, but I guess that is my next step.  This is very frustrating.

[Edit: I should add that if CGMiner is restarted, it will not pick up the BE that apparently failed.  It will seem to be OK, in that Windows says it is OK, and working, but the LED will stay on steady, and I have to manually unplug and replug it to get it to be seen by CGMINER.]

If anyone cares, I switched these Block Erupters over to my Linux box using BFGMiner, and now they are 100% rock solid.  I don't know if the problem is CGMiner or WinUSB, but my stuff works now.