I think the lack of core clock boost on the 1080 may somehow be a symptom of underutilzation, but not the major cause of underperformance. It seems somehow the host is not keeping the 1080 very busy. Could you observe and report the % GPU Load as reported by GPU-Z on the two systems?
I was also wondering about under utilization as well. It's not always a matter of GPU load, but how hard that work is pushing the card. Anyway, the 1080 is running around 90% GPU Usage and around 75% MCU Usage at 3x on these tasks. The 1070 is at around 94% GPU Load and 85% MCU Usage.
I may try swapping the cards around in the near future to see if that does anything.
One more interesting note, I recently updated the driver on the 1080 system to the latest, and decreased my task times at 3x by 10 minutes each. Before this, the 1070 was actually completing work FASTER than the 1080.
Matt,
Just a question. If the 1080 is providing video to your monitor. What is the speed of the 1080 if you don't overclock it. Does it boost at all? If it's only providing video to the monitor and no Einstein work units is it still boosting or is it underclocking?
I was also wondering about under utilization as well. It's not always a matter of GPU load, but how hard that work is pushing the card. Anyway, the 1080 is running around 90% GPU Usage and around 75% MCU Usage at 3x on these tasks. The 1070 is at around 94% GPU Load and 85% MCU Usage.
I may try swapping the cards around in the near future to see if that does anything.
One more interesting note, I recently updated the driver on the 1080 system to the latest, and decreased my task times at 3x by 10 minutes each. Before this, the 1070 was actually completing work FASTER than the 1080.
Those observations move me away from thinking the host system is failing to support the card, more to the direction that the current Einstein BRP6/CUDA55 application in concert with current drivers may not find a way to deploy a substantial fraction of the computational assets of a 1080, even when it is active. So far as I know, for GPU load purposes no accounting is made of what fraction of the computational resources are working on task at any given moment--only whether something is actively working at all.
Pretty high GPU loading reported combined with such low power consumption seems rather clearly to mean a bunch of resources are resting unused.
Even with the 1070 and 1060 full-out Einstein use at high GPU load uses much less power than reports from game reviewers, suggesting that even with them either some type of resource is little used, or else that the fraction of parallel units employed is not so high.
Bottom line, I've moving in the direction of thinking you don't have a rogue system, but rather are helping us see that 1080 is a particularly inefficient fit to the current Einstein code on current drivers.
@Zalster: The 1080 is in the computer I use for everyday things (web, work, etc) but also for gaming. It is connected to two monitors. When running Einstein, the GPU clock runs at its base speed of 1708MHz. Sometimes, if I open up a website which is able to take advantage of video acceleration, then the 1080 will boost to around 1974MHz. When I'm not running any any tasks, the 1080 reduces speed down to 265MHz. I hope that answered your questions. Let me know if not.
@Archae86: I tend to agree with your analysis and it's what I've been suspecting for some time. Once GPUGrid is able to support Pascal cards, I'll be moving back over there (while keeping Einstein as my backup if they are low on work). That project pushes cards harder than any other I've found, so I hope the 1080 will finally be able to show what it is really capable of doing.
I've started a Pascal overclocking thread. I certainly don't want to terminate this thread, but perhaps pesky details of Pascal overclocking technique can best be added over there. I've made eight posts with rather a lot of words--I hope they don't discourage others from contributing, arguing, disagreeing...
I've started a Pascal overclocking thread. I certainly don't want to terminate this thread, but perhaps pesky details of Pascal overclocking technique can best be added over there. I've made eight posts with rather a lot of words--I hope they don't discourage others from contributing, arguing, disagreeing...
It looks really good! Thanks for putting the time into that. I'm sure it will help out a lot of people.
@Zalster: The 1080 is in the computer I use for everyday things (web, work, etc) but also for gaming. It is connected to two monitors. When running Einstein, the GPU clock runs at its base speed of 1708MHz. Sometimes, if I open up a website which is able to take advantage of video acceleration, then the 1080 will boost to around 1974MHz. When I'm not running any any tasks, the 1080 reduces speed down to 265MHz. I hope that answered your questions. Let me know if not.
Thanks Matt. That helps. I had a 1080 (founder's edition) that I hybrid for cooling and discovered that it was underpowered. Once Hybridized, the power being supplied to the card was insufficient to power the card to it's standard speed or boost without applying a small amount of overclocking to it. If I left it alone, it would never reach standard or boost speeds but once I applied any amount of OC it boosted it's speed back up to where it normally was. Eventually we concluded that the power was just enough to keep that card running at specs but nothing left over for anything else. Eventually it forced me to return the card to it's original design. To add to the question on this, EVGA decided to go with the FTW platform for their hybrids. 2-8 pin power supplies on the card. Left a few of us wondering if there was something they weren't telling us about the single 8 pin configuration. I also run some 1070s FTW and have never seen an issue that I mention here with those.
@Zalster: The 1080 is in the computer I use for everyday things (web, work, etc) but also for gaming. It is connected to two monitors. When running Einstein, the GPU clock runs at its base speed of 1708MHz. Sometimes, if I open up a website which is able to take advantage of video acceleration, then the 1080 will boost to around 1974MHz. When I'm not running any any tasks, the 1080 reduces speed down to 265MHz. I hope that answered your questions. Let me know if not.
@Archae86: I tend to agree with your analysis and it's what I've been suspecting for some time. Once GPUGrid is able to support Pascal cards, I'll be moving back over there (while keeping Einstein as my backup if they are low on work). That project pushes cards harder than any other I've found, so I hope the 1080 will finally be able to show what it is really capable of doing.
That kind of sounds like a driver or 2d/3d clocks type of issue and not so much an OC/cooling issue. My 1070 boosted right on up to 1900 something as long as its cooled. I only added a slight additional OC to get it to 2050 and it seems like yours can do that too as long as the driver is in the right mode.
This morning I woke to find that the driver on my 1080 rig must have crashed sometime during the night as the GPU clock was swinging around at low speeds and tasks were very behind on their normal completion time. I rebooted the computer and when I started Einstein again, the 1080 went to it's full boost speed (plus some, as I have +100 set in Precision X). Since then, it has remained steadily at 2062MHz all day and around 79% power level. The card is staying nice and cool at around 56C with a custom fan curve.
I really don't know how to account for this. Just waiting to see if it drops again at some point. As I stated previously, this computer is my "daily driver" and has many different programs opening and closing on it during the day. I have not changed my normal usage patterns at all today.
P.S. I should note that this increase in GPU clock speed has not lead to a dramatic increase in task completion speed, confirming what others have observed. The increase of over 350MHz on the clock has resulted in about a five minute reduction in completion times with BRP6/CUDA55 at 3x.
You would think so but since it was on a hybrid the temperature was down to around 41C. So there wasn't overheating issue. I looked at GPU-Z and notice that it was giving me a warning in the Percap Reason. I moved the 8 pins from other cards but the warning continued. If I added just a tiny amount of OC to the card, then the Speed increased back to where it was originally. Maybe the 2d/3d is correct but I wasn't going to fool with it anymore so I opted to go for a 1070 FTW with 2 -8 pins. No problems after that
The next members of the Pascal family to ship apparently will be the 1050 and 1050Ti, within days.
As I have believed for quite a while that the 750/750Ti cards are remarkably good Einstein cards, with fabulous power efficiency for their generation, good Einstein performance per unit price, and easy fit into systems, I look forward to seeing actual Einstein results with these new cards.
The announced stock clock rates are pretty low compared to other Pascals. It remains to be seen what the practical overclocking limits for memory and core will turn out to be, running Einstein. As the memory bus is only 128 bits wide, these certainly are going to be far lower in Einstein performance (at least on the recently retired BRP6 application--which I understand better than others) than the higher grade Pascal cards, but the rumored prices are very low, with launch prices of $109 for the 1050, and $139 for the 1050Ti mentioned.
Regarding power, although both cards state a 75W TDP, they both lack a supplementary power connector, and in general the Pascal cards have been burning considerably less than TDP while running Einstein work. It remains to be seen whether these are remotely so good a power outlier within line as were the 750s, but at least they seem likely low enough as to pose little problem of existing supply adequacy for most people considering an upgrade.
For before and after launch discussion, and links to reviews when they come out, one source is this reddit thread.
While the users who built four 980Ti cards into one system may not find these of any interest, I think people with older hardware toying with the idea of a graphics card upgrade who have some sensitivity to purchase cost and electric power operating cost may find them pretty interesting.
One real wild card in any such decisions is the unknown matter of how GPU-using applications available next year on Einstein will behave, both in terms of GPU hardware fit and in terms of host requirements. The recent cuda55 variants of both the BRP6 and BRP4G applications have had pretty modest host impact, but there is nothing fundamental about that. There is reason to suspect a hoped-for GW application using GPU power may have much higher relative CPU demand, for example.
Matt_145 wrote:archae86
)
Matt,
Just a question. If the 1080 is providing video to your monitor. What is the speed of the 1080 if you don't overclock it. Does it boost at all? If it's only providing video to the monitor and no Einstein work units is it still boosting or is it underclocking?
Matt_145 wrote:I was also
)
Those observations move me away from thinking the host system is failing to support the card, more to the direction that the current Einstein BRP6/CUDA55 application in concert with current drivers may not find a way to deploy a substantial fraction of the computational assets of a 1080, even when it is active. So far as I know, for GPU load purposes no accounting is made of what fraction of the computational resources are working on task at any given moment--only whether something is actively working at all.
Pretty high GPU loading reported combined with such low power consumption seems rather clearly to mean a bunch of resources are resting unused.
Even with the 1070 and 1060 full-out Einstein use at high GPU load uses much less power than reports from game reviewers, suggesting that even with them either some type of resource is little used, or else that the fraction of parallel units employed is not so high.
Bottom line, I've moving in the direction of thinking you don't have a rogue system, but rather are helping us see that 1080 is a particularly inefficient fit to the current Einstein code on current drivers.
@Zalster: The 1080 is in the
)
@Zalster: The 1080 is in the computer I use for everyday things (web, work, etc) but also for gaming. It is connected to two monitors. When running Einstein, the GPU clock runs at its base speed of 1708MHz. Sometimes, if I open up a website which is able to take advantage of video acceleration, then the 1080 will boost to around 1974MHz. When I'm not running any any tasks, the 1080 reduces speed down to 265MHz. I hope that answered your questions. Let me know if not.
@Archae86: I tend to agree with your analysis and it's what I've been suspecting for some time. Once GPUGrid is able to support Pascal cards, I'll be moving back over there (while keeping Einstein as my backup if they are low on work). That project pushes cards harder than any other I've found, so I hope the 1080 will finally be able to show what it is really capable of doing.
I've started a Pascal
)
I've started a Pascal overclocking thread. I certainly don't want to terminate this thread, but perhaps pesky details of Pascal overclocking technique can best be added over there. I've made eight posts with rather a lot of words--I hope they don't discourage others from contributing, arguing, disagreeing...
archae86 wrote:I've started a
)
It looks really good! Thanks for putting the time into that. I'm sure it will help out a lot of people.
Matt_145 wrote:@Zalster: The
)
Thanks Matt. That helps. I had a 1080 (founder's edition) that I hybrid for cooling and discovered that it was underpowered. Once Hybridized, the power being supplied to the card was insufficient to power the card to it's standard speed or boost without applying a small amount of overclocking to it. If I left it alone, it would never reach standard or boost speeds but once I applied any amount of OC it boosted it's speed back up to where it normally was. Eventually we concluded that the power was just enough to keep that card running at specs but nothing left over for anything else. Eventually it forced me to return the card to it's original design. To add to the question on this, EVGA decided to go with the FTW platform for their hybrids. 2-8 pin power supplies on the card. Left a few of us wondering if there was something they weren't telling us about the single 8 pin configuration. I also run some 1070s FTW and have never seen an issue that I mention here with those.
Matt_145 wrote:@Zalster: The
)
That kind of sounds like a driver or 2d/3d clocks type of issue and not so much an OC/cooling issue. My 1070 boosted right on up to 1900 something as long as its cooled. I only added a slight additional OC to get it to 2050 and it seems like yours can do that too as long as the driver is in the right mode.
This morning I woke to find
)
This morning I woke to find that the driver on my 1080 rig must have crashed sometime during the night as the GPU clock was swinging around at low speeds and tasks were very behind on their normal completion time. I rebooted the computer and when I started Einstein again, the 1080 went to it's full boost speed (plus some, as I have +100 set in Precision X). Since then, it has remained steadily at 2062MHz all day and around 79% power level. The card is staying nice and cool at around 56C with a custom fan curve.
I really don't know how to account for this. Just waiting to see if it drops again at some point. As I stated previously, this computer is my "daily driver" and has many different programs opening and closing on it during the day. I have not changed my normal usage patterns at all today.
P.S. I should note that this increase in GPU clock speed has not lead to a dramatic increase in task completion speed, confirming what others have observed. The increase of over 350MHz on the clock has resulted in about a five minute reduction in completion times with BRP6/CUDA55 at 3x.
You would think so but since
)
You would think so but since it was on a hybrid the temperature was down to around 41C. So there wasn't overheating issue. I looked at GPU-Z and notice that it was giving me a warning in the Percap Reason. I moved the 8 pins from other cards but the warning continued. If I added just a tiny amount of OC to the card, then the Speed increased back to where it was originally. Maybe the 2d/3d is correct but I wasn't going to fool with it anymore so I opted to go for a 1070 FTW with 2 -8 pins. No problems after that
The next members of the
)
The next members of the Pascal family to ship apparently will be the 1050 and 1050Ti, within days.
As I have believed for quite a while that the 750/750Ti cards are remarkably good Einstein cards, with fabulous power efficiency for their generation, good Einstein performance per unit price, and easy fit into systems, I look forward to seeing actual Einstein results with these new cards.
The announced stock clock rates are pretty low compared to other Pascals. It remains to be seen what the practical overclocking limits for memory and core will turn out to be, running Einstein. As the memory bus is only 128 bits wide, these certainly are going to be far lower in Einstein performance (at least on the recently retired BRP6 application--which I understand better than others) than the higher grade Pascal cards, but the rumored prices are very low, with launch prices of $109 for the 1050, and $139 for the 1050Ti mentioned.
Regarding power, although both cards state a 75W TDP, they both lack a supplementary power connector, and in general the Pascal cards have been burning considerably less than TDP while running Einstein work. It remains to be seen whether these are remotely so good a power outlier within line as were the 750s, but at least they seem likely low enough as to pose little problem of existing supply adequacy for most people considering an upgrade.
For before and after launch discussion, and links to reviews when they come out, one source is this reddit thread.
While the users who built four 980Ti cards into one system may not find these of any interest, I think people with older hardware toying with the idea of a graphics card upgrade who have some sensitivity to purchase cost and electric power operating cost may find them pretty interesting.
One real wild card in any such decisions is the unknown matter of how GPU-using applications available next year on Einstein will behave, both in terms of GPU hardware fit and in terms of host requirements. The recent cuda55 variants of both the BRP6 and BRP4G applications have had pretty modest host impact, but there is nothing fundamental about that. There is reason to suspect a hoped-for GW application using GPU power may have much higher relative CPU demand, for example.