Category Archives: Articles

Longer posts

Sager 9750, ICS953201 FSB overclocking

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.

So all that remains to improve this machine would be to purchase the GeForce Go 7950 GTX 512Mb video card, which is rare and still pricey.

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.

So let’s get down and dirty with with some schematics!

From the Clevo D900K Sager NP9750 Service Manual, skip to page 55 which details the schematic for the clock generator just as it is wired on the motherboard:

Clock Generator Schematic, ICS953201

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.

For the following experimentation, I used Read-Write Everything 1.4.7. Click the waveform icon for access to the clock generator.

Read Write Everything UI

Let’s take a look at the SMBus data again, this time in binary:

|   73    |   00    |   FF    |   FF    |   FF    |   08    |   F7    |   21    |   0F    |   07    |   00    |   CE    |   76    |   0E    |   30    |
|  7 | 3  |  0 | 0  |  F | F  |  F | F  |  F | F  |  0 | 8  |  F | 7  |  2 | 1  |  0 | F  |  0 | 7  |  0 | 0  |  C | E  |  7 | 6  |  0 | E  |  3 | 0  |
|0111|0011|0000|0000|1111|1111|1111|1111|1111|1111|0000|1000|1111|0111|0010|0001|0000|1111|0000|0111|0000|0000|1011|1110|0111|0110|0000|1110|0011|0000|

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:

FS[4:0]:= 01001 will give me a 202Mhz core clock, 101Mhz PCIExpress, 67.33Mhz AGP, and 33.67Mhz PCI.

I use CPU-Z to watch the clock rate and see if it changes.

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!

JBoss Seam and conversation boundaries

In the web site we are building we have a set of search pages to identify records, and a long list of CRUD pages for various aspects of those records. This section of the application looks and feels just as a standard web application, where as a user you are engaged in only one activity at a time and none of the business transactions you engage in span more than a single database transaction (unlike, say, a wizard).

Another section of the application works completely differently – it is a document editor that can edit complex structured documents associated with records in the system. This cries out for the ability to have multiple editors available, which is exactly the kind of thing that can be modeled by a Conversation in Seam .

Supporting the document editor feature we have several command buttons distributed throughout the application that allow you to add, edit, or view (in PDF form) these documents.  Once in a document editor, you can leave the editor, visiting the rest of the application, and resume it with a click of a button.

Implementing this turned out to be a little trickier than expected and required a solid understanding of conversation boundaries, or when a conversation comes into existence, and when it leaves.

Here are the key players in the architecture:

SeamEditorCD1

So the navigation flow is very simple – the user visits a search results page, and from there opens an editor. In between the visit to the search-results page and the editor being ready to use in the browser,  the various other components shown are accessed. I’ve explicitly omitted conversation boundaries from this diagram since there are so many ways to start and stop the conversation and it’s the core of what I want to talk about.

In the diagram, the component classes are omitted since they are irrelevant in Seam.

  • editorCollection: Keep track of conversations associated with specific documents.
  • search-results.xhtml: Display a list data items, each with action buttons.
  • editorActions: Contains the code backing the buttons in search-results.xhtml, acts on documents before they are being edited.
  • document: An entity instance of a document being edited or viewed
  • editorManager: Contains the code backing the buttons in editor.xhtml, allowing operations to be performed on a document while it is being edited.
  • editor.xhtml: The actual editor page – consists of a range of buttons to act on the document or to leave the editor, along with document specific widgets that allow data to be entered into the document.
  • pages.xml: This is the global Seam page configuration file, similar to faces-config.xml in JSF.

Navigation

pages.xml is the central piece that establishes navigation among pages in terms of responses to actions triggered by buttons on the page. A simple example might simply be:

[xml]<pages>
<page view-id="search-results.xhtml">
<navigation from-action="#{editorActions.edit(documentId)}">
<redirect view-id="editor.xhtml" />
</navigation>
</page>
</pages>[/xml]

This action would correspond to a link from search-results.xhtml:

[xhtml]<s:link action="#{editorActions.edit(documentId)}" />[/xhtml]

The from-action attribute in pages.xml is not executed – it simply identifies the operation that the navigation rule applies to by being the same exact string. When the link is clicked, the edit() function is executed, and the editor.xhtml view is loaded.

Starting a conversation

This navigation rule and the code listed so far does not actually start a conversation, which means that anything the edit() function does is going to do will act on the session as a whole (since it is a Seam SESSION component). So we have no segregation between document editor instances.

Ignoring the ability to declare that a conversation is required (that’s really just defensive coding, and who wants to see exception handling code?); there are three main places you can instruct Seam to start up a conversation:

* Java 1.5 Annotations provided by Seam (@Begin) on the components
* Attributes on s:link and s:button or tags applied to JSF components; all provided by the Seam UI tag library
* Within page rules in pages.xml using directives like

There are good reasons for using each, but the necessarily page and component spanning nature of conversations make the third option a good choice. The declarative features of pages.xml allow the start and end points of conversations to be placed in a single file, centralizing the lifetime of a conversation, while still allowing the option of implementing conditional navigation logic with EL expressions.

Document editor pages.xml with conversations

[xml]<pages>
<page view-id="search-results.xhtml">
<navigation from-action="#{editorActions.edit(documentId)}">
<start-conversation />
<redirect view-id="editor.xhtml" />
</navigation>
</page>
<page view-id="editor.xhtml">
<navigation from-action="#{editorManager.discard()}">
<end-conversation />
<redirect view-id="search-results.xhtml" />
</navigation>
</page>
</pages>[/xml]

This simple fragment easily shows the ability to cycle between the two pages, starting a conversation before being in the editor and ending a conversation when leaving.

Exactly when does a conversation come to exist?

Upon a click from the search results page, an action method on the editorActions component is invoked. Since the editorAction methods are working on any of the iterated search results, we need to pass the selected record to the action method.

This data is the documentId of the document being edited, (or equivalently the documentTypeId of the document being added). Using this parameter we retrieve from persistence all the data required to display and format the document. Obviously all this information needs to be scoped to the current conversation context in order for it to be segregated from other instances of editors.

Which poses the question: is the conversation context active when the editorActions.edit(documentId) method is executing? If the answer is yes, we should be able to place variables into the conversation context from within editorActions.edit(documentId).

Unfortunately for our system the answer is no, which means this code is bad:

[java]import org.jboss.seam.annotations.*;
import static org.jboss.seam.ScopeType.*;
@Name("editorActions") public class EditorActions {
@In(required = false)
Conversation conversation;
public void edit(int documentId)
{
assert conversation != null;
// record the conversation editor instance
}
}[/java]

We find that during this method, access to the conversation object is unavailable. The obvious inference is that there is no active Seam conversation at this time.

Now it is possible that the tag in pages.xml acts differently to placing an @Begin annotation on an action method. However, the following code acts no differently:

[java]@Begin public void edit(int documentId)
{
assert conversation != null;
// record the conversation editor instance
}[/java]

The problem, and neglected alternate approaches

Event with a conversation context in place, the code performs a significant amount of startup of other components that rely on Conversation scoped data, but because Seam manages outjection through interceptors around method calls, any @Out annotated variables will not actually be placed into the conversation scope until the method returns. So all those other components cannot perform the work they need to do in response to code in the editorActions.edit(documentId) action method.

The issue could be resolved by starting the conversation on one page, and redirecting the user to a temporary page in which a document is not yet loaded, but in which the Seam conversation is fully active. We have tried this approach before, but routing the user indirectly does not give the application the slick feel we are looking for.

One thing we tried when creating a workaround that would allow us to place the loaded document into the conversation context was to observe the built-in seam event that is fired when a new conversation is created. This turned out to be a complicated path to take because the component dealing with creating the document is in the SESSION scope, meaning that it synchronized by Seam to ensure that there are no concurrent accesses. This prevented our observer from interacting with the session scoped editorActions bean as the action method was already executing.

Establishing and populating a Seam conversation context in one go

What we finally tried and have discovered to work well is to access directly the Conversation context from within the editorAction.edit(documentId) method:

[java]public void edit(int documentId)
{
Document d = loadDocument(documentId);
Context conversationContext = Contexts.getConversationContext();
conversationContext.set("documentData", d);
d.activate();
}[/java]

The d.activate() function can access conversation scoped variables manually placed in the conversation context by this method, despite the conversation not having been fully created, and despite any outjections (@Out annotated variables) not having yet been processed.

This is inline with Seam’s published behaviour in which there is always a conversation context present, but that it is temporary unless it has been converted to a long running conversation.

Final Solution

In the end we opted to leverage the Seam @Begin annotation on the editorActions methods that trigger a switch to an editor.  In this manner we ensure the creation of a Conversation is co-located with the functionality that is so tightly coupled to it. We did not do the same for the end of the conversation, since there are various buttons and links on the editor that assist with leaving the page, not all of which have action methods associated with them.  In addition, we decided to sink exceptions and internally log and email them, and altered the action methods to return an outcome string. This allows us to conditionally return to the results page if an error occurs creating an editor and also be able to display an appropriate message. This works nicely with Richfaces/A4J .

The pages.xml now looks like this:

[xml]<pages>
<page view-id="search-results.xhtml">
<navigation from-action="#{editorActions.edit(documentId)}">
<rule if-outcome="success">
<redirect view-id="editor.xhtml" />
<rule>
<rule if-outcome="bad-template">
<message severity="ERROR">Failed to create the editor because template #{errorTemplate} is broken</message>
</rule>
</navigation>
</page>
<page view-id="editor.xhtml">
<navigation from-action="#{editorManager.discard()}">
<end-conversation />
<redirect view-id="search-results.xhtml" />
</navigation>
</page>
</pages>[/xml]

As was mentioned above, we also opted to create a separate editorCollection bean. This bean was necessary purely to avoid concurrent access to a single Seam component. When a conversation is created, this bean manages the process of figuring out a human readable name for the conversation for use in conversation switcher components (i.e., to switch editors).

More on concurrent access to conversation components

As I’ve noted, a SESSION scoped bean cannot be accessed concurrently. Really, no Seam component can be treated as re-entrant. Synchronization on SESSION components is provided to you by Seam because it is likely that a user may double click a link or otherwise trigger multiple concurrent requests. Seam components in lower scopes like PAGE and EVENT do not need synchronization since there will be multiple instances of them created to respond to each activity.

CONVERSATION scoped components are synchronized by Seam by locking the whole conversation while the request is ongoing. New requests for the same conversation are blocked for up to 500ms (configurable), and if the conversation is still not free, then Seam returns a message. In my experience, those web requests received a blank document.

This is critical to understand if you need to make back-end round-trip requests to the web server – you cannot use the same conversation for those. But that’s a topic for another time.