Bitcoin Forum
December 05, 2016, 06:45:39 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 ... 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 [602] 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 ... 830 »
  Print  
Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.9.2  (Read 4818310 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.
Askit2
Hero Member
*****
Offline Offline

Activity: 524


View Profile
August 20, 2013, 03:24:00 AM
 #12021

Kano,
I recompiled, make clean and make'd the 3.3.4 on Raspbian. I used the command you posted. Thank You!

I am still getting nearly 100% load. I am getting with 4 BFL jalapeno's 40% load cgminer and 33% load on ksoftirqd/0. I can not kill ksoftirqd/o so I assume its required. If it is then it has always been available but as I check top to see how much load cgminer has per instance I think I would have noticed a long time ago that it was pinning the processor. Running all 9 BFL jalapeno's results in 58% CGMiner and 40% Ksoftirqd/0.

I am running it with logging now. Is there something I should be looking for?

Have you been using 3.3.4 official or a git pull? At various stages there were issues in the git master tree and only now it has stabilised in preparation for the next release. If you are building from git, try pulling the latest git now.

I pulled from git. recompiled and now it peaks up to 14%. Most of the time it is under 10%. Thank You for letting me know what caused the higher load.

I don't mind compiling directly and I really haven't had that much trouble in the past. Had the card dying not taken out all my old versions I would have just went back a version and ran that. Still I am thrilled that its again working at the low processor load I am used to.

I appreciate donations at ( 1NwkQdmomQPLtdes5KuZhB1D22p7ZGRy4p )
If I am helping in the CGMiner thread give it to Con or Kano. They do the work there.
If you want to sign up for a coinbase account I would appreciate it if you use my referral link. US people now wire, 1% fee give or take a little for sending to your bank account. https://coinbase.com/?r=515bf6145682db9d11000028&utm_campaign=user-referral&src=
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480963539
Hero Member
*
Offline Offline

Posts: 1480963539

View Profile Personal Message (Offline)

Ignore
1480963539
Reply with quote  #2

1480963539
Report to moderator
1480963539
Hero Member
*
Offline Offline

Posts: 1480963539

View Profile Personal Message (Offline)

Ignore
1480963539
Reply with quote  #2

1480963539
Report to moderator
dooglio
Newbie
*
Offline Offline

Activity: 5



View Profile
August 20, 2013, 06:43:47 AM
 #12022

Hello,

I just got two Block Erupter USBs today. I plugged them both into my USB-2 port on my computer, using a Digital 7-Port Hub. cgminer recognizes them, but when I run I get really low hash rates (~100Mh/s). Both AMUs report timeouts:

AMU0: TIMEOUT GetResults took...

Thing is, when I pull one of the USB sticks out, and restart cgminer, it starts to hash at 335Mh/s, more what I was expecting. But even if I plug the other USB dongle into the other USB-2 port on my computer (without using the hub), I get the same results. I tried this on my laptop as well. It seems more than one Erupter is too much at a time.

Has anyone else had this problem? What if anything can I do to fix it?

It's not a total loss because I can plug in and run the two separately, but it would be nice to buy more Erupters and be able to plug them all into the same hub.

Any ideas? Tongue
bitpop
Legendary
*
Offline Offline

Activity: 1918


https://keybase.io/bitpop


View Profile WWW
August 20, 2013, 07:01:47 AM
 #12023

Have you tried both into your computer?

Reputation  |  PGP  |  DigitalOcean  |  OpenVPN 2GB Free  |  TorGuard  |  Ethereum Classic
Bitcoin: 3DSh6AnmvBpDJFUz2mnLirMLmTMcFs9nDm
Bitmessage: BM-2cXN9j8NFT2n1FxDVQ6HQq4D4MZuuaBFyb
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
August 20, 2013, 08:41:21 AM
 #12024

Hello,

I just got two Block Erupter USBs today. I plugged them both into my USB-2 port on my computer, using a Digital 7-Port Hub. cgminer recognizes them, but when I run I get really low hash rates (~100Mh/s). Both AMUs report timeouts:

AMU0: TIMEOUT GetResults took...

Thing is, when I pull one of the USB sticks out, and restart cgminer, it starts to hash at 335Mh/s, more what I was expecting. But even if I plug the other USB dongle into the other USB-2 port on my computer (without using the hub), I get the same results. I tried this on my laptop as well. It seems more than one Erupter is too much at a time.

Has anyone else had this problem? What if anything can I do to fix it?

It's not a total loss because I can plug in and run the two separately, but it would be nice to buy more Erupters and be able to plug them all into the same hub.

Any ideas? Tongue
The libusb problem only occurs when you have 2 or 3 or more plugged in.
Are you using the current cgminer and the current cgminer libusb.dll ?
Coz that error is exactly what will happen with the bad libusb ...

If you are not sure which libusb.dll is in your current directory or which version you are using,
you'll need to delete them to make sure you are not using an old one and also that there isn't an old e.g. in the system ddl folders.
For windows, I have the current working libusb.dll needed for running and the 2 extra files needed for compiling and linking here also:
https://github.com/kanoi/cgminer-binaries/tree/master/libusb

I guess it may also be possible that windows is holding onto the old dll and using that?
So typical of windows you may also need to reboot after you get rid of all the wrong dlls and put the right one in?

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
dooglio
Newbie
*
Offline Offline

Activity: 5



View Profile
August 20, 2013, 03:32:54 PM
 #12025

The libusb problem only occurs when you have 2 or 3 or more plugged in.
Are you using the current cgminer and the current cgminer libusb.dll ?
Coz that error is exactly what will happen with the bad libusb ...

If you are not sure which libusb.dll is in your current directory or which version you are using,
you'll need to delete them to make sure you are not using an old one and also that there isn't an old e.g. in the system ddl folders.
For windows, I have the current working libusb.dll needed for running and the 2 extra files needed for compiling and linking here also:
https://github.com/kanoi/cgminer-binaries/tree/master/libusb

I guess it may also be possible that windows is holding onto the old dll and using that?
So typical of windows you may also need to reboot after you get rid of all the wrong dlls and put the right one in?

Success! Kano, excellent post, you fixed the problem! Technically, I'm not running under Windows (I'm using Ubuntu Quantal), and I'm building from source from the git archive. However, I was using Ubuntu's release of libusb-1.0, which as you point out is broken. I grabbed the libusb-1.0.16-rc10.tar.bz2 tarball from the cgminer-binaries archive, and voila! It works with more than one plugged in. :-)

Thanks so much for your help!
MacDschie
Jr. Member
*
Offline Offline

Activity: 33



View Profile
August 20, 2013, 07:54:58 PM
 #12026

Hi there,

I just upgraded from version 3.3.1 to the latest release in the github repository (V 3.3.4). All works fine, also the hashing speed is the same as before.

But there is one difference: I noticed that the orange LED (task buffer LED) on my Avalon is flashing with a frequency of ~1 second with the new version. Normally, this LED should stay off and only light when the task buffer runs empty and FPGA board has no data to process (see https://en.bitcoin.it/wiki/Avalon#FPGA_controller LEDs). Does this mean, the new version of cgminer is potenitially more efficient and could deliver the hasing data even faster to the Avalon device than before, but doesn't do it?
Tigggger
Legendary
*
Offline Offline

Activity: 952



View Profile
August 20, 2013, 08:09:17 PM
 #12027

Hi there,

I just upgraded from version 3.3.1 to the latest release in the github repository (V 3.3.4). All works fine, also the hashing speed is the same as before.

But there is one difference: I noticed that the orange LED (task buffer LED) on my Avalon is flashing with a frequency of ~1 second with the new version. Normally, this LED should stay off and only light when the task buffer runs empty and FPGA board has no data to process (see https://en.bitcoin.it/wiki/Avalon#FPGA_controller LEDs). Does this mean, the new version of cgminer is potenitially more efficient and could deliver the hasing data even faster to the Avalon device than before, but doesn't do it?

https://bitcointalk.org/index.php?topic=140539.msg2967902#msg2967902

-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
August 21, 2013, 12:16:02 PM
 #12028

New release: Version 3.4.0 - 21st August 2013

Very little in the way of new features, but lots of changes under the hood so since the code changes were so large, the minor version number was incremented. Having said that it has been heavily tested. A lot of profiling was done to determine where the main CPU users were and try and optimise them.


Human readable changelog:

- HW error % will show in the cgminer API log tab on the avalon web interface.
- Bitburner variables (the version number and voltage) will only show with bitburner hardware in API stats.
- Backup pools will pick up their connections faster when the primary pool goes down.
- When there is no work available, a new message will appear on the screen informing you so you will know why if your hashrate falls, along with another message when there is work available.
- Some devices would unintentionally be flagged SICK and DEAD when there was a total network outage. This should be fixed now.
- Rewrite of every single use of sleep within the code to use absolute time differences where possible (windows doesn't fully support this so it's only emulated). This leads to less sleep overruns and tighter control of timing.
- Much more relaxed delays, capitalising on the tighter timing in various BFLSC and Avalon functions making for less CPU usage overall.
- Higher hashrates possible on Avalon now with --avalon-auto due to better timing.
- The avalon LED will flash regularly now whenever it's about to receive more work due to the timing functions.
- Less chance of lost shares on Avalon
- Avalon displayed data aligns on the text interface when used on a PC.
- Replaced the sha256 code with a faster implementation to decrease CPU usage.
- Bitburner allows up to 1400mv
- "d" can be used for a timeout on Avalon now to allow it to be calculated when used in --avalon-options
- Fixed a rare potential crash with avalon devices.


Full changelog:


- Use stack data for HW error% in avalon stats.
- Add avalon HW error% to stats and only show BTB variables if avalon is a BTB.
- Check for cnx_needed on each loop through wait_lp_current.
- Return positive for cnx_needed when no_work is true.
- Stratum is used more often so test for it first.
- Reorder support names alphabetically.
- Only display the no pool work message once if there are multiple waiters in
hash_pop
- Provide a message and set a bool when no work is available from any pools and
when it resumes again.
- We don't want to continue into the hash_pop function if the getq is frozen.
- Only report threads in and out in queued work devices across a get work since
the rest happens asynchronously and the get work is what the device might be
waiting on.
- Thread reportin and out can be static non inline.
- usbutils cps sleep_estimate is not an underestimate
- usbutils add cps stats estimates
- Provide cgtimer_sub helper functions.
- Provide cgtimer_to_ms helper functions.
- Rename cgsleep_prepare_r as cgtimer_time to get time in cgtimer_t format and
call cgsleep_prepare_r as a macro for cgtimer_time
- Use the reentrant cgsleep functions for usecps in usbutils.
- TimeBeginPeriod and TimeEndPeriod do not add significant overhead when run the
entire time for cgminer so avoid trying to maintain balanced numbers of them for
specific time calls to simplify code.
- Replace all references to the old n*sleep functions with the equivalent
cgsleep_*s replacements.
- timeGetTime uses huge resources on windows so revert to using timevals for its
implementation of cgtimer_t
- Quotient/remainder error in ms division.
- Only grab a queued work item if we successfully grab the lock to submit work
in bflsc_send_work
- BTB get version from Firmware
- Carve out the unused portions of sha2 implementation.
- Import Aaron D. Gifford's fast sha256 implementation.
- Increase the que_low watermarks on BFLSC for they are too low to keep the
device busy on scanwork loops.
- Provide cgtimer_to_timeval helper functions.
- Provide a timeval_to_cgtime helper function to reuse values.
- Check for thr->work_restart in restart_wait.
- We should be using que_low to decrease scan sleep time in bflsc.
- Prepare sleep time on bflsc if no dev needs work yet to avoid busy waiting.
- Simplify cgsleep code for windows by using a typedef for cgtimer_t that
resolves to clock resolution, using that internally.
- On windows use the higher accuracy timegettime function to really get 1ms
clock and timer accuracy.
- Use the cgsleep reentrant function to sleep for bflsc between read results to
account for time taken to perform reads.
- Use 100ms delay between checking for results on all bflsc devices as the
buffering of results mean checking more frequently just wastes CPU and causes
more lock contention for only marginally better latencies.
- Fix missed endtimeperiod in overrun timer on windows.
- Make cgsleep_us_r take an int64_t for us.
- Make the cgsleep functions build on windows.
- Use the cgsleep reentrant function in avalon_send_task.
- Use the reentrant cgsleep functions within the avalon_send_tasks function.
- Set high resolution timing on windows within the cgsleep functions.
- Use the reentrant cgsleep function to time sleeps on reading from avalon.
- Provide reentrant versions of cgsleep functions to allow start time to be set
separately from the beginning of the actual sleep, allowing scheduling delays to
be counted in the sleep.
- Make the nmsleep and nusleep functions use the new cgsleep functions
internally till functions are migrated to the new cgsleep API.
- Add a ms_to_timespec helper function, and create a cgsleep_ms function that
uses absolute timers with clock_nanosleep to avoid overruns.
- Add rt lib linkage to enable use of clock_nanosleep functions with older
glibc.
- Add necessary time header include to avalon driver.
- Do a sleep of the full duration it would take to do all the work using
clock_nanosleep in avalon_send_tasks to avoid sleep overruns before polling to
see if it's ready.
- Add a timeraddspec helper function.
- Provide a us_to_timespec helper function.
- Use the us_to_timeval helper function in the avalon driver.
- Provide a us_to_timeval helper function.
- Use timeval_to_spec helper in avalon driver.
- Add helper functions to convert timespec to timeval and vice versa.
- simplifying buffer full check
- forking bitburner write thread function
- making sure original Avalon is unaffected by BitBurner changes
- changes to queueing strategy for BitBurner boards
- Do not poll in avalon_get_results without sleeping if we have finished parsing
a full result.
- Add c to ambient temperature display for avalon driver.
- BTB allow up to 1400mV as per firmware limits
- avalon for timeout allow d='calculate it' and fix uninitialised
- Use cloned work when finding avalon results since another thread can discard
the work item while it's in use.
- Provide a variant of find_work_bymidstate that returns a clone of the found
work.

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

Activity: 16


View Profile
August 21, 2013, 12:28:18 PM
 #12029

How can I disable Intel GPU without using "cgminer -n" at all? I would like to automatically disable Intel GPU without having to manually check up the numbers with -n switch...
Lucko
Hero Member
*****
Offline Offline

Activity: 714



View Profile
August 21, 2013, 01:08:04 PM
 #12030

Is it normal that I can't run debug on windows 7 x64?

If I use -D or --debug cgminer crashes. And -P doesn't do anything...I tested this on 3.1.1 and 3.3.1.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
August 21, 2013, 01:10:19 PM
 #12031

Is it normal that I can't run debug on windows 7 x64?

If I use -D or --debug cgminer crashes. And -P doesn't do anything...I tested this on 3.1.1 and 3.3.1.
Normal? No

Happens? Yes

Bug? Yes

Known cause? No

Fix in the works? See Known cause above.

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

Activity: 714



View Profile
August 21, 2013, 01:15:01 PM
 #12032

Thanks.
Zanatos666
Sr. Member
****
Offline Offline

Activity: 280


Sometimes man, just sometimes.....


View Profile
August 21, 2013, 03:10:09 PM
 #12033

How can I disable Intel GPU without using "cgminer -n" at all? I would like to automatically disable Intel GPU without having to manually check up the numbers with -n switch...

If you are talking about the integrated graphics on the board, then you might have to use -d <device number> in order to declare specific GPUs to use so that it will ignore your integrated graphics.

If you arent using your integrated graphics at all on your system, then disable it in the device manager and use --remove-disabled.

Squiggly letters, written really fast, with a couple of dots for good measure.
Schleicher
Hero Member
*****
Offline Offline

Activity: 630



View Profile
August 21, 2013, 03:22:08 PM
 #12034

Is it normal that I can't run debug on windows 7 x64?
If I use -D or --debug cgminer crashes. And -P doesn't do anything...I tested this on 3.1.1 and 3.3.1.
It used to crash here too, but to my surprise it doesn't after I reinstalled Windows.
Don't ask me why.

Bitcoin donations: 1H2BHSyuwLP9vqt2p3bK9G3mDJsAi7qChw
HenriH
Newbie
*
Offline Offline

Activity: 16


View Profile
August 21, 2013, 05:13:14 PM
 #12035

Antivirus software are always whining about bitcoin miners like cgminer. Can you somehow modify cgminer so that antivirus software won't whine about it anymore? It's annoying.
rav3n_pl
Legendary
*
Offline Offline

Activity: 1320


Don`t panic! Organize!


View Profile
August 21, 2013, 06:49:55 PM
 #12036

It is AV program matter, not cgminer. Just add exception.

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
My SatoshDice bot https://bitcointalk.org/index.php?topic=897685
Zanatos666
Sr. Member
****
Offline Offline

Activity: 280


Sometimes man, just sometimes.....


View Profile
August 21, 2013, 08:06:19 PM
 #12037

Antivirus software are always whining about bitcoin miners like cgminer. Can you somehow modify cgminer so that antivirus software won't whine about it anymore? It's annoying.

Would involve completely rewriting it.  anti-virus programs think that its a botnet (some of the code may have been used). Just add an exception to your antivius program for cgminer.exe and it should ignore it going forward.

Squiggly letters, written really fast, with a couple of dots for good measure.
-ck
Moderator
Legendary
*
Offline Offline

Activity: 1988


Ruu \o/


View Profile WWW
August 21, 2013, 09:26:34 PM
 #12038

How can I disable Intel GPU without using "cgminer -n" at all? I would like to automatically disable Intel GPU without having to manually check up the numbers with -n switch...
No, the numbers of the GPUs on Intel vs the numbers on AMD don't work that way anyway. cgminer will only mine on one SDK platform at any time (eg AMD or Intel). If you don't have the Intel OpenCL SDK installed, cgminer can't even mine on the Intel GPUs. If you have both the Intel and AMD OpenCL SDKs installed, you will need to specify one of them with the --gpu-platform command.

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

Activity: 447


View Profile
August 22, 2013, 01:16:01 AM
 #12039

What you are showing there is libusb failing to timeout.
That's what the test program will test and show for the version of libusb you use.
I've put usbfail.c and the working libusb libusb-1.0.16-rc10.tar.bz2 in my binaries git:
https://github.com/kanoi/cgminer-binaries

On linux, To use the working libusb for cgminer instead of the system libusb -
First install udev-dev via one of:
Fedora: yum install libgudev1
Ubuntu derivatives: apt-get install libudev-dev
Arch: it should be installed by default as part of systemd
When you are in the cgminer folder:
mkdir libusb
cd libusb
wget -O libusb-1.0.16-rc10.tar.bz2 https://github.com/kanoi/cgminer-binaries/blob/master/libusb-1.0.16-rc10.tar.bz2?raw=true
tar -xvf libusb-1.0.16-rc10.tar.bz2
cd libusb-1.0.16-rc10
./configure
make
cd ..
cd ..

If you have already autogen/configured cgminer, next you want to edit Makefile
Search for -I/usr/include/libusb-1.0 change all 3 to make sure it's working to -Ilibusb/libusb-1.0.16-rc10/libusb/
Also search for -lusb-1.0 and change both of them to libusb/libusb-1.0.16-rc10/libusb/.libs/libusb-1.0.a -ludev (without the first -l)
Then
make clean
make

and now your cgminer will have been compiled against my specific libusb-1.0.16-rc10 properly
N.B. you have to use that version in my git, not the system versions - it would appear a lot if linux distros have a bad libusb

Thank you so much for this! Just spent a long time trying to get libusb working correctly on Ubuntu 12.04 with my usb miners. This solved the problem immediately, great guide.

Also, is there a guide for what difficulty I should set in cgminer based on hashrate? Or should I just let cgminer decide?

kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
August 22, 2013, 01:21:18 AM
 #12040

...
Thank you so much for this! Just spent a long time trying to get libusb working correctly on Ubuntu 12.04 with my usb miners. This solved the problem immediately, great guide.
You're welcome.
I've also since updated the README with that but using the command line autogen/configure options to generate the correct Makefile so you don't have to edit it

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 ... 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 [602] 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 ... 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!