Askit2
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 12:21:44 AM |
|
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 (OP)
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 12:30:36 AM |
|
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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
kano
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 03:15:05 AM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) However, I presume you've found it is quite easy to build even on RPi - just a bit slow ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif)
|
|
|
|
Askit2
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 03:24:00 AM |
|
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
Newbie
Offline
Activity: 6
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 06:43:47 AM |
|
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](https://bitcointalk.org/Smileys/default/tongue.gif)
|
|
|
|
bitpop
Legendary
Offline
Activity: 2912
Merit: 1060
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 07:01:47 AM |
|
Have you tried both into your computer?
|
|
|
|
kano
Legendary
Offline
Activity: 4578
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 08:41:21 AM Last edit: August 20, 2013, 08:58:13 AM by 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? ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) 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/libusbI 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
Newbie
Offline
Activity: 6
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 03:32:54 PM |
|
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/libusbI 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
Newbie
Offline
Activity: 33
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 07:54:58 PM |
|
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
Activity: 1098
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 08:09:17 PM |
|
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 (OP)
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 21, 2013, 12:16:02 PM |
|
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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
HenriH
Newbie
Offline
Activity: 16
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 21, 2013, 12:28:18 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 21, 2013, 01:08:04 PM |
|
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 (OP)
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 21, 2013, 01:10:19 PM |
|
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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
Lucko
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 21, 2013, 01:15:01 PM |
|
Thanks.
|
|
|
|
Zanatos666
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 280
Merit: 250
Sometimes man, just sometimes.....
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 21, 2013, 03:10:09 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 21, 2013, 03:22:08 PM |
|
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
Newbie
Offline
Activity: 16
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 21, 2013, 05:13:14 PM |
|
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
Activity: 1361
Merit: 1003
Don`t panic! Organize!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 21, 2013, 06:49:55 PM |
|
It is AV program matter, not cgminer. Just add exception.
|
|
|
|
Zanatos666
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 280
Merit: 250
Sometimes man, just sometimes.....
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 21, 2013, 08:06:19 PM |
|
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.
|
|
|
|