Pages:
Author

Topic: HASHRA CONTROLA on Raspberry Pi for Gridseed - page 5. (Read 39584 times)

member
Activity: 112
Merit: 10
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.

The clock settings are mapped to the serialnumber of the miners. The chip amount setting is now an all or nothing deal I'm afraid, no individual configuration for that part. If you want to see a representative hashrate you can switch to the advanced tab.
newbie
Activity: 24
Merit: 0
Does 875 bring any hashrate gains? I was under the impression that increments of 50 was the best way to go, although that could be attributed to older versions of mining software.
newbie
Activity: 50
Merit: 0
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.
newbie
Activity: 24
Merit: 0
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 Cheesy
member
Activity: 112
Merit: 10
Since no one has announced it yet, 1.4.5 update is available, just updated now  Smiley

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

Is there a changelog of the changes in this release?

Thanks again

Glad you liked it Smiley

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.
newbie
Activity: 6
Merit: 0
Since no one has announced it yet, 1.4.5 update is available, just updated now  Smiley

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

Is there a changelog of the changes in this release?

Thanks again
member
Activity: 112
Merit: 10
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.
legendary
Activity: 1974
Merit: 1003
wow .. my topic really got popular  Cheesy

btw, now im using the latest gridseed firmware on gridseed controllers, uptime is great, over 4 days since im using it
hero member
Activity: 742
Merit: 500
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?
member
Activity: 112
Merit: 10
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
newbie
Activity: 50
Merit: 0
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?
hero member
Activity: 854
Merit: 506
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.
member
Activity: 112
Merit: 10
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
hero member
Activity: 854
Merit: 506
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
member
Activity: 112
Merit: 10
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.
member
Activity: 112
Merit: 10
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.

full member
Activity: 126
Merit: 100
I just updated my mini controlla but haven't seen any changes. Can you start posting change logs here when you release updates?
newbie
Activity: 25
Merit: 0
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?
member
Activity: 112
Merit: 10
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).
newbie
Activity: 25
Merit: 0
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.
Pages:
Jump to: