HASHRA CONTROLA on Raspberry Pi for Gridseed

[bexwhitt]

Since every time I've tried hashra 1.4 across 3 cards and 2 rpi's it crashes every few hours giving me the
"Forbidden
You don't have permission to access / on this server."

I gave up and made my own image with a simple startup script running the new version of CPUminer with autotune.

It now has a text user interface and API json stats output, you should consider using this in the hashra image since autotune is a lovely feature.

(If anyone is interested in my image PM me. It requires configuration by manually editing the startup script to match your setup and pools but, it seems solid and autotunes per-chip.)

I think the new image in some way puts stress on somewhat faulty sd cards that work with other stuff, since I have changed card it's been fine

[fivejonnyfive]

Since every time I've tried hashra 1.4 across 3 cards and 2 rpi's it crashes every few hours giving me the
"Forbidden
You don't have permission to access / on this server."

I gave up and made my own image with a simple startup script running the new version of CPUminer with autotune.

It now has a text user interface and API json stats output, you should consider using this in the hashra image since autotune is a lovely feature.

(If anyone is interested in my image PM me. It requires configuration by manually editing the startup script to match your setup and pools but, it seems solid and autotunes per-chip.)

I think the new image in some way puts stress on somewhat faulty sd cards that work with other stuff, since I have changed card it's been fine

Curious. All the cards I tried have been similarly generic el-cheapo cards that worked with minepeon. I'll throw a sandisk at it and see if that helps.

[Fizikal]

I'm using 1.4.0.1 with a blade. For me, it is stable as a rock. Up and running almost immediately. Stabilizes after 1 minute or so. Apparently it reads hash rate from the pool (I cannot remember where I saw this, but my pool hash rate is not always similar). I need a link to quote that, but cannot remember where I read it, so treat that last bit as only a possibility. I don't care for the frequency intervals it allows you to clock the miners (as a whole, not per device) at (only 800, 850, 900, etc). It does not graph hash rate, it does not monitor temps (can you monitor temps with Gridseeds?). The log output is kinda rough as it does not maintain the buffer for you to go back and look at items as they pass.

Like I said, it is extremely stable and I am at least happy with it for that. I am going to try Mox's Scripta at some point soon.

[maxzilla]

I'm using 1.4.0.1 with a blade. For me, it is stable as a rock. Up and running almost immediately. Stabilizes after 1 minute or so. Apparently it reads hash rate from the pool (I cannot remember where I saw this, but my pool hash rate is not always similar). I need a link to quote that, but cannot remember where I read it, so treat that last bit as only a possibility. I don't care for the frequency intervals it allows you to clock the miners (as a whole, not per device) at (only 800, 850, 900, etc). It does not graph hash rate, it does not monitor temps (can you monitor temps with Gridseeds?). The log output is kinda rough as it does not maintain the buffer for you to go back and look at items as they pass.

Like I said, it is extremely stable and I am at least happy with it for that. I am going to try Mox's Scripta at some point soon.

Yes the blade version calculates the hashrate differently. It counts the average amount of difficulty 1 hashes being submitted to the pool in 1 second (not taking in to account rejected work).
Other versions of CONTROLA calculates the hashrate by core frequency + the amount of Gridseed chips (calculated by BFGMiner), which is just an estimation. BFGMiner has the amount of chips defined as a constant (not configurable) so it still thinks it's mining with the 5 chip units instead of the blades, hence it shows just 360khs per blade instead of 2.6Mhs. I didn't have the time to fork BFG, change the code, build it for the blade... It's much easier to just calculate the hashrate by submitted shares (just like how a pool would do it).

[Fizikal]

I'm using 1.4.0.1 with a blade. For me, it is stable as a rock. Up and running almost immediately. Stabilizes after 1 minute or so. Apparently it reads hash rate from the pool (I cannot remember where I saw this, but my pool hash rate is not always similar). I need a link to quote that, but cannot remember where I read it, so treat that last bit as only a possibility. I don't care for the frequency intervals it allows you to clock the miners (as a whole, not per device) at (only 800, 850, 900, etc). It does not graph hash rate, it does not monitor temps (can you monitor temps with Gridseeds?). The log output is kinda rough as it does not maintain the buffer for you to go back and look at items as they pass.

Like I said, it is extremely stable and I am at least happy with it for that. I am going to try Mox's Scripta at some point soon.

Yes the blade version calculates the hashrate differently. It counts the average amount of difficulty 1 hashes being submitted to the pool in 1 second (not taking in to account rejected work).
Other versions of CONTROLA calculates the hashrate by core frequency + the amount of Gridseed chips (calculated by BFGMiner), which is just an estimation. BFGMiner has the amount of chips defined as a constant (not configurable) so it still thinks it's mining with the 5 chip units instead of the blades, hence it shows just 360khs per blade instead of 2.6Mhs. I didn't have the time to fork BFG, change the code, build it for the blade... It's much easier to just calculate the hashrate by submitted shares (just like how a pool would do it).

Any plans to do a fork? Or include the miner Mox is using in his scripta image?

[dloganbill]

I just updated my mini controlla but haven't seen any changes. Can you start posting change logs here when you release updates?

[maxzilla]

I'm using 1.4.0.1 with a blade. For me, it is stable as a rock. Up and running almost immediately. Stabilizes after 1 minute or so. Apparently it reads hash rate from the pool (I cannot remember where I saw this, but my pool hash rate is not always similar). I need a link to quote that, but cannot remember where I read it, so treat that last bit as only a possibility. I don't care for the frequency intervals it allows you to clock the miners (as a whole, not per device) at (only 800, 850, 900, etc). It does not graph hash rate, it does not monitor temps (can you monitor temps with Gridseeds?). The log output is kinda rough as it does not maintain the buffer for you to go back and look at items as they pass.

Like I said, it is extremely stable and I am at least happy with it for that. I am going to try Mox's Scripta at some point soon.

Yes the blade version calculates the hashrate differently. It counts the average amount of difficulty 1 hashes being submitted to the pool in 1 second (not taking in to account rejected work).
Other versions of CONTROLA calculates the hashrate by core frequency + the amount of Gridseed chips (calculated by BFGMiner), which is just an estimation. BFGMiner has the amount of chips defined as a constant (not configurable) so it still thinks it's mining with the 5 chip units instead of the blades, hence it shows just 360khs per blade instead of 2.6Mhs. I didn't have the time to fork BFG, change the code, build it for the blade... It's much easier to just calculate the hashrate by submitted shares (just like how a pool would do it).

Any plans to do a fork? Or include the miner Mox is using in his scripta image?

forking as we speak.

[maxzilla]

I just updated my mini controlla but haven't seen any changes. Can you start posting change logs here when you release updates?

Sorry man, just did some prep work in a development branch, no new functionality yet, I forgot the detection script looks at the whole repository, not just one branch.

[KryptoKings]

Niceman from Coinmine.pw changed up somethings on his pool to optimize it for BFGMiner. I ran my gridseed minis and blade last night and had close to 0 rejects. Pool ran super smooth. Give that pool a try with Hashra Controla and let me know what you guys think.

Thanks

[maxzilla]

Made a fork of BFGMiner 3.10.0 (not 3.99.0, that version is a lot slower then 3.10??? anybody experiencing this?)

added support for loads more frequencies (838 is in there)
added an extra bfg parameter --gridseed-chips (default 5) but is set to 40 for the blades. So hashrate calculation will be local hashrate instead of pool hashrate

This will all be in CONTROLA version 1.4.5

[KryptoKings]

Made a fork of BFGMiner 3.10.0 (not 3.99.0, that version is a lot slower then 3.10??? anybody experiencing this?)

added support for loads more frequencies (838 is in there)
added an extra bfg parameter --gridseed-chips (default 5) but is set to 40 for the blades. So hashrate calculation will be local hashrate instead of pool hashrate

This will all be in CONTROLA version 1.4.5

I have gridseed minis on 1.4.0 and run same speeds as 1.3.0
Only ever ran blade on 1.4.0.1

I will update it all when I get home. Thx.

[bexwhitt]

Made a fork of BFGMiner 3.10.0 (not 3.99.0, that version is a lot slower then 3.10??? anybody experiencing this?)

added support for loads more frequencies (838 is in there)
added an extra bfg parameter --gridseed-chips (default 5) but is set to 40 for the blades. So hashrate calculation will be local hashrate instead of pool hashrate

This will all be in CONTROLA version 1.4.5

I am running the hashra controlla for blade with a mixed 5 chip 40 chip setup will the new version totally screw this up?

[maxzilla]

Made a fork of BFGMiner 3.10.0 (not 3.99.0, that version is a lot slower then 3.10??? anybody experiencing this?)

added support for loads more frequencies (838 is in there)
added an extra bfg parameter --gridseed-chips (default 5) but is set to 40 for the blades. So hashrate calculation will be local hashrate instead of pool hashrate

This will all be in CONTROLA version 1.4.5

I am running the hashra controlla for blade with a mixed 5 chip 40 chip setup will the new version totally screw this up?

No. shouldn't make a difference, the chips setting is just for local hashrate calculation. If you mix and match devices, the numbers wouldn't make sense anymore though... need to figure out how to display the proper hashrate for different devices in the same list

[miter_myles]

Just checking - prolly me...

When I load up the web GUI for one of my gseed batches..  on 1.4 it says there is a newer version available.. of course I hit "yes" upgrade.. then it reboots.. and still tells me there is an update available... went through it three times now..  perhaps I need to reburn the image?

[rammy2k2]

wow .. my topic really got popular 

btw, now im using the latest gridseed firmware on gridseed controllers, uptime is great, over 4 days since im using it

[maxzilla]

Just checking - prolly me...

When I load up the web GUI for one of my gseed batches..  on 1.4 it says there is a newer version available.. of course I hit "yes" upgrade.. then it reboots.. and still tells me there is an update available... went through it three times now..  perhaps I need to reburn the image?

This is a bug. I have to fix it in the future. Simon (HASHRA) or I will announce when the new firmware is out. sorry about this.

[harpss1ngh]

Since no one has announced it yet, 1.4.5 update is available, just updated now  

Fantastic update as always, can now set individual frequencies! Great job

Is there a changelog of the changes in this release?

Thanks again

[maxzilla]

Since no one has announced it yet, 1.4.5 update is available, just updated now  

Fantastic update as always, can now set individual frequencies! Great job

Is there a changelog of the changes in this release?

Thanks again

Glad you liked it

As you can probably tell, it has the advanced tab now, where you can set individual clock frequencies. No need to restart the miner, it can do it in realtime.

And it has support for these frequencies:

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

The advanced tab shows the pool hashrate, so you can immediatly see if the tweaking has helped.

It also shows which miner is giving the hw error. which was missing in the previous version

It has a modified BFGminer with support of the above frequencies + blade support (40 chips per blade) for local hashrate calculation.

[Joe9]

I was just about to make a comment how rock solid the 1.4 release has been (20 GSD >1 RPi) and you go and update to 1.4.5! Amazing. Just seeing if it's available for the mini GSDs... it is! I'm going to wait for someone else to try this out, yup I'm a big baby like that

[bexwhitt]

the individual cpu tweeks are great most of the minis will run at 875 with no hardware errors the blades at 850 with minimal errors.

Quick question as the miners set themselves up in a different order on reboot does are the individual cpu speeds set to the serial of each miner or the listed miner?

Also as I can see which is the blade the serial on both is 48..... (the mini are all 6d.... or 8d.....) me being able to set 5 or 40 chip to correct the display would be nice.