…and related fields

Menu

This article explains how to overclock the FSB on Clevo D900K derived models like the Alienware M7700, the Sager NP9750, and the Eurocom F-Bomb.

This technique is NOT for the faint-of-heart. You will be playing around with the frequency generator on your motherboard. Frequency=Heat and Heat=Damage. Be careful. If you fry your electronics, I will not be able to help.

I’ve become pretty familiar with my Sager 9750 laptop over the past 5 years. Check out my YouTube videos in which I reconstruct it:

I purchased it with a lesser processor rather than stump the cash for the top of the line CPU, but I remedied that last year by purchasing an Athlon FX60 off of eBay.

One thing that’s been bugging me about these custom laptops (even, most laptops), is the inflexibility of the BIOS. There are zero overclocking options available. Here’s what I would alter, if I could:

* The FSB (using tools like SetFSB , and ClockGen)
* The CPU multiplier
* The memory interface (which I have done by writing updates to the SPD data on one of my memory chips to lower the CAS to 2.5 ( causing the BIOS to auto-select DDR800 ), using SPDTool )

This article covers altering the FSB.

Unfortunately to alter the FSB requires software that understands the specific clock generator hardware integrated into the motherboard. For the Sager 9750 D900K, the tools I mention above do not recognize the model present.

Our first bit of useful information is written directly under the chip representation, it’s model – an ICS953201. Each clock generator IC has an SMBUS (I2C) interface, but uses different registers necessitating specific drivers for each chip. While there is great software out there, none of the applications I located could supports this specific clock generator.

ClockGen would happily read the following string of bytes directly off of the SMBus, without needing to know the specific clock generator IC:

73 00 FF FF FF 08 F7 21 0F 07 00 CE 76 0E 30

I poked 80 into the first byte and it happily locked up the computer. Obviously, I need to work smarter!

Sadly, it’s several years on, and the chip has since been discontinued by the manufacturer, Integrated Device Technology. I was unable to find a datasheet on their web site or on the wider web.

Referring to the schematic again, the handy clock generator table indicates that FS[4:0] should be set to 10011 (in binary) by default for the 200Mhz bus.

I can see 10011 in two places – in the first byte, and crossing the least significant nibble of the byte at index 11 (CE) and the most significant of the one at index 12 (76). Great! Only two possibilities (assuming the lines aren’t distributed over multiple registers… ).

Since I do not want to be rebooting the machine every time something goes wrong, I choose a safe, but noticeable increase in the clock rate. From the table in the schematics:

Attempting to write the CE 76 bits is a failure – a refresh shows that the changes didn’t take. But at least no crash! Writing the initial byte is only slightly more successful. The change took, and the machine did not crash. but the clock rate did not change.

| 73 | | 69 |
| 7 | 3 | => | 6 | 9 |
|0111|0011| |0110|1001|

Time to hit the datasheets! As I’ve said, I do not have the datasheets for this chip, but the datasheets for another chip from IDT, or IDT’s other motherboard clock chips, tell an interesting story. On page 10, we see that Byte 0 bit 7 is the ‘FS’ (Frequency Select, I’m sure) Source flag – either Latched Input (0) or SMBus (1). Latched Input means using the hard-wired pin outs on the clock generator IC.

Sure enough, we can see in the binary above that the first byte, 73, has a zero initial bit.

Using RW-Everything, I set this bit as well as what I believe to be the clock rate FS flags:

| 73 | | E9 |
| 7 | 3 | => | E | 9 |
|0111|0011| |1110|1001|

…

…

Hurray! CPU-Z instantly reports the increase in the CPU clock from 1200Mhz to 1212Mhz (CPU multiplier is 6 when the processor is not under load).

So folks, in summary, using RW Everything, use the table from the schematic, and update the bits in byte 0 of the clock generator registers to your desired frequency. Your mileage may vary, depending on your video card, memory, and processor. Reminder; you can destroy your hardware attempting this. If your system locks up, turn it off immediately. Listen to your fans. To do any more significant overclocking, it may be necessary to tune the CPU multiplier downwards.

If I discover how to do that on this machine, I’ll be sure to let you know right here!

In 2009 I uploaded a video to YouTube showing an Arduino measuring the rotational speed of a basic computer fan. It was one of a number of YouTube videos I did as I was studying for a Masters in Computer Science. This particular module was an embedded systems programming course, with a bit of electronics thrown in. Here’s the video:

I was recently asked if the schematics were available for this video. Unfortunately I was unable to locate the schematics as shown in the video, however I do have the source code. This is a simple Arduino Sketch that uses an open source ‘Timer’ library. You can download the fan-rpm-sketch source code. When reading this source code please keeping in mind that there are three processes going on:

a) setup/loop Sketch methods – responsible for attaching interrupts, configuring the Timer, and writing the RPM count out to the serial port

b) IR ISR – this interrupt routine is configured to be triggered by the falling edge of the IR input – i.e. whenever the leading (or falling, I forget which) fan blade <em>edge</em> passes the sensor

c) A Timer routine that is attached to a high speed timer and called every second to calculate the RPM value extrapolated from the number of fins seen that second.

I also have schematics and documentation for the newer application – a Temperature Controlled Fan:

The difference between the two is the addition of two modules to the layout – the thermistor temperature sensor, and the opto-isolated pulse-width-modulated speed controller. On the software side, we now use FreeRTOS on Arduino.

Except for a few edits, the text that follows was mostly written in 2009.

Hardware Discussion

The use of an opto-coupler is separates the low voltage Arduino digital IO from the slightly higher voltage used to power the Arduino board and the Fan. Potentially any voltage is supported up to the limits of the CNY 75B part.

Thermistor
Use of this component required a low current limiting resistor to generate an acceptable voltage drop over the thermistor, so a 4.7k was chosen.

IR LED and Transistor
The IR transistor from radio shack required a large bias resistance to place it in ‘switching’ mode rather than amplification mode. A 100K ohm resistor was chosen. An approximate 100 ohm current limiting resistance for the IR LED was provided through two 47ohm resistors in serial.

Fan and Power choice
Using the 12V fan in conjunction with a 7.5V power source is not optimal but it works. The current required to feed the base of the NPN transistor is obviously changed by the lowered voltage, so the resistances used needed to be different. A 4.7k ohm resistor was placed in parallel with a 10k ohm resistor which appears to provide a faster response from the fan ( I assume due to lowered switch time of the NPN transistor ).

Software

System Software Block DiagramDesign Discussion

The system software is built upon FreeRTOS but is wrapped in a C++ layer. All tasks inherit from a task class that provides wrappers around functions applicable to tasks, including creation, stack and priority configuration, and the ability to invoke a derived (virtual) method that is the actual task code provided by the implementor of the derived class.

In addition to tasks, there is one other class to wrap the configuration of timer 2 as a PWM output. The combination of timer 2 and output compare B means that we are driving pin 3 as the PWM output.

The C++ layer follows the arduino sketch model in three regards:
a) The use of a setup and loop function for task code
b) The provision of implicitly available functions – basically anything wrapped by the task base class
c) The code is built entirely within the sketch tool

However, it needed to implement a global override of the new operator to call pvPortMalloc – the FreeRTOS implementation. In addition I had to place dummy overrides for pure virtual and guard C++ runtime implementation functions.

The original setup method is used to both initialize all tasks in the system – configure the hardware to some base state, and then invoke the FreeRTOS Scheduler. If something goes wrong, it falls through to the original arduino sketch loop method, which is implemented to provide a distinct LED pattern so that this error condition can be seen.

After implementing the C++ layer, however, it became readily apparent that something was wrong, as the stability of the software was variable depending on the order in which tasks were created, whether they were created in FreeRTOS. What is provided is a working version, but only after much trial and error. Changes to stack sizes, queue sizes, serial debug messages, adding of tasks, or changing the order of tasks and hardware initialization is not recommended! I suspect but cannot be sure that the combination of heap, stack, and static allocations conflict in some non-trivial way. (edit: based on later experiences, I have to see it is actually quite trivial. If you run out of stack of heap memory, you’ll have trouble. If the stack expands onto the heap, you’ll have trouble. Also, you don’t have much to start with, and working in C++ you can easily be fooled that you don’t have to worry about this. You do.)

Were I to implement this project again, I would either go with Eclipse or WinAVR as the build tool and eliminate the use of Arduino functions like the serial engine, or I would strip the C++ layer out to minimize overhead on the Arduino.

RPM Counter

Internally the software is using an interrupt triggered by the IR phototransistor on digital pin 2 to monitor the fan RPM count. A task converts the count to an RPM measure and writes it to the serial every second. A semaphore is used to synchronize the interrupt ISR with the RPM task.

Originally I tried to go with a counting semaphore, but the FreeRTOS download I am using complained that it does not exist. I did not want to resort to a mutex semaphore on an integer so instead I went with a recursive semaphore. The recursive semaphore allowed itself to be taken as many times as the interrupt is fired, so the task keeps taking the semaphore until it blocks. It waits a maximum of 1 second updated each time the semaphore is taken, so the task is able to block and yet still sum up the counts at the end of each second.

Analog / Thermal / Sense task

This variously named task reads the analog reading on analog port 0 which is hooked up to the thermistor. This value is scaled, inverted, and biased back from a 0-1023 range, of which 900+ is ice and 673 is room temperature back to a zero to 255 value that can be used to set the PWM duty period.

timer2pwm object

This singleton object is used to manage the timer2 output compare B configuration which drives the PWM period on digital pin 3, which drives the fan. Use of timer 2 does not conflict with analog readings or with the FreeRTOS timer tick interrupt.

Serial task/class

The serial task exposes functions that are intended to be called from other tasks. They place values onto internally managed FreeRTOS queues which are processed once a second by the serial task code. This centralizes access to the serial bus.

But no that’s not my favorite, because it’s not neat enough, the spec is huge, and there are interactions that mean it won’t safe to use in a browser for many years to come. That’s not the reason for this post, so I won’t go into detail.

Canvas is great, we can draw. But we could do that before, albeit server side. Also, I think I dislike the 2d context API.

Truly, I don’t have a favorite feature – the ones I like the best are the smaller APIs that slot neatly into the spec and are well defined. Which brings me to the point of this post:

To understand the oe event parameter, read the spec. It is tiny, so don’t be afraid! There are 3 orientation attributes, alpha, beta and gamma. Each is a rotation around an axis referenced to a frame where the device is lying flat. Alpha goes between 0 and 360, beta goes between -180 and 180 (degrees), and gamma goes between -90 and 90 degrees.
Zero’s across the board imply the device matches the reference frame, which means it is lying flat on a table in front of you.

There is no guaranteed rate at which the rotate event is called, so you’ll see I use a separate render function called at regular intervals.

Using this API, I decided to implement a mobile version of xeyes – only the eyes follow you, reacting to the angle of the screen so that they are always looking at you!

If you’ve read this far, feel free to see the live version here: Eyes for HTML5.

Here are the steps I took:

1) Draw a face on a Canvas on page load
2) On each render:
a) Clear the eye sockets
b) Add pupils at a set distance based on beta and gamma angles.

Since we don’t know when or if we will get an orientation event, we keep it separate to our render routine. This is just good practice in general. The render routine runs often to keep the animation smooth. The orientation handler can do processing only when needed. Of course, it’s not doing anything other than storing a variable here.

1) Back in the days of the 80486 (1995) where I lived in Coventry, England; there was an a con going on where computers were being sold as containing 2nd level cache memory, but in fact to save money, the cache memory was dummy. This was possible because the cache memory just sat on top of the memory bus and responded more quickly than main memory. The upgrade path was obvious to me: unsolder the bad cache memory directly from the board, and replace it with good cache memory DIP chips and sockets that I would buy for the purpose. Sure enough, the first unsoldered chip I smashed apart was a block of solid plastic – no silicon!
Well, unfortunately my soldering skills were not up to the task, and after all was said and done, it wouldn’t boot any more. Happy ending: I gave it to my dad who managed to fix it back up by replacing a bad power transistor that happened to be close to where I had been soldering.

2) A little later on I had an Athlon on MSI m/b machine I had decided to flash the BIOS to a newer version. Something went wrong and I was left with a bricked machine. Now, I actually had two machines at that time, and I’ve always been a fan of MSI motherboards so I happened to have two almost identical boxes. Inspiration struck and I booted up the working machine to DOS. Then, *while it was running*, I opened the case up and popped the BIOS chip out, replacing it with the bad one. This worked because the BIOS had been shadowed to main memory and didn’t care that it had just been gutted! I flashed the bad chip from DOS, popped it back out and returned it to the bad machine,…and crossed my fingers… Worked like a charm.

jboss seam session vs conversation: A Session is a standard Servlet concept – a collection of attributes that the server maintains while a user is active on web application. Applications leverage it heavily to store server-side the current state of the user – such as the contents of his or her shopping basket. There are other collections – for example, those associated with a single HTTP request. Seam takes this several steps further. Each of these original collections has it’s place in Seam as a Context, along with several new ones that Seam uses and provides. This sounds onerous, but in Seam you no longer have to know that the attribute you want is stored in the session, you can instead just ‘inject’ the attribute, and Seam will find it for you from any of the contexts it supports.

One of these contexts is the Seam conversation context. It doesn’t last as long as a the user’s Session, by default timing out after 5 minutes of inactivity, but it’s lifetime is entirely managed by the Seam framework, avoiding the messiness that comes with losing all the user-specific state you left in an expired Session when a user resumes activity.

Naturally just as an application may manage multiple concurrent user sessions, Seam lets you have multiple conversations per user session. A widely used analogy is that of a workspace; in our case we have one workspace for each document that our users may be editing.

I can only speak about JSF, as Seam supports several view layers; but here Seam really shines. In JSF plain, managed beans have to be declared in faces-config.xml. In Seam, a custom EL resolver evaluates EL statements (#{}) and dynamically identifies from the Seam contexts which bean to use. This process is similar to injection, and so Seam is able to look up any bean stored in any of it’s contexts, or even create on the fly an instance of properly annotated java class. So – no more faces-config.XML.

With the custom EL resolver and a heirarchical context search, Seam allows you to write beans and pages that work in the context of a particular workspace (conversation). When a page is rendered, Seam knows what conversation that page is being rendered in, and so it can dynamically pull the correct bean instances from the correct conversation context instance.

Part of the state of a conversation is what page you are looking at in an application. Seam conversations can be used for a limited form of page flow. This is because not only can a user have multiple conversations per session, but conversations can also be nested. By creating a nested conversation, the parent conversation is frozen along with the view the user was last looking at while in that conversation. When a user causes the nested conversation to end, Seam can return the user to the parent conversation and also to the page they were on before the user entered into the scope of the nested conversation. Conversations can be arbitrarily nested, and attributes of the parent conversation are available to the nested conversations through injection and EL resolution. The process of searching contexts for attributes is known as the hierarchical context search in Seam.

Lastly, I should mention that there is always a Seam conversation in place. This differs from explicitly created ‘long running conversations’ in that it is temporary and lives only for the duration of postback + possible redirect. This temporary conversation is used by Seam to traffic JSF Faces Messages through a redirect. For example, say you have a page with a button, and when you click that button you trigger an error. But you want the specific error to be displayed on another page. The postback for the button could redirect the user to the error handling page, but in standard JSF you would lose the specific error message stored in the FacesMessages object. Seam keeps those messages in the conversation context so that it doesn’t matter what page renders the result of the user’s interaction – the messages will still be available. This is just one example where the conversations helps Seam smooth over JSF’s wrinkles.

no active conversation context: With the above knowledge, this exception should now be easy to understand. Take the example of a deep bookmark saved from a Seam web application. Let’s say that this page was bookmarked from the a ticket reservation system, and because of this it relies on beans that exist only while tickets are temporarily reserved for purchasing. These beans could reasonably be marked @Conversational or otherwise explicitly scoped to the Conversation contexts as even just 5 minutes later, the tickets would no longer reserved for purchasing. (In this case the 5 minute expiry of the conversation is tied to the business process, however all conversations in Seam expire). If the user navigates to this deep bookmark after the conversation has expired, then this exception will be thrown.

You have a couple of options to work around this exception:
1) Increase the conversation timeout in components.xml, or more likely
2) Trap the exception in pages.xml and redirect the user to a page that will let them restore or restart their activity.

(And for the record, yes, the keywords that caused me to write these articles were listed as incoming searches using google analytics )

The primary reason that I have found that our consolidated AJAX page is slow, and that no amount of HTTP traffic optimization is going to fix, is that two of our composited components had implemented getters by way of a database query.

This is absolute bad practice – JSF does not guarantee that your getters will be called just once, so even in a Web 1.0 application you may be making redundant database queries.

In an AJAX application this problem is exacerbated – doubtless none of those queries are necessary on the AJAX request.

In our application each of those queries ate up about 100ms, multiplied about 3 times each because they were embedded in getters. Obviously this soon becomes a noticeable delay ruins the feel of the application.

Simply caching the query in the bean removes this problem, but in a Seam component you have several more options to refine this approach.

Since our beans were EVENT scoped, we specifically outjected PAGE scoped variables to host the cache.