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

[techman05]

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 .

[-ck]

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.

[techman05]

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.

[Taugeran]

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.

stratum+tcp:// is a direct connection to a stratum pool http:// should work just the same or be redirected

[-ck]

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.

[Taugeran]

 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?

[kano]

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' ?

[Taugeran]

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' ?

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

[Askit2]

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' ?

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

use other .sh file to call cgminer. with your ./cgminer and everything. call the .sh file from your current command. can even put the cgminer in a loop to make sure it restarts if it died.

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.

[Askit2]

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.

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

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.

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.

[-ck]

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.

[kano]

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' ?

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

As suggested above used a script to run cgminer (and log it) and have screen only run that script and do nothing else.
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.

[Askit2]

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.

My Usb cable was the shortest I could find It looks like 12" it was a monster brand one. Supply is rated at 1.5A and all devices attached to raspberry pi have hubs (they are usb3...) and are powered off a 12V supply (they have an internal switch mode circuit) and will deliver 1.5A per port and only 4 ports so no internal hub on hub action. It shouldn't be a lack of power. Then again I can't be sure it isn't somehow related to power.

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.

[juhakall]

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.

[kano]

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.

My Usb cable was the shortest I could find It looks like 12" it was a monster brand one. Supply is rated at 1.5A and all devices attached to raspberry pi have hubs (they are usb3...) and are powered off a 12V supply (they have an internal switch mode circuit) and will deliver 1.5A per port and only 4 ports so no internal hub on hub action. It shouldn't be a lack of power. Then again I can't be sure it isn't somehow related to power.

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 other thing to consider is Arch rather than Raspbian.
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

[greek_hephaestus]

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!!!

[-ck]

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!!!

KFC sent me a saturn unit for development. I am currently swamped with other work but will eventually get around to working on integrating support for it into master cgminer and hopefully improve on the driver too.

[wolfskill]

Still getting the error below with 3.6.4:

 [2013-10-21 20:25:38] BAL0: empty result (INPROCESS:10x0aCOUN0x00) ignored
 [2013-10-21 20:25:39] BAL0: Error: Get temp returned nothing (0:0)
 [2013-10-21 20:25:40] BAL0: GetResults failed no data returned  (err=0 amt=0)
 [2013-10-21 20:25:41] BAL 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-21 20:25:41] BAL0: RequestResults failed (err=-7 amt=0)
 [2013-10-21 20:25:42] BAL 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-21 20:25:42] BAL0: RequestResults failed (err=-7 amt=0)
 [2013-10-21 20:25:44] BAL0: GetResults failed (err=-7 amt=0)
 [2013-10-21 20:26:06] BAL0: GetResults failed (err=-7 amt=16)
 [2013-10-21 20:26:07] BAL0: GetResults failed no data returned  (err=0 amt=0)
 [2013-10-21 20:26:08] BAL0: GetResults failed (err=-7 amt=0)
 [2013-10-21 20:26:09] BAL 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-21 20:26:09] BAL0: RequestResults failed (err=-7 amt=0)
 [2013-10-21 20:26:10] BAL 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-21 20:26:10] BAL0: RequestResults failed (err=-7 amt=0)
 [2013-10-21 20:26:11] BAL 0 usb write err:(-7) LIBUSB_ERROR_TIMEOUT
 [2013-10-21 20:26:11] BAL0: RequestResults failed (err=-7 amt=0)
 [2013-10-21 20:26:13] BAL0: GetResults failed no data returned  (err=0 amt=0)

Using USB 2.0 ports directly on the motherboard, restarting CGMINER seems to fix the issue.  Tried different USB ports, same issue.  Can happen 20 minuter or hours after CGMINER.

WolfSkill

[-ck]

Still getting the error below with 3.6.4:

 [2013-10-21 20:26:13] BAL0: GetResults failed no data returned  (err=0 amt=0)

Using USB 2.0 ports directly on the motherboard, restarting CGMINER seems to fix the issue.  Tried different USB ports, same issue.  Can happen 20 minuter or hours after CGMINER.

It's possible you're having a hardware issue that only shows up after it's been under load for a while. I had this sort of failure with a bad power brick on a single.

[wolfskill]

Ok, thank you for the information.

WolfSkill