Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 247. (Read 5805531 times)
August 21, 2013, 09:15:01 AM
Thanks.
August 21, 2013, 09:10:19 AM
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? NoIf I use -D or --debug cgminer crashes. And -P doesn't do anything...I tested this on 3.1.1 and 3.3.1.
Happens? Yes
Bug? Yes
Known cause? No
Fix in the works? See Known cause above.
August 21, 2013, 09:08:04 AM
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.
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.
August 21, 2013, 08:28:18 AM
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...
August 21, 2013, 08:16:02 AM
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.
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.
August 20, 2013, 04: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?
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://bitcointalksearch.org/topic/m.2967902
August 20, 2013, 03: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?
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?
August 20, 2013, 11:32:54 AM
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?
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!
August 20, 2013, 04:41:21 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?
The libusb problem only occurs when you have 2 or 3 or more plugged in.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?
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?
August 20, 2013, 03:01:47 AM
Have you tried both into your computer?
August 20, 2013, 02: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?
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?
August 19, 2013, 11:24:00 PM
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 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?
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.
August 19, 2013, 11:15:05 PM
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 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?
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
August 19, 2013, 08:30:36 PM
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 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?
August 19, 2013, 08:21:44 PM
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?
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?
August 19, 2013, 08:14:32 PM
Now now, no need to get narky. Most people aren't aware of the bitter history there and why Kano gets so pissed off at the mention of brickminer. It seemed an innocent enough report to me, he just didn't know that mere mention of the hostile fork makes it hard to see through the seething rage that it brings on.
August 19, 2013, 08:08:10 PM
Go away
August 19, 2013, 07:46:59 PM
...
I was using the released binaries on Windows7 x64 and I was continuously getting the failures described above.
I tried CrapMiner first on Linux (which I did build myself), and it worked flawlessly - so I never tried building CGMiner. My problem is fixed.
I am just posting this in case others have the same problems I did with the Windows binary release of CGMiner, and so that you guys are aware that there may be an issue.
The problem there is that is failed logic (as a certain other developer enjoys ...)I was using the released binaries on Windows7 x64 and I was continuously getting the failures described above.
I tried CrapMiner first on Linux (which I did build myself), and it worked flawlessly - so I never tried building CGMiner. My problem is fixed.
I am just posting this in case others have the same problems I did with the Windows binary release of CGMiner, and so that you guys are aware that there may be an issue.
Firstly, make sure you have the right libusb.dll - that is the actual cause of the problems.
If you use your old libusb.dll it of course will not work.
If, however, it still doesn't work, then it wont work with the clone either.
The problem will be either bad cables or a USB3 that causes it to fail.
On linux, it will work fine, but you simply are advertising using some other clone software coz you couldn't be bothered running cgminer.
i.e. go away.
It's not clear to me what I did to get you into such a defensive stance. Whatever it was, I apologize.
I thought I was just reporting an issue you might want to know about.
Again, I was using whatever binaries that were in your official Windows distribution, from the link at the beginning of this topic, and the zadig binary that is linked there also.
August 19, 2013, 06:04:57 PM
...
I was using the released binaries on Windows7 x64 and I was continuously getting the failures described above.
I tried CrapMiner first on Linux (which I did build myself), and it worked flawlessly - so I never tried building CGMiner. My problem is fixed.
I am just posting this in case others have the same problems I did with the Windows binary release of CGMiner, and so that you guys are aware that there may be an issue.
The problem there is that is failed logic (as a certain other developer enjoys ...)I was using the released binaries on Windows7 x64 and I was continuously getting the failures described above.
I tried CrapMiner first on Linux (which I did build myself), and it worked flawlessly - so I never tried building CGMiner. My problem is fixed.
I am just posting this in case others have the same problems I did with the Windows binary release of CGMiner, and so that you guys are aware that there may be an issue.
Firstly, make sure you have the right libusb.dll - that is the actual cause of the problems.
If you use your old libusb.dll it of course will not work.
If, however, it still doesn't work, then it wont work with the clone either.
The problem will be either bad cables or a USB3 that causes it to fail.
On linux, it will work fine, but you simply are advertising using some other clone software coz you couldn't be bothered running cgminer.
i.e. go away.
August 19, 2013, 05:57:06 PM
Since I am often making changes, testing stuff, I always run cgminer in a loop that simply restarts if it fails.
The windows version of this is
The 5s sleep is good in case you change the options and it keeps hard looping due to a mistake
The windows version of this is
Code:
@echo off
REM cgminer
:Loop
Set NOW=%date:~10,4%%date:~7,2%%date:~4,2%.%time:~0,2%%time:~3,2%%time:~6,2%
.\cgminer.exe --no-restart --api-port 4028 --api-listen --api-allow W:127.0.0.1,W:192.168.1.0/24 --api-description Des -c pools.json 2> "run.%NOW%.log"
echo Sleeping for 5 seconds
ping -n 5 127.0.0.1 > NUL
GOTO Loop
If someone is interested, here is my linux version:
Code:
#!/bin/bash
for (( ; ; ))
do
cgminer --config cg_$1_$2.conf 2>log$2.log
echo sleeping.....
sleep 5
echo done sleeping
done
I'm using few instances of cgminer for different devices and with parameters I can start different configs.
For example:
./gocg btc e
Runs config file cg_btc_e.conf logfile loge.log for my erupters.
(how I do it - though I do it in 2 scripts one that calls the other - this is essentially what it is)
Code:
#!/bin/bash
#
nam="$HOME/cgminer-run.log"
while true ; do
echo "`date`: Starting cgminer" 2>&1 | tee -a "$nam"
ulimit -c 2097152
now="`date +%Y%m%d%H%M%S`"
./cgminer --api-listen "$@" 2> "$HOME/run.$now.$$.log"
s="$?"
echo "`date`: cgminer exited status ($s)" 2>&1 | tee -a "$nam"
echo "`date`: Sleeping for 5..." 2>&1 | tee -a "$nam"
sleep 5
done
Any other options you want you can add when you run it
So e.g. if you call it cgminer.sh
You can run it as:
./cgminer.sh -c pools.conf
In your $HOME directory you'll have cgminer-run.log that will list all the starts and stops
And run.YYYYMMDDHHMMSS.$$.log for each run
Jump to: