Topic: [GUIDE] GridSeed GC3355 5 Chip Setup/power/windows/linux/rpi by UnicornHasher - page 16. (Read 365630 times)

yeah this is the one I'm using.

Interesting. I started using the girnyau version recently but have not noticed this. Will take a closer look. The two versions are not much different from comparing the source code. The dtbartle version went away from setting static freq's and now support increments of 25. The version you referenced is an earlier build of dtbartle that had static freq.

I have considered forking the current dtbartle version with the per miner freq part of girnyau but am still undecided on doing static freq's or increments of 25. If I could figure out how to code increments of 5 that would be great. If static then there is not much benefit over just using girnyau's fork.

My miners are all over the map supporting freq's of 850 - 900+. Most of them do 863.

Are you basing your results on the pool reported hashrates? Contrary to what that one poster spams all over various threads the hashrate reported by pools are inaccurate and should not be used as a basis of your miners performance.

Edit: I'm not using a Pi. I found it too unreliable and like you mentioned about 10% lower hashrate.

Start at 800 and if it works well (few hardware errors and good pool hashrate) you can move up to 850, which is where most Gridseeds work best. You can try 900 too, but that typically doesn't yield any increase in performance. Gridseed has 5 ASIC chips inside, but as far as I can tell cgminer works fine without that parameter.

Hello,
what is the recommended frequency i can set for cgminer?
I'm currently using 650... what is the maximum and what is the recommended?

Moreover, what is it "chips=5"?

As part of another investigation into a problem I have seen with disconnects, I compared the girnyau sources to the dtbartle version. As far as I can tell, the girnyau changes look reasonable and are in line with what the author intended. I can see no reason for a 10% difference in hash rate. Certainly there is nothing intentionally in the code changes that would account for that difference.

This is probably a dumb question given that you're an active forum member and this is not your first rodeo, but if you're overclocking your units are you seeing a lot of hardware errors? As you're probably aware hardware errors can eat up your effective hash rate.

I'm using the girnyau version on a Raspberry Pi, mostly so that I can underclock some badly behaved units. I'm seeing what I believe are correct effective hash rates.

At the risk of seeming paranoid, I never use prebuilt binaries. I always build them myself from source.

If you're certain that you're configuring your miners exactly the same between the two cgminer versions and you're seeing a significant performance difference, maybe you should build cgminer yourself from sources. It's easy to do and is worth it for piece of mind.

this version gives me around 10% lesser hashrate then the orginal cgminer .... I did a test with 20 miners ....

I asked for it ... with PM no answer ... so far ...

This version supports "Per device frequency setting by serial number ":

https://github.com/girnyau/cgminer-gc3355

You need a special version of cgminer for that. I think only the girnyau fork supports that, and dtbartle does not.

http://cryptomining-blog.com/1688-alternative-cgminer-3-7-2-for-scrypt-mining-on-gridseed-5-chip-gc3355-asics/

Are you using the one linked from this page? There are many different versions floating around, defining specific unit freqs is an option that has to be compiled into the build. Links for source (linux) and a pre-compiled (win) here:
http://cryptomining-blog.com/1688-alternative-cgminer-3-7-2-for-scrypt-mining-on-gridseed-5-chip-gc3355-asics/

I found this online --gridseed-freq 6D9426984857=988,6D9656774857=975,6D8956965251=975
But when I put that in my .bat and launch cgminer just crashes (Of coarse after I put my serial numbers there lol) and change the frequencies to 850 and 900

Yes if some one could point to the fork that this has been working on best that be awesome. im running them on linux./

Hey guys I didn't know where else to ask this question so I'll ask here and sorry if it's already been answered.
I have 3 gridseed modules 2 of them are stable at 900mhz and the third on is stable at 850mhz is it possible to run different modules at different frequencies? If so how can I manually set each frequency in cgminer? I'm not using a controller I just have them plugged into my computer windows 7 thanks in advance!

I'm still seeing disconnects where after running for a while units disappear and are rediscovered. I'm on a Raspberry Pi running 10 GS units with the girnyau version of cgminer that I built from sources, plus Scripta as the web front end. Most of the units are on an Orico P10 U2.

After a disconnect, the device always reconnects a couple of seconds later. This leaves a "zombie" in the API because cgminer doesn't mark the device's status as dead. Sometimes more than one device at a time disconnects.

Here's an example of a disconnect from the log:


The errors are *always* in the "prepare_work" method of the driver. In the sources, the function name is gridseed_prepare_work. I never see any other USB errors in the log. I've reviewed the various Linux system logs but don't see a correlation to the problem there.

When this error happens, the thread associated with the device exits. But the code doesn't mark the device as dead. That, in combination with the way that Scripta detects "live" devices by verifying that the last 5 second hash value is non-zero, results in irritating and bogus device info and hash rate totals in the web front end.

I don't have a spare 10 port hub, so I can't swap that out. I do have some poorly behaving Gridseeds that have excessive hardware failures, so I've tried further under-clocking them. But I still get disconnects.

One thing I've noticed is that all of the failures in the log are aligned on 5 minute boundaries within a few seconds. Here's the most recent ones:


Scripta has several cron jobs that run on 5 minute boundaries. Most of the cron jobs call the cgminer API for status, which should be harmless.

But the timing of these events is very suspect. I'm starting to think that there's a cgminer race condition where sometimes an API status call can interfere with the general operation of cgminer.

As a binary chop, I'm going to try disabling the Scripta cron jobs to see if the problem goes away.

If anyone else has any suggestions, I'm all ears...

i'm not sure but i dint think thats enough power on the 5v Line to power all the gridseeds.

This is the Monoprice 24-port USB hub. I don't have it in front of me right now, but I think the power adapter for it is 12V at 4A = 48W. The Gridseeds are powered using 12V at 7A = 84W power bricks. Each one powers 8 Gridseeds each, and the Gridseeds run in scrypt only mode. I purchased the 20x Gridseed kit from Zoomhash, 4 of them.

I think you will find the HUB dose not have enough power to run 24 gridseeds

what size is the PSU?

I've run it for several days now, the screenshot was just an example. I normally use cpuminer because cgminer crashes after a few hours and disconnects all the Gridseeds, and I have to reboot the Raspberry Pi in order to get them all back.

I should be getting around 28 MH/s for 80 Gridseeds, but my pool only reports 6.5 MH/s. Strangely, one of the Raspberry Pi's has only 8 miners connected to it and each one is submitting shares, unlike the remaining 3 Raspberry Pi's that are hooked up to 24 miners each and only 1-3 Gridseeds per Pi are submitting shares. I'm not sure if it's because of the USB hub or the number of Gridseeds used, but this is the kit from Zoomhash so I'm under the assumption (perhaps erroneously) that everything should work.

It's showing "difficulty shares", i.e. increments by the pool difficulty (32 in your case). How long have you tested it? Your screenshot shows only about 10 minutes. I would start with one Raspberry, a smaller number of Gridseeds (e.g. 10) and after that is working and stable for at least an hour start adding more.

I'm trying to get 80 Gridseeds working across 4 Raspberry Pi's (24 Gridseeds for each Raspberry Pi using Monoprice 24-port USB hubs). However, I'm running into an issue with btbartle's cgminer:

http://i.imgur.com/wbdUUuA.png

It looks like the Gridseeds are hashing, but only 3 of them have submitted shares, and a very low amount at that (and strangely, it always increments by a power of 2). Does anybody have any idea why this is happening? I've tried using the default 600 MHz speed and also using cpuminer, but the results are always the same.