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

[Askit2]

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?

[-ck]

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.

[kano]

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?

As Con said above, but also:
I got my 2nd RPi yesterday I bought.
I did already put a Raspbian 3.3.4a in cgminer-binaries yesterday, but yeah wait until the next release now (or you can build current git)
I'll be running some tests today with current git across a few platforms also, just to be sure there's nothing strange.
Next version release I'll of course have both an RPI_Arch and an RPI_Raspbian in cgminer-binaries also
However, I presume you've found it is quite easy to build even on RPi - just a bit slow

[Askit2]

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.

[dooglio]

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?

[bitpop]

Have you tried both into your computer?

[kano]

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?

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?

[dooglio]

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]

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]

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]

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.

[HenriH]

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]

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]

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.

[Lucko]

Thanks.

[Zanatos666]

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.

[Schleicher]

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.

[HenriH]

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]

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

[Zanatos666]

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.