Bitcoin Forum
December 02, 2016, 06:30:49 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 [731] 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4814196 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
March 01, 2014, 09:13:37 PM
 #14601

- Fixed AMUs being detected as failing and resetting them too early
Does this mean it's now safe to use 4.0.1 with Block Erupters again?
That's what the change is for...

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
1480703449
Hero Member
*
Offline Offline

Posts: 1480703449

View Profile Personal Message (Offline)

Ignore
1480703449
Reply with quote  #2

1480703449
Report to moderator
1480703449
Hero Member
*
Offline Offline

Posts: 1480703449

View Profile Personal Message (Offline)

Ignore
1480703449
Reply with quote  #2

1480703449
Report to moderator
1480703449
Hero Member
*
Offline Offline

Posts: 1480703449

View Profile Personal Message (Offline)

Ignore
1480703449
Reply with quote  #2

1480703449
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480703449
Hero Member
*
Offline Offline

Posts: 1480703449

View Profile Personal Message (Offline)

Ignore
1480703449
Reply with quote  #2

1480703449
Report to moderator
1480703449
Hero Member
*
Offline Offline

Posts: 1480703449

View Profile Personal Message (Offline)

Ignore
1480703449
Reply with quote  #2

1480703449
Report to moderator
canford
Member
**
Offline Offline

Activity: 86


View Profile
March 01, 2014, 10:36:04 PM
 #14602

- Fixed AMUs being detected as failing and resetting them too early
Does this mean it's now safe to use 4.0.1 with Block Erupters again?
That's what the change is for...

Running 12 BE's with 4.0.1, working well.  Also updated Avalon Mini to 4.0.1, no issues.  Though oddly, the Mini has slowed down from 62 GH/s to 59 GH/s over a period of months, unrelated to cgminer - I suspect some of the chips have failed.
AngusCanine
Hero Member
*****
Offline Offline

Activity: 812


View Profile
March 02, 2014, 01:28:50 AM
 #14603

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

“Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!”
― Hunter S. Thompson
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
March 02, 2014, 01:52:55 AM
 #14604

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

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
AngusCanine
Hero Member
*****
Offline Offline

Activity: 812


View Profile
March 02, 2014, 02:10:51 AM
 #14605

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

“Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!”
― Hunter S. Thompson
Internet151
Full Member
***
Offline Offline

Activity: 174



View Profile
March 02, 2014, 11:18:39 AM
 #14606

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
Hero Member
*****
Offline Offline

Activity: 574


View Profile
March 03, 2014, 08:57:28 AM
 #14607

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

I suggest you keep your nose out of it.  Tongue
canford
Member
**
Offline Offline

Activity: 86


View Profile
March 03, 2014, 09:39:57 AM
 #14608

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
Sr. Member
****
Offline Offline

Activity: 292


View Profile WWW
March 04, 2014, 05:56:54 AM
 #14609

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.

Tips and donations: 1KyrosREGDkNLp1rMd9wfVwfkXYHTd6j5U  |  BTC P2Pool node: p2pool.kyros.info:9332
deagel
Member
**
Offline Offline

Activity: 67


View Profile
March 04, 2014, 06:10:06 AM
 #14610

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
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
March 05, 2014, 07:57:52 AM
 #14611

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

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
March 05, 2014, 09:39:26 AM
 #14612

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.


Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
KyrosKrane
Sr. Member
****
Offline Offline

Activity: 292


View Profile WWW
March 05, 2014, 10:16:37 AM
 #14613

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.

Tips and donations: 1KyrosREGDkNLp1rMd9wfVwfkXYHTd6j5U  |  BTC P2Pool node: p2pool.kyros.info:9332
M3kk
Full Member
***
Offline Offline

Activity: 125


View Profile
March 05, 2014, 01:43:47 PM
 #14614

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" Smiley.
crazyates
Legendary
*
Offline Offline

Activity: 938



View Profile
March 05, 2014, 01:55:40 PM
 #14615

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" Smiley.
W:192.168.0.0/16 would allow anyone on the 192.168.x.x range.

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
March 05, 2014, 09:32:52 PM
 #14616

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

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
JoseSan
Member
**
Offline Offline

Activity: 86


View Profile
March 05, 2014, 11:14:38 PM
 #14617

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

Well that piqued my curiosity...
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
March 06, 2014, 03:03:05 AM
 #14618

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.

Primary developer/maintainer for cgminer and ckpool/ckproxy.
Pooled mine at kano.is, solo mine at solo.ckpool.org
-ck
nowaltcoin
Member
**
Offline Offline

Activity: 115


View Profile
March 06, 2014, 09:41:30 AM
 #14619

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
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
March 06, 2014, 09:44:32 AM
 #14620

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

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Pages: « 1 ... 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 [731] 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 ... 830 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!