Wednesday 2nd April
Previous posts in series
0. Introduction
My attempts at dual mining were dismal. 250Khps and 9Ghps (both as measured by BTCGuild) per Gridseed. I didn't bother to try to figure out if this was still economically viable as I found dual mining was just too unstable - at least one Gridseed would stop working each day and I'd lose 12 hours mining until I could get home and reset it. On the "scrypt mining only" setting they're fairly stable - I've only had one Gridseed need resetting once in several weeks.
So I decided to overclock them using a version of cpuminer introduced in this post. This particular version allows overclocking in 50MHz steps, from 600MHz and up. Since there is always some variability in any manufactured product, it seemed likely that the Gridseeds might respond to various amounts of overclock differently to each other. So I spent a bit more than a week calibrating them.
1.0 Calibrating Gridseeds.
My Gridseeds have not been modified in any way so the overclocked hashrates may seem low. However the method I use can be used for modified Gridseeds as well.
1.1 Don't use your local hashrate.
Apart from the the local hashrate being recorded as 0.00 kphs on cpuminer, the local estimate should not be used if you're trying to figure out your effective hashrate. A better method is to use a stable pool with a useable API and record the number of shares you submit over a period of time, from which you can then estimate your effective (at the pool) hashrate.
In my case, I use Scryptguild as it is quite stable and has a nice API from which the data can easily be collected. I varied the times of day over which I collected data for different overclocking frequencies as time of day may be a hashrate affecting variable - for example changes to network traffic or the local WiFi environment.
Using a non-multipool might be better for calibration since there will be fewer stale shares and the stale amounts should remain fairly constant. However, a multipool like Scryptguild will earn you a bit more and will pay out in BTC without having to exchange it yourself.
1.2 Create a table of results.
For each Gridseed, for each overclock frequency sum the difficulty 1 (litecoin) equivalent shares submitted and divide by the sum of the durations and multiply by two to the power of sixteen. Record which overclock frequency provided the best result for each Gridseed and you're done.
2.0 YMMV
My data were taken over durations of between 87,000 and 150,000 seconds - long enough to reduce the variance due to share submission to less than two percent of the mean.
The amount by which each worker contributed to the total, by overclock frequency:
0. Introduction
My attempts at dual mining were dismal. 250Khps and 9Ghps (both as measured by BTCGuild) per Gridseed. I didn't bother to try to figure out if this was still economically viable as I found dual mining was just too unstable - at least one Gridseed would stop working each day and I'd lose 12 hours mining until I could get home and reset it. On the "scrypt mining only" setting they're fairly stable - I've only had one Gridseed need resetting once in several weeks.
So I decided to overclock them using a version of cpuminer introduced in this post. This particular version allows overclocking in 50MHz steps, from 600MHz and up. Since there is always some variability in any manufactured product, it seemed likely that the Gridseeds might respond to various amounts of overclock differently to each other. So I spent a bit more than a week calibrating them.
1.0 Calibrating Gridseeds.
My Gridseeds have not been modified in any way so the overclocked hashrates may seem low. However the method I use can be used for modified Gridseeds as well.
1.1 Don't use your local hashrate.
Apart from the the local hashrate being recorded as 0.00 kphs on cpuminer, the local estimate should not be used if you're trying to figure out your effective hashrate. A better method is to use a stable pool with a useable API and record the number of shares you submit over a period of time, from which you can then estimate your effective (at the pool) hashrate.
In my case, I use Scryptguild as it is quite stable and has a nice API from which the data can easily be collected. I varied the times of day over which I collected data for different overclocking frequencies as time of day may be a hashrate affecting variable - for example changes to network traffic or the local WiFi environment.
Using a non-multipool might be better for calibration since there will be fewer stale shares and the stale amounts should remain fairly constant. However, a multipool like Scryptguild will earn you a bit more and will pay out in BTC without having to exchange it yourself.
1.2 Create a table of results.
For each Gridseed, for each overclock frequency sum the difficulty 1 (litecoin) equivalent shares submitted and divide by the sum of the durations and multiply by two to the power of sixteen. Record which overclock frequency provided the best result for each Gridseed and you're done.
2.0 YMMV
My data were taken over durations of between 87,000 and 150,000 seconds - long enough to reduce the variance due to share submission to less than two percent of the mean.
The amount by which each worker contributed to the total, by overclock frequency:
Hashrates for each Gridseed at frequencies between 600 and 1000 MHz; and the changes in hashrates between those frequencies.
2.1 Calibration results
It's pretty clear that 850MHz is the best overall overclock frequency. However, Gridseed 0 has its maximum at 900 MHz and Gridseed 1 has a maximum at 800MHz. So for me this results in a 0.66% improvement.
The 0.066% improvement seems hardly worth the time I spent on calibration, or the time I let the Gridseeds hash at less than optimal overclock frequencies. However this is to overlook a couple of interesting points:
- It is likely that mining software with more granular tuning might be able to find more "sweet spots" like the 7% improvement it found for Gridseed 0.
- Of my ten Gridseeds, one had a large improvement by increasing the overclock frequency, and one had a small (and possibly not significant) improvement by decreasing the overclock frequency. Is this a representative sample? Is it possible that the Gridseed 0 type are more common? If that is the case, then an appropriate calibration method might be much more useful to you.
- You'll want to make sure that your Gridseeds are not opened by your group buy organiser - what happens if some unscrupulous resellers was keeping all the higher rated Gridseeds for himself?
2.2 Strange results I don't have the knowledge to comment on, but nevertheless bear pointing out.
Separate the Gridseeds into the following groups:
Group 1: Gridseeds 1, 2, 3, 6, 8
Group 2: Gridseeds 0, 4, 5, 7, 9
The mean of group 2 at 850 MHz is 331 khps and at the best performing frequencies the average is 335 khps. Group 1 has averages of 327 khps in both cases. Assuming these differences are significant, I've separated these two groups in the charts below - group 1 is the upper row (greatest negative change in hashrate after 800MHz) and group 2 is the lower row (greatest negative change in hashrate after 850MHz).
The greatest drop in hashrate with a change in overclock frequency seems to relate to the best achievable hashrate - an early drop in hashrate correlates with a lower maximum hashrate, and a later drop correlates with a higher maximum hashrate. Why? I'm hoping one of you can tell me.
2.3 Stale shares
I've included this for completeness, but the changes in stale rates are minimal and probably more affected by the pool changing the coin on which it was working than the overclocking.
3.0 Further improvements?
The obvious improvement would be the much mentioned voltage modifications. However, for those with a lack of time an inclination, there recently became available versions of cgminer and cpuminer which allow more fine grained changes in the overclock frequency. As soon as I finish compiling them, I plan to write a cronjob that will record hashrates at various frequencies for either cgminer or cpuminer or both) over the next few weeks, and find the best frequencies for my miners.
Yes, this is the trouble I'll go to in order to avoid getting out the soldering iron.
organofcorti.blogspot.com is a reader supported blog:
1QC2KE4GZ4SZ8AnpwVT483D2E97SLHTGCG
Find a typo or spelling error? Email me with the details at organofcorti@organofcorti.org and if you're the first to email me I'll pay you 0.012 btc per ten errors.
Please refer to the most recent blog post for current rates or rule changes.
I'm terrible at proofreading, so some of these posts may be worth quite a bit to the keen reader.
Exceptions:
- Errors in text repeated across multiple posts: I will only pay for the most recent errors rather every single occurrence.
- Errors in chart texts: Since I can't fix the chart texts (since I don't keep the data that generated them) I can't pay for them. Still, they would be nice to know about!
No comments:
Post a Comment
Comments are switched off until the current spam storm ends.