The nice thing about all of this is that I can push a code change to git, and Jenkins can build it, run through all the tests and then deploy to production automatically.

Layout of a pipeline script

Pipeline scripts are written in Groovy, which is a variant of Java. In general, a pipeline script is laid out like this:

node {
    def SOME_CONSTANT = "whatever"
    ...

    stage('some stage name like Build') {
        // Stuff to do as a part of this stage
    }

    stage('another stage') {
        // More stuff
    }

    ...
}

Each stage represents a stage in the pipeline (e.g. building, beta deployment, prod deployment etc.)

Defining some constants

First, a list of constants can be defined that can be used throughout the pipeline so that if the pipeline script gets reused somewhere, only these constants have to be changed. I’m not aware of anything that lets me reuse a pipeline in Jenkins without copying and pasting the code somewhere else so for now I’ll have to live with copying and pasting.

My project uses Maven so I got Jenkins to download its own copy of Maven that it can use to execute builds and have defined it as a constant. The name I’ve given it in the Jenkins Global Tool Configuration is “Maven 3.3.9” exactly. My project also uses Tomcat so there are some Tomcat specific things in there that may or may not be relevant to your use case.

def MAVEN_HOME = tool 'Maven 3.3.9'
    def WORKSPACE = pwd()

    def PROJECT_NAME = "name-of-project"
    def WAR_PATH_RELATIVE = "App/target/${PROJECT_NAME}.war"
    def WAR_PATH_FULL = "${WORKSPACE}/${WAR_PATH_RELATIVE}"
    def TOMCAT_CTX_PATH_BETA = "Tomcat-context-path-for-the-beta-stage"
    def TOMCAT_CTX_PATH_PROD = "Tomcat-context-path-for-the-prod-stage"
    def GIT_REPO_URL = "URL-to-git-repo-ending-in-.git"

Preparation Stage

First, the code has to be retrieved from the repository before it gets built. Jenkins allows storing username/password pairs so that they can be referenced without having to write out the password in plaintext. Jenkins uses a “credential ID” for this.

    stage('Preparation') {
        git branch: "master",
        credentialsId: "credentials-ID-stored-in-Jenkins-that-can-access-the-git-repo",
        url: "${GIT_REPO_URL}"
    }

Build Stage

Next, the code must be built and unit tested. “mvn clean install” will do just that (depending on what you want, you can always put in a different maven goal). The junit command is just there to take the resulting XML that gets generated during the build process and posts a graph of how many tests were run for each build.

    stage('Build') {
        sh "'${MAVEN_HOME}/bin/mvn' clean install"
        junit '**/target/surefire-reports/TEST-*.xml'
    }

Beta Stage

Once the build succeeds, you’ll want to deploy it to a beta environment, so integration tests can happen. The following happens at this stage:

1. Get the right credentials to get permissions to Tomcat
2. Call the deploy method to deploy the war file in Tomcat (more on that later)
3. If the deployment fails for whatever reason, print out the deployment log for debugging and fail the build
4. If the deployment succeeds, run the integration tests (the command to do this may differ based on use case)

    stage('Beta') {
        withCredentials([[$class: 'UsernamePasswordMultiBinding',
            credentialsId: 'credential-id-for-tomcat',
            usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD']]) {
                // Password is available as an env variable, but will be masked 
                // if you try to print it out any which way
                def output = deploy(WAR_PATH_FULL, TOMCAT_CTX_PATH_BETA,
                        env.USERNAME, env.PASSWORD)
                if (output.contains("FAIL - Deployed application at context path " + 
                        "/${TOMCAT_CTX_PATH_BETA} but context failed to start")) {
                    echo "----- Beta deployment log -----"
                    echo output
                    echo "-------------------------------"
                    currentBuild.result = 'FAILURE'
                    error "Beta stage deployment failure"
                }
            }

        echo "Running integration tests"
        sh "'${MAVEN_HOME}/bin/mvn' -Dtest=*IT test"
        junit '**/target/surefire-reports/TEST-*.xml'
    }

The deploy method is what takes care of the actual deployment to Tomcat, which is how the Jenkins build tells Tomcat about the newly built war file. The deploy method is below (be sure to change the server IP and port). Alternatively, I could have built my project as an embedded jar file, but that has a different challenge in figuring out how to get Jenkins to tell the OS to execute the newly built jar file as a particular user.

1. Based on the Tomcat context path, decide whether a beta or production deployment is happening
2. Make a copy of the build war file and add .prod or .beta to the end of it so as to keep the original
3. Set the Spring profile to use on the newly copied war file (more on that later)
4. Call the curl command to do the actual deployment to Tomcat (more on that later)

def deploy(warPathFull, tomcatCtxPath, username, password) {
    def envSuffix = ""
    def isBeta = tomcatCtxPath.contains("beta")
    if (isBeta) {
        envSuffix = "beta"
    } else {
        envSuffix = "prod"
    }
    sh script: "cp ${warPathFull} ${warPathFull}.${envSuffix}" 
    setSpringProfile(warPathFull, isBeta)
    def output = sh script: "curl --upload-file '${warPathFull}.${envSuffix}' " +
            "'http://${username}:${password}@localhost:8081/manager/text/deploy" + 
            "?path=/${tomcatCtxPath}&update=true'", returnStdout: true
    return output
}

In the case of my project, I’m building a single war file that does not have a Spring profile (beta/prod) defined. This means that I have to manually define this before I deploy the app to Tomcat since there are some things that differ between beta and prod like database URL’s. To do this, I wrote a method that opens the war file like a zip (jar/war files are zip files) and adds a line to my application.properties to define a Spring profile.

Admittedly, doing this zip file manipulation seems kind of hacky. Alternatively, I could have defined my build such that I had a separate beta build and a prod build to avoid modifying the zip file, but the drawback is that I’d then have to build my code twice.

def setSpringProfile(warPathFull, isBeta) {
    def zipFileFullPath = warPathFull + "." + (isBeta ? "beta" : "prod")
    def zipIn = new File(zipFileFullPath)
    def zip = new ZipFile(zipIn)
    def zipTemp = File.createTempFile("temp_${System.nanoTime()}", 'zip')
    zipTemp.deleteOnExit()
    def zos = new ZipOutputStream(new FileOutputStream(zipTemp))
    def toModify = "WEB-INF/classes/application.properties"

    for(e in zip.entries()) {
        if(!e.name.equalsIgnoreCase(toModify)) {
            zos.putNextEntry(e)
            zos << zip.getInputStream(e).bytes
        } else {
            zos.putNextEntry(new ZipEntry(toModify))
            zos << zip.getInputStream(e).bytes
            zos << ("\nspring.profiles.active=" + (isBeta ? "beta" : "prod")).bytes
        }
        zos.closeEntry()
    }

    zos.close()
    zipIn.delete()
    zipTemp.renameTo(zipIn)
}

A curl command to Tomcat is what actually does the deployment. To deploy a file to Tomcat, do the following below. This will deploy the war file to Tomcat and instantly run it, thus it will be accessible at the given context path.

curl --upload-file 'path-to-war-file' http://username:password@server-address:port/manager/text/deploy?path=/tomcat-context-path&update=true

Prod Stage

The same kind of stuff happens in the prod stage as in the beta stage with a few exceptions. The following happens at this stage:

1. Get the right credentials to get permissions to Tomcat
2. Call the deploy method to deploy the war file in Tomcat (except this time it is prod)
3. If the deployment fails for whatever reason, print out the deployment log for debugging and roll back the deployment
4. If the deployment succeeds, save the build files, and then the pipeline is finished. Alternatively, smoke tests can be run at this point, but I did not implement this in my project

Rollback is important because if the deployment fails, you don’t want to be stuck with a broken environment. Since build artifacts are saved on successful deployments, these same artifacts can be brought back if future deployments fail. This means they can be redeployed so that the code can be fixed before another deployment happens.

    stage('Prod') {
        withCredentials([[$class: 'UsernamePasswordMultiBinding',
            credentialsId: 'credential-id-for-tomcat',
            usernameVariable: 'USERNAME', passwordVariable: 'PASSWORD']]) {
                // Password is available as an env variable, but will be masked 
                // if you try to print it out any which way
                def output = deploy(WAR_PATH_FULL, TOMCAT_CTX_PATH_PROD, env.USERNAME, env.PASSWORD)
                if (output.contains("FAIL - Deployed application at context path " + 
                        "/${TOMCAT_CTX_PATH_PROD} but context failed to start")) {
                    echo "Prod stage deployment failure, rolling back deployment"
                    echo "----- Prod deployment log -----"
                    echo output
                    echo "-------------------------------"
                    step([$class: 'CopyArtifact',
                            filter: "${WAR_PATH_RELATIVE}",
                            fingerprintArtifacts: true,
                            projectName: "${PROJECT_NAME}",
                            target: "${WAR_PATH_RELATIVE}.rollback"])
                    deploy(WAR_PATH_FULL + ".rollback/" + WAR_PATH_RELATIVE,
                            TOMCAT_CTX_PATH_PROD, env.USERNAME, env.PASSWORD)
                    currentBuild.result = 'FAILURE'
                    error "Prod deployment rolled back"
                } else {
                    archiveArtifacts artifacts: "${WAR_PATH_RELATIVE}*", fingerprint: true
                }
            }
    }

At the end you get to have something like this:

That pretty much sums up the whole Jenkins pipeline that I’ve been using lately for Spring projects!

Every now and then I get this annoying problem in GGTS (Grails/Groovy Tool Suite – Version 3.6.2.RELEASE at the time of this writing), where the IDE just complains about how it can’t resolve a class.  The weird thing is that the file that the IDE is complaining about is in the same package as the class that I’m trying to use.  It built before, and the source hadn’t changed – so clearly this should not be happening.

The Fix

Hitting the Clean button on the Eclipse side (Project -> Clean) seems to make the errors go away.

This apparently has been a problem since June 2010 (forum post reference here), so I’m surprised that it is still an issue in the current version.

Script

I’ve managed to produce a script to disable mouse acceleration (works for me on Ubuntu 14.04).  However, this script needs to be run every time the computer boots because the settings don’t stay.  Here is the script:

#wait for the desktop to settle
sleep 5

#gets the hardware id's of all mice plugged into the system
hardwareIds=$(xinput | grep -i mouse | awk '{print substr($(NF-3),4)}')

#turn off mouse acceleration
for i in $hardwareIds
do
xinput set-prop ${i} 'Device Accel Profile' -1
xinput set-prop ${i} 'Device Accel Velocity Scaling' 1
done

Explanation

The script works by extracting the hardware id’s of the mice that are connected to the system and then applying properties to them that disable mouse acceleration for that device.  The extraction of the mouse hardware id’s are done with this:

#gets the hardware id's of all mice plugged into the system
hardwareIds=$(xinput | grep -i mouse | awk '{print substr($(NF-3),4)}')

Calling xinput in the Terminal will list all the connected input devices, which is grepped (case insensitively) for the word “mouse”, which gives something like this on my machine:

⎜ ↳ Logitech G500s Laser Gaming Mouse id=14 [slave pointer (2)]
⎜ ↳ Logitech G500s Laser Gaming Mouse id=15 [slave pointer (2)]

The call to awk extracts the hardware id from those two lines (14, 15 in the above case) and stores them in an array that is iterated through when setting the mouse properties.

Reference

This is the website that showed me how to disable mouse acceleration to begin with: http://ubuntuforums.org/showthread.php?t=1734400

In a computer, there are various methods of storing information.  Information can be stored in the processor cache, RAM, hard disk, etc.  It can be faster to request information from a storage medium that is smaller.  However, this smaller storage medium cannot fit all the possible information that can be requested.  So the idea is to insert a portion of the data into the faster, smaller medium (the cache) and the rest into the slower, larger medium (main memory).

If a request is made and the data is not available in the faster, smaller medium first, then the data will be read from the slower, larger medium – this is what is known as a cache miss.

Given that all the data cannot possibly live in the cache, there must be a way to minimize the amount of times that the data must be read from the main memory.

Optimal Caching – Farthest-in-Future

The Algorithm

The idea is that there is an algorithm that minimizes the amount of cache misses that occur for a set of requests.  The Farthest-in-Future Algorithm evicts the item in the cache that is not requested until the farthest in the future.  For example, given the following cache with items “a” through “f”.

It is clear that “g” does not exist in the set of cache items and so when “g” is requested, a cache miss will result. An item will be evicted because “g” is not in the cache.  According to the Farthest-in-Future Algorithm, element “f” will be evicted since it is the one that will be used furthest in the future.

Definitions

Cache Miss – Occurs when it is necessary to bring in an item from the main memory into the cache

Schedule – A list that contains, for each, request, which item is brought into the cache, and which item is evicted

Reduced Schedule – a schedule that only brings in an item when there is a request for that item – so a non-reduced schedule would bring an item into the cache outside of a request for that item

Theorem

To be shown:

Farthest-in-Future is the optimal algorithm that minimizes the number of cache misses.

To prove this, let’s say there is a schedule SFF that follows the Farthest-in-Future Algorithm and that there is a schedule optimal S that has a minimum number of cache misses. It can be shown that it is possible to transform S into SFF by performing a series of evictions without increasing the number of cache misses.  Since S^* is already optimal, and the number of cache misses did not increase, then SFF must be optimal.

To perform one transformation, the statement below can be used.  Right now, it isn’t all that clear why this is necessary, but it should become clearer further on.

Let S be a reduced schedule that is the same as SFF for the first j requests, then there is a reduced schedule S’ that is the same as SFF for the first j+1 requests, and incurs no more misses than S

Proof

Let’s say the cache at the start looks like this.  S and SFF have the exact same contents (this is what was defined in the previous section).

Given a schedule S, it can be shown that any request can be made, and the resulting schedule would be equal to the ideal algorithm and does not increase the number of cache misses.  Essentially, we want S = S’ = SFF after a request is made and that the number of cache misses have not increased.  If this can be shown for all different scenarios that items are requested, then Farthest-in-Future is the ideal algorithm.

Case 1: Item Is Already in the Cache

Now let’s say the next item to be requested is item “d”.  It is clear that this item exists in both caches and no evictions are necessary.  Since no evictions are necessary, SFF does not change.  It was specified in a prior section that there is a schedule S’ that equals SFF, which incurs no more misses than S.

Here, S = S’ because no changes had to be made to the cache and there were no cache misses.  After the request for item “d”, S = S’, each with zero cache misses, which is a valid outcome.

Case 2: Item Is Not in the Cache, S and SFF Evict the Same Item

Let’s say the next item to be requested is item “e”.  Neither cache has this item, so an eviction will have to be made.  Let’s also say SFF and S both choose to evict item “a” to make room for “e”.  It was specified in a prior section that there is a schedule S’ that equals SFF, which incurs no more misses than S.

Here S = S’ because S and SFF both evicted the same item.  Both S and S’ each have one cache miss (no increase relative to one another), which is a valid outcome.

Case 3: Item Is Not in the Cache, S and SFF Each Evict A Different Item

This is where the proof can become more confusing (as if it isn’t already).  Let’s say the next item to be requested is “e”.  Let’s also say that the ideal algorithm, SFF, evicts “a” and S evicts “b”. It was specified in a prior section that there is a schedule S’ that equals SFF, which incurs no more misses than S. This means that in order to get S’ = SFF, S’ should evict “a” in order to match with SFF.

Here, S does not agree with S’ = SFF.  Essentially, these two schedules behave the same, so long as future requests do not request items “a” or “b”.  This shows that there is a schedule S’ that equals SFF, but it is not known whether or not S’ has no more cache misses than S, since “a” or “b” can be requested in the future, which can determine whether S or S’ has more cache misses.  From this point onward, S and S’ behave the same until one of the following happens:

Case 3a: Item Is in SFF, But Not S; S Evicts “a”

Let’s say eventually item “b” gets requested.  In this case, S’ and SFF do not need to change.  All S has to do is evict “a” to make room for “b”.  In this case, S has two total cache misses (from request “e” and “b”), while SFF and S’ each have only one cache miss, thus fulfilling the cache miss requirement.

Case 3b: Item Is Neither in SFF Nor S

Let’s say eventually item “f” gets requested.  S’, SFF, and S all need to make an eviction. S’ and SFF can evict “b” to make room for “f”, and S can evict “a” to make room for “f”.  In this case, each schedule as two cache misses, thus fulfilling the cache miss requirement.

Case 3c: Item Is in SFF, But Not S; S Evicts Item Not Equal to “a”

Let’s say eventually item “b” gets requested and S evicts an item that isn’t “a”, say “c”.  Now, SFF and S’ both already have “b” in the cache.  In order to synchronize S and S’ to make them comparable to see how many cache misses each have, S’ and SFF will evict “c” to make room for “a”.

Since “a” is being brought into the cache without a request for “a”, this makes S’ and SFF no longer a reduced schedule.  However, the proof calls for S’ and SFF being a reduced schedule.  Fortunately, it is possible to transform an unreduced schedule into a reduced one.  In this case, each schedule has two cache misses, thus fulfilling the cache miss requirement.

Case 3d: Item Is Not in SFF, But in S

The only item that is in S and not SFF is item “a”.  SFF had evicted it initially at the beginning of Case 3.  Since SFF had evicted it, it must have been the item that would be requested furthest into the future.  Therefore, it is not possible for item “a” to be requested before other items.

After going through all possible eviction decisions that the schedules can do, it was shown that for each scenario, there was indeed a schedule S’ = SFF, where the cache misses incurred in S’ no more than S.

These two keys toggle the full-width (double-byte), and the half-width (single-byte”) character sets when typing with the Chinese IME.  Full-width characters look like “ｔｈｉｓ “ while half-width is what people are normally used to.  The default key combinations are easy to press by accident in situations such as capitalizing a title.  Therefore, it is beneficial to remove this hotkey.

Solution

Because changing the key settings manually through Windows does not work, one must go through the registry.  The following fix applies to the current user that is logged in.  Apply the following registry keys and then restart the computer.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys]

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys\00000010]
“Virtual Key”=hex:ff,00,00,00
“Key Modifiers”=hex:00,c0,00,00
“Target IME”=hex:00,00,00,00

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys\00000011]
“Virtual Key”=hex:ff,00,00,00
“Key Modifiers”=hex:00,c0,00,00
“Target IME”=hex:00,00,00,00

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys\00000012]
“Virtual Key”=hex:ff,00,00,00
“Key Modifiers”=hex:00,c0,00,00
“Target IME”=hex:00,00,00,00

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys\00000070]
“Virtual Key”=hex:ff,00,00,00
“Key Modifiers”=hex:00,c0,00,00
“Target IME”=hex:00,00,00,00

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys\00000071]
“Virtual Key”=hex:ff,00,00,00
“Key Modifiers”=hex:00,c0,00,00
“Target IME”=hex:00,00,00,00

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys\00000072]
“Virtual Key”=hex:ff,00,00,00
“Key Modifiers”=hex:00,c0,00,00
“Target IME”=hex:00,00,00,00

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys\00000201]
“Virtual Key”=hex:ff,00,00,00
“Key Modifiers”=hex:00,c0,00,00
“Target IME”=hex:00,00,00,00

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys\00000202]
“Virtual Key”=hex:ff,00,00,00
“Key Modifiers”=hex:00,c0,00,00
“Target IME”=hex:00,00,00,00

[HKEY_CURRENT_USER\Control Panel\Input Method\Hot Keys\00000203]
“Virtual Key”=hex:ff,00,00,00
“Key Modifiers”=hex:00,c0,00,00
“Target IME”=hex:00,00,00,00

In the registry, one can also navigate to “HKEY_CURRENT_USERControl PanelInput MethodHot Keys” and see a list of folders with names that have eight numbers in them with leading zeroes.  Each folder here represents a particular hotkey related to an IME.  Clicking on one of these folders will show data for these keys.

Setting “Key Modifiers” to “00 c0 00 00” removes the use of the Ctrl and Alt key for the hotkey.
Setting “Virtual Key” to “ff 00 00 00” sets the key to nothing.
The key “Target IME” can be left as is.

In the case of the “Shift+Space” hotkey, “Shift” is the key modifier and “Space” is the virtual key.

It is unclear which folder corresponds to the key that toggles the character shape, therefore this fix is a blanket approach.

If the Above Still Fails

Try combining the fix with an installation of Microsoft Office IME 2010, which can be downloaded here: http://www.microsoft.com/downloads/zh-tw/details.aspx?FamilyID=60984ecd-9575-411a-bd38-2294f17c4131&displaylang=zh-tw.  Despite the name, it does not require Microsoft Office to be installed. After installing, apply the registry keys and restart.

The following solution is proposed:

Use Microsoft AppLocale

Microsoft AppLocale allows running a program using a particular language without changing the Windows language setting.  That means, one can change between multiple languages on-the-fly for each program.

According to Microsoft:

Unicode based platforms, such as Windows XP, emulate the language environment required to run non-Unicode applications by internally converting application’s non-Unicode text data to Unicode using a system-wide variable commonly called the system local (or language for non-Unicode applications). The language of the non-Unicode applications should be of the same script or family as the one defined by the system locale. Failing to meet this condition results in display of garbage characters in the UI of the application.

Download link

Once downloaded, install and run it.  Follow the instructions and choose what program that is to be run at the wanted language.  If the correct language was chosen, the application should show the correct characters.

I didn’t really go into specifics as to what kind of modem lights to look for because all modems are different.  But they almost always will have an “Online” light.  If that is off, then there is clearly a problem.

Router lights are usually just a power light, the WAN and LAN lights.  If the WAN light is off, it means the router has no access to the Internet.

Each network adapter on the computer can be disabled and enabled by accessing “Network Connections” in Windows.  That can be accessed by typing the name without the quotes in the address bar in any open Explorer window.

• RXTX
• JavaComm

Unfortunately, the current version of JavaComm does not support Windows, and only supports Solaris SPARC, Solaris x86, and Linux x86.  Since I use none of those operating systems, this article will only discuss how to install RXTX in Windows.

UPDATE: 12 Sept 2011 – Thanks to a comment from Kurt Zoglmann, there are instructions on how to do this with a Mac!  I never tried this myself because I don’t have a Mac, but the procedures stated there look good to me (see comments).

A 32 and 64 bit version of the library exists.   I’ve updated this article from when it was first published to include the new locations for where to download the libraries, but I have not gone through the installation of the libraries again, so I’m not surprised if the rest of the content on this page is outdated too.

32-bit version: http://rxtx.qbang.org/wiki/index.php/Download
64-bit version: http://fizzed.com/oss/rxtx-for-java

To install the libraries (instructions from JControl):

1. Copy rxtxSerial.dll to %JAVA_HOME%\bin, (%JAVA_HOME% is the folder where JRE is installed on your system; e.g. c:\Program Files\Java\j2re1.4.1_01)
2. Copy RXTXcomm.jar to %JAVA_HOME%\lib\ext

Once installed, the IDE will need to know where to look for these installed files.  Even though the files exist in the JRE directory, each project needs to know about these files.  More information on this website.

In order to start coding with this library, import gnu.io.*.  For more information about Java Serial Programming, look here.

Happy coding!

UPDATE 12/08/10: One of the comments (thanks to Jørgen) provided an even better solution for getting rid of this annoying process.  It involves removing the plugins from Adobe Reader completely.

…Program Files…AdobeReader 9.0Readerplug_ins
there are 3 files you should delete (or maybe just rar them so you still got them in case something goes wrong)
Accessibility.api, MakeAccessible.api, ReadOutLoud.api
(if that gives troubles, just delete the files with the same name and .xxx where xxx stands for a certain language too)

OR – if you’re afraid Adobe won’t work or you’ll need the files later – rename the extension to .api_

Below is the original solution that I had.  It changes the settings so that the program will process each page as you read.  It’s not as good as the previous solution that completely disables it though.

1. Go to Adobe Reader’s Preferences (Edit > Preferences)
2. Go to the Reading tab
3. In Screen Reader Options, choose Only read the currently visible pages

Doing this pretty much tells Adobe to do the reading as you scroll through the pages.  Although this can still be annoying, but it’s way better waiting through that screen for larger PDF’s.

According to the writer of the guide, undervolting simply reduces the voltage applied to the processor.  Since all processors have a different voltage requirement, they all use one standardized value which is most likely higher than the amount that the processor itself requires.  By reducing this excess voltage, the power dissipated by the processor will decrease, and thus reduce heat and increase battery life.  It should also be noted that this process will not impact performance since the performance of a processor is governed by its clock speed.

By doing this, I’ve reduced the temperature of my laptop by about 12-15 degrees Celcius.  The laptop’s keyboard and touchpad are no longer warm to the touch and the side heat vent no longer feels like burning.  Definitely a major improvement!

Link: http://forum.notebookreview.com/hardware-components-aftermarket-upgrades/235824-undervolting-guide.html