The most important portion of the source contains what I call the Intel AMT Remote Stack. It's all the code needed to build a console application. Basically, I started by generating C# web services classes from the Intel AMT SDK and built wrapper classes around each of the web services interfaces. The wrapper classes perform two important functions: They abstract the web services interface into higher level objects, and provide selective caching to boost performance.

The other portion that is released in source code form is a fully working VT100/ANSI terminal for use with Serial-over-LAN. It contains the VT100 state machine and all the code needed to actually draw each character on the screen correctly. This is quite a big deal since developers can customize this terminal code to integrate well within an existing application.

The source code provides C# wrapper classes around the 3rd Party Storage library and Redirection Libraries. Just for that, I expect many developers to jump on downloading this new package. You can use these wrapper classes to easily build a Microsoft .NET application that does IDE redirection to Intel AMT.

There is plenty more in there, like the classes I built to perform TCP-over-Serial-over-LAN, a feature that is most likely unique to the DTK.

Ylian

Hardware Evolution

Throughout the history of modern computing, enterprise application developers have been able to rely on new hardware to deliver significant performance improvements while actually reducing costs at the same time. Unfortunately, increasing difficulty with heat and power consumption along with the limits imposed by quantum physics has made this progression increasingly less feasible.

There is good news. Hardware vendors recognized this several years ago, and have introduced multi-core hardware architectures as a strategy for continuing to increase computing power without having to make ever smaller circuits.

Sounds Good, So What's the Dilemma?

The "dilemma" is this: a large percentage of mission-critical enterprise applications will not "automagically" run faster on multi-core servers. In fact, many will actually run slower.

There are two main reasons for this:

1. The clock speed for each "core" in the processor is slower than previous generations. This is done primarily to manage power consumption and heat dissipation. For example, a processor with a single core from a few years ago that ran at 3.0 Ghz is being replaced with a dual or quad-core processor with each core running in the neighborhood of 2.6 Ghz. More total processing power, but each one is a bit slower.

1. Most enterprise applications are not programmed to be multi-threaded. A single-threaded application cannot take advantage of the additional cores in the multi-core processor without sacrificing ordered processing. The result is idle processing time on the additional cores. Multi-threaded software should do better, but many people are finding that their multi-threaded code behaves differently in a multi-core environment than it did on a single core, so even these should be tested.

Won't my application server or operating system take care of this for me?

One of the key considerations here is the order of processing. A single threaded application that needs to ensure that A happens before B cannot run multiple instances concurrently on multiple cores and still ensure a particular order.

Application servers and operating systems are generally multi-threaded themselves, but unfortunately their multi-threaded nature does not necessarily extend to the applications that run on them. The app server and OS don't know what the proper order is for your particular business logic unless you write code to tell them. In fact, they are designed to simply process any thread as soon as possible, potentially disastrous in a business application. SMP (symmetric multiprocessing) has similar limitations.

So we are back to the same problem -- how to run multiple instances concurrently on multiple cores and still ensure a particular order.

Intel's 45nm announcement

Intel recently announced that they will have chips in the near future with 45nm features, a significant advance from the 60-65nm that is prevalent today. The company has also made it clear that this is not reducing the need for multi-core.

Around the same time as this announcement, Intel announced that they have an 80 core processor in the works. Power and heat will have to be addressed for a processor with 80 cores to come to market. So 45nm may mean some increase in clock speeds for future processors, but its primary use will be enablement of a higher number of cores.

Concurrent Computing

There is no easy solution, but there are several options, and they all involve bringing concurrency to your software. Concurrent computing (or parallel programming, as many refer to it) is likely to be a very hot topic in the coming years, so it's a good idea to start preparing now.

Since multi-core servers already make up most of the new servers shipments, concurrent computing in the enterprise will quickly become a way of life. So we need to put some thought into two things: how to make existing applications run concurrently, and how to build new systems for concurrency.

More people are talking now than any time in recent memory about how to do multi-threaded software development as the primary answer to concurrency. However, instead of writing our application code to be multi-threaded, we should consider how to abstract threading out of application code. Multi-threaded code is difficult to write and difficult to test, which is why many people have avoided it in the first place.

At Rogue Wave Software we have been working for several years in the area of "Software Pipelines". Software Pipelines* is an approach that can be used to abstract the threading model out of the application code. As software developers, you would not mix your UI code with your business logic, and for good reasons. A similar principle should apply for programming for concurrency -- the threading model should not be driven from within the application logic.

There are several important benefits to this approach. Removing threading from application code means:· The application developer doesn't have to own the threading model· Existing applications can move into a concurrent environment with much less effort· Makes it easier to scale to additional computing resources without modifying the application· If done right, the application can continually be tuned for performance without modifying application code

This approach does not allow the application developer to wash their hands entirely of concurrency. Application code needs to be written to be thread-aware, but does not need to have threads written into it. For more information on Software Pipelines, you can read this white paper (you have to log in to webservices.org to download it).

Consider how to abstract your threading model from your application logic, and you may find a smoother (concurrent) path ahead.

* Software Pipelines is a general term, not owned or trademarked by Rogue Wave or anyone as far as I'm aware. It also does not require the use of any of our technology. Software Pipelines borrows conceptually from hardware pipelines and also from fluid dynamics, which has interesting parallels to software systems.

Scalability is a (comparative) quality of an application and its execution profile in the face of changing resources (both more and less). There is no unit of measure for scalability, much like there is no unit of measure for greenness (a leaf is more green than a twig). Speedup is the ratio of serial execution time to parallel execution time (for a given number of threads/processes and cores). It is a dimensionless number and usually expressed as a percentage or a multiplier (e.g., 2X). (Other examples of dimensionless numbers include albedo, Reynolds number, drag coefficient, and Weaver flame speed number.) 

An application is considered to be more scalable the longer (or closer) it can maintain a fixed relationship with linear speedup as the number of cores and threads increases.  We can say App_A is more scalable than App_B if App_A has higher speedup beyond some number of cores/threads.  But, we don't say App_A has 2.8 fleginites more scalability than App_B.

As you read through some of the papers and articles collected in the Intel Software Network, you may find the term "scalability" used in place of "speedup." I can only think that the reason for this is becasue the former term is sexier than the former. (Even so, I'm sure Ricardo Montalban would use them correctly, if he ever has occasion to do so.) Please, let me apologize in advance for this word misuse. I'm trying to educate my colleagues here at Intel and abroad. Won't you help by using the proper term in the proper context? My biscuits thank you.

In the console tool, there are many improvements. Probably the best one is the addition of TLS support, which is useful if you going to use the setup and configuration tool above to setup machines with TLS. The terminal window that is within the console tool now supports two different emulation modes: "VT100/UTF-8" and "ANSI/Extended-ASCII". The default is set to ANSI mode. This mode will display all of the old-style 256 extended-characters correctly. These characters are often used to make menus and visuals look good in text mode. I have noticed the HP vPro machines make use of these characters if you put the BIOS in "ANSI" mode. Many text applications look much better in this mode. The UTF-8 mode is there, but I don't have any BIOS what sends UTF-8, so, I can't test this mode yet.

Like the console tool, the Intel AMT agent tool now has TLS support; it also has improved serial agent command for shutting down the machine and more. One new command that now works correctly is the "HWRESCAN" command. It forced Microsoft Windows on the AMT machine to rescan its plug-and-play devices. If you start an IDE-R session, you can type this command that the redirected drives will pop-up in Windows.

Ylian