GridSeed 5-chip USB miner voltage mod

[Xer0]

we should do a table with frequency vs hashrate vs wattage

to find the sweet spot of efficiency and maximum with 5V fan

[1715187664]

1715187664

[1715187664]

1715187664

[1715187664]

1715187664

[ajareselde]

ok, so i did the mod from original post, 1 bridge only, i can get to 938 mhz with very low amount of hw errors.. cca 20 in 24hours.
pools also confirm 400 avg. on 24 hour run., tested on ghash.io, 15min,1hour,and 24hour say the same, 2mh for 5 units moded.

i see that u guys pushed further, can anyone confirm what more mods EXACTLY is needed to be done to get past 400?

and what do you have extra in your .bat? i only have added voltage=1, should there be more ?

thanks and realy good work guys !










.

[wolfey2014]

Awesome! I'll gonna try to beat that !

My opinion is it's not a good idea, because
- every 100mV gives more less extra frequency and efficiency will be very bad.
- i tried to add more 280mV and it caused temperature runaway in idle state.

Solder bridges + resistor + pencil ?

Tell me your secret!

Nope, you need to change resistors only. Replace R52 with 100k, and place 120k to C32. In parallel it is 54.54kOhm, and VDD will be 1.97V.
If you would like to use only one resistor there is a 54.9kOhm in E96 series, but VDD will be more than 1.97V maybe 2V.

If it is working pls. for you, pls support my risky experiments:)
BTC: 1gqdzx8iSwUGt3vaoEaPCjvrWo7zKn7PK

I am giving out 0.6BTC to the first to get his Gridseed miner stable at 1100 MHz (<10 HW error in 24h) and post the steps to mod the miner. So far I have managed to get it stable at 1013 MHz, but I feel we can push it further.

Disclaimer: as always, I am not responsible for damage to your miner, do this at your own risk!

So i won 0.6BTC 

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

[chanberg]

wow 30 watts! lol intense

[nemercry]

We gonna beat you all!


BEAT THIS, GUYS



1350mhz, @31Watt, longterm proof comming soon.

wow....its just getting better, did you meant 1250mhz?

Yeah youre right .

[wolfey2014]

Hello all.

Earlier someone made an important point and I'd like to re-iterate and re-state it.

Regarding modifications and overclocking:
the only thing that matters in the end, is increased pool side accepted shares and pay out! $Moolah!$
That's why we're all trying to squeeze more hashes out of these little beauties! Mo Money!
We're not doing it just to make it run faster! 1400MHz ain't for shyt if it doesn't yield more profit much less burns the little buggers out prematurely!

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!

So when reporting your overclock results, please be sure that you have not only achieved stable operation with extremely minimum to ZERO hardware errors locally, but most importantly, improved hash rates and $increased profit$, pool side!

No increase in profits = negative results = wasted energy and of course, ones valuable time!

And so, The Evolution Continues!

Fantastic work my fellow Techies! Keep it up!

Thank you all!
Wolfey2014

[jwoodyu]

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!

[wolfey2014]

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

[Xer0]

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

[jwoodyu]

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

Doh!!!! i was looking at the 5sec Average or whatever.

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? 

[nemercry]

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)

[nemercry]

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 .
Acutally (as far as i know), you need to hard mod those voltages.
Regards

[wolfey2014]

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

[Xer0]

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 .
Acutally (as far as i know), you need to hard mod those voltages.
Regards

one of the miners has an "vid=1" option
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

[jamieb81]

we should do a table with frequency vs hashrate vs wattage

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

[XScrypt]

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.

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.

[DarkKnight]

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.

[wolfey2014]

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.

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

[ajareselde]

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.

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

[mixdio]

- 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 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
https://i.imgur.com/ryfJsjJ.jpg