Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Linux, Unix › Overclock CPU in Linux - Necessary Program Names Given!
New Posts  All Forums:Forum Nav:

Overclock CPU in Linux - Necessary Program Names Given! - Page 3

Poll Results: Prior to this thread, have you found it difficult to find software to overclock the CPU in Linux, that isn't tied to a specific machine (like the Linux overclocking software for the Eee PC)?

 
  • 26% (6)
    It was a breeze to find, what are you talking about?!
  • 8% (2)
    It was moderately easy to find.
  • 13% (3)
    Medium difficulty
  • 26% (6)
    Difficult
  • 26% (6)
    Absurdly difficult/ I did not succeed
23 Total Votes  
post #21 of 34
Oh wow, this is all very interesting indeed! Great stuff! thumb.gif
Neckpain
(12 items)
 
LAN rig
(8 items)
 
For Sale: HP Proliant DL380 Rack Mount Server
$150 (USD) or best offer
CPUMotherboardGraphicsRAM
i7 3820 Sabertooth x79 Nvidia 650ti Corsair Vengeance 
CoolingOSMonitorKeyboard
H100 Linux Mint ASUS 21.5" CMSTORM Quick Fire 
PowerCaseMouseAudio
Enermax 1050W Corsair Vengeance Series C70 Logitech Performance MX Xonar DX 
CPUMotherboardGraphicsRAM
AMD A10 5800K ASRock FM2A75M-ITX AMD Radeon HD 7660D samsung wonder ram 
Optical DriveCoolingOSOS
None Stock Linux Mint 14 64bit Windows Server 2012 
  hide details  
Reply
Neckpain
(12 items)
 
LAN rig
(8 items)
 
For Sale: HP Proliant DL380 Rack Mount Server
$150 (USD) or best offer
CPUMotherboardGraphicsRAM
i7 3820 Sabertooth x79 Nvidia 650ti Corsair Vengeance 
CoolingOSMonitorKeyboard
H100 Linux Mint ASUS 21.5" CMSTORM Quick Fire 
PowerCaseMouseAudio
Enermax 1050W Corsair Vengeance Series C70 Logitech Performance MX Xonar DX 
CPUMotherboardGraphicsRAM
AMD A10 5800K ASRock FM2A75M-ITX AMD Radeon HD 7660D samsung wonder ram 
Optical DriveCoolingOSOS
None Stock Linux Mint 14 64bit Windows Server 2012 
  hide details  
Reply
post #22 of 34
Thread Starter 
After finding this: http://www.mjmwired.net/kernel/Documentation/cpu-freq/pcc-cpufreq.txt, I was reminded of the need to dispel an illusion.

Now take all this with a grain of salt. I'm not infallible, but I try to be as accurate as I can. I give what I have found/ figured out so far. And this forum does have an edit button, lucky for me : ). Please post anything you believe to be a correction.

Many things out there create the illusion that the BIOS or other system firmware is underneath the operating system, and that the operating system runs on top of the system firmware. In fact, some diagrams straight-up show this. Some times, the illusion gets so thorough as to be tempting to think the system firmware is a hypervisor, actually executing the OS, parallel to how the OS runs programs. Chief examples of the latter are booting a DOS floppy image with memdisk (which is thought of as causing the BIOS to emulate a floppy drive, as if the BIOS were a hypervisor, like VirtualBox or something) and booting an iso with grub4DOS by creating a drive mapping in memory pointing to the iso and then chainloading that drive mapping, which might be thought of as causing the BIOS to emulate a CD drive.

And it is particularly easy to think that the system firmware is running at the same time as your OS. It doesn't, unless you're doing something pretty wild. And no, overclocking isn't wild enough.

Sometimes it looks like the system firmware has more access to hardware than the OS does. This is not true because they execute on the same processor.

Following the above link, you will be taken to a webpage discussing one particular method of overclocking: have the operating system communicate to the system firmware (BIOS, EFI, whatever), and then have the system firmware do the overclocking.

If you're not on your toes, that method of overclocking might be in the number of things that support the aforementioned illusion.

Remember: the operating system and the system firmware are executed on _the_same_processor, the CPU, therefore anything that system firmware does, the operating system can do (and probably better, because it has more storage space for code). This is unique amongst firmwares, because all other firmware is executed on a separate processor. Your hard drive, optical drives, mouse, keyboard, monitor, card reader, joystick, graphics card, sound card, SATA controllers, USB controllers and every piece of hardware that executes firmware (except the motherboard) has its own processor for executing its firmware. Since the operating system is not executing on any of those processors, the operating system can't directly do anything with those pieces of hardware, and the only way to use all this hardware is by communicating to the firmware running on the devices. For example, the SCSI command set is a way the operating system can communicate with the firmware running on the hard drive to read from and write to that hard drive.

But such communication with the system firmware is unnecessary because the operating system is already running on the CPU, which is the processor the system firmware runs on.

Note that the operating system can't replace any of those "local" firmwares, because the OS is not running on any of the processors controlling those pieces of hardware. In fact, it's physically impossible for the OS to run on any of those processors.

But the system firmware and the OS _do_ run on the same processor, and therefore, the operating system _can_, in theory, replace the system firmware once the system is booted into the OS.




Anyways, I think your typical example of overclocking the CPU that involves the OS communicating to firmware simply has the firmware write to the MSR rather than having the OS write to the MSR.





For the curious, let me break down the illusion (consider the above my actual post, and the below an extra).

The system firmware (BIOS, EFI, whatever) actually sits in memory. All RAM is memory, but not all memory is RAM. Some of the memory addresses actually point to a flash storage chip soldered to the motherboard, which holds the system firmware.

So in a simple world, if you knew the memory address range that pointed to the system firmware chip, you could make an image of your firmware simply by reading from memory and writing what you read to a file. In Linux (and all Unix-like OSes, such as Mac OS X), this can be done with dd in terminal, setting your input file (abbreviated as "if") to /dev/mem (the abstraction file created by the OS that represents all memory), using the skip parameter to start where you need to, specifying how much to copy with bs (block size) and count, and setting "of" (output file) to the path and name of the new file you want dd to create as dd writes the system firmware to file.

QEMU is such a groovy computer emulator that you can actually specify the BIOS (or EFI) image you wish for it to use as its firmware in the virtual machine. So in theory, you could then execute your system firmware image in an emulator, but due to the differences between your real hardware and the hardware QEMU emulates, this probably won't work.

And, similarly, in a simple world, you could switch the "if" and "of" parameters of dd to write a firmware image to your system firmware chip, flashing your system firmware.

But we don't live in a simple world. Often, during startup, the system firmware (or maybe only the routines component of it, talked about later) is actually copied from the chip to RAM for faster access. This is called shadow RAM. I think at this point the CPU does a little black magic and actually reroutes those memory addresses to point to those locations in RAM, and they no longer point to the chip, but I might be wrong on that one. Another thing that convolutes the matter is that the firmware is often compressed on the chip, and is decompressed as it is copied into RAM.

Anyways, as far as I know, almost all processors, whether it be your brand-new Ivy Bridge Intel processor; the 25-cent processor in your wrist-watch; the processor in your mouse executing its firmware; the processor of your optical drive performing witchcraft with the crazy firmware needed summon out processed sectors from a very strange analog medium; any one of the many processors in an automobile; a processor in a router executing its firmware; the processor in your digitalized washing machine, coffee maker, touch-screen hair dryer; or whatever, are either physically designed or programmed (pure hardware processors are physically designed to do this, and processors that use microcode are possibly programmed to do this) to, upon power up, immediately being executing whatever is at a certain location in memory.

This certain spot in memory is where the firmware is. Your CPU is no exception and starts executing the system firmware upon power-up. The firmware does the Power On Self Test (POST), as well as hardware initialization.

After doing the POST and hardware initialization, the system firmware hopefully then passes control to a bootloader, which hopefully then passes control to an operating system.

But there's really 2 parts to the BIOS. Part of it is the part the processor goes right to and executes upon startup. The other part is a bunch of programs chillin' out in memory, just sitting there at your disposal. Since there is a BIOS standard, it is known what each one does, and I'm guessing you could probably, in theory, execute any one of them right out of memory as a program running in an operating system, but that's not how they are traditionally executed.

These BIOS programs chillin' in memory (called BIOS routines) are traditionally executed by interrupts. When a program tells a processor to do an interrupt (each interrupt has a number), the processor pauses whatever it's doing, does the program on that interrupt (a BIOS program chillin' in memory, in this example), then resumes what it was doing before. So never is the system firmware executed at the same time as the OS. You can also see that the OS isn't running inside the system firmware. One is not on top of or below the other.

DOS hardly, if ever, communicates to hardware. Rather, it calls BIOS programs in memory by interrupts to communicate to hardware for it. When you boot an Acronis True Image CD, it communicates to the CD drive by BIOS interrupts. So you can fool DOS into thinking there is a floppy drive present that really isn't by modifying the program in memory that DOS uses to communicate to floppy drives. Let's say you don't have a floppy drive. You can boot a bootable floppy image with DOS on it with memdisk because memdisk does some stuff to what's in memory so that when DOS makes that interrupt call to talk to a floppy drive, it is communicating to the program memdisk put in memory (rather than the original BIOS routine), which reads from a copy of the floppy image that was copied into memory by memdisk, and this impostor routine sends back the data at DOS in an identical fashion to how the normal BIOS routine would send data back at DOS from an actual floppy drive. And DOS doesn't know any different, because it never bothers to look at the hardware itself.

I believe something similar is at play when you use grub4DOS to boot an iso image of the Acronis True Image CD.

Note that never for a moment did you emulate hardware. The moment the OS actually looks at hardware for itself, the illusion from this pho-emulation is dispelled. Here's a fun example you can do. Make an iso image of a WinXP installation disc (I think Win98 works too. If WinXP doesn't work, try Win98), and boot it with grub4DOS by doing that mem, hook, chainload stuff. It will work for a while, but when you hit a certain point, it will blue-screen! This is because for a while it's using (a) BIOS routine(s) to communicate with the non-existent CD drive, then, at a certain point, it starts to look at hardware for itself, and poof! The non-existent CD drive from which the installer is running disappears. Uh-oh, blue screen time.

So note that this pho-emulation works only with operating systems that never look at hardware themselves _and_ this pho-emulation is also dependent that there be BIOS routines in memory present. If these routines aren't present, such as on a pure EFI machine, this won't fly. This makes this method useable only for very few applications. DOS and Acronis are the only two I personally know of that will work with this.

Notice the design flaw of making an OS that depends on system firmware. For one, the OS is dependent on a certain type of firmware (as in BIOS vs EFI vs whatever). DOS and Acronis can't run on a pure EFI machine. Because Macs have a BIOS compatibility module that their EFI can load, DOS and Acronis _can_ run on Macs, but Acronis can't image any drive that has any partitioning scheme other than MBR (that I know of), at least the version I have, another design flaw of Acronis, thus it still wouldn't be able to image your Mac's GPT schemed hard drive.

Any limitation that the firmware has, your OS would have. For example, DOS can't use GPT drives because it never reads and writes to the hard drive. Rather it has BIOS routines do that for it. BIOS can't do GPT. Therefore DOS can't do GPT.

If the system firmware has a bug, then that sucks if you use the system firmware instead of your own code.

Also, system firmware routines are executed on interrupt, abruptly bringing the entire operating system and all programs it is executing to a halt while everyone waits for this one program to get done executing.

To quote Linus Torvalds, the task of the system firmware (BIOS, EFI, whatever) is "just load the OS and get the hell out of there". So methods of overclocking the CPU in Linux that have Linux itself write to the MSR are more in line with his beliefs than running a program in Linux that calls system firmware to overclock for it. As far as I know, Linux isn't supposed to execute any system firmware routines, but apparently it does sometimes: http://kerneltrap.org/node/6884. And just look at Xorg. Why is EFI such an issue for Xorg, and why does loading a partial BIOS dump into memory fix it? Because it uses a BIOS routine. You could, however, argue that Xorg isn't technically a part of Linux, even though, as far as I know, is in the Linux kernel.


So when the computer powers on and goes sys firmware > bootloader > OS, the sys firmware is no longer being executed once control has been passed to the bootloader. Only at the very beginning is the system firmware being executed without having been called via interrupt. Now that control has been passed to the bootloader, the bootloader may choose to ask the processor to execute a sys firmware routine via interrupt. If the bootloader calls such an interrupt, the bootloader is then paused, that routine is executed, then execution of the bootloader is resumed. Likewise once the bootloader passes control to the OS.

So never is the system firmware ran at the same time as the OS (unless there's a such thing as an OS that runs a firmware routine out of memory as a program under the OS, like how Linux runs FireFox. I don't think this exists.).
And most assuredly, the system firmware never executes the OS, unless you have system firmware that really is a hypervisor, which exists in some embedded systems, sometimes even with a processor dedicated to the task of creating the emulated hardware platform.
And unless your system firmware is a hypervisor, your OS has just as much access to the hardware as the firmware does, thus the firmware is not "underneath" the OS, because they run on the same CPU. However, some OSes choose to have firmware communicate to hardware for it, even though the OS could have communicated to hardware.

Any diagram showing the OS on top of the system firmware, where the system firmware is not a hypervisor, is doing so from the perspective that the OS is having the system firmware talk to the hardware for it, thus in that situation the system firmware is behaviorally closer to the hardware, even thought the OS has just as much access to the hardware.

And be aware of pho-emulation of hardware. Memdisk and grub4DOS do not emulate hardware. If you wish to actually emulate a CD drive and boot an iso from that, you need to use a hypervisor such as the Xen Hypervisor, creating a virtual machine in "Hardware-assisted or Full Virtualization (HVM)" mode (which uses QEMU - QEMU scores two for two), rather than in parvirtualization mode. Thus with the Xen Hypervisor, you could boot an iso off your thumb drive and actually be emulating a CD drive. Just note that you'll be running on Xen's (QEMU's) emulated hardware platform, not your real hardware. Thus booting into a Windows installation disc iso via the Xen Hypervisor and going through the installer will result in an installation of Windows configured for Xen's (QEMU's) emulated hardware, not your real hardware. If you boot a Linux installation iso with Xen and install Linux, you'll be fine because Linux doesn't get specific to one set of hardware, unless maybe you start doing stuff with graphics drivers.

Edited by SpawnHappyJake - 5/10/12 at 11:44pm
post #23 of 34
I done some more research and here's what i found in Wakoopa when I search for "frequency":
http://cpupowerd.sourceforge.net/
http://lfsb.sourceforge.net/ (there's good info in the "README" on lfsb-0.4.2.tar.bz2)

I will try find more overclocking tools in SourceForge...
Edited by CrazyGangster - 5/13/12 at 8:11am
post #24 of 34
Hi,
very good material SpawnHappyJake, thank you! Very clear and I was surprised, that about something esentially easy, you can read a lot of misconceptions on the net.
On the other hand, have some problems implemating the whole thing. I have an asus with an atom n450 where I would like to test OC. I can read the register 0x198, but then? I have read, that with this processor you can do an OC from 1,6 to 1,9Ghz and remain stable. How do I set it? And what about voltage? Should I change also?
ciao
jorgey
post #25 of 34
For the Intel Core I series there is a monitoring program called I7Z the author includes a ruby script to read and right to the registers
Quote:
Additional Script to read / write to registers

The svn contains a script to read/write to registers on Nehalems and Sandy Bridges machine to change multipliers, turbo mode, check power and clock modulation in Linux. Do give it a try and please post if you encounter any issues.

Script : http://code.google.com/p/i7z/source/browse/trunk/i7z_rw_registers.rb

Download from this link: http://i7z.googlecode.com/svn/trunk/i7z_rw_registers.rb

Script can be run (needs ruby installed) as: sudo ruby i7z_rw_registers.rb

msr-tools need to be installed. In Debian/Ubuntu its sudo apt-get install msr-tools and probably sudo modprobe msr before running the script
Core I7
(13 items)
 
  
CPUMotherboardGraphicsRAM
I7 920 rev. D0 @ 4.26Ghz EVGA X58 SLI EVGA GTX 285 OCZ XMP 3x2Gb (pc3 12800) 
Hard DriveOptical DriveOSMonitor
Western Digital Caviar Black 640Gb x 2 LG GH22LS30 openSuse 12.1 x64 HP F2105 
PowerCase
CORSAIR 850TX Cooler Master ATCS 840 
  hide details  
Reply
Core I7
(13 items)
 
  
CPUMotherboardGraphicsRAM
I7 920 rev. D0 @ 4.26Ghz EVGA X58 SLI EVGA GTX 285 OCZ XMP 3x2Gb (pc3 12800) 
Hard DriveOptical DriveOSMonitor
Western Digital Caviar Black 640Gb x 2 LG GH22LS30 openSuse 12.1 x64 HP F2105 
PowerCase
CORSAIR 850TX Cooler Master ATCS 840 
  hide details  
Reply
post #26 of 34
Thread Starter 
It's been forever since I've checked on this thread.
Just wanted to say thanks to Tom.Slick for finding another tool!

Honestly, I still haven't had a chance to try any of this because I spent the summer trying to save an old Dell Dimension 4400...but really it was more than just trying to save it. It was about teaching myself stuff.

I learned a lot about Linux-wide things, Arch-specific things, and even about hardware.

The next step is for me to try and overclock it. (Maybe next summer)

Sadly, the machine is so slow, that even a ramdisk (created via the brd module) only goes 28 MB/s! Compare that to the ramdisk on my main machine (Dell XPS 8300), which can go 2600 MB/s. Yes, 2.6 gigabytes per second. On the 4400, there's some deep bottleneck that prevents any physical disk from being read much faster than 20 MB/s. I even got a PCI IDE busmaster card to put the drives through to see if the bottleneck was the onboard busmaster. Nope. It's a deeper bottleneck. USB drives suffer from it as well. I even played around with UDMA settings. Nope.

Not even RAID0 between two IDE drives helped. Not even when on different ribbons, and nothing else on those ribbons. Not even when on different busmasters.

Cheers,
Jake
Edited by SpawnHappyJake - 9/2/12 at 11:18am
post #27 of 34
Greetings all,

I just bought an ASRock Z68 Extreme4 Gen3 and a Core i5 2500K CPU and I find myself unable to overclock the latter under Linux !!!

I of course set the new multiplier in the UEFI BIOS, and I did check it worked under Windows (set it to 40x, for a first try).

I compile my kernels myself under Linux, but I'm no newbie and I did enable Intel Speedstep support, MSR, CPUID and the frequency scaling governor (performance only, and enabled by default), and yet, I keep getting a max frequency of 3.3GHz from /sys/devices/system/cpu/cpuN/cpufreq/cpuinfo_max_freq, and other utilities playing directly with the MSR, such as c2ctl seem just as helpless to change this matter of fact (changing the vid with c2ctl doesn't seem to achieve anything).

What did I miss ?


Did anyone here overclock an i5 2500K on a similar system ?

Many thanks in advance !
post #28 of 34
Nevermind... I found what was wrong... Apparently, you can only overclock the turbo mode... That is, when idle the Core i5 2500K will keep its 33x BCLK multiplier, and Linux will consider it's a 3.3GHz processor, but as soon as you start drawing power from a core, the Turbo mode kicks in (and as long as you disabled speedstep in the BIOS, disabled all the C1E/3/6 modes, and set the turbo multiplier to affect all cores at once, the 4 cores will get overclocked together).

That's quite a bit different from what former CPUs were allowing, and apparently, there is no way to lock the Core i5 in turbo mode at all time: you therefore have only a 3.3GHz processor when you draw only small spikes of power from the CPU, like during I/O activity (and with software RAID, a turbo-locked CPU would make things faster)...

So, I'm changing my question to this one: do you know any mean to lock the core clock multiplier of a Core i5 into turbo mode "forever" (i.e. from boot time to power off time) ?...

EDIT: I found the solution, finally.
Edited by dinosaur - 9/7/12 at 2:50pm
post #29 of 34
Great thread and Great tools, just what I was looking for for my netbook.

I have overclocked in the past, mostly moderately to get a better expierence. Although I still won't call myself a low-level hardware expert. I thought I'd share my perspective.

I never really bought the "software overclocking" moniker, I've always taken it as a "I-dont-have-to-constantly-shutdown-and-reboot-my-computer-to-find-a-good-overcloock" kind of thing.
Quote:
Originally Posted by SpawnHappyJake View Post

I've heard the phrase "the multipler is locked" thrown around a lot. I'm skeptical that this has actually been locked, rather than simply not provided. "Locked" implies that the ability is there, but has artificially been made unavailable, like the disabling of ring negative one. _That's_ locking. My guess with the unchangable multiplier is that the hardware to change the multiplier simply isn't on the baord.
.

Pentium-era PCs almost exclusively used "Hardware" overclocking that would require you to flip jumpers on the motherboard to enable faster system bus clockspeeds.This was still common enough into the P4 era. However by then many of these hardware switches had been converted into 'software' switches in the BIOS. I imagine the difference is that the physical wiring was modifying the register rather than the BIOS setting it. Typically these options were only left in the BIOS/EFI (or hidden inside proprietary features like cool&quiet or Power-now), unless the manufacturer decided not to include them (for whatever reason) requiring the user (us) to get creative. The primary rationale was for not including it was "stability" for the end user in a variety of conditions.

Most processors also had the same thing for the clock-speed multiplier between the system bus (FSB) and the CPU frequency. These were often 'locked' in the sense that the physical switches were present and/or hardwired only INSIDE the CPU package, and modifying was akin to some kind of surgery. I expect that these CPUs constantly updated the multiplier register based on the physical connections. The original AMD athlon/duron chips had "locked" multipliers that could be "unlocked" with the graphite from a pencil, allowing you to choose the multiplier based on which contacts you bridged on the surface of the chip.

It's really only recently with the late P4's and newer processors that these 2 settings have become almost completely software-modifiable. Specificially this was probably done to allow for true "dynamic overclocking" or where a software agent dynamically adjusts the processor frequency and multiplier according to the present (and even predicted) load on the system. My understanding is that, on modern platforms the FSB has been effectively decoupled from the processor's and RAM's operating speed and is now responsible only for the system communication buses (between CPU and RAM and other devices), although I imagine cheaper boards may do some tricks to cheap out on components.


Newer chips leave some headroom with regard to what frequency/multiplier they run so the dynamic programming can give the chip a turbo boost if it decides it's prudent. They often overclock quite easily, however you may loose the dynamic clocking ability should you decide to do so. They have an effective max performance that corresponds to 1) how hot the chip is getting (they will hard-stop @ ~80-100 deg C, and will often dynamically clock themselves back when they're getting close to protect the hardware) and 2) transistor switching time of that specific chip (which is why some chips get massive clocks and others, next to nothing - this can be overcome with more voltage but that can, and WILL, damage your CPU over time through electromigration).
post #30 of 34
I have a Intel Pentium M processor and Linux Mint 13 KDE. I have been beating my head against a wall trying to figure out how the heck to overclock this P.O.S. when I ran across this article. I tried adding the PPA for the program that CrazyGangster found, but I got 404 errors after apt-get update. So I decided to use c2ctl after using modprobe msr and when I set it higher the numbers dropped!...

Output of c2ctl 0:
  • Before c2ctl 0 20 45:
    Code:
    CPU0
          Current  Target    Min.    Max.
    FID:       18      18       6      18
    VID:       40      40      18      40
    ESIT_ENABLE = TRUE    ESIT_LOCK = TRUE
    
  • After c2ctl 0 20 45:
    Code:
    CPU0
          Current  Target    Min.    Max.
    FID:        6       6       6      18
    VID:       18      18      18      40
    ESIT_ENABLE = TRUE    ESIT_LOCK = TRUE
    

What am I doing wrong?
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Linux, Unix
Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Linux, Unix › Overclock CPU in Linux - Necessary Program Names Given!