[GUIDE] GridSeed GC3355 5 Chip Setup/power/windows/linux/rpi by UnicornHasher

[pjcltd]

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

what size is the PSU?

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'm not sure but i dint think thats enough power on the 5v Line to power all the gridseeds.

I've tried 4 different USB hubs and it looks like the max number of Gridseeds I can get running at the same time is around 7-9. This is using the Raspberry Pi across 3 different distros (Hashra, Scripta, Zoomhash). The hubs were:

4-port USB hub - 5V @ 1 A adapter, all 4 Gridseeds working
10-port USB hub - 5V @ 1 A adapter, 8 Gridseeds working
10-port USB hub - 5V @ 2.5A adapter, 8 Gridseeds working in Scripta, 9 Gridseeds working in Hashra.
Monoprice 24-port USB hub - 5V @ 4A adapter, 7 Gridseeds working in Scripta.

So I don't think it's related to the power.

I've had 20 working for about a month on two 10-port hubs, each with a 5A adapter.

I also had 26 working for a few days on two 13-port hubs, which came with 2.5A (I think) adapters, but I used an ATX PSU to feed 5V to them, so not sure how many amps that was.

I couldn't get the Monoprice hub to work either, at most I think I got 18 Gridseeds on it.

I also found that USB cables matter too. Cheap thin cables wasted me a lot of time with random drop outs and freezes.

I had my first 20 grid seeds working on a 49 port hub
and on Monday i got 30 more in
now i can not put more that 25 grid seeds on the 49 port hub if i do then all the grid seeds stop mining.
i have changed the PSU with one that has a 25amp 5v rail but its still the same
now I'm looking for a different usb hub to use.

had anyone got any of the 10 port hubs that come in the grid seed accessory pac they are not using and want to sell ?

[jamieb81]

Anyone can let me know if what I am experiencing is normal

I connected my gridseed and using CGminer 3.7.2 with windows everything in CGminer looks like its working well ( no HW or rejects after 20 min) but the Gridseed fan seems like changing the speed of the fan from slow to fast every few seconds, it is not consistent.

the fan never stop rotating but you clearly hear the noise level go up and down.

is this normal or there is something wrong with my gridseed

Thanks in advance for your help

Never seen it happening before. What kind of Power supply you use?

[Ranma13]

I had my first 20 grid seeds working on a 49 port hub
and on Monday i got 30 more in
now i can not put more that 25 grid seeds on the 49 port hub if i do then all the grid seeds stop mining.
i have changed the PSU with one that has a 25amp 5v rail but its still the same
now I'm looking for a different usb hub to use.

had anyone got any of the 10 port hubs that come in the grid seed accessory pac they are not using and want to sell ?

When you say "not mining", do you mean that it's hashing, but not submitting any shares? That's the same issue I'm getting, but my limit seems to be around 7-9 Gridseeds.

[wolfey2014]

I had my first 20 grid seeds working on a 49 port hub
and on Monday i got 30 more in
now i can not put more that 25 grid seeds on the 49 port hub if i do then all the grid seeds stop mining.
i have changed the PSU with one that has a 25amp 5v rail but its still the same
now I'm looking for a different usb hub to use.

had anyone got any of the 10 port hubs that come in the grid seed accessory pac they are not using and want to sell ?

When you say "not mining", do you mean that it's hashing, but not submitting any shares? That's the same issue I'm getting, but my limit seems to be around 7-9 Gridseeds.

Which operating system are you guys using? Or are you using controllers?

[Ranma13]

I had my first 20 grid seeds working on a 49 port hub
and on Monday i got 30 more in
now i can not put more that 25 grid seeds on the 49 port hub if i do then all the grid seeds stop mining.
i have changed the PSU with one that has a 25amp 5v rail but its still the same
now I'm looking for a different usb hub to use.

had anyone got any of the 10 port hubs that come in the grid seed accessory pac they are not using and want to sell ?

When you say "not mining", do you mean that it's hashing, but not submitting any shares? That's the same issue I'm getting, but my limit seems to be around 7-9 Gridseeds.

Which operating system are you guys using? Or are you using controllers?

Raspberry Pi here, as well as a regular desktop. Gonna try the regular desktop again and see how many I can get running this time.

[wolfey2014]

I had my first 20 grid seeds working on a 49 port hub
and on Monday i got 30 more in
now i can not put more that 25 grid seeds on the 49 port hub if i do then all the grid seeds stop mining.
i have changed the PSU with one that has a 25amp 5v rail but its still the same
now I'm looking for a different usb hub to use.

had anyone got any of the 10 port hubs that come in the grid seed accessory pac they are not using and want to sell ?

When you say "not mining", do you mean that it's hashing, but not submitting any shares? That's the same issue I'm getting, but my limit seems to be around 7-9 Gridseeds.

Which operating system are you guys using? Or are you using controllers?

Raspberry Pi here, as well as a regular desktop. Gonna try the regular desktop again and see how many I can get running this time.

Okay, it doesn't sound like your 49 port hub is the problem. It's probably getting plenty of power and current.
If you are using Windows 7 32 bit, or maybe 64 bit too, try turning OFF FIFO buffers completely. This will allow the comm lines to flow wide open and freely. Set your port speed to 115,200 also if it isn't already set there.
This may help if not correct your problem. It will certainly help increase speed to it's maximum just like it has with mine.
My pods have been mining for over 80 hours since I killed the buffers! No more unexpected crashes or disconnects etc. GONE!
Peace!

[CartmanSPC]

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

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

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

Sorry to bother you.

I just used your https://github.com/girnyau/cgminer-gc3355

which was compiled in https://bitcointalk.org/index.php?topic=477709.msg5763819#msg5763819 for the raspberry.

Somehow I'm getting around 10% less kh with the same setup .... then with the orginal cgminer from andreed from here https://bitcointalk.org/index.php?topic=477709.msg5539257#msg5539257

... Why does this happen ....?

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.

IMO 25 MHz increments work the best, one of my miners runs stable at 925 MHz, but throws HW errors at 856 MHz. The 25 MHz increments have the lowest PLL frequency and other PLL dividers set at 0. I have also found that the cgminer forks does not take in account the hashing time lost when finding an invalid nonce (HW error).

Interesting. Thanks...hadn't actually looked at the methods they are using to increment. When you say "cgminer doesn't take in account the hashing time lost when finding an invalid nonce (HW error)" are you referring to it's display of hashrate? Are you using dtbartle or girnyau?

Here's a 48 hour run on girnyau. Notice that some of the individual chips are not as good as others. I think someone mentioned perhaps coding freq per chip in the future (might have been bfgminer). I'm going to scale down to increments of 25 on girnyau to see what that does. Also some of these HW errors may be due to the internet connection as I only have 1-2 bars on the mobile hotspot it's hooked up to...not the best setup for testing  

[Stanford]

Hello! Excuse me, I don't know where to find out  - what type of usb cable end goes into the gridseed so that I know what to buy. thanks in advance

[Qwerty777]

 Thanks for the great guide! Finally I've got cgminer to work. I did the plug unplug thing it didn't work so I moved my usb hub to a 2.0 usb port and it started working. 

[jamieb81]

Hello! Excuse me, I don't know where to find out  - what type of usb cable end goes into the gridseed so that I know what to buy. thanks in advance

Hi

Use an 5 pin mini usb cable to standard usb 2.0

[edonkey]

IMO 25 MHz increments work the best, one of my miners runs stable at 925 MHz, but throws HW errors at 856 MHz. The 25 MHz increments have the lowest PLL frequency and other PLL dividers set at 0. I have also found that the cgminer forks does not take in account the hashing time lost when finding an invalid nonce (HW error).

This is very helpful. I was trying to tune my GridSeeds and was puzzling over the results. Sometimes a lower non-25 MHz boundary value would result in more HW errors.

I've reworked my frequencies on 25 MHz boundaries and things seem to be much more predictable.

Thanks for this observation!

[simon66]

IMO 25 MHz increments work the best, one of my miners runs stable at 925 MHz, but throws HW errors at 856 MHz. The 25 MHz increments have the lowest PLL frequency and other PLL dividers set at 0. I have also found that the cgminer forks does not take in account the hashing time lost when finding an invalid nonce (HW error).

This is very helpful. I was trying to tune my GridSeeds and was puzzling over the results. Sometimes a lower non-25 MHz boundary value would result in more HW errors.

I've reworked my frequencies on 25 MHz boundaries and things seem to be much more predictable.

Thanks for this observation!

Try this, it seems to work well for me. Ofcourse you need a modded unit to go over 1000Mhz with 0 HW errors.

Can someone point me to the page/thread that has the Gridseed 5 chip overclock frequency chart on it?
You know, the one that lists all the different frequencies from 450MHz up to 1400Mhz...
I can't seem to find it, easily..... ;(
Thanks

250, 400, 450, 500, 550, 600, 650, 700, 706, 713, 719, 725, 731, 738, 744, 750,
756, 763, 769, 775, 781, 788, 794, 800, 813, 825, 838, 850, 863, 875, 888, 900,
913, 925, 938, 950, 963, 975, 988, 1000, 1013, 1025, 1038, 1050, 1063, 1075, 1088,
1100, 1113, 1125, 1138, 1150, 1163, 1175, 1188, 1200, 1213, 1225, 1238, 1250, 1263,
1275, 1288, 1300, 1313, 1325, 1338, 1350, 1363, 1375, 1388, 1400.


Is that the one you are looking for?

I've put a notepad in my CPUminer folder right away so that I could have quick access to it hehe

[jamieb81]

Anyone using CGWatcher with bfg or cgminer on the gridseeds? if yes does it work good?

[sandor111]

Prolly being biased, but you guys should throw away the Rpi and switch to Lightningasic firmware, we now have an auto-overclocking feature that will overclock each individual chip (5 chips per Gridseed miner). Also the reject rate is close to 0, I've been getting 99.91% accepted running over 24 hours at Ghash.io.
BTW, Jack is making a test rig with 100 miners connected on a single controller, I will have a pic up to prove it.

[Quartium]

Hi, I need some help please.
I'm running one GridSeed with Cgminer and I used Zadig to replace the driver.
I changed the conf and I let it run, but now I'm having problem because even if it is running at 361 kh/s it is not accepting shares!

I waited one hour and nothing new.

Does someone had the same problem?

Thank you

[dmz241]

Having a bit of a problem here I am running one gridseed miner on windows xp for some reason it goes into Ph/s and now Th/s. Though it is accepting shares. One thing I did was later I added another pool now everytime it clocks up and change pool and it slowly clocks down. Any body having same problems?

[chup]

Anyone using CGWatcher with bfg or cgminer on the gridseeds? if yes does it work good?

I'm using it with bfgminer. But I'm using first version of bfgminer that supports gridseeds and dualminers. That version doesn't report well asic miners to cgwatcher so actual hashrate is far from acurate. Meaning it's not possible using restarts when hashrate goes down. Last version I tried was not supporting dualminers so I didn't tried it with cgwatcher.

[sandor111]

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

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

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

Sorry to bother you.

I just used your https://github.com/girnyau/cgminer-gc3355

which was compiled in https://bitcointalk.org/index.php?topic=477709.msg5763819#msg5763819 for the raspberry.

Somehow I'm getting around 10% less kh with the same setup .... then with the orginal cgminer from andreed from here https://bitcointalk.org/index.php?topic=477709.msg5539257#msg5539257

... Why does this happen ....?

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.

IMO 25 MHz increments work the best, one of my miners runs stable at 925 MHz, but throws HW errors at 856 MHz. The 25 MHz increments have the lowest PLL frequency and other PLL dividers set at 0. I have also found that the cgminer forks does not take in account the hashing time lost when finding an invalid nonce (HW error).

Interesting. Thanks...hadn't actually looked at the methods they are using to increment. When you say "cgminer doesn't take in account the hashing time lost when finding an invalid nonce (HW error)" are you referring to it's display of hashrate? Are you using dtbartle or girnyau?

Here's a 48 hour run on girnyau. Notice that some of the individual chips are not as good as others. I think someone mentioned perhaps coding freq per chip in the future (might have been bfgminer). I'm going to scale down to increments of 25 on girnyau to see what that does. Also some of these HW errors may be due to the internet connection as I only have 1-2 bars on the mobile hotspot it's hooked up to...not the best setup for testing  

Yes the hashrate displayed is basically (time elapsed x some constant x frequency x 5). So in that sense, hardware errors don't affect hashrate, at all. The way I do it, increment a hashes variable and time_spent_hashing variable, when a HW error occurs the hashes isn't incremented, but the time_spent_hashing is, and thus hashrate drops. That is the way it should be IMO, to get an accurate estimation of how HW errors affect the hashrate. Not using any of those, but Lighningasic firmware (which uses cpuminer) has per chip auto overclocking ATM.

[suchmoon]

Yes the hashrate displayed is basically (time elapsed x some constant x frequency x 5). So in that sense, hardware errors don't affect hashrate, at all. The way I do it, increment a hashes variable and time_spent_hashing variable, when a HW error occurs the hashes isn't incremented, but the time_spent_hashing is, and thus hashrate drops. That is the way it should be IMO, to get an accurate estimation of how HW errors affect the hashrate. Not using any of those, but Lighningasic firmware (which uses cpuminer) has per chip auto overclocking ATM.

Can you explain (or provide a link to) how the auto overclocking feature works? Thanks.

[sandor111]

Yes the hashrate displayed is basically (time elapsed x some constant x frequency x 5). So in that sense, hardware errors don't affect hashrate, at all. The way I do it, increment a hashes variable and time_spent_hashing variable, when a HW error occurs the hashes isn't incremented, but the time_spent_hashing is, and thus hashrate drops. That is the way it should be IMO, to get an accurate estimation of how HW errors affect the hashrate. Not using any of those, but Lighningasic firmware (which uses cpuminer) has per chip auto overclocking ATM.

Can you explain (or provide a link to) how the auto overclocking feature works? Thanks.

https://bitcointalk.org/index.php?topic=554542.msg6155656#msg6155656