Topic: [GUIDE] GridSeed 5-Chip USB, Blade &amp; Black Miner Support/Tuning - page 27. (Read 308847 times)

Quote from: racebyu on May 05, 2014, 10:51:25 AM

I woke up this morning and found the Blade miner had stopped again during the night
using the latest software. I did turn OFF the FIFO buffers and set the baud speed to
115200 for ports 3 & 4 which are being used. Anything else I can check?

Its not the Blade as if I use BFGminer it works for days on end but lower hash power.
The software has stopped working on 3 different pools randomly and the laptop is hard
wired to the network console.

Here is a picture of the software as it was this morning on the Mining Pool Co.
http://i60.tinypic.com/xm1pcg.jpg

Sadly I'm facing the same, have two blades running on-location right now and I get at least one half dropping off every ~6 hours. Thought it was a power issue so I moved them to different locations but still the same. Already abandoned both BFG and CG miners as CPUMiner has been the most stable, but regardless cannot keep the blades running without issue. A few times I've seen the LIBUSB errors pop up, but generally by the time I see the dropoff I only see a screen like the above with a few stratum messages, a few new jobs listed, but nothing accepted and the rate moving down.

Trying a different usb hub this morning, but overall getting very frustrated at keeping these online. Tuned units of any other sort haven't kept me this involved in tuning/restarting/etc. in a long time. :/

It could be a Windows thing, did any if you try a different platform?

I think I had this issue - first time round on autotune with 0.9d it lasted 11 hours
Unfortunately I was running just the .bat file and it just was closed when I got back to it

now running in a command window, has autotuned to 847 and 831 and currently been going for 8 hours so far.....

Definitely no power issues - running off a 1000W gold. very susceptible to pool/connection issues though, need to set up a pool backup loop......

reactor

sr. member

Activity: 420

Merit: 250

So for my latest update... I'll include software/hardware info here too so it is easy to track what I'm talking about.

RPi / ZoomHash image / CPUMiner .9d / 2x Blade / 3x 5-Chip

Been running for about an hour and a half and one of my 5-chips cut out on me. I only noticed because when the output is displayed for new block/dispatch suddenly GSD 0 fell off the list. Confirmed it with no accepted shares or additional reference in the output window since then. New power management strategy seems to be working for blades, all are running with similar numbers right now:

GSD 3 | 850 MHz | 2711.2/2756.0 KH/s | A: 284 R: 0 H: 2
GSD 4 | 850 MHz | 2568.0/2568.9 KH/s | A: 268 R: 1 H: 29
GSD 5 | 850 MHz | 2625.3/2836.2 KH/s | A: 274 R: 1 H: 0
GSD 6 | 850 MHz | 2825.7/2704.5 KH/s | A: 295 R: 1 H: 15

HW errors seem to come in batches, like the 15 on unit 6 popped up over a few minutes but otherwise it is the strongest performer for consistent accepted shares. Like an idiot I just killed my screen so I've gotta start over now, did a quick reboot and now waiting to see what units are working.

Out of curiosity to sandor111, is there any way to report hashrate before a share is accepted? I don't know what numbers are floating around, but I'm sitting here staring at my output and see hashrate and A as 0 for one of the 5-chips but don't know if it is technically working. Just got the new block dispatch and all seven units were included (so running reboot returned the non-hashing unit to me), so I think it is working, just cannot confirm until it gets an accepted share.

wolfey2014

sr. member

Activity: 378

Merit: 250

Sandor111,
I wanted to turn off autotune and just set all my seeds to 1188KHs but it won't run at 1188 which is in the frequency chart I have on hand. It only resets to 1175KHs.

Also, the TUI looks a bit different with '--gc3355-autotune' removed from the command line.
Is it okay to just leave --gc3355-autotune out? Will that keep autotune from running without causing any problems?
Thanks!

Edit - Never mind. It seems to be running fine without autotune in the command line. I can tell autotune is not running. My hash rates seem to be a bit more consistently higher too.
I'm still running 2.3.2 too.

daddyfatsax

hero member

Activity: 857

Merit: 1000

Anger is a gift.

Anybody got a way to use the blades and 5 chips on the same instance of cg/cpuminer? I have tried cpuminer, and I am having the same issues as everyone else.

tc61

hero member

Activity: 494

Merit: 500

I am seeing the same problems, after some time the hash just stops and the one board on the blade will seem to be normal and the other almost no hash, and no accepts.. this is the same problem from rev. c.

csmflynt3

member

Activity: 86

Merit: 10

Quote from: csmflynt3 on May 05, 2014, 09:54:26 AM

Quote from: reactor on May 05, 2014, 09:35:40 AM

Quote from: csmflynt3 on May 05, 2014, 09:54:26 AM

I woke up this morning and found the Blade miner had stopped again during the night
using the latest software. I did turn OFF the FIFO buffers and set the baud speed to
115200 for ports 3 & 4 which are being used. Anything else I can check?

Its not the Blade as if I use BFGminer it works for days on end but lower hash power.
The software has stopped working on 3 different pools randomly and the laptop is hard
wired to the network console.

Here is a picture of the software as it was this morning on the Mining Pool Co.

Sadly I'm facing the same, have two blades running on-location right now and I get at least one half dropping off every ~6 hours. Thought it was a power issue so I moved them to different locations but still the same. Already abandoned both BFG and CG miners as CPUMiner has been the most stable, but regardless cannot keep the blades running without issue. A few times I've seen the LIBUSB errors pop up, but generally by the time I see the dropoff I only see a screen like the above with a few stratum messages, a few new jobs listed, but nothing accepted and the rate moving down.

Trying a different usb hub this morning, but overall getting very frustrated at keeping these online. Tuned units of any other sort haven't kept me this involved in tuning/restarting/etc. in a long time. :/

It could be a Windows thing, did any if you try a different platform?

I gave up on Windows + gridseed a long time ago.

I'm on rpi right now but having some of the same issues, cannot seem to keep my two blades + three 5-chips running steadily for any duration. Have tried different power configurations, different usb layouts, hell, different areas of the room, different frequencies, using 1 CGM instance vs. 7 CPUM instances, nada, still can't go ~12 hours without needing to reset a device or do a reboot to bring a few back. Previously just restarting CGM/CPUM on the device worked a couple of times but eventually needs to reboot.

Great devices, just frustrating right now.

Do you mind posting the full log (with --debug), till the point when the Blades stop hashing? That could help identify the cause.

I am curious if you tried setting a higher difficulty? 32 is awfully low for blades that is a lot of data going back and forth. I am running difficulty 256 with no issue

Hum, I do not know how to do that, just run the .bat file and the software.
How would I set the difficulty to 256, in the .bat file or in cpuminer?

You should be able to set that in your worker settings on the pool website. I am not familiar with that particular pool though. Normally 32 is for low hashrate miners

racebyu

sr. member

Activity: 346

Merit: 260

Quote from: reactor on May 05, 2014, 09:35:40 AM

I woke up this morning and found the Blade miner had stopped again during the night
using the latest software. I did turn OFF the FIFO buffers and set the baud speed to
115200 for ports 3 & 4 which are being used. Anything else I can check?

Its not the Blade as if I use BFGminer it works for days on end but lower hash power.
The software has stopped working on 3 different pools randomly and the laptop is hard
wired to the network console.

Here is a picture of the software as it was this morning on the Mining Pool Co.

Sadly I'm facing the same, have two blades running on-location right now and I get at least one half dropping off every ~6 hours. Thought it was a power issue so I moved them to different locations but still the same. Already abandoned both BFG and CG miners as CPUMiner has been the most stable, but regardless cannot keep the blades running without issue. A few times I've seen the LIBUSB errors pop up, but generally by the time I see the dropoff I only see a screen like the above with a few stratum messages, a few new jobs listed, but nothing accepted and the rate moving down.

Trying a different usb hub this morning, but overall getting very frustrated at keeping these online. Tuned units of any other sort haven't kept me this involved in tuning/restarting/etc. in a long time. :/

It could be a Windows thing, did any if you try a different platform?

I gave up on Windows + gridseed a long time ago.

I'm on rpi right now but having some of the same issues, cannot seem to keep my two blades + three 5-chips running steadily for any duration. Have tried different power configurations, different usb layouts, hell, different areas of the room, different frequencies, using 1 CGM instance vs. 7 CPUM instances, nada, still can't go ~12 hours without needing to reset a device or do a reboot to bring a few back. Previously just restarting CGM/CPUM on the device worked a couple of times but eventually needs to reboot.

Great devices, just frustrating right now.

Do you mind posting the full log (with --debug), till the point when the Blades stop hashing? That could help identify the cause.

I am curious if you tried setting a higher difficulty? 32 is awfully low for blades that is a lot of data going back and forth. I am running difficulty 256 with no issue

Hum, I do not know how to do that, just run the .bat file and the software.
When the cpuminer first starts it changes the diff in the software automatically.
How would I set the difficulty to 256, in the .bat file or in cpuminer?

reactor

sr. member

Activity: 420

Merit: 250

Do you mind posting the full log (with --debug), till the point when the Blades stop hashing? That could help identify the cause.

I'll set that up, got it up and running for another round on a different power setup (desperation move - switch which power cables go into which blade halves to see if that impacts anything), next round has the debug tag in my script already for the reboot which will inevitably show up. Wink

csmflynt3

member

Activity: 86

Merit: 10

Quote from: reactor on May 05, 2014, 09:35:40 AM