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

[AngusCanine]

when using 4.0.1 what should my bat file look like for overclocking antminer u1

edit : thank you ckolivas for the speedy reply on the other thread

[-ck]

when using 4.0.1 what should my bat file look like for overclocking antminer u1

Whatever it normally looks like plus: --anu-freq 250

[AngusCanine]

when using 4.0.1 what should my bat file look like for overclocking antminer u1

[/quote)
Whatever it normally looks like plus: --anu-freq 250

works perfectly

[Internet151]

Tried out 4.0.1 with my hashfast babyjets with upgraded 0.4 preview firmware. I noticed now when a babyjet reconnects for any reason it will keep it's name (ex. HFB 0) in the cgminer window, but in the API it will get a new name (ex. HFB 14) instead of just reactivating the old name. It's not really high priority, but id help clean up the stats I'm pulling from the API if this was corrected.

Also, had a few cases were 4.0.1 crashed when a babyjet hit 90C, went back to 3.12.0 and this did not reoccur.

EDIT: Also, cpu usage by cgminer seems to have greatly increased. I noticed these things with two machines running Windows 7.

[HellDiverUK]

Is there a way to ban Luke from this thread? I suggest asking Theymos.

I suggest you keep your nose out of it. 

[canford]

Will do, I have reverted the erupters to 3.12.3, which works great.  The bitcoin mining world is an odd combination of old and new hardware, I'm just running everything I have.  I suppose the financially logical thing to do would be to flip the erupters on Ebay, but I'd rather mine with them as long as they make more than the cost of the electricity that they consume.  Right now, the Avalon Mini + BE's make about $6 a day but cost around $4.  When that line is crossed, the tough thing will be throwing away working hardware, which the engineer in me hates the idea of.

Indeed, it's tough, but I'm pretty sure the erupters fell below their electricity costs a while ago, though I don't have the numbers here. You could always bet on BTC going $10k in the future and thus mining at an electricity cost loss now will pay off longer term... or you could just sell them now for more than they'll ever earn anyway (highly recommend the latter). Anyway in a future version I'll be more lax for these slowest devices left that cgminer still mines on, as this was clearly an oversight on my part. The next slowest device is a normally clocked antminer U1 at 1.6GH, and everyone overclocks them to 2GH anyway, so the difference is stark.

I ran all the numbers today in an excel spreadsheet.  First, let me say that I am mining bitcoin because I believe in bitcoin, so making money would be great but it is not a requirement.  Having run the numbers through, it appears that the Block Erupters and Avalon Mini do indeed make a small profit: Per day electricity cost $1.98, income $4.93, profit $2.95.  This is at the current 3.82G difficulty.  So it looks like 110nm has a little run life left.  I'm going to keep mining and perhaps expand the operation, depending on what happens as the all of the pre-orders are delivered and people mine regardless of cost to recoup what they can.  Interesting days ahead.  Thanks again CK for keeping cgminer up to date.

[KyrosKrane]

I've noticed two odd behaviors with cgminer since switching to 4.0.1.  This is on Ubuntu 13.10 using the precompiled 64-bit binary of cgminer.  I have a small farm of 31 USB Block Erupters set up on this rig.  I configured the box using the instructions in the README file for USB devices running as a non-root user on Linux. Starting cgminer, they all run fine.

First thing, if I restart cgminer (using Settings -> Restart ->Yes), cgminer throws a "SEM" error for each device saying the devices are already in use.  Even if I wait a bit, cgminer doesn't re-detect them using hotplug.  I'll try to get you the exact error message if you need it.  Exiting cgminer then immediately restarting from the command line works fine; it instantly detects the devices and starts mining.

Second thing, cgminer doesn't seem to save queue settings.  I run p2pool, which recommends a queue of zero.  I set the queue (using Settings -> Queue -> 0), and it confirms the queue is set to zero.  Then I write the config file (Write -> type in path and name) and the summary screen that comes up shows a non-zero value for the queue.  After leaving the node running for a few days, I checked this morning and the queue size was at a stunning 4808! It manifested as a 6% drop in the hash rate for the devices.  Normally they run at a steady 335MH/s, give or take a 1%.  Today I found them at 315MH/s.

[deagel]

hi,
is there an option to use a http proxy on multi pools?

i found this but it is only for single pools:

Code:

EXECUTIVE SUMMARY ON USAGE:

Single pool:

cgminer -o http://pool:port -u username -p password

Multiple pools:

cgminer -o http://pool1:port -u pool1username -p pool1password -o http://pool2:port -u pool2usernmae -p pool2password

Single pool with a standard http proxy:

cgminer -o "http:proxy:port|http://pool:port" -u username -p password

Single pool with a socks5 proxy:

cgminer -o "socks5:proxy:port|http://pool:port" -u username -p password

Single pool with stratum protocol support:

cgminer -o stratum+tcp://pool:port -u username -p password

The list of proxy types are:
 http:    standard http 1.1 proxy
 http0:   http 1.0 proxy
 socks4:  socks4 proxy
 socks5:  socks5 proxy
 socks4a: socks4a proxy
 socks5h: socks5 proxy using a hostname

[kano]

hi,
is there an option to use a http proxy on multi pools?
...

You use a proxy setting on each pool you want a proxy for ...

[-ck]

I've noticed two odd behaviors with cgminer since switching to 4.0.1.  This is on Ubuntu 13.10 using the precompiled 64-bit binary of cgminer.  I have a small farm of 31 USB Block Erupters set up on this rig.  I configured the box using the instructions in the README file for USB devices running as a non-root user on Linux. Starting cgminer, they all run fine.

First thing, if I restart cgminer (using Settings -> Restart ->Yes), cgminer throws a "SEM" error for each device saying the devices are already in use.  Even if I wait a bit, cgminer doesn't re-detect them using hotplug.  I'll try to get you the exact error message if you need it.  Exiting cgminer then immediately restarting from the command line works fine; it instantly detects the devices and starts mining.

Second thing, cgminer doesn't seem to save queue settings.  I run p2pool, which recommends a queue of zero.  I set the queue (using Settings -> Queue -> 0), and it confirms the queue is set to zero.  Then I write the config file (Write -> type in path and name) and the summary screen that comes up shows a non-zero value for the queue.  After leaving the node running for a few days, I checked this morning and the queue size was at a stunning 4808! It manifested as a 6% drop in the hash rate for the devices.  Normally they run at a steady 335MH/s, give or take a 1%.  Today I found them at 315MH/s.

Yep restart's pretty broken. It's another one of those features from the GPU days unfortunately and shutting down all these threads reliably is really hard. I mentioned it a few pages back that only quit and start works. If I had infinite hours to work on it I'd eventually fix it, but new device drivers/features keep taking priority sorry.

I changed the queue size to auto adjust every time it hits zero now since it shouldn't - and there are devices with massive hashrates that need a huge queue to keep busy. Unfortunately that seems to be fighting with you trying to set it to zero, but that shouldn't actually drop the hashrate unless you're running out of cpu. So yeah it's not ideal. Kinda hard writing code for 333MH and 50TH setups at the same time. Lemme think about it. This might need a new command line option.

[KyrosKrane]

I changed the queue size to auto adjust every time it hits zero now since it shouldn't - and there are devices with massive hashrates that need a huge queue to keep busy. Unfortunately that seems to be fighting with you trying to set it to zero, but that shouldn't actually drop the hashrate unless you're running out of cpu. So yeah it's not ideal. Kinda hard writing code for 333MH and 50TH setups at the same time. Lemme think about it. This might need a new command line option.

Awesome, thanks for the update.  I'm not worried about the restart, so long as you're aware of it and it isn't a symptom of something else being broken.  Exit/restart works fine for me.

For the other, could I set the work queue to 1 as a workaround? Or would the system still try to raise it?

As for CPU, that's possible, I guess.  I'm running on a decade-or-so old Pentium dual-core box.  I'll see if I can set up some kind of CPU monitoring.

[M3kk]

Hello, what i need to set to --api-allow to be accesed from ANY ip? Not only 127.0.0.1 and 192.168.0.x, but from 192.168.x.x too for example.. W:192.168.0.0/24,127.0.0.1 is only for localhost and 192.168.0.x ...

Ty.

LE: Nevermind, i think this is "W:0/0" .

[crazyates]

Hello, what i need to set to --api-allow to be accesed from ANY ip? Not only 127.0.0.1 and 192.168.0.x, but from 192.168.x.x too for example.. W:192.168.0.0/24,127.0.0.1 is only for localhost and 192.168.0.x ...

Ty.

LE: Nevermind, i think this is "W:0/0" .

W:192.168.0.0/16 would allow anyone on the 192.168.x.x range.

[kano]

Hello, what i need to set to --api-allow to be accesed from ANY ip? Not only 127.0.0.1 and 192.168.0.x, but from 192.168.x.x too for example.. W:192.168.0.0/24,127.0.0.1 is only for localhost and 192.168.0.x ...

Ty.

LE: Nevermind, i think this is "W:0/0" .

Seriously, that's a bad idea in general.
It means anyone with any access (local or remote) to your miner can change anything they like ... including who it mines for.
That's what KFC put in their miners originally, no idea if they ever fixed it.

Also, 192.168/16 will also work

[JoseSan]

Kinda hard writing code for 333MH and 50TH setups at the same time.

Well that piqued my curiosity...

[-ck]

Kinda hard writing code for 333MH and 50TH setups at the same time.

Well that piqued my curiosity...

Icedrill still don't have the controllers they require to run all the Sierras they're getting from hashfast. This means a LOT of devices are being attached to less controllers(PCs running cgminer), and to make matters worse, the hashfast devices don't actually ntime roll internally in their firmware the way the documentation claims, which means cgminer has to actually generate every single work item for these devices, which is usually ~2300 at a time. We found the i3 in one laptop could reliably run about 50TH of Sierras. Note that this is thousands of time more work than a pool receiving and processing 50TH of shares.

...gotta love the efficiency of well written c code.

[nowaltcoin]

Good morning


is there any way to tell cgminer (newest version) not to use some devices?

Story:

I'am using some NFY-Devices with BFGMiner. (stable for now more than 4 month)
But i did not get my BiFury and Redfury running with BFGMiner so i use CGMiner for these.

The last weeks CGMiner is starting crashing constantly every 6-10 hours. (with usblib errors on alternating devices)
So i downloaded the 4.0.1 Version and it is more stable (crash every 18-24 hours)

But this version is complaining about the NFY-Devices ( should consult the readme about the right usb-lib drivers for the devices)

So any hint are very welcome

[kano]

Good morning

is there any way to tell cgminer (newest version) not to use some devices?

...

So any hint are very welcome

What does ./cgminer -n say?

You may be able to ignore them with --usb

[-ck]

But this version is complaining about the NFY-Devices ( should consult the readme about the right usb-lib drivers for the devices)

Every single USB device on cgminer uses exactly the same USB driver. Crashes should never happen, and any debugging would be most appreciated as per:
http://ck.kolivas.org/apps/cgminer/debug/README-debug

If you're not interested in helping the developers debug issues with the software you're depending on for free, feel free to read how to use the --usb command (as Kano has suggested) from the readme, to choose only the devices you want it to work on.

[nowaltcoin]

Good morning

is there any way to tell cgminer (newest version) not to use some devices?

...

So any hint are very welcome

What does ./cgminer -n say?

You may be able to ignore them with --usb

failed to open USB DEV4 - DEV13 err -12

Thanks for helping!