Most discussion here has been about the "ti" variant class of 750 cards, which uses the same chip, but enables somewhat more resources, is expected to consume a little more power, and is generally configured with 2 GBytes of RAM instead of the 1 GB on this card. Also many of the offerings of both 750 and 750 ti run by default at a slightly higher clock rate than this one (sometimes calling themselves OC, or overclocked, or superclocked). So my choice is definitely the economy model, and is likely to be offered within a few months for rather less than the $120 I paid.
In the future I may regret not noticing that there is a 2 Gbyte variant of my card nominally selling for just $10 more. Depending on the memory needs of Einstein applications over the next couple of years, and depending on the performance benefit of running a given number of simultaneous tasks, this could vary from being inconsequential to paying for itself handsomely.
But for the time being, I remain quite happy with my choice.
My understanding is that some of these cards get all their power from the PCI slot while others might require an additional 6 pin power source. Just something to be aware of.
My understanding is that some of these cards get all their power from the PCI slot while others might require an additional 6 pin power source. Just something to be aware of.
Yes. The one I chose is pure PCIe (not PCI) motherboard slot power, which I think is about universal for the various vendor base GTX 750 non-ti models. Many of the overclocked ti models have the 6-pin connector. In between it varies.
As my candidate supplies had a 6-pin PCIe supplementary power connector, I'd actually have preferred if the card had the connection, as I think lower current through connections is generally a good thing, but I was happy that the manufacturer was confident that it would stay below the 75-watt motherboard PCIe connection limit to omit additional connection provision.
Most discussion here has been about the "ti" variant class of 750 cards, which uses the same chip, but enables somewhat more resources, is expected to consume a little more power, and is generally configured with 2 GBytes of RAM instead of the 1 GB on this card. Also many of the offerings of both 750 and 750 ti run by default at a slightly higher clock rate than this one (sometimes calling themselves OC, or overclocked, or superclocked). So my choice is definitely the economy model, and is likely to be offered within a few months for rather less than the $120 I paid.
In the future I may regret not noticing that there is a 2 Gbyte variant of my card nominally selling for just $10 more. Depending on the memory needs of Einstein applications over the next couple of years, and depending on the performance benefit of running a given number of simultaneous tasks, this could vary from being inconsequential to paying for itself handsomely.
But for the time being, I remain quite happy with my choice.
I checked out the 1 and 2 GB, Superclocked and not, versions (but stopped short of confusing myself with the Tis). The images on EVGA's web site don't show extra power connectors, even on the Superclocked ones, and the spec sheets don't mention needing extra power connectors. As you noted, the 2 GB is $10 more than your 1 GB; the 1 GB SC is the same as the 2 GB, and the 2 GB SC adds another $10. I checked prices on Newegg, Microcenter, TigerDirect, and eBay; there don't appear to be any discounts to be had right now.
Well, I won't be buying anything this month anyway. My credit card is twice as high as I wanted it to be, and it's not even half way through the billing cycle yet.
Forgive me if I missed this above, but how many tasks are you running at a time on it, and how many CPU cores are you reserving to support it?
David
Miserable old git
Patiently waiting for the asteroid with my name on it.
Currently that extra power connector isn't of much use: a PCIe slot must be able to provide 75 W per specification, but the cards are hard-limited to 60 W actual power draw until bios tuners set them free.
In current reviews the cards have massive overclocking headroom, being limited only by the slider limit in the software. That's also something a custom bios can fix. Anyway, if you don't want to use this headroom for OC you could lower the voltage to reduce power consumption even further. The effect won't be dramatic, but better than stock neverthless :)
And a comparison between the regular and the Ti model would be highly appreciated. The Ti costs only 20€ more over here, which is next to nothing (for a GPU) and already includes 2 instead of 1 GB. Power consumption is about the same for both models in game benchmark (the Ti draws a few W more - that's almost no difference). But the Ti has 25% more raw horse power, which could translate into up to 25% higher E@H throughput... if the memory bandwidth does not limit.
but how many tasks are you running at a time on it, and how many CPU cores are you reserving to support it?
For the results reported in message 129688 in this thread, I was uniformly running two Arecibo jobs on the Intel 4400 onchip graphics (iGPU), two S6 CasA jobs purely on the CPU, and two matched tasks of the same kind at a time on the GTX 750. I don't use the "reserved cores" terminology, as I consider it inaccurate and misleading, but, yes, I did adjust the BOINC location preference "On multiprocessors, use at most " nn "% of the processors" to obtain this end.
I should perhaps mention that this particular Haswell CPU has two physical cores and is running with hyperthreading enabled, so when I get around to using affinity to control the CasA jobs to avoid the "unlucky assignment" problem, there will always be one of them active on each physical core in the case I am running two if I continue this particular task configuration, so not a huge amount of leftover CPU capability waiting for use.
I should confess that I've made a first few tentative steps on the tuning front (using affinity and priority adjustment by Process Lasso), and promptly got into some trouble. For those no more experienced than I who might tread this path, I'll make a couple of warnings:
It appears that the Einstein preference item "GPU utilization factor of BRP apps" (which controls how many jobs run simultaneously on a GPU), applies BOTH to the HD4400 and to the GTX 750, but only propagates to actual use when a task for that type of GPU is actually allocated and downloaded after the setting change. Also, the scheduler initially thinks you get a sudden simple ratio in compute capability. The bottom line is when I attempted to adjust my GTX 750 to run three jobs as a test, I instead first got the HD4400 running three jobs, and promptly exhausted my daily quota of tasks for this host from Einstein getting a huge number of tiny Arecibo jobs for the Intel GPU. This was much more awkward than it otherwise might have been because the tuning configuration I was testing turned out greatly to slow the Intel GPU jobs. The scheduler, in its wisdom, initially interprets a job which takes far longer than expected as immediate reason greatly to increase the Task duration correction factor--which changes the estimated completion time (and thus willingness to download) for ALL task flavors. Much later, if you run a stable load, the task to task relationships will get worked out, but in the short term this can get you to quite a mess (and meant I actually could not download a task to get my intended 3-up test running).
As always, very small queue size parameters can be helpful during trials, and I in addition plan in the future temporarily to disable the "Binary Radio Pulsar Search (Arecibo)" item (which is the one currently generating Intel GPU work) during some of my experiments, just to avoid download gushes and daily quota exceptions.
Affinity shouldn't matter much, as task/data transfers between cores in your Haswell are quite fast (and the L3 is shared anyway). And Win is aware of HT and mostly schedules the work just fine. This is not a cornercase of 2 older CPUs connected through a slow and already oversaturated FSB :)
And regarding your task number & scheduling issue: you could avoid this by using an app_config, where you can set the number of concurrent tasks per work unit item, and hence per GPU (since they're running different projects). Anyway, the warning might help someone!
The Gamma-Ray Pulsar #3 pair, as expected from experience on other platforms, got very low GPU loading, very low credit production, restricted the possible count of pure CPU jobs to 1 (as compared to two for the other two cases) and took enough resources to drive down the iGPU productivity as well. I intend to take a look at the method recently posted by Gary Roberts to allow GRP3 pure CPU jobs but not GPU of the current flavor.
Update: The method initially tried by Gary Roberts did not work, but Bernd posted another method which does. Brutally simple (and called a bit of a dirty hack by him), it calls for setting the GPU utilization factor of FGRP apps to a negative value to suppress GRP3 GPU work fetch. I applied it (specifically using -1) a couple of days ago or more, to all three GPU-equipped hosts in my flotilla, and so far I have gotten the results I wanted: CPU GRP3 jobs and no GPU GRP3 jobs.
archae86, can you provide a
)
archae86, can you provide a link to which specific card you bought? Manufacturer's site, retailer, anywhere...
David
Miserable old git
Patiently waiting for the asteroid with my name on it.
RE: archae86, can you
)
The exact card I bought was the base EVGA GTX 750, which has the official part number of 01G-P4-2751-KR
Here is the EVGA page on it:
Most discussion here has been about the "ti" variant class of 750 cards, which uses the same chip, but enables somewhat more resources, is expected to consume a little more power, and is generally configured with 2 GBytes of RAM instead of the 1 GB on this card. Also many of the offerings of both 750 and 750 ti run by default at a slightly higher clock rate than this one (sometimes calling themselves OC, or overclocked, or superclocked). So my choice is definitely the economy model, and is likely to be offered within a few months for rather less than the $120 I paid.
In the future I may regret not noticing that there is a 2 Gbyte variant of my card nominally selling for just $10 more. Depending on the memory needs of Einstein applications over the next couple of years, and depending on the performance benefit of running a given number of simultaneous tasks, this could vary from being inconsequential to paying for itself handsomely.
But for the time being, I remain quite happy with my choice.
My understanding is that some
)
My understanding is that some of these cards get all their power from the PCI slot while others might require an additional 6 pin power source. Just something to be aware of.
robl wrote:My understanding
)
Yes. The one I chose is pure PCIe (not PCI) motherboard slot power, which I think is about universal for the various vendor base GTX 750 non-ti models. Many of the overclocked ti models have the 6-pin connector. In between it varies.
As my candidate supplies had a 6-pin PCIe supplementary power connector, I'd actually have preferred if the card had the connection, as I think lower current through connections is generally a good thing, but I was happy that the manufacturer was confident that it would stay below the 75-watt motherboard PCIe connection limit to omit additional connection provision.
I ordered an Asus PCI-E N
)
I ordered an Asus PCI-E N GeForce GTX 750 for my SUN WS running SuSE Linux 13.1 as a first attempt to use a GPU.But shall I find the drivers?
Tullio
RE: RE: archae86, can you
)
I checked out the 1 and 2 GB, Superclocked and not, versions (but stopped short of confusing myself with the Tis). The images on EVGA's web site don't show extra power connectors, even on the Superclocked ones, and the spec sheets don't mention needing extra power connectors. As you noted, the 2 GB is $10 more than your 1 GB; the 1 GB SC is the same as the 2 GB, and the 2 GB SC adds another $10. I checked prices on Newegg, Microcenter, TigerDirect, and eBay; there don't appear to be any discounts to be had right now.
Well, I won't be buying anything this month anyway. My credit card is twice as high as I wanted it to be, and it's not even half way through the billing cycle yet.
Forgive me if I missed this above, but how many tasks are you running at a time on it, and how many CPU cores are you reserving to support it?
David
Miserable old git
Patiently waiting for the asteroid with my name on it.
Currently that extra power
)
Currently that extra power connector isn't of much use: a PCIe slot must be able to provide 75 W per specification, but the cards are hard-limited to 60 W actual power draw until bios tuners set them free.
In current reviews the cards have massive overclocking headroom, being limited only by the slider limit in the software. That's also something a custom bios can fix. Anyway, if you don't want to use this headroom for OC you could lower the voltage to reduce power consumption even further. The effect won't be dramatic, but better than stock neverthless :)
And a comparison between the regular and the Ti model would be highly appreciated. The Ti costs only 20€ more over here, which is next to nothing (for a GPU) and already includes 2 instead of 1 GB. Power consumption is about the same for both models in game benchmark (the Ti draws a few W more - that's almost no difference). But the Ti has 25% more raw horse power, which could translate into up to 25% higher E@H throughput... if the memory bandwidth does not limit.
MrS
Scanning for our furry friends since Jan 2002
N9JFE wrote:but how many
)
For the results reported in message 129688 in this thread, I was uniformly running two Arecibo jobs on the Intel 4400 onchip graphics (iGPU), two S6 CasA jobs purely on the CPU, and two matched tasks of the same kind at a time on the GTX 750. I don't use the "reserved cores" terminology, as I consider it inaccurate and misleading, but, yes, I did adjust the BOINC location preference "On multiprocessors, use at most " nn "% of the processors" to obtain this end.
I should perhaps mention that this particular Haswell CPU has two physical cores and is running with hyperthreading enabled, so when I get around to using affinity to control the CasA jobs to avoid the "unlucky assignment" problem, there will always be one of them active on each physical core in the case I am running two if I continue this particular task configuration, so not a huge amount of leftover CPU capability waiting for use.
I should confess that I've made a first few tentative steps on the tuning front (using affinity and priority adjustment by Process Lasso), and promptly got into some trouble. For those no more experienced than I who might tread this path, I'll make a couple of warnings:
It appears that the Einstein preference item "GPU utilization factor of BRP apps" (which controls how many jobs run simultaneously on a GPU), applies BOTH to the HD4400 and to the GTX 750, but only propagates to actual use when a task for that type of GPU is actually allocated and downloaded after the setting change. Also, the scheduler initially thinks you get a sudden simple ratio in compute capability. The bottom line is when I attempted to adjust my GTX 750 to run three jobs as a test, I instead first got the HD4400 running three jobs, and promptly exhausted my daily quota of tasks for this host from Einstein getting a huge number of tiny Arecibo jobs for the Intel GPU. This was much more awkward than it otherwise might have been because the tuning configuration I was testing turned out greatly to slow the Intel GPU jobs. The scheduler, in its wisdom, initially interprets a job which takes far longer than expected as immediate reason greatly to increase the Task duration correction factor--which changes the estimated completion time (and thus willingness to download) for ALL task flavors. Much later, if you run a stable load, the task to task relationships will get worked out, but in the short term this can get you to quite a mess (and meant I actually could not download a task to get my intended 3-up test running).
As always, very small queue size parameters can be helpful during trials, and I in addition plan in the future temporarily to disable the "Binary Radio Pulsar Search (Arecibo)" item (which is the one currently generating Intel GPU work) during some of my experiments, just to avoid download gushes and daily quota exceptions.
Affinity shouldn't matter
)
Affinity shouldn't matter much, as task/data transfers between cores in your Haswell are quite fast (and the L3 is shared anyway). And Win is aware of HT and mostly schedules the work just fine. This is not a cornercase of 2 older CPUs connected through a slow and already oversaturated FSB :)
And regarding your task number & scheduling issue: you could avoid this by using an app_config, where you can set the number of concurrent tasks per work unit item, and hence per GPU (since they're running different projects). Anyway, the warning might help someone!
MrS
Scanning for our furry friends since Jan 2002
archae86 wrote:The Gamma-Ray
)
Update: The method initially tried by Gary Roberts did not work, but Bernd posted another method which does. Brutally simple (and called a bit of a dirty hack by him), it calls for setting the GPU utilization factor of FGRP apps to a negative value to suppress GRP3 GPU work fetch. I applied it (specifically using -1) a couple of days ago or more, to all three GPU-equipped hosts in my flotilla, and so far I have gotten the results I wanted: CPU GRP3 jobs and no GPU GRP3 jobs.