Topic: [GUIDE] GridSeed 5-Chip USB, Blade & Black Miner Support/Tuning - page 31. (Read 308807 times)
Your pool is sending a new job like every second, could you please try a different pool?
This does not have a whole lot of information , but here is what i have using 1 Gridseed Blade. https://dl.dropboxusercontent.com/u/109298881/cpuminer-gc3355.log
Do you mind posting a log with debug mode (--debug) enabled? Thanks
This does not have a whole lot of information , but here is what i have using 1 Gridseed Blade. https://dl.dropboxusercontent.com/u/109298881/cpuminer-gc3355.log
I really don't know why. Guys, it's really helpful if you post the logs till it stopped sending shares.
If anyone wants to volunteer to help me fix cpuminer for the Blades, shoot me a PM.
If anyone wants to volunteer to help me fix cpuminer for the Blades, shoot me a PM.
csmflynt3,
I concur , same thing is happening to me as well. There is something wrong that effects the blades.
TC
I concur , same thing is happening to me as well. There is something wrong that effects the blades.
TC
Yes I tried different power supplies / usb cables etc. It still just starts up for a few minutes then stops hashing. Bfgminer 3.10 for gridseed still works the best though. It is almost like the blades cannot keep up with the work cpuminer keeps sending. Cpuminer keeps sending work even though the blades are not sending anything back yet. Not sure if bfgminer sends work differently somehow. Cpuminer is still fantastic for the 5 chips though.
I am not a programmer so this is probably way off, but I notice that bfgminer seems to que the work somehow where cpuminer just sends it immediately?. I don't know if that could be related.
csmflynt3,
I concur , same thing is happening to me as well. There is something wrong that effects the blades.
TC
I concur , same thing is happening to me as well. There is something wrong that effects the blades.
TC
Is there any way to tell which Gridseed is not running at maximum speed using Sandor's cpuminer? For example, in this screenshot:
Gridseed #1 is running really slowly, which probably means that I need to either re-seat the heatsink or resolder the resistor. However, how do I determine which one is Gridseed #1? When I unplug the USB cable to a Gridseed, the UI doesn't update to let me know that it's dead, and every Gridseed looks like it's still hashing.
Gridseed #1 is running really slowly, which probably means that I need to either re-seat the heatsink or resolder the resistor. However, how do I determine which one is Gridseed #1? When I unplug the USB cable to a Gridseed, the UI doesn't update to let me know that it's dead, and every Gridseed looks like it's still hashing.
Try using cgminer to see if it still shows a slow hashrate. I found cpuminer 0.9a would sometimes report the wrong hash rate. Also, it was causing one of my miners (new one with LED lights) to continuously light up red. Not sure if that was the same one reporting a slow hashrate.
I have been running for 10 +hrs with no issues on my 10 Gridseed (5 chip). Still have problems with the 40 chips Blades so just curious if anyone is successfully running this new cpuminer with blades on windows 7 .
It appears that all 80 chips initially begin hashing , but after about 10 minutes 40 stop hashing. The other 40 may keep hashing for 30 minutes or so. CPUminer is still trying to send out work so the program is not locking up etc. I thought it may be a usb issue so I switched out the cables with the 5 chips to rule that out. Com port settings have FIFO disabled etc. I also tested this out with bfgminer-3-99-0-windows-clean and my blades seem to work fine with that so far, but I would rather use this cpuminer version.
I tried the most basic script to rule out as much as possible. Frequency can be anywhere from 600-900 with same result so not sure what my problem is
minerd-gc3355 --freq=600 --gc3355=\\.\COM11,\\.\COM12 --url=stratum+tcp://us-east.multipool.us:7777 --userpass=X.XXXX:x
Thanks
It appears that all 80 chips initially begin hashing , but after about 10 minutes 40 stop hashing. The other 40 may keep hashing for 30 minutes or so. CPUminer is still trying to send out work so the program is not locking up etc. I thought it may be a usb issue so I switched out the cables with the 5 chips to rule that out. Com port settings have FIFO disabled etc. I also tested this out with bfgminer-3-99-0-windows-clean and my blades seem to work fine with that so far, but I would rather use this cpuminer version.
I tried the most basic script to rule out as much as possible. Frequency can be anywhere from 600-900 with same result so not sure what my problem is
minerd-gc3355 --freq=600 --gc3355=\\.\COM11,\\.\COM12 --url=stratum+tcp://us-east.multipool.us:7777 --userpass=X.XXXX:x
Thanks
Are you confident that your power supply is not sagging to the blade?
I haven't downloaded the latest version, but a few back that works for me with my blade and two 5-chip models and they have been running non-stop since 4/28/2014. I am running on Windows Server 2008/Windows Home Server.
----------------------------------------------------------
cpuminer-gc3355 - Started: [2014-04-28 22:22:04]
==============================================================================================================
(2s): 5.41/5.69 MH/s A:56591 R:0 HW:486
Connected to useast.coinsolver.com:3333 diff 256 with stratum as user
==============================================================================================================
GSD 0 850 MHz 2720.3/2858.1 KH/s A:28452 R:0 HW:122
GSD 1 850 MHz 2690.4/2832.1 KH/s A:28139 R:0 HW:364
==============================================================================================================
[2014-04-30 23:04:50] Accepted c0109a1f GSD 0@30
[2014-04-30 23:04:59] Accepted c6809634 GSD 1@31
[2014-04-30 23:05:00] New job_id: eff6_4059 Diff: 256
[2014-04-30 23:05:00] Stratum detected new block
[2014-04-30 23:05:01] Accepted 4ccdb708 GSD 1@12
[2014-04-30 23:05:03] Accepted 399c5a90 GSD 0@9
[2014-04-30 23:05:03] Accepted a66917cb GSD 1@26
Posted from Bitcointa.lk - #1hu28FuDGkFdbveS
The only thing I have no swapped out is the power supply so I may try a spare that I have just to rule that out. That may explain why it isn't stable for me.
Thanks
Is there any way to tell which Gridseed is not running at maximum speed using Sandor's cpuminer? For example, in this screenshot:
https://i.imgur.com/piH2iDA.png
Gridseed #1 is running really slowly, which probably means that I need to either re-seat the heatsink or resolder the resistor. However, how do I determine which one is Gridseed #1? When I unplug the USB cable to a Gridseed, the UI doesn't update to let me know that it's dead, and every Gridseed looks like it's still hashing.
GSD1 is the second on the the list. This means it is the second on your com port list as well. If your com port list starts with COM3, then GSD1 = COM4.https://i.imgur.com/piH2iDA.png
Gridseed #1 is running really slowly, which probably means that I need to either re-seat the heatsink or resolder the resistor. However, how do I determine which one is Gridseed #1? When I unplug the USB cable to a Gridseed, the UI doesn't update to let me know that it's dead, and every Gridseed looks like it's still hashing.
From here you can just open your device manager and start disconnecting miners one by one. If you see COM3 disappearing from your device manager list, then thats your GSD1.
Its highly likely that your miner is faulty. I have one of those as well. Only one core out of 5 is mining. I tried everything to get it working, but i cant tell which component is faulty. Everything looks good for an eye.
Is there any way to tell which Gridseed is not running at maximum speed using Sandor's cpuminer? For example, in this screenshot:
https://i.imgur.com/piH2iDA.png
Gridseed #1 is running really slowly, which probably means that I need to either re-seat the heatsink or resolder the resistor. However, how do I determine which one is Gridseed #1? When I unplug the USB cable to a Gridseed, the UI doesn't update to let me know that it's dead, and every Gridseed looks like it's still hashing.
https://i.imgur.com/piH2iDA.png
Gridseed #1 is running really slowly, which probably means that I need to either re-seat the heatsink or resolder the resistor. However, how do I determine which one is Gridseed #1? When I unplug the USB cable to a Gridseed, the UI doesn't update to let me know that it's dead, and every Gridseed looks like it's still hashing.
I have been running for 10 +hrs with no issues on my 10 Gridseed (5 chip). Still have problems with the 40 chips Blades so just curious if anyone is successfully running this new cpuminer with blades on windows 7 .
It appears that all 80 chips initially begin hashing , but after about 10 minutes 40 stop hashing. The other 40 may keep hashing for 30 minutes or so. CPUminer is still trying to send out work so the program is not locking up etc. I thought it may be a usb issue so I switched out the cables with the 5 chips to rule that out. Com port settings have FIFO disabled etc. I also tested this out with bfgminer-3-99-0-windows-clean and my blades seem to work fine with that so far, but I would rather use this cpuminer version.
I tried the most basic script to rule out as much as possible. Frequency can be anywhere from 600-900 with same result so not sure what my problem is
minerd-gc3355 --freq=600 --gc3355=\\.\COM11,\\.\COM12 --url=stratum+tcp://us-east.multipool.us:7777 --userpass=X.XXXX:x
Thanks
It appears that all 80 chips initially begin hashing , but after about 10 minutes 40 stop hashing. The other 40 may keep hashing for 30 minutes or so. CPUminer is still trying to send out work so the program is not locking up etc. I thought it may be a usb issue so I switched out the cables with the 5 chips to rule that out. Com port settings have FIFO disabled etc. I also tested this out with bfgminer-3-99-0-windows-clean and my blades seem to work fine with that so far, but I would rather use this cpuminer version.
I tried the most basic script to rule out as much as possible. Frequency can be anywhere from 600-900 with same result so not sure what my problem is
minerd-gc3355 --freq=600 --gc3355=\\.\COM11,\\.\COM12 --url=stratum+tcp://us-east.multipool.us:7777 --userpass=X.XXXX:x
Thanks
Are you confident that your power supply is not sagging to the blade?
I haven't downloaded the latest version, but a few back that works for me with my blade and two 5-chip models and they have been running non-stop since 4/28/2014. I am running on Windows Server 2008/Windows Home Server.
----------------------------------------------------------
cpuminer-gc3355 - Started: [2014-04-28 22:22:04]
==============================================================================================================
(2s): 5.41/5.69 MH/s A:56591 R:0 HW:486
Connected to useast.coinsolver.com:3333 diff 256 with stratum as user
==============================================================================================================
GSD 0 850 MHz 2720.3/2858.1 KH/s A:28452 R:0 HW:122
GSD 1 850 MHz 2690.4/2832.1 KH/s A:28139 R:0 HW:364
==============================================================================================================
[2014-04-30 23:04:50] Accepted c0109a1f GSD 0@30
[2014-04-30 23:04:59] Accepted c6809634 GSD 1@31
[2014-04-30 23:05:00] New job_id: eff6_4059 Diff: 256
[2014-04-30 23:05:00] Stratum detected new block
[2014-04-30 23:05:01] Accepted 4ccdb708 GSD 1@12
[2014-04-30 23:05:03] Accepted 399c5a90 GSD 0@9
[2014-04-30 23:05:03] Accepted a66917cb GSD 1@26
Posted from Bitcointa.lk - #1hu28FuDGkFdbveS
Sandor111, can you Ctrl-C out of the program in the newest version? I am still using one of the older TUI versions (hasn't crashed on me when running on Windows Server 2008) and the program doesn't accept a Ctrl-C to quit. The only way to exit is to close the cmd window.
Posted from Bitcointa.lk - #8KTJckFnM6xsHNsq
Posted from Bitcointa.lk - #8KTJckFnM6xsHNsq
There seems to be a deadlock issue when the curses TUI is enabled, the whole cpuminer locks up. Anyone with C coding experience can chime in? I think it happens in util.c from line 193.
Do you really have multiple threads trying to get tui_lock without having applog_lock? Can you simplify it? Do you really need to protect the else condition of opt_curses with the mutex? Also, if opt_log is false, does it matter what happens - does it still deadlock or is it in the tui_lock context it mostly craps out?
Posted from Bitcointa.lk - #ZI4oMVMppYKUmKVN
Using Cpuminer .9c, problem got worst for me. Unit only run 1 hour max before is craps out on my Gridseed Blade.
No big deal but the stats seem to have got a bit tripped up in v0.9c:
Rebooted, tried again as root... Don't know what was missing, but it works now, seems to be hashing away. Will test how it goes through the night. Activated autotune, is there an estimated time on when the autotune infos will start appearing?
You need to enable debug mode (--debug) for that info.
Thank you. Already seeing autotune info's. Will report back later with stability info, but so far so good.
i keep getting failed to open /dev/ttyACM0
I am running on Raspberry pi:
./minerd --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2,/dev/ttyACM3,/dev/ttyACM4,/dev/ttyACM5,/dev/ttyACM6,/dev/ttyACM7 --freq=1000 --gc3355-autotune --url=stratum+tcp://usa-1.liteguardian.com:3335 --userpass=cxxx:x --retries=5
I am running on Raspberry pi:
./minerd --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2,/dev/ttyACM3,/dev/ttyACM4,/dev/ttyACM5,/dev/ttyACM6,/dev/ttyACM7 --freq=1000 --gc3355-autotune --url=stratum+tcp://usa-1.liteguardian.com:3335 --userpass=cxxx:x --retries=5
I have the same problem ... I'm using Kernel ... 3.10.37+
I don't have any ttyACM0 in my dev folder ... got 9 Blades connected thru 2 x 10 port usb hubs ... working well with cgminer ...
Having exactly the same issue, am I forgetting something or is there a workaround?
IIRC cgminer uses a different driver than cpuminer/bfgminer. Try modprobe cdc_acm and see if that helps.
Thank you, will try when I have time available to play with my rig.
I had the same problem trying to use cpuminer after having just used cgminer. Could not get a listing of any ttyACM devices. Quick fix was to reboot and start cpuminer without first using cgminer.
Already tried it, did not work, but thanks
Running it as root should clear up that problem.
Already tried this also but it did not help
but thanks anyway!Rebooted, tried again as root... Don't know what was missing, but it works now, seems to be hashing away. Will test how it goes through the night. Activated autotune, is there an estimated time on when the autotune infos will start appearing?
You need to enable debug mode (--debug) for that info.
i keep getting failed to open /dev/ttyACM0
I am running on Raspberry pi:
./minerd --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2,/dev/ttyACM3,/dev/ttyACM4,/dev/ttyACM5,/dev/ttyACM6,/dev/ttyACM7 --freq=1000 --gc3355-autotune --url=stratum+tcp://usa-1.liteguardian.com:3335 --userpass=cxxx:x --retries=5
I am running on Raspberry pi:
./minerd --gc3355=/dev/ttyACM0,/dev/ttyACM1,/dev/ttyACM2,/dev/ttyACM3,/dev/ttyACM4,/dev/ttyACM5,/dev/ttyACM6,/dev/ttyACM7 --freq=1000 --gc3355-autotune --url=stratum+tcp://usa-1.liteguardian.com:3335 --userpass=cxxx:x --retries=5
I have the same problem ... I'm using Kernel ... 3.10.37+
I don't have any ttyACM0 in my dev folder ... got 9 Blades connected thru 2 x 10 port usb hubs ... working well with cgminer ...
Having exactly the same issue, am I forgetting something or is there a workaround?
IIRC cgminer uses a different driver than cpuminer/bfgminer. Try modprobe cdc_acm and see if that helps.
Thank you, will try when I have time available to play with my rig.
I had the same problem trying to use cpuminer after having just used cgminer. Could not get a listing of any ttyACM devices. Quick fix was to reboot and start cpuminer without first using cgminer.
Already tried it, did not work, but thanks
Running it as root should clear up that problem.
Already tried this also but it did not help
but thanks anyway!Rebooted, tried again as root... Don't know what was missing, but it works now, seems to be hashing away. Will test how it goes through the night. Activated autotune, is there an estimated time on when the autotune infos will start appearing?
the...
git clone https://github.com/siklon/cpuminer-gc3355
Seems to fail when I run it, even as root.
Cloning into 'cpuminer-gc3355'...
error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing https://github.com/siklon/cpuminer-gc3355/info/refs
fatal: HTTP request failed
Update: So I was able to download the files to a ZIP and then move them via WINSCP to the directory I created. I am logged in as 'root'.
When I try and run the './autogen.sh' command I receive the following error: '-bash: ./autogen.sh: Permission denied'
I feel I am getting closer....
Thanks for all the input so far!
git clone https://github.com/siklon/cpuminer-gc3355
Seems to fail when I run it, even as root.
Cloning into 'cpuminer-gc3355'...
error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing https://github.com/siklon/cpuminer-gc3355/info/refs
fatal: HTTP request failed
Update: So I was able to download the files to a ZIP and then move them via WINSCP to the directory I created. I am logged in as 'root'.
When I try and run the './autogen.sh' command I receive the following error: '-bash: ./autogen.sh: Permission denied'
I feel I am getting closer....
Thanks for all the input so far!
chmod +x ./autogen.sh
Jump to: