Some tuning news on Gridseeds (Scrypt Mining)
1.) Tuning of Gridseed Hardware (Soldering required) upto 436 KH/s per Miner
2.) Fork from CGMiner for Gridseed Hardware (Frequency per Miner, Easy Overclocking for more stable Miners)
http://gridseed-blog.com (contains link to Originalpost, BLOG about Gridseed Mining is currently created)
Topic: GridSeed 5-chip USB miner voltage mod - page 65. (Read 156988 times)
- Enable VID1: Short R336 (original VMOD)
- Increase DVDD to 1.4V: Cut R46 (0R jumper) and replace with 2.94k
- Increase VDD_PLL to 1.2V: Add 27.4k on top of R212 (27.4k || 10k = 7326R)
For reference, the default VDD_PLL is 0.8 x (R211 + R212) / R212, or 1.092V.
Not getting HW errors at 1000 MHz, but I haven't tested long term because I only got my units yesterday. I'm sure 1100+ could be achieved by increasing DVDD using the above method.
- Increase DVDD to 1.4V: Cut R46 (0R jumper) and replace with 2.94k
- Increase VDD_PLL to 1.2V: Add 27.4k on top of R212 (27.4k || 10k = 7326R)
For reference, the default VDD_PLL is 0.8 x (R211 + R212) / R212, or 1.092V.
Not getting HW errors at 1000 MHz, but I haven't tested long term because I only got my units yesterday. I'm sure 1100+ could be achieved by increasing DVDD using the above method.
It's currently stable (no HW errors, short term) at 1250 MHz (529 kH/s) at 1821 mV, with R46 being 14.7k.
Here are my R46 values and measured DVDD:
| Resistance (R) | Voltage (mV) |
| 4.32k | 1450 |
| 5.90k | 1509 |
| 7.79k | 1581 |
| 12.1k | 1734 |
| 14.7k | 1821 |
I think I'll stop there before I damage anything
Edit: here is a microscope shot of the mods
Blue: R336
Green: R46
Purple: R212
@Mixdio:
Could you explain me which benefit i'll get when i give it a higher PLL voltage ?
Doesnt make sense for me to higher the voltage there ?
Would be nice if you can help me on that here.
- Enable VID1: Short R336 (original VMOD)
- Increase DVDD to 1.4V: Cut R46 (0R jumper) and replace with 2.94k
- Increase VDD_PLL to 1.2V: Add 27.4k on top of R212 (27.4k || 10k = 7326R)
For reference, the default VDD_PLL is 0.8 x (R211 + R212) / R212, or 1.092V.
Not getting HW errors at 1000 MHz, but I haven't tested long term because I only got my units yesterday. I'm sure 1100+ could be achieved by increasing DVDD using the above method.
- Increase DVDD to 1.4V: Cut R46 (0R jumper) and replace with 2.94k
- Increase VDD_PLL to 1.2V: Add 27.4k on top of R212 (27.4k || 10k = 7326R)
For reference, the default VDD_PLL is 0.8 x (R211 + R212) / R212, or 1.092V.
Not getting HW errors at 1000 MHz, but I haven't tested long term because I only got my units yesterday. I'm sure 1100+ could be achieved by increasing DVDD using the above method.
It's currently stable (no HW errors, short term) at 1250 MHz (529 kH/s) at 1821 mV, with R46 being 14.7k.
Here are my R46 values and measured DVDD:
| Resistance (R) | Voltage (mV) |
| 4.32k | 1450 |
| 5.90k | 1509 |
| 7.79k | 1581 |
| 12.1k | 1734 |
| 14.7k | 1821 |
I think I'll stop there before I damage anything
Edit: here is a microscope shot of the mods
Blue: R336
Green: R46
Purple: R212
If I wanted to run mine at 1150 stable, which resistor values should I use on R46 and R212? I appreciate your picture and the risk you put in finding this mod.
Here is my resistor vs voltage table. + mean serial connected resistors, x mean parallel connected resistors
32k+1.8k 1.37V
32k+3k 1.42V
32k+4.7k 1.48V
32k+7.5k 1.58V
32k+10k 1.67V
32k+13k 1.78V
50k 1.81V
47k+5.1k 1.87V
100kx120k 1.97V
Exactly.
There are an equalation for cmos logic IC power consumption:
P=c*f*V^2+Pleakage, where c is a constant.
Gridseed uses 45nm technology, so Pleakage is high, but you see P~V^2.
If you divide it with the nominal values, you will get P/Pn=1200/850*2^2/1.2^2 -> P=4*Pn plus the leakage, but it is not easy to calculate.
Yes, there are a point after the real sweet spot which have the highest local hashrate and almost no HW error. It looks like it is a sweet spot, but it is the opposite(lets call it "black sweet spot"). As you know(or no:D), there are two kind of HW error.
- The first is when the calculation error gives a false positive result and the share submitted to cgminer. Then cgminer does an error checking, and recognises it is a false result, and increases the HW error counter.
- The second is when the calculation error gives a false negative result and the gs doesn't submit a share to cgminer. You will never get an error report in this situation because it is theoretically undetectable, only the WU decreases.
I experienced that, there are almost always a black sweet spot after a real sweet spot.
Yes i had 429 error and 43531 shares(including the errors). It means there are 429/43531*100%=0.9855% error rate, so the real hashrate is 510*(1-0.009855)=504.97 kH/s. I've tested it on some pools(ghash.io,clevermining,middlecoin,wemineltc) and it is fine.
BTC: 1gqdzx8iSwUGt3vaoEaPCjvrWo7zKn7PK
32k+1.8k 1.37V
32k+3k 1.42V
32k+4.7k 1.48V
32k+7.5k 1.58V
32k+10k 1.67V
32k+13k 1.78V
50k 1.81V
47k+5.1k 1.87V
100kx120k 1.97V
So, you're saying to put a 120k resistor across C32 in parallel with it, right?
If one chooses the single resistor method of 54.54k instead, it is to replace R52 instead, right?
No longer any need for the 4 previous mods i.e. 2 jumpers, 39k and pencil mod, correct?
The ultimate option / mod is:
Just a single resistor (54.54k) solution and that's it?
If so,,,,
How sweet it is!
Wolfey2014
If one chooses the single resistor method of 54.54k instead, it is to replace R52 instead, right?
No longer any need for the 4 previous mods i.e. 2 jumpers, 39k and pencil mod, correct?
The ultimate option / mod is:
Just a single resistor (54.54k) solution and that's it?
If so,,,,
How sweet it is!
Wolfey2014
Exactly.
There are an equalation for cmos logic IC power consumption:
P=c*f*V^2+Pleakage, where c is a constant.
Gridseed uses 45nm technology, so Pleakage is high, but you see P~V^2.
If you divide it with the nominal values, you will get P/Pn=1200/850*2^2/1.2^2 -> P=4*Pn plus the leakage, but it is not easy to calculate.
There is obviously a point where overclocking no longer yields positive results at the pool, not to mention making magic black smoke 
. Seeing positive results locally 'client side' means nothing if it isn't reflected pool side!
. Seeing positive results locally 'client side' means nothing if it isn't reflected pool side! Yes, there are a point after the real sweet spot which have the highest local hashrate and almost no HW error. It looks like it is a sweet spot, but it is the opposite(lets call it "black sweet spot"). As you know(or no:D), there are two kind of HW error.
- The first is when the calculation error gives a false positive result and the share submitted to cgminer. Then cgminer does an error checking, and recognises it is a false result, and increases the HW error counter.
- The second is when the calculation error gives a false negative result and the gs doesn't submit a share to cgminer. You will never get an error report in this situation because it is theoretically undetectable, only the WU decreases.
I experienced that, there are almost always a black sweet spot after a real sweet spot.
You keep saying that. However so far the reports from the modified miners don't back that up.
I can overclock my unmodified miner to get 500 kh/s, but that doesn't mean I'm getting 500 kh/s worth of completed work. Due to rejects/HW errors I'd be getting a lot less than that. You posted a screenshot showing 500kh/s but you had 429 HW errors over the course of about two days. For the same period of time, I have 9 HW errors. Those HW errors hurt and lower your effective hashrate.
It doesn't matter what hashrate your miner is reporting. What matters is how much work the pool sees you are doing. If, as we've seen, your miner is reporting 450 kh/s but the pool is reporting a 24 hour average of 350 kh/s then something is off.
We need OBJECTIVE tests to verify how effective the mods are. Testing shouldn't be run against pools or solomining anyway. There's too much variance. A real test would be run against test blocks. Remove the pools and coins from it entirely. Send the same workunit over and over again. Take the stats from that and calculate the effective hashrate. I think cgminer has a test mode that does something like this.
I can overclock my unmodified miner to get 500 kh/s, but that doesn't mean I'm getting 500 kh/s worth of completed work. Due to rejects/HW errors I'd be getting a lot less than that. You posted a screenshot showing 500kh/s but you had 429 HW errors over the course of about two days. For the same period of time, I have 9 HW errors. Those HW errors hurt and lower your effective hashrate.
It doesn't matter what hashrate your miner is reporting. What matters is how much work the pool sees you are doing. If, as we've seen, your miner is reporting 450 kh/s but the pool is reporting a 24 hour average of 350 kh/s then something is off.
We need OBJECTIVE tests to verify how effective the mods are. Testing shouldn't be run against pools or solomining anyway. There's too much variance. A real test would be run against test blocks. Remove the pools and coins from it entirely. Send the same workunit over and over again. Take the stats from that and calculate the effective hashrate. I think cgminer has a test mode that does something like this.
Yes i had 429 error and 43531 shares(including the errors). It means there are 429/43531*100%=0.9855% error rate, so the real hashrate is 510*(1-0.009855)=504.97 kH/s. I've tested it on some pools(ghash.io,clevermining,middlecoin,wemineltc) and it is fine.
BTC: 1gqdzx8iSwUGt3vaoEaPCjvrWo7zKn7PK
So, you're saying to put a 120k resistor across C32 in parallel with it, right?
If one chooses the single resistor method of 54.54k instead, it is to replace R52 instead, right?
No longer any need for the 4 previous mods i.e. 2 jumpers, 39k and pencil mod, correct?
The ultimate option / mod is:
Just a single resistor (54.54k) solution and that's it?
If so,,,,
How sweet it is!
Wolfey2014
If one chooses the single resistor method of 54.54k instead, it is to replace R52 instead, right?
No longer any need for the 4 previous mods i.e. 2 jumpers, 39k and pencil mod, correct?
The ultimate option / mod is:
Just a single resistor (54.54k) solution and that's it?
If so,,,,
How sweet it is!
Wolfey2014
Exactly.
There are an equalation for cmos logic IC power consumption:
P=c*f*V^2+Pleakage, where c is a constant.
Gridseed uses 45nm technology, so Pleakage is high, but you see P~V^2.
If you divide it with the nominal values, you will get P/Pn=1200/850*2^2/1.2^2 -> P=4*Pn plus the leakage, but it is not easy to calculate.
BTC: 1gqdzx8iSwUGt3vaoEaPCjvrWo7zKn7PK
- Enable VID1: Short R336 (original VMOD)
- Increase DVDD to 1.4V: Cut R46 (0R jumper) and replace with 2.94k
- Increase VDD_PLL to 1.2V: Add 27.4k on top of R212 (27.4k || 10k = 7326R)
For reference, the default VDD_PLL is 0.8 x (R211 + R212) / R212, or 1.092V.
Not getting HW errors at 1000 MHz, but I haven't tested long term because I only got my units yesterday. I'm sure 1100+ could be achieved by increasing DVDD using the above method.
It's currently stable (no HW errors, short term) at 1250 MHz (529 kH/s) at 1.821V, with R46 being 14.7k.
Here are my R46 values and measured DVDD:
Resistor Value Resulting DVDD Voltage
4.32k 1.450V
5.90k 1.509V
7.79k 1.581V
12.1k 1.734V
14.7k 1.821V
I think I'll stop there before I damage anything
Good. Thank you!
I edited it a bit for my own clarity. Hope you don't mind.
What is your pool side hash rate - current hash rate and - average hash rate < most important....
Wolfey2014
- Enable VID1: Short R336 (original VMOD)
- Increase DVDD to 1.4V: Cut R46 (0R jumper) and replace with 2.94k
- Increase VDD_PLL to 1.2V: Add 27.4k on top of R212 (27.4k || 10k = 7326R)
For reference, the default VDD_PLL is 0.8 x (R211 + R212) / R212, or 1.092V.
Not getting HW errors at 1000 MHz, but I haven't tested long term because I only got my units yesterday. I'm sure 1100+ could be achieved by increasing DVDD using the above method.
- Increase DVDD to 1.4V: Cut R46 (0R jumper) and replace with 2.94k
- Increase VDD_PLL to 1.2V: Add 27.4k on top of R212 (27.4k || 10k = 7326R)
For reference, the default VDD_PLL is 0.8 x (R211 + R212) / R212, or 1.092V.
Not getting HW errors at 1000 MHz, but I haven't tested long term because I only got my units yesterday. I'm sure 1100+ could be achieved by increasing DVDD using the above method.
It's currently stable (no HW errors, short term) at 1250 MHz (529 kH/s) at 1821 mV, with R46 being 14.7k.
Here are my R46 values and measured DVDD:
| Resistance (R) | Voltage (mV) |
| 4.32k | 1450 |
| 5.90k | 1509 |
| 7.79k | 1581 |
| 12.1k | 1734 |
| 14.7k | 1821 |
I think I'll stop there before I damage anything
Edit: here is a microscope shot of the mods
Blue: R336
Green: R46
Purple: R212
http://i.imgur.com/ryfJsjJ.jpg
Same here. My unmodified miner gets poolside results of anywhere from 250-500 kh/s. Using the 500 kh/s spike to make any claims doesn't make a lot of sense. My average rate is somewhere around 360-370.
As has been said many times in this thread, a faster hashrate does not necessarily mean better overall performance. The rest of the miner needs to be taken into account. I can think of several issues off the top of my head that would prevent improved performance (and even worse performance) with overclocking. Even the firmware could become an issue (ever played an old DOS game that didn't have an FPS limiter on a modern machine?).
I'm waiting to see what the numbers look like after another 24 hours.
As has been said many times in this thread, a faster hashrate does not necessarily mean better overall performance. The rest of the miner needs to be taken into account. I can think of several issues off the top of my head that would prevent improved performance (and even worse performance) with overclocking. Even the firmware could become an issue (ever played an old DOS game that didn't have an FPS limiter on a modern machine?).
I'm waiting to see what the numbers look like after another 24 hours.
There are no problem or performance issues at higher frequencies, except if HW error rate is increased. I'am using 230400 serial baudrate and the hashrate/freq ratio is constant.
That isn't what the results indicate so far. If you're running at 1000 MHz, you should be hashing at around 420 kh/s. The stats so far indicate that even with no errors the performance isn't noticeably better than an unmodified unit. There could be a number of reasons for that.
That being said, you can't make the claim that there are no other issues when overclocking without knowing how every part of the system works. If any part of the system is being saturated or starved, increasing chip speed isn't going to help (and may even make things worse depending on the software/firmware/architecture).
Again, hashrate does NOT equal performance. Hashrate is a measure of how fast the chips are hashing, not how much work is actually being done. That's why you need to look at the whole system when you're trying to improve performance. More hashing power is pointless if the problem is actually IO, for example.
If after another 24 hours elapse and the performance is still about the same, then other parts of the system may need to be investigated for potential bottlenecks.
Again, there are no bottleneck or performance issue.
You keep saying that. However so far the reports from the modified miners don't back that up.
I can overclock my unmodified miner to get 500 kh/s, but that doesn't mean I'm getting 500 kh/s worth of completed work. Due to rejects/HW errors I'd be getting a lot less than that. You posted a screenshot showing 500kh/s but you had 429 HW errors over the course of about two days. For the same period of time, I have 9 HW errors. Those HW errors hurt and lower your effective hashrate.
It doesn't matter what hashrate your miner is reporting. What matters is how much work the pool sees you are doing. If, as we've seen, your miner is reporting 450 kh/s but the pool is reporting a 24 hour average of 350 kh/s then something is off.
We need OBJECTIVE tests to verify how effective the mods are. Testing shouldn't be run against pools or solomining anyway. There's too much variance. A real test would be run against test blocks. Remove the pools and coins from it entirely. Send the same workunit over and over again. Take the stats from that and calculate the effective hashrate. I think cgminer has a test mode that does something like this.
just calculate % of hw compared to total accepted shares, i get about 2% rejects+hw errors combined @ 950mhz.
bottomline, few hw is nothing. and pls update thread to 500kh+ mods, so i can verify them also.
cheers
Same here. My unmodified miner gets poolside results of anywhere from 250-500 kh/s. Using the 500 kh/s spike to make any claims doesn't make a lot of sense. My average rate is somewhere around 360-370.
As has been said many times in this thread, a faster hashrate does not necessarily mean better overall performance. The rest of the miner needs to be taken into account. I can think of several issues off the top of my head that would prevent improved performance (and even worse performance) with overclocking. Even the firmware could become an issue (ever played an old DOS game that didn't have an FPS limiter on a modern machine?).
I'm waiting to see what the numbers look like after another 24 hours.
As has been said many times in this thread, a faster hashrate does not necessarily mean better overall performance. The rest of the miner needs to be taken into account. I can think of several issues off the top of my head that would prevent improved performance (and even worse performance) with overclocking. Even the firmware could become an issue (ever played an old DOS game that didn't have an FPS limiter on a modern machine?).
I'm waiting to see what the numbers look like after another 24 hours.
There are no problem or performance issues at higher frequencies, except if HW error rate is increased. I'am using 230400 serial baudrate and the hashrate/freq ratio is constant.
That isn't what the results indicate so far. If you're running at 1000 MHz, you should be hashing at around 420 kh/s. The stats so far indicate that even with no errors the performance isn't noticeably better than an unmodified unit. There could be a number of reasons for that.
That being said, you can't make the claim that there are no other issues when overclocking without knowing how every part of the system works. If any part of the system is being saturated or starved, increasing chip speed isn't going to help (and may even make things worse depending on the software/firmware/architecture).
Again, hashrate does NOT equal performance. Hashrate is a measure of how fast the chips are hashing, not how much work is actually being done. That's why you need to look at the whole system when you're trying to improve performance. More hashing power is pointless if the problem is actually IO, for example.
If after another 24 hours elapse and the performance is still about the same, then other parts of the system may need to be investigated for potential bottlenecks.
Again, there are no bottleneck or performance issue.
You keep saying that. However so far the reports from the modified miners don't back that up.
I can overclock my unmodified miner to get 500 kh/s, but that doesn't mean I'm getting 500 kh/s worth of completed work. Due to rejects/HW errors I'd be getting a lot less than that. You posted a screenshot showing 500kh/s but you had 429 HW errors over the course of about two days. For the same period of time, I have 9 HW errors. Those HW errors hurt and lower your effective hashrate.
It doesn't matter what hashrate your miner is reporting. What matters is how much work the pool sees you are doing. If, as we've seen, your miner is reporting 450 kh/s but the pool is reporting a 24 hour average of 350 kh/s then something is off.
We need OBJECTIVE tests to verify how effective the mods are. Testing shouldn't be run against pools or solomining anyway. There's too much variance. A real test would be run against test blocks. Remove the pools and coins from it entirely. Send the same workunit over and over again. Take the stats from that and calculate the effective hashrate. I think cgminer has a test mode that does something like this.
I whole heatedly agree with everything you've said thus far, XScrypt! I've said the same thing in different words on here.
I'd be very interested in knowing how to get cgminer to perform the tasks you mention re: re run the same work unit over and over again in order to gain a true benchmark of actual real time performance.
This just might be the thing that finally makes me transition over to cgminer
I am liking it more and more, the more I read about it vs other mining programs out there. I still love cpuminer though! It was my first! 
Peace!
Wolfey2014
I was looking at my miners today as I was desoldering the fans and I noticed that there are actually two different builds of the gold models. The new ones use smd leds and have a 2nd chip under the large grey one, while the older ones use standard LEDs (much brighter/better IMO) and have just solder pads and only 1 chip under the large grey one.
Not sure the relevance, but I thought I'd mention it.
Not sure the relevance, but I thought I'd mention it.
Same here. My unmodified miner gets poolside results of anywhere from 250-500 kh/s. Using the 500 kh/s spike to make any claims doesn't make a lot of sense. My average rate is somewhere around 360-370.
As has been said many times in this thread, a faster hashrate does not necessarily mean better overall performance. The rest of the miner needs to be taken into account. I can think of several issues off the top of my head that would prevent improved performance (and even worse performance) with overclocking. Even the firmware could become an issue (ever played an old DOS game that didn't have an FPS limiter on a modern machine?).
I'm waiting to see what the numbers look like after another 24 hours.
As has been said many times in this thread, a faster hashrate does not necessarily mean better overall performance. The rest of the miner needs to be taken into account. I can think of several issues off the top of my head that would prevent improved performance (and even worse performance) with overclocking. Even the firmware could become an issue (ever played an old DOS game that didn't have an FPS limiter on a modern machine?).
I'm waiting to see what the numbers look like after another 24 hours.
There are no problem or performance issues at higher frequencies, except if HW error rate is increased. I'am using 230400 serial baudrate and the hashrate/freq ratio is constant.
That isn't what the results indicate so far. If you're running at 1000 MHz, you should be hashing at around 420 kh/s. The stats so far indicate that even with no errors the performance isn't noticeably better than an unmodified unit. There could be a number of reasons for that.
That being said, you can't make the claim that there are no other issues when overclocking without knowing how every part of the system works. If any part of the system is being saturated or starved, increasing chip speed isn't going to help (and may even make things worse depending on the software/firmware/architecture).
Again, hashrate does NOT equal performance. Hashrate is a measure of how fast the chips are hashing, not how much work is actually being done. That's why you need to look at the whole system when you're trying to improve performance. More hashing power is pointless if the problem is actually IO, for example.
If after another 24 hours elapse and the performance is still about the same, then other parts of the system may need to be investigated for potential bottlenecks.
Again, there are no bottleneck or performance issue.
You keep saying that. However so far the reports from the modified miners don't back that up.
I can overclock my unmodified miner to get 500 kh/s, but that doesn't mean I'm getting 500 kh/s worth of completed work. Due to rejects/HW errors I'd be getting a lot less than that. You posted a screenshot showing 500kh/s but you had 429 HW errors over the course of about two days. For the same period of time, I have 9 HW errors. Those HW errors hurt and lower your effective hashrate.
It doesn't matter what hashrate your miner is reporting. What matters is how much work the pool sees you are doing. If, as we've seen, your miner is reporting 450 kh/s but the pool is reporting a 24 hour average of 350 kh/s then something is off.
We need OBJECTIVE tests to verify how effective the mods are. Testing shouldn't be run against pools or solomining anyway. There's too much variance. A real test would be run against test blocks. Remove the pools and coins from it entirely. Send the same workunit over and over again. Take the stats from that and calculate the effective hashrate. I think cgminer has a test mode that does something like this.
we should do a table with frequency vs hashrate vs wattage
to find the sweet spot of efficiency and maximum with 5V fan
to find the sweet spot of efficiency and maximum with 5V fan
this is a good question, because would it be worth it to spend an extra 20w on like 100KH/s ?
it could get counter productive to use more power as you will pay more in KW than you get back in moolah from the added boost
these 4 resistors on the vrm, are they all selectable?
would it be possible to set 4 different voltages,
and select them in software?
so you could rund 30W/500kH now
but switch later to 10W/400kH
I have to admit that i dont get the profit from doing this would it be possible to set 4 different voltages,
and select them in software?
so you could rund 30W/500kH now
but switch later to 10W/400kH
.Acutally (as far as i know), you need to hard mod those voltages.
Regards
the second solder bridge is the hard-set equivalent for that
the profit?
beeing able to switch between high performance and high efficiency without resoldring
I was about to settle in and do the other mods but if the 533 turns out to be legit and sustainable,,,, i mean DAMN!
I can assure you that the unit is stable with that value. But to be honest at the actual power draw(31Watts), its not really worth the effort. (Also with nearly zero HW-Errors, its just a question of the voltage given.)
( I will post a description how to do those modifications next week, so everyone can do it itself if skills are available.)
Yet not a 24 h run, but i only got my desktop for this. And Everytime i want to test another modification i need to turn it off...
(I will point it to a headless machine the next days, and deliver the proof)
532.0k/532.7KH/s means what? 532KH/s client side / 532.7 pool side?
The rest of the print out means what, exactly?
I don't know how to read cgminerese yet
Wolfey2014
these 4 resistors on the vrm, are they all selectable?
would it be possible to set 4 different voltages,
and select them in software?
so you could rund 30W/500kH now
but switch later to 10W/400kH
I have to admit that i dont get the profit from doing this would it be possible to set 4 different voltages,
and select them in software?
so you could rund 30W/500kH now
but switch later to 10W/400kH
.Acutally (as far as i know), you need to hard mod those voltages.
Regards
I was about to settle in and do the other mods but if the 533 turns out to be legit and sustainable,,,, i mean DAMN!
I can assure you that the unit is stable with that value. But to be honest at the actual power draw(31Watts), its not really worth the effort. (Also with nearly zero HW-Errors, its just a question of the voltage given.)
( I will post a description how to do those modifications next week, so everyone can do it itself if skills are available.)
Yet not a 24 h run, but i only got my desktop for this. And Everytime i want to test another modification i need to turn it off...
(I will point it to a headless machine the next days, and deliver the proof)
I was about to settle in and do the other mods but if the 533 turns out to be legit and sustainable,,,, i mean DAMN!
533?
Oh...
You mean 532KH/s....DOH! lost me there a sec....
Damn somebody needs to take one for the team and confirm this mod independently. So it is not even removing a component to tacking an additional one on?
these 4 resistors on the vrm, are they all selectable?
would it be possible to set 4 different voltages,
and select them in software?
so you could rund 30W/500kH now
but switch later to 10W/400kH
would it be possible to set 4 different voltages,
and select them in software?
so you could rund 30W/500kH now
but switch later to 10W/400kH
I was about to settle in and do the other mods but if the 533 turns out to be legit and sustainable,,,, i mean DAMN!
533?
Oh...
You mean 532KH/s....DOH! lost me there a sec....
I was about to settle in and do the other mods but if the 533 turns out to be legit and sustainable,,,, i mean DAMN!
Jump to: