ECS NVIDIA GeForce GT 240 512MB

Published on January 22, 2010
Written by Michael Larabel
Page 3 of 9
Discuss This Article

The ECS GeForce GT 240 was installed into a system running an Intel Core i7 920 processor clocked to 3.60GHz, used an ASRock X58 SuperComputer motherboard, had 3GB of DDR3 system memory, and ran with a 320GB Seagate ST3320620AS SATA HDD. On the software side was Ubuntu 9.10 (x86_64) with the Linux 2.6.31 kernel, X Server 1.6.4, and the NVIDIA 195.30 beta display driver was installed.

The GeForce GT 240 booted up just fine with the binary NVIDIA graphics driver and had properly mode-set to 2560 x 1600. The PCI ID for this graphics card was 0x0ca3 while the PCI vendor ID is of course 0x10de. Compiz was working and OpenGL applications were running just fine. PowerMizer also had no problems dynamically changing the performance levels based upon load, but when we tried using CoolBits to overclock the GPU was the first signs of a problem. When attempting to change the 3D clock frequencies manually or using the auto detect feature, the clocks would not change from 550MHz for the CPU and 1700MHz for the GDDR5 memory. Attempting to apply any other core/memory clock values would not take. We could not overclock (or underclock) this ECS GeForce GT 240 graphics card under Linux and all attempts to do so had failed. This is either a bug within NVIDIA's binary Linux driver, an issue with the video BIOS on this ECS graphics card, or some combination thereof.

Due to this overclocking issue and another set of problems to be mentioned in this article, the ECS GeForce GT 240 graphics card was then installed in an entirely different AMD-based system and it was running with the NVIDIA 190.53 stable Linux driver rather than the 195 series beta. With this driver, CoolBits claimed to work and the optimal 3D clocks that it found was 720MHz for the graphics processor and 2040MHz for the memory. These optimal clocks are rather high and equates to the GPU running 30% faster and the memory running 20% above its rated speed. These values seemed to apply fine, but once carrying out the testing following this, there was no difference in the performance compared to its stock speeds. When polling the NV-CONTROL extension to see what the clocks were reading, they were back at their stock frequencies.

Latest Hardware Reviews
  1. Sumo Lounge Emperor
  2. Gallium3D Continues Improving OpenGL For Older Radeon GPUs
  3. 15-Way Open vs. Closed Source NVIDIA/AMD Linux GPU Comparison
  4. Nouveau vs. NVIDIA Linux Comparison Shows Shortcomings
Latest Software Articles
  1. The Cost Of Ubuntu Disk Encryption
  2. Btrfs vs. EXT4 vs. XFS vs. F2FS On Linux 3.10
  3. AMD Radeon R600 GPU LLVM 3.3 Back-End Testing
  4. F2FS File-System Shows Regressions On Linux 3.10
Latest Linux News
  1. Mageia 3 Released, Still Using Legacy GRUB
  2. NetBSD 6.1 Brings In More Features
  3. Using Six Monitors With AMD's Open-Source Linux Driver
  4. Benchmarking The Intel P-State, CPUfreq Changes
  5. FreeBSD Still Working On Next-Gen Package Manager
  6. DNF Still Advancing As Experimental Yum For Fedora
  7. Logitech Begins Supporting Linux Users
  8. Modern Intel Gallium3D Driver Still Being Toyed With
  9. Linux 3.10 Kernel Benchmarks On A Core i7 Laptop
  10. GCC 4.8.1 Compiler Due To Be Out Next Week
  11. Linux 3.10 Kernel Benchmarks For Intel Ivy Bridge
Latest Forum Talk
  1. Mageia 3 Released, Still Using Legacy GRUB
  2. The Cost Of Ubuntu Disk Encryption
  3. Logitech Begins Supporting Linux Users
  4. Logitech supports linux!
  5. Btrfs vs. EXT4 vs. XFS vs. F2FS On Linux 3.10
  6. Kubuntu, KDE Has Little Hope For Ubuntu's Mir
  1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Motherboards
  5. Peripherals
  6. Processors
  7. Software
  8. Operating Systems
  9. All Articles
  1. Linux Benchmarking
  2. OpenBenchmarking.org
  3. Phoronix Test Suite