Helo CKolivas and Kano,
Do you have any plans to release a KnCMiner version of CGMiner?
Thank you very much for your contribution to Cryptocoin Mining!!!
Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.0 - page 200. (Read 5806015 times)
October 21, 2013, 01:39:07 PM
October 21, 2013, 08:13:35 AM
snip
Well that definitely sounds better than it was. The only other thing I've seen suggested is using a good powered USB supply to the RPi. Perhaps a shorter, thicker cable from a USB3 slot if running off a PC, or a well powered hub if not.It could be USB 3 related but I have used these hubs since I started getting asics. My only asics are BFL and don't seem to draw power from the USB. I am expecting this will be like it used to be stable 24/7 for months at a time.
Thank You for all that you do.
The Arch USB network driver seems to be more reliable than the Raspbian one.
As mentioned before, the network device on the RPi is actually USB.
The basics of RPi Arch setup:
http://www.kano-kun.net/?p=87
October 21, 2013, 08:01:49 AM
If you don't specify stratum+tcp:// cgminer will try a few different ways to connect first. Some pools might not like the multiple attempts to connect so it is always cleaner and faster to specify the stratum+tcp:// prefix.
Thanks for mentioning this! I'd been having a problem connecting to ghash.io, it would always take ~5 minutes after a miner restart. Specifying the stratum+tcp:// removed this delay.
October 21, 2013, 05:46:26 AM
snip
Well that definitely sounds better than it was. The only other thing I've seen suggested is using a good powered USB supply to the RPi. Perhaps a shorter, thicker cable from a USB3 slot if running off a PC, or a well powered hub if not.It could be USB 3 related but I have used these hubs since I started getting asics. My only asics are BFL and don't seem to draw power from the USB. I am expecting this will be like it used to be stable 24/7 for months at a time.
Thank You for all that you do.
October 21, 2013, 04:21:41 AM
im trying to get 2>name.file logging working from a startup script that starts a cgminer instance inside a detached GNU screen window.
screen -S cgminer -d -m sudo ./cgminer --queue 4 -o stratum.btcguild.com:3333 -u *************** -p **** 2>logs/test.activity.log
this creates the test.activity.log file in the logs folder and starts hashing away happily but nothing gets written to the log. any ideas?
At a guess, the log is the output of 'screen' not 'cgminer' ?screen -S cgminer -d -m sudo ./cgminer --queue 4 -o stratum.btcguild.com:3333 -u *************** -p **** 2>logs/test.activity.log
this creates the test.activity.log file in the logs folder and starts hashing away happily but nothing gets written to the log. any ideas?
is there a hidden option to log to a file or will i have to delve deep into the innards of linux to figure out how to redirect the output of cgminers display within that screen session to file
I think I've posted this or similar in here a few times now ...
Code:
while true ; do
echo "`date`: Starting cgminer"
ulimit -c 2097152
#
now="`date +%Y%m%d%H%M%S`"
#
./cgminer --api-listen --api-allow W:127.0.0.1,R:0/0 --api-description MyMiner --api-mcast --api-mcast-des MyMiner --no-restart "$@" 2> ~/run.$now.$$.log
s="$?"
echo "`date`: cgminer exited status ($s)"
echo "`date`: Sleeping for 5..."
sleep 5
done
This will create a log file in your home directory for each time cgminer runs with the date stamp it started and the process number in case you run 2 at the same time. echo "`date`: Starting cgminer"
ulimit -c 2097152
#
now="`date +%Y%m%d%H%M%S`"
#
./cgminer --api-listen --api-allow W:127.0.0.1,R:0/0 --api-description MyMiner --api-mcast --api-mcast-des MyMiner --no-restart "$@" 2> ~/run.$now.$$.log
s="$?"
echo "`date`: cgminer exited status ($s)"
echo "`date`: Sleeping for 5..."
sleep 5
done
October 21, 2013, 04:12:26 AM
Due to me fat fingering an edit on cron I think if my math is correct it never restarted cgminer with the newest built from git and made it overnight.
That having been said I am not sure that */220 wouldn't ever run the restart script. I intended to put the new version from */30 to */20 for minutes making it restart 3 times an hour. Since that had stopped the hanging before.
I have moved things around and I still do get errors of the IO type. While moving things I noticed no errors with only 4 jalapeno's. As I was adding the next 4 I didn't see IO errors until the third from that set was added. After having all 9 back on I have only noticed a couple of IO errors. Maybe I should spread the proverbial love to a couple of more raspberry pi's.
Upgrading in the past hasn't helped me at all. I get more crashes and more corrupted sd cards. I tried very shortly arch but my Linux command line is lack luster at best so I went back to raspbian. I even tried MinePeon but the image I downloaded was corrupted. I really do hope the newest version won't require as frequent of a restart.
Well that definitely sounds better than it was. The only other thing I've seen suggested is using a good powered USB supply to the RPi. Perhaps a shorter, thicker cable from a USB3 slot if running off a PC, or a well powered hub if not. That having been said I am not sure that */220 wouldn't ever run the restart script. I intended to put the new version from */30 to */20 for minutes making it restart 3 times an hour. Since that had stopped the hanging before.
I have moved things around and I still do get errors of the IO type. While moving things I noticed no errors with only 4 jalapeno's. As I was adding the next 4 I didn't see IO errors until the third from that set was added. After having all 9 back on I have only noticed a couple of IO errors. Maybe I should spread the proverbial love to a couple of more raspberry pi's.
Upgrading in the past hasn't helped me at all. I get more crashes and more corrupted sd cards. I tried very shortly arch but my Linux command line is lack luster at best so I went back to raspbian. I even tried MinePeon but the image I downloaded was corrupted. I really do hope the newest version won't require as frequent of a restart.
October 21, 2013, 04:06:48 AM
The IO error on the devices only seems to happen on Linux not my windows box. When I moved those units to the raspberry pi it started having issues.
I can't say for sure there isn't a problem with a cable but I can hook it back up to windows 7 tomorrow maybe and try that.
I built the version from the git. I don't so far dare to stop cron from killing it every half hour. I can't watch it constantly and so far my script to start them up at boot isn't working correctly.
I do have a side issue that isn't cgminer directly. I have been plagued by crashes for a while. I haven't in the past seen anything to make me think mining specifically caused it. The most recent crash left me with the following error. I am including the last line of cgminers output and the crash report. Crash was 3.5.1 not newest from git. crashed after 57 minutes of running. 3 more and it would have restarted at the hour.
After that is some unwind kdb info I can type that up if you would like. It seems like there is a kernel error. I got lucky as for a change the monitor was still getting a signal. Usually power management manages to keep the signal off making the crashes far less useful. I don't know that this will help anything.
There's no doubt the USB in the RPi is less reliable than a real PC. Part of the problem is that the network device is actually a USB device low down meaning USB comms are compromised as a result, and it's all on the same bus.I can't say for sure there isn't a problem with a cable but I can hook it back up to windows 7 tomorrow maybe and try that.
I built the version from the git. I don't so far dare to stop cron from killing it every half hour. I can't watch it constantly and so far my script to start them up at boot isn't working correctly.
I do have a side issue that isn't cgminer directly. I have been plagued by crashes for a while. I haven't in the past seen anything to make me think mining specifically caused it. The most recent crash left me with the following error. I am including the last line of cgminers output and the crash report. Crash was 3.5.1 not newest from git. crashed after 57 minutes of running. 3 more and it would have restarted at the hour.
After that is some unwind kdb info I can type that up if you would like. It seems like there is a kernel error. I got lucky as for a change the monitor was still getting a signal. Usually power management manages to keep the signal off making the crashes far less useful. I don't know that this will help anything.
Code:
Bus 001 Device 004: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. LAN9500 Ethernet 10/100 Adapter / SMSC9512/9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. LAN9500 Ethernet 10/100 Adapter / SMSC9512/9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Unfortunately I can't really start digging into kernel code, but I can at least suggest trying a different distro (though I believe I've said that before). I can reliably crash my RPi by just plugging something into the USB slot that draws more power than usual (such as the BF1 stick) without mining even running. Would be interesting to see now that you've built from git whether you get complete failures with transfer errors or just IO errors as a temporary glitch now.
That having been said I am not sure that */220 wouldn't ever run the restart script. I intended to put the new version from */30 to */20 for minutes making it restart 3 times an hour. Since that had stopped the hanging before.
I have moved things around and I still do get errors of the IO type. While moving things I noticed no errors with only 4 jalapeno's. As I was adding the next 4 I didn't see IO errors until the third from that set was added. After having all 9 back on I have only noticed a couple of IO errors. Maybe I should spread the proverbial love to a couple of more raspberry pi's.
Upgrading in the past hasn't helped me at all. I get more crashes and more corrupted sd cards. I tried very shortly arch but my Linux command line is lack luster at best so I went back to raspbian. I even tried MinePeon but the image I downloaded was corrupted. I really do hope the newest version won't require as frequent of a restart.
October 21, 2013, 03:04:45 AM
im trying to get 2>name.file logging working from a startup script that starts a cgminer instance inside a detached GNU screen window.
screen -S cgminer -d -m sudo ./cgminer --queue 4 -o stratum.btcguild.com:3333 -u *************** -p **** 2>logs/test.activity.log
this creates the test.activity.log file in the logs folder and starts hashing away happily but nothing gets written to the log. any ideas?
At a guess, the log is the output of 'screen' not 'cgminer' ?screen -S cgminer -d -m sudo ./cgminer --queue 4 -o stratum.btcguild.com:3333 -u *************** -p **** 2>logs/test.activity.log
this creates the test.activity.log file in the logs folder and starts hashing away happily but nothing gets written to the log. any ideas?
is there a hidden option to log to a file or will i have to delve deep into the innards of linux to figure out how to redirect the output of cgminers display within that screen session to file
Thank You for showing me how to finish my boot script. I Was trying to run the commands in order like I do from the console to start screen, then change directory, then start the cgminer script. Now I have it working. Cron will fire it up, my loop will keep it up. I can attach using putty.
October 21, 2013, 02:14:53 AM
im trying to get 2>name.file logging working from a startup script that starts a cgminer instance inside a detached GNU screen window.
screen -S cgminer -d -m sudo ./cgminer --queue 4 -o stratum.btcguild.com:3333 -u *************** -p **** 2>logs/test.activity.log
this creates the test.activity.log file in the logs folder and starts hashing away happily but nothing gets written to the log. any ideas?
At a guess, the log is the output of 'screen' not 'cgminer' ?screen -S cgminer -d -m sudo ./cgminer --queue 4 -o stratum.btcguild.com:3333 -u *************** -p **** 2>logs/test.activity.log
this creates the test.activity.log file in the logs folder and starts hashing away happily but nothing gets written to the log. any ideas?
is there a hidden option to log to a file or will i have to delve deep into the innards of linux to figure out how to redirect the output of cgminers display within that screen session to file
October 21, 2013, 01:29:04 AM
im trying to get 2>name.file logging working from a startup script that starts a cgminer instance inside a detached GNU screen window.
screen -S cgminer -d -m sudo ./cgminer --queue 4 -o stratum.btcguild.com:3333 -u *************** -p **** 2>logs/test.activity.log
this creates the test.activity.log file in the logs folder and starts hashing away happily but nothing gets written to the log. any ideas?
At a guess, the log is the output of 'screen' not 'cgminer' ? screen -S cgminer -d -m sudo ./cgminer --queue 4 -o stratum.btcguild.com:3333 -u *************** -p **** 2>logs/test.activity.log
this creates the test.activity.log file in the logs folder and starts hashing away happily but nothing gets written to the log. any ideas?
October 20, 2013, 10:41:36 PM
im trying to get 2>name.file logging working from a startup script that starts a cgminer instance inside a detached GNU screen window.
screen -S cgminer -d -m sudo ./cgminer --queue 4 -o stratum.btcguild.com:3333 -u *************** -p **** 2>logs/test.activity.log
this creates the test.activity.log file in the logs folder and starts hashing away happily but nothing gets written to the log. any ideas?
screen -S cgminer -d -m sudo ./cgminer --queue 4 -o stratum.btcguild.com:3333 -u *************** -p **** 2>logs/test.activity.log
this creates the test.activity.log file in the logs folder and starts hashing away happily but nothing gets written to the log. any ideas?
October 20, 2013, 09:01:16 PM
If you don't specify stratum+tcp:// cgminer will try a few different ways to connect first. Some pools might not like the multiple attempts to connect so it is always cleaner and faster to specify the stratum+tcp:// prefix.
October 20, 2013, 08:36:23 PM
Regaudless of wording . Most of the sites I've used start with "http://". Stratum+tcp which bitminter uses is different to me so I go along the lines that it is treated differently than a site with just "http://". I don't have a degree in network protocols so I'm not sure how much differently they play if any.
I made a mention on their post about my eroupter stopping after instructing cgminer to mine there instead of another. It will be enough for cgminer to crap out on this site again to think somethings up and to go back to my other pool and hope it never happens again.
I don't expect all my eroupters to crap out at the same time without a reason.
I made a mention on their post about my eroupter stopping after instructing cgminer to mine there instead of another. It will be enough for cgminer to crap out on this site again to think somethings up and to go back to my other pool and hope it never happens again.
I don't expect all my eroupters to crap out at the same time without a reason.
stratum+tcp:// is a direct connection to a stratum pool http:// should work just the same or be redirected
October 20, 2013, 07:50:58 PM
Regaudless of wording . Most of the sites I've used start with "http://". Stratum+tcp which bitminter uses is different to me so I go along the lines that it is treated differently than a site with just "http://". I don't have a degree in network protocols so I'm not sure how much differently they play if any.
I made a mention on their post about my eroupter stopping after instructing cgminer to mine there instead of another. It will be enough for cgminer to crap out on this site again to think somethings up and to go back to my other pool and hope it never happens again.
I don't expect all my eroupters to crap out at the same time without a reason.
I made a mention on their post about my eroupter stopping after instructing cgminer to mine there instead of another. It will be enough for cgminer to crap out on this site again to think somethings up and to go back to my other pool and hope it never happens again.
I don't expect all my eroupters to crap out at the same time without a reason.
October 20, 2013, 07:17:15 PM
CK , you might have another big bug. My miners lasted after restart with bitminter and then stopped reacting. I closed and restarted and all is running again.
Any Idea if tcp protocols are not friendly with cgminer? I have to start taking pictures next time I see it like that. 3.6.4 lasted alot longer than past 3.6's.
Can't say I'll play with bit minter too much more. I'm not getting alot of shares and I can't seem to find what difficulty I should be set at for my Gigahashes
and it hasn't yelled at me to tell me I'm not at a difficulty level it likes 
and otherwise its not cell phone friendly 
.
cgminer ONLY does tcp, so I think you're confusing your terminology and looking at something totally unrelated. Any Idea if tcp protocols are not friendly with cgminer? I have to start taking pictures next time I see it like that. 3.6.4 lasted alot longer than past 3.6's.
Can't say I'll play with bit minter too much more. I'm not getting alot of shares and I can't seem to find what difficulty I should be set at for my Gigahashes
and it hasn't yelled at me to tell me I'm not at a difficulty level it likes and otherwise its not cell phone friendly . October 20, 2013, 07:15:23 PM
CK , you might have another big bug. My miners lasted after restart with bitminter and then stopped reacting. I closed and restarted and all is running again.
Any Idea if tcp protocols are not friendly with cgminer? I have to start taking pictures next time I see it like that. 3.6.4 lasted alot longer than past 3.6's.
Can't say I'll play with bit minter too much more. I'm not getting alot of shares and I can't seem to find what difficulty I should be set at for my Gigahashes and it hasn't yelled at me to tell me I'm not at a difficulty level it likes and otherwise its not cell phone friendly .
Any Idea if tcp protocols are not friendly with cgminer? I have to start taking pictures next time I see it like that. 3.6.4 lasted alot longer than past 3.6's.
Can't say I'll play with bit minter too much more. I'm not getting alot of shares and I can't seem to find what difficulty I should be set at for my Gigahashes
and it hasn't yelled at me to tell me I'm not at a difficulty level it likes and otherwise its not cell phone friendly . 
October 20, 2013, 02:42:49 PM
When using with Eligius it tells me to use this line:
cgminer -o stratum+tcp://stratum.mining.eligius.st:3334 -u YourAddress -p x -I 9
Towards the end of that line, can someone let me know what the "x -I 9" means? I can't seem to find it in any of the readme files.
Thanks
The "x" would be your password (preceded by the -p flag) and the "-I 9" would set your GPU intensity to 9, assuming you're mining with a GPU. If you're not GPU mining, the intensity flag is unnecessary.cgminer -o stratum+tcp://stratum.mining.eligius.st:3334 -u YourAddress -p x -I 9
Towards the end of that line, can someone let me know what the "x -I 9" means? I can't seem to find it in any of the readme files.
Thanks
Thank you. I'm trying to learn what all the numbers are on the screen and what they mean. Trying to following an ever changing change log against text is difficult. One of these days I'll take a screen capture of the mining screen and start to box out in nice yellow highlights what everything means. So the uses after me don't need to read through pages and pages of text. Thanks again.
Explanation of the numbers on the mining screen are in the Readme: https://github.com/ckolivas/cgminer/blob/master/README
About halfway down the page, you'll see a section called "WHILE RUNNING:" that describes the menu options and what each of the status display and log items are.
That said, it would be nice to have this in graphical form with screenshots and arrows highlighting each item.
October 20, 2013, 02:35:02 PM
When using with Eligius it tells me to use this line:
cgminer -o stratum+tcp://stratum.mining.eligius.st:3334 -u YourAddress -p x -I 9
Towards the end of that line, can someone let me know what the "x -I 9" means? I can't seem to find it in any of the readme files.
Thanks
The "x" would be your password (preceded by the -p flag) and the "-I 9" would set your GPU intensity to 9, assuming you're mining with a GPU. If you're not GPU mining, the intensity flag is unnecessary.cgminer -o stratum+tcp://stratum.mining.eligius.st:3334 -u YourAddress -p x -I 9
Towards the end of that line, can someone let me know what the "x -I 9" means? I can't seem to find it in any of the readme files.
Thanks
Thank you. I'm trying to learn what all the numbers are on the screen and what they mean. Trying to following an ever changing change log against text is difficult. One of these days I'll take a screen capture of the mining screen and start to box out in nice yellow highlights what everything means. So the uses after me don't need to read through pages and pages of text. Thanks again.
October 20, 2013, 11:19:20 AM
I have never had issues with any of my RPi's running cgminer (besides operator error). I have heard stories of other people having problems and those problems going away when they upgraded their power supplies.
I can recommend this one from Adafruit: http://www.adafruit.com/products/501
Note that it's actually 5.25V which is within the +/- 5% spec and the little bit of extra voltage is insurance against voltage drooping.
Here is another one I've used successfully but for shorter time from Sparkfun: https://www.sparkfun.com/products/11456
In short, make sure your power supply is a good one. A marginal one will cause lots of grief.
Sorry for the thread derail. Back on topic now.
I can recommend this one from Adafruit: http://www.adafruit.com/products/501
Note that it's actually 5.25V which is within the +/- 5% spec and the little bit of extra voltage is insurance against voltage drooping.
Here is another one I've used successfully but for shorter time from Sparkfun: https://www.sparkfun.com/products/11456
In short, make sure your power supply is a good one. A marginal one will cause lots of grief.
Sorry for the thread derail. Back on topic now.
October 20, 2013, 11:17:30 AM
Hi Guys,
I am re-compiling on Windows to get ready for some Bitfury's that should appear soon but I have run into problems with make. I can successfully compile and run cgminer versions up to 3.3.3 but after that all versions to
"ws2tcpip.h is not compatible with winsock.h. Include winsock2.h instead."
There are a number of fixes around the Interweb but I would rather use the same fix that you guys must be using to build the exe's. I am using the same versions of mingw, gtk, etc as per the windows build doc and follow the guide without problems for versions to 3.3.3, all builds are clean onto a fresh Win 7 VM.
As an aside I am also noticing differences in the dll's included in the exe distro against those required from the windows build doc, not a biggie but something that needs to be added to a tidy up list at some point.
Con, Kano, any bandwidth left to throw me a bone, which fix are you using?
Jump to: