Yes I know that. The problem is that it can be done if you have 1-2 rig. But if you have 10-20-100, then you won't do that. May be there is some way to spread setting to all cards?
It can be done with any number of rigs, the principle is exactly the same as with any other way of GPU tuning. "Making" a curve takes me about 30 seconds, while setting +xxx clocks and -% powerlimit takes ~ 10 seconds. Then you test the card(s) as usual. On average it takes ~ 5-10 adjustments per card, so 150-300 seconds vs 50-100 seconds. Not that big of a deal even if you have 100 rigs 8 cards each. Will only take a few days to go through all of them. It all boils down to how much your time's worth. I don't have that many rigs and with curves I get more out of the cards since I can push them further (because the clocks/voltages don't fluctuate as much as they do with +/- xxx kind of tuning, so I don't have to leave nearly as much of a leeway). 
Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 133. (Read 2347599 times)
1070 sp4 18.5-18.8 -i20 vs 18.8-19.5 sp2 i20
sp-mod #4 test with different intensities: gigabyte g1 gaming 100% tdp and mild oc (core and memory)
-i 20: 18.64 MHASH
-i 22: 20.50 MHASH (+9,9%)
-i 24.7998 (default): 21.14MHASH (+13.4%)
So don't run with intensity 20 because you get 13.4% more hash if you run without the -i in the batfile
I don't get crashes on my rigs.
Wich drivers are you using and operating system?
Try to run the miner at default intensity without any oc and 100% tdp. (stock settings.) does it still crash?
screenshot:
What's the reason for me to do that? To mine your devfee? 
)
To increase your profit. Do you want a 35MHASH bitcore miner? Or do you want a 31MHASH bitcore miner?)The point is that #4 is faster, but it use more power and you need to run with the correct launch configuration.
Intensities between #2 and #3/4 for Bitcore SP is indeed different and not because he's just increasing the intensity. Workable intensity in #4 is -i 22, higher then that causes random crashing even at stock clocks and highest TDPs.
The net difference between #2 and #4 is about 7%, minus a 2% devfee. So it's about 5% faster at stable intensities.
No it doesn't have anything to do with power delivery, I've mined on more demanding algos, such as Nexus and SIB. It has something to do with the fluctuating GPU loads (probably due to the algo) that causes your gpu clock thrashing So depending on how well your card is factory OC'd it can indeed crash on the default intensity with your miner SP. I have enough cards to know certain models will crash and some wont at those intensities. No matter what you adjust the clocks to unless you underclock, they will crash.
Open afterburner and watch the stats. That's also why the hashrate goes up and down as it cycles through the algos.
Bitcore when it was first implemented was a band aid fix in order to get it up and running, I don't think it really ever got past that point. There was a LOT of initial crashing when the algo was first implemented.
What I have with sp4.
With 1080 and OC that I mentioned above. SP4 crashes with i22+. It is more or less stable at i20. But at that intencity it gives less result than sp2. 22 vs 24
1080ti with sp4 makes 30-30.5 on i25 vs 29-29.5 with sp2 on i20. Same OC settings.
1070 sp4 18.5-18.8 -i20 vs 18.8-19.5 sp2 i20
So it is clear that on the same intensity sp4 is worse than sp2. You can get extra 3-4% by rising intensity but loose at least the same by devfee.
That's because 5min devfee is taken first, so after every crash or change you will actually loose much more. As always liar sp_ is calling it 2% devfee while it is not.
Workable intensity in #4 is -i 22, higher then that causes random crashing even at stock clocks and highest TDPs.
All my rigs use the default intensities without crashing. (windows 8/7 32gb virtual memory)
Could it be a windows 10 issue?
What's the reason for me to do that? To mine your devfee? )
To increase your profit. Do you want a 35MHASH bitcore miner? Or do you want a 31MHASH bitcore miner?)The point is that #4 is faster, but it use more power and you need to run with the correct launch configuration.
You have no idea what you're talking about, punctuated by 'burning your card'. TDP is what you're looking for if you want to reduce the load on the cards, not intensity. That's independent of intensity. There is nothing wrong with miners that use more power. If you don't like it, you reduce your TDP. That's your choice.
Intensities between #2 and #3/4 for Bitcore SP is indeed different and not because he's just increasing the intensity. Workable intensity in #4 is -i 22, higher then that causes random crashing even at stock clocks and highest TDPs.
The net difference between #2 and #4 is about 7%, minus a 2% devfee. So it's about 5% faster at stable intensities.
No it doesn't have anything to do with power delivery, I've mined on more demanding algos, such as Nexus and SIB. It has something to do with the fluctuating GPU loads (probably due to the algo) that causes your gpu clock thrashing So depending on how well your card is factory OC'd it can indeed crash on the default intensity with your miner SP. I have enough cards to know certain models will crash and some wont at those intensities. No matter what you adjust the clocks to unless you underclock, they will crash.
Open afterburner and watch the stats. That's also why the hashrate goes up and down as it cycles through the algos.
Bitcore when it was first implemented was a band aid fix in order to get it up and running, I don't think it really ever got past that point. There was a LOT of initial crashing when the algo was first implemented.
16 gpu's supported in sp-mod #4
sp_ is there any gpu limitations? ie more than 8 gpu mining is possible?
The 1060 3gb can do 14 mhash++. 1060 6gb is normally around 10% faster. 14-15 MHASH
If you run with reduced tdp, f.ex 80% you loose around 10% hash. 12.5MHASH 1060 3gb
Thx sp_! If you run with reduced tdp, f.ex 80% you loose around 10% hash. 12.5MHASH 1060 3gb
The 1060 3gb can do 13.5-14 mhash++. 1060 6gb is normally around 10% faster. 14-15 MHASH
If you run with reduced tdp, f.ex 80% you loose around 10% hash. 12.5MHASH 1060 3gb
If you run with reduced tdp, f.ex 80% you loose around 10% hash. 12.5MHASH 1060 3gb
Can anybody tell hashrate bitcore sp-mod on 1060 mining cards and 1060 3Gb?
which one ) , there is mod2 and mod4 most popular )both ((=
Can anybody tell hashrate bitcore sp-mod on 1060 mining cards and 1060 3Gb?
which one ) , there is mod2 and mod4 most popular )
Can anybody tell hashrate bitcore sp-mod on 1060 mining cards and 1060 3Gb?
Yea you can expect to realistically get about 19.5 Mh out of SP Bitcore. The intensity is way too high and it crashes constantly to get the hash SP is talking about.
I get 20MHASH with 80% tdp. 20% less power-> 10% less hash. I don't have problems with crashes in the latest builds. Running fine on 6x 1070 rigs...
What's the reason for me to do that? To mine your devfee? )
To increase your profit. Do you want a 35MHASH bitcore miner? Or do you want a 31MHASH bitcore miner?)The point is that #4 is faster, but it use more power and you need to run with the correct launch configuration.
With the same settings and even -i 22 the system goes to reboot after some shares.
Thats because ridiculous frequency changes - even 1568-2164 is reached sometimes.
But these OC are used for all other algos and miners and works perfectly.
That's why I don't overclock Pascal cards by simply inputting +xxx in clocks and setting the powerlimit. It's very easy but also very imprecise. Not to mention downright useless for discussing with other people (and SP regularly exploits it by not saying the actual clocks/voltages but only something like +200 MHz which makes it harder for other users to figure out when we try to assess the actual difference between the free miners and the paid sp mods). When you simply set the max powerlimit and +/- clocks, you allow the GPU to set the clocks and voltages however it sees fit — the only limit being the power limit / TDP. So voltage and clocks jump like crazy, especially with algos like timetravel10. Thats because ridiculous frequency changes - even 1568-2164 is reached sometimes.
But these OC are used for all other algos and miners and works perfectly.
If you don't want it, adjust these parameters with curves (msi ab and evga precision have this functionality). With curves you have complete control over clocks and voltages. It's more time-consuming to figure out the stable clocks for each card/algo, but a lot more predictable as well since the card will stay at the clock/voltage pair that you set.
What's the reason for me to do that? To mine your devfee? )
)To increase your profit. Do you want a 35MHASH bitcore miner? Or do you want a 31MHASH bitcore miner?
The point is that #4 is faster, but it use more power and you need to run with the correct launch configuration.
With the same settings and even -i 22 the system goes to reboot after some shares.
Thats because ridiculous frequency changes - even 1568-2164 is reached sometimes.
But these OC are used for all other algos and miners and works perfectly.
That's why I don't overclock Pascal cards by simply inputting +xxx in clocks and setting the powerlimit. It's very easy but also very imprecise. Not to mention downright useless for discussing with other people (and SP regularly exploits it by not saying the actual clocks/voltages but only something like +200 MHz which makes it harder for other users to figure out when we try to assess the actual difference between the free miners and the paid sp mods). When you simply set the max powerlimit and +/- clocks, you allow the GPU to set the clocks and voltages however it sees fit — the only limit being the power limit / TDP. So voltage and clocks jump like crazy, especially with algos like timetravel10. Thats because ridiculous frequency changes - even 1568-2164 is reached sometimes.
But these OC are used for all other algos and miners and works perfectly.
If you don't want it, adjust these parameters with curves (msi ab and evga precision have this functionality). With curves you have complete control over clocks and voltages. It's more time-consuming to figure out the stable clocks for each card/algo, but a lot more predictable as well since the card will stay at the clock/voltage pair that you set.
Thats because ridiculous frequency changes - even 1568-2164 is reached sometimes.
But these OC are used for all other algos and miners and works perfectly.
But these OC are used for all other algos and miners and works perfectly.
every algo needs to be tuned differently.
You need to find out why your card is trottleing. Open gpuz and check the perfCap reason. Reboots and freezes is often caused by lack of power or missing powered risers, or that you have to many powered risers on the same cable in the psu. Tune the kernel with one card first. Then add more cards later.
)No thanks - free sp2mod is better and faster. But it crashes on some rigs frequently.
Thats because ridiculous frequency changes - even 1568-2164 is reached sometimes.
But these OC are used for all other algos and miners and works perfectly.
But these OC are used for all other algos and miners and works perfectly.
every algo needs to be tuned differently.
You need to find out why your card is trottleing. Open gpuz and check the perfCap reason. Reboots and freezes is often caused by lack of power or missing powered risers, or that you have to many powered risers on the same cable in the psu. Tune the rig with one card first. Then add more cards later.
Something is very wrong with your statements
sp2 => TDP95 ~2000/5054 -i 20 6*1080 = 145Mh/s
sp4 => same OC and -i 20 6*1080 = 135Mh/s - devfee.
sp2 => TDP95 ~2000/5054 -i 20 6*1080 = 145Mh/s
sp4 => same OC and -i 20 6*1080 = 135Mh/s - devfee.
The intensities has changed in sp4. (memory usage has been reduced in the kernel code) To run at full speed You need to run with -i 25 and not -i 20. sp4 also need alot of oc on the memory. -500 on mem is slow. +750 is good.
Thats because ridiculous frequency changes - even 1568-2164 is reached sometimes.
But these OC are used for all other algos and miners and works perfectly.
Jump to: