Hi,
01000101 wrote:is there a way to crank both processor FSB and memory timings (with or without voltage alterations) in a protected mode enviroment?
The way I understand it, the BIOS is the only part that can make those decisions.
and if so, could this be implemented into an actual functional overclocking feature later in kernel dev? when I say functional, I dont mean like the software utilities for win/lin that can 'soft-clock' your system, I mean something far lower-level that actually interacts directly with the appropriate pins.
Overclocking isn't necessary a good idea - sometimes it works, sometimes it works but pushes the part outside it's thermal envelope (possibly causing automatic thermal throttling and reduced or fluctuating performance), sometimes it seems to work but introduces subtle bugs (random crashes and data corruption), and sometimes it doesn't work.
Usually if the manufacturers thought it'd be safe to run a part at a faster speed (and higher voltage) they'd sell the part as a faster part for a little extra cash. Sometimes manufacturers sell a faster part as a slower part due to a higher demand for the lower speed part (typically due to bad pricing causing a mismatch between supply and demand), and sometimes manufacturers build in a safety margin (e.g. they'll test a part to find out it works up to 3 Ghz and then sell it as a 2.8 GHz part just in case).
However, a small increase in the performance of one part is likely to make an insignificant difference to overall performance, as overall performance depends on the performance of many individual parts. For example, if the CPU is running 10% faster but software is spending 33% of it's time idle, 33% of it's time waiting for I/O and 15% of it's time waiting for RAM, then that 10% CPU speed increase might only to correspond to a 2% increase in overall performance.
In general, for an OS designed for security/stability the risks aren't worth the benefits and overclocking isn't useful. From my perspective there's still 2 related things that I'd consider - detecting if the machine has been overclocked (or underclocked) by the BIOS and issuing a warning for system administrators if it is, and deliberate underclocking (for e.g. to improve battery life and reduce heat and/or noise).
For this sort of thinking you end up with an entire power management policy (where you dynamically make compromises between performance, heat and noise based on things like CPU load, temperature and battery state) that may control several things (not just CPU speed). This would involve a chipset specific driver, a CPU specific driver and other device specific drivers (PCI bus driver, video driver, hard disk driver, etc).
Some notes:
- Older CPUs use the chipset to control the STPCLK signal, which modulates CPU clock cycles and can be used for underclocking
Newer CPUs have (one or more) methods of performance control built in - STCLK, SpeedStep, LongRun, etc.
Newer CPUs have thermal monitoring built into the local APIC to allow the OS to determine if the CPU got too hot.
Newest Intel CPUs have digital temperature sensors.
For newer AMD CPUs you can control the frequency of the HT links (think of it as bus speed control that's CPU specific rather than chipset specific).
Most chipsets use SMBus to control fan speeds.
Newer hard drives have ways to control noise, power and performance.
Newer video cards have ways to control GPU performance/heat (it might be good to severely underclock the GPU when it's not being used).
All chipsets have (chipset specific) RAM speed controls that might be interesting for underclocking purposes (I wouldn't dare overclock RAM chips).
Cheers,
Brendan
Я нe пoнимаю!
for fun. If they would answer, I will inform you 