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

Thanks,
Also the timeout number "N" is that in Minutes?
What is a fair number to set this to, 10 or 10 minutes or is that too short.

600-1400

Perfect, downloaded and running now!
What is the freq range, 800-1200?

What is the command syntax for resetting the 5 chips when or after closing the program so the miners stop pulling current as if they were still hashing?
Right now, the only way to get them back to idle (about 50% less current than when hashing) is to re-power them.
Can you add this feature so it runs upon program close?
Thanks

GOOD JOB, buddy...!!!...

cpuminer-gc3355 v0.9e

* Any frequency is supported now.
* Add --gc3355-timeout=N option: restart GC3355 chips when no share is submitted and timeout expires. N = value in seconds.
* Fix GC3355 firmware detection and hashrate display
* Fix stability issues with Blades
* Autotune: only 5-chip USB miner

Binaries have been updated.
Windows: https://www.dropbox.com/s/ttqa9p851siz8oi/minerd-gc3355.zip
Raspberry PI: https://www.dropbox.com/s/xc3lvysi8vtrt00/minerd-gc3355

It would.

Sorry to ask the stupid question, but you mentioned "send the reset command to the Blade", would this method/command work for the 5-chips too?

Do no use autotune on the Blades.

I forgot that the chip_id can only be half a byte long (0-7) when sending commands to the GC3355 chip, but the chip_id we are seeing from the nonces ranges from 0-39 (= # of chips)
You cannot set the frequency of chip 39, it will overflow the 4 bits. BUT... chip_id 0 is actually referencing chip 0, 8, 16, 32. chip_id 1 is actually referencing chip 1, 9, 17, 33... and so on, they are clusters of 8 chips.
To get the chip_id (to be used in frequency setting), simply do chip_id = chip_id_cpuminer % 8.
So if you set the frequency of chip 0, you will also set it for chip 8, 16 and 32, there is no way around that. This is why I will disable autotune for Blades in the next update.

Instead of killing cpuminer when a Blade is not submitting shares, it will send the reset command to the Blade, which is effectively the same as restarting cpuminer. I will push the code soon, still testing it.

Thanks a lot to Icemoment for lending his Blade to test, I wouldn't have concluded this without him.

Thanks for confirming this.  Now since the 5-chips look the same running vs. not running I get to play the game of which port/plug/unit is it.

BTW - Since reconfiguration and on .9d the blades have been steady.  There is still a bit of a variance in hashrate:

 GSD 3 | 850 MHz | 2766.8/2806.6 KH/s | A: 663 R: 3 H: 10
 GSD 4 | 850 MHz | 2604.8/2528.4 KH/s | A: 626 R: 1 H: 90
 GSD 5 | 850 MHz | 3024.4/2863.0 KH/s | A: 726 R: 2 H:  2
 GSD 6 | 850 MHz | 2579.9/2740.2 KH/s | A: 619 R: 2 H: 26

But this has been my experience with all the Gridseed stuff, no two units are exactly the same.

Gotcha! I'm not a Blade user nor will I probably ever be given what's coming down the pipe in a few weeks.
I'm also not using the latest cpuminer yet! Glad I'm waiting to see what else shakes lose before I dive in.
I'm still using Ver 2.3.2 which is working rock steady.
One thing I just changed today was I removed the autotune command and just put all my miners at 1175 which seems to have helped in a few different ways i.e. increased and or improved pool side stats. It's using less overhead now to run the show so.... maybe this will help. Who knows?
Good luck and God speed to a solution for your wasted hashes!
Wolfey2014

Sorry. I'm not a Raspi user. But I believe that's what it says at the support page on Hashra's website.
Have a looksee....

UART write error = faulty or loose USB cable/connection/hub.

Simply put, 0.9d gives me high rejects 0.9c does not. Same pool, same auto adjusting difficulty, and the discrepancy is reproducible just by switching between the two builds. Nothing to do with pool. And its not just me, someone else mentioned it a few posts ago, albeit on RPi),

Its now been another 5 hours since the stats I posted above (9+ hours in total) and the number of rejects is still no where near the numbers that were produced in 0.9d in just 4 hours.

FIFO buffers are still off.

This is not a problem for me, I just use 0.9c, works fine.

Wolfey I think that firmware is only for the RasPI right? I'm using windows still the same issue.

TC

There is a brand new firmware upgrade for the Blade and all other Gridseed models.
You can find it at the Hashra support link on the main site.
They're saying that they now offer multiple speed settings for your hardware and that the magic clock is 838 when using their latest firmware on your blade.
This may very well cure what ails your hardware.
Just thought you guys would like to know.
They're also stating that the release date of their Lunar Lander has been moved up to the 31st of this month!
Hope this helps!

I have to ask. Have you tried some simple solutions first?
Like, running at a higher difficulty rating? Does your pool offer one? If not, I'd try another pool that does.
Also, depending on your platform, comm port FIFO buffers might need to be turned OFF....
Just a couple thoughts.
I don't see reports of others having the same problem you are the last couple days so.....
Good luck!

I found these in the Raspbian FAQ:
http://www.raspbian.org/RaspbianFAQ#What_compilation_options_should_be_set_Raspbian_code.3F

Looks like I spoke too soon.  After about 15 minutes of hashing I start getting massive rejects.  Pool shows 15% rejected right now.

These are the rejects I get:

DEBUG: reject reason: Job 'c907' not found

Sorry, could give access if I were at home but can't get through the wall to access that from offsite.  Also, just noticed the point one of the 5-chips cut out my output read:

0: UART write error
0: Terminating GC3355 chip mining thread

After this it was no longer in the new block work dispatch a few minutes later.  Now hashrate is slowly dwindling but the device "looks" alive, although I know the UART error is the kiss of death I was seeing yesterday.

Here's some of the output after the restart:

 [2014-05-05 19:26:31] 1@3: Work_id differs (e59bbc40 != e59bbf04)
 [2014-05-05 19:26:41] 4@2: Work_id differs (e59bbc40 != e59bbf04)
 [2014-05-05 19:26:46] 3@1: Work_id differs (e59bbc40 != e59bbf04)
 [2014-05-05 19:26:48] 6@12: Work_id differs (e59bbc40 != e59bbf04)
 [2014-05-05 19:26:55] 6@23: Work_id differs (e59bbc40 != e59bbf04)
 [2014-05-05 19:27:01] 6@4: Work_id differs (e59bbc40 != e59bbf04)
 [2014-05-05 19:27:04] 4@1: Work_id differs (e59bbc40 != e59bbf04)
 [2014-05-05 19:27:15] Stratum connection timed out
 [2014-05-05 19:27:15] Stratum connection interrupted
 [2014-05-05 19:27:16] Failed to get Stratum session id
 [2014-05-05 19:27:16] Stratum difficulty set to 800
 [2014-05-05 19:27:16] New job_id: 1454 Diff: 800
 [2014-05-05 19:27:16] Stratum detected new block
 [2014-05-05 19:27:16] 4: Dispatching new work to GC3355 cores (0xe614d2e1)
 [2014-05-05 19:27:16] 1: Dispatching new work to GC3355 cores (0xe614d2e1)
 [2014-05-05 19:27:16] 0: Dispatching new work to GC3355 cores (0xe614d2e1)
[2014-05-05 19:27:16] 0: UART write error
 [2014-05-05 19:27:16] 3: Dispatching new work to GC3355 cores (0xe614d2e1)
[2014-05-05 19:27:16] 0: Terminating GC3355 chip mining thread
 [2014-05-05 19:27:16] 6: Dispatching new work to GC3355 cores (0xe614d2e1)
 [2014-05-05 19:27:16] 2: Dispatching new work to GC3355 cores (0xe614d2e1)
 [2014-05-05 19:27:16] 5: Dispatching new work to GC3355 cores (0xe614d2e1)

Going to throw a full reboot to see if all seven come back again.