Friday, November 7, 2008

STAC Benchmark Results for Red Hat Enterprise MRG Realtime

STAC Research performs a number of third-party benchmarks for the financial community.  Recently, they performed a benchmark of RMDS on top of a system running Red Hat Enterprise MRG Realtime.  Our realtime offering enhances Red Hat Enterprise Linux with deterministic latency and performance for critical applications like RMDS.

The results of this test included:

- Lowest mean latency reported to date with RMDS
Less than 1ms mean latency at up to 700,000 updates per second
- Standard deviation of latency remained below 0.5 ms through 600,000 updates per second
- In the "Producer 50/50" fanout test of a multiplexed P2PS, total output was:
7.07M updates per second with jumbo frames (MTU = 9000 bytes)
5.56M updates per second with standard frames (MTU = 1500 bytes)
You can see the entire summary and report here.

QPid Welcomes a New Member

QPid is the upstream open source project led by Apache that Red Hat participates heavily in to help develop Red Hat Enterprise MRG and to provide AMQP in Fedora.  The initial QPid proposal was submitted by a Red Hat engineer to Apache, and the QPid community has grown significantly since then to include a large set of diverse participants.

Building on the recent announcement that it has joined the AMQP working group, Microsoft has now announced that it will be joining and contributing to the open source QPid project at Apache to build its AMQP implementation.  This is also great news for the open source world and a bold new step for Microsoft. 

As we previously highlighted, Microsoft adopting the open AMQP standard will enable a new wave of innovation and interoperability—especially between Linux and Windows.  Now that Microsoft will be working on development of AMQP software in open source, we expect this  to further enhance the interoperability between Linux and Windows—they will not only speak the same protocol but share the same open source code base for that communication, offering an opportunity for Microsoft to build its relationship with the open source community.

The  Advantages of Open Source
With Qpid’s new addition, there are several highlights to point out:

  • Open source provides a way for active contributors and community members to accelerate significantly the timeline in which vendors like Microsoft can provide an AMQP implementation.  By joining an established open source project, these such vendors are able to reap the benefits of all the engineering work that many of the leading messaging developers in the world have already done.  Now, these developers in the QPid project will also benefit from Microsoft's contributions.
  • There are strategic benefits in joining an open source community.  QPid is distributed under an Apache license.  So, a vendor could easily just take the QPid code base, fork it for internal use, and then proceed to build its own, proprietary AMQP implementation.  By joining the QPid project, Microsoft will not have total control over the direction of the code base beneath its products, and its engineers will have to earn their commit rights and status the same way that other QPid committers have.  Still, as companies like Red Hat have shown, building products collaboratively in the open source community leads to more rapid innovation and the opportunity to create better software.
  • There is value in the QPid community and implementation.  There are multiple open source projects that are implementing AMQP (this is great for making AMQP pervasive).  However, that Microsoft is joining QPid indicates that it sees significant value and leadership in QPid.  Indeed, QPid is the first open source project to achieve compliance with the latest version of AMQP (0-10).  QPid also has support for a wide variety of platforms, including .NET.  Indeed, Red Hat engineers have developed a native WCF-compliant .NET client for QPid.  Others in the community have contributed an Excel plugin for QPid and are driving the advancement of the QPid broker on Windows.
Red Hat welcomes new members to the QPid open source community to help
expand its technology and continue to create long-term benefits for the project, community and its members.  For more information, see here.

* Note: I have also published this blog at  You can see other MRG blog entries there at

Friday, October 24, 2008

AMQP and Fedora 10

I love AMQP, I love Fedora, and I love blog entries that list AMQP support as the number 1 feature of Fedora 10!

Welcome to AMQP, Microsoft

Today, Microsoft announced that it has joined the AMQP working group.  As a founding member of the AMQP working group, we at Red Hat are excited about this development.

Just as Red Hat has been adding native AMQP support into the Linux platform and ecosystem at Fedora and through Red Hat Enterprise MRG, Microsoft is bringing AMQP support to Windows and its ecosystem.  Between Linux and Windows, AMQP will become a standard messaging facility on the vast majority of operating systems and server platforms.  It will offer a new level of interoperability between Linux and Windows using open standards and open source software.  And, it is designed to lead to breakthroughs in everything from core infrastructure software to management tools to next-generation applications and architectures.   At Red Hat, we are already building upon our AMQP messaging implementation for everything from virtualization management to security management to monitoring.

Enabling Next-Generation Architectures
AMQP (Advanced Message Queuing Protocol) is the industry's first standard for messaging that spans from the wire-level to the semantics of messaging; it provides a full specification of an Internet Protocol for business messaging.  This is significant because before the arrival of AMQP, no two messaging implementations could natively interoperate with each other—even though messaging software's core mission is to distribute data across disparate systems.  Furthermore, with the rise of messaging-based architectures like SOA or EDA and the critical nature of messaging to many of today's networked applications, the lack of a standard in messaging is a major obstacle for integration and developing next-generation applications.

People used to have to purchase TCP/IP stacks until they became a standard facility in operating systems.  Once that happened, there was a tremendous leap forward in networking and networked applications, even though the technology was previously available.  The fact that everyone could now count on this same network protocol to be ubiquitous and interoperable meant that applications and architectures started depending and building upon this capability in ways that previously no one had envisioned.  The same thing happened with other standards, like http.  The same thing is happening with technologies like virtualization.  And, the same thing will happen in the messaging space via AMQP—in today's networked world, when developers can count on the prevalence of a common messaging protocol with authentication, security, reliability, and all the desired patterns like point-to-point, publish/subscribe, or eventing, they will unleash a new generation of applications and architectures that we have only begun to imagine.

Microsoft's joining AMQP and decision to integrate AMQP into its platforms, combined with the work that we have already been doing with AMQP at Red Hat and elsewhere, has made the fulfillment of AMQP's promise inevitable and quite exciting.  But, this does not diminish the contribution of others.  The AMQP working group already has a well-esteemed set of members, ranging from software vendors like Red Hat to hardware vendors like Cisco to end-users like JP Morgan Chase, Goldman Sachs, Credit Suisse, and Deutsche Börse (see the full list of participants at  Indeed, one of the unique hallmarks of the AMQP working group is that it started as an initiative at an end-user (JPMC) and has many other end-users contributing to the specification.  This ensures that AMQP is developing into a standard that solves and addresses significant real-world issues rather than just being a lowest-common denominator amongst various competing vendors.

Legal Note
Because this will be of concern to many people—particularly in the open source community—it is worth pointing out one of the legal ramifications of Microsoft joining AMQP.  There is a strong IP provision in the contract for joining the AMQP working group.  Anyone joining the AMQP working group must freely license IP that is used by AMQP—AMQP is and will always be an open standard that is free to implement.  By joining the AMQP working group, Microsoft has signed this contract.  So, there is no threat of Microsoft holding the AMQP standard hostage via patent threats.

* Note: I have also published this blog at  You can see other MRG blog entries there at

Sunday, September 21, 2008

High Performance on Wall St

I'll be at the High Performance on Wall St show tomorrow in NYC at the Roosevelt Hotel.  This should be an interesting show, despite (in part, because of?) the recent turmoil on Wall St--all the recent financial calamity isn't going to reduce financial service's need for computational power.

I'm going to be speaking on a panel at 4pm on "Building The Perfect Financial Services Data Center."  Red Hat has a booth (#102), where we'll be debuting publicly the new GUI Tools we've developed around Condor for Red Hat Enterprise MRG as well as showing off our integration between MRG and Amazon's EC2 Cloud.  Come check us out if you're at the show!

Friday, August 1, 2008

Can AMQP break IBM's MOM monopoly?

Jeff Gould at InteropSystems has written a great series of articles about the value and promise of AMQP.  Part 1 of the article is here: Can AMQP break IBM's MOM monopoly?  In part 2 of the series, Gould interviews Red Hat's Carl Trieloff, who talks about what we're doing with AMQP, JBoss and MRG.

Monday, June 23, 2008

Red Hat Enterprise MRG Presentations From the 2008 Red Hat Summit

I've posted online the presentations that we just did at the 2008 Red Hat Summit about Red Hat Enterprise MRG. You can download them at:

Thursday, June 19, 2008

Red Hat Enterprise MRG v1 is Released

Today marks the release of version 1 of Red Hat Enterprise MRG, our high performance distributed computing platform that integrates Messaging, Realtime, and Grid technologies. Red Hat has been working across each of these technologies for years, so we're excited to be launching the initial release at the Red Hat Summit.

We've got some pretty impressive performance results, customers, partners, and use cases for MRG. For details, see:

Additionally, if you happen to be at the Red Hat Summit, we're featuring MRG pretty prominently:
  • Our CEO, Jim Whitehurst, highlighted MRG Messaging and AMQP yesterday in his keynote as an example of a customer (JPMC) contributing to open source
  • Our CTO, Brian Stevens, featured MRG in this morning's keynote
  • We have several sessions on MRG
  • We are doing MRG demos at the Red Hat booth in the Expo Hall
  • Cisco is a sponsor at the Summit and is demonstrating their AON Message Bus Interconnect (MBI) solution. Cisco is debuting support for Red Hat Enterprise MRG Messaging in their AON MBI product at the Summit and demonstrating this in the Expo Hall.
  • IBM is a sponsor at the Summit and is demonstrating their WebSphere Real Time, which is an RTSJ-compliant realtime JVM. IBM supports WebSphere Real Time exclusively on Red Hat Enterprise MRG. They have also been a strong development partner with Red Hat around realtime, and they are a winner in this year's Red Hat Innovation Awards for this work. IBM is demonstrating WebSphere Real Time in the Expo Hall.
Congratulations to the entire MRG team for this fantastic release!

Monday, June 16, 2008

Red Hat Summit 2008 (and FUDCon!)

Tomorrow is the start of the 2008 Red Hat Summit in Boston. There are going to be several sessions related to Red Hat Enterprise MRG there:

  • Thursday 1:30pm: Realtime Linux: Who, What, When, Where and Why by Clark Williams. Clark is the tech lead for realtime at Red Hat, so he'll have a lot of good stuff to say about performance results, how we've developed realtime, what's happening in the open source community, what's planned for the future, and so on.
  • Thursday 4:00pm: Red Hat Enterprise MRG Overview by Carl Trieloff. Carl is the technical director and visionary behind MRG, so this will be a great opportunity to hear first-hand about the origins, successes, and benefits of MRG. Way back, I spent over a year working to get Carl into Red Hat to launch and drive our MRG initiatives. Now, after creating AMQP, starting new open source projects, bringing realtime to maturity, and signing our partnership with the University of Wisconsin around Condor, we are starting to see significant traction around MRG.
  • Friday 9:00am: Dynamic Grid Computing With Red Hat Enterprise MRG & Amazon EC2 by Bryan Che. That's me! I hope you can get up early enough to attend my session. I'll be presenting on the work we've been doing to enable dynamically provisioning grid capacity at Amazon EC2's cloud infrastructure right from your MRG Grid's Condor scheduler. This will enable enterprises to add capacity dynamically to existing data centers or even to provision entire grids on-demand in the cloud. Cloud computing is hot these days, and we are seeing a lot of customer interest in MRG's integration with EC2.
This week also marks the start of FUDCon 2008 in Boston. Matt Farrellee, who is our tech lead for Condor and MRG Grid, will be coming to town to help lead discussions on implementing Fedora Nightlife. Of course, I'll be there too.

Thursday, June 5, 2008

Fedora Nightlife Article on

There's a nice, detailed article about Fedora Nightlife on

Sunday, June 1, 2008

Fedora Nightlife and Energy Usage

Wow, lots of response to my blog post about Nightlife! It's great to see so much interest right at the start. There are a lot of questions, but many of the conversations around these should happen on the Fedora Nightlife mailing lists as they're not just for me to answer. Also, I've now created an initial Wiki page for Nightlife (, so a lot of information will ultimately go over there. I will, however, blog about some of the topics that have stirred more discussion.

I'll start with one of the questions that always seems to arise when people talk about harvesting idle computing capacity: energy usage. Specifically, isn't it a waste of energy to leave your computer running when you're not using it so that others can leverage it for distributed computation? This is a complex issue with a complicated answer: it sometimes is a waste of energy, but it doesn't have to be a waste and can even save energy in the long run.

Cycle harvesting is sometimes a waste of energy
Let's start with the obvious: harvesting idle computer capacity across many--perhaps millions--of computers can definitely waste energy. Computers that might otherwise have been turned off are now running at full power crunching data for projects that may not be useful. Furthermore, these computers won't all be fully utilized 100% of the time, so there will be many instances of computers running with nothing to do but waste energy. Yes, unfortunately, cycle harvesting can and often does waste energy.

Cycle harvesting doesn't have to be a waste of energy
Cycle harvesting can waste energy, but it doesn't have to do so. I hope that as we work on Nightlife, this will prove to be the case.

There are many worthwhile tasks which can only be accomplished by heavy computation. A lot of fundamental research today in biology or healthcare, for example, requires access to large computer grids. If you believe that this type of research is a worthy use of energy, then the issue of wasting energy becomes an engineering problem of utilization and efficiency. That is, there are certain tasks for which it is worthwhile to let others use your available computing power. As long as these tasks fully utilize your computer when it is idle and they do so in the most efficient manner, then they aren't really wasting energy. More concretely, what if finding a cure to cancer required a lot of computational modeling? Would it be a waste of energy if there was a good project devoted to harvesting idle capacity to find such a cure, and it did so in a way that fully utilized all the computers which were donating capacity in an efficient manner?

If the keys to preventing energy waste in cycle harvesting are utilization and efficiency for worthwhile projects, then this is a problem we can address for Nightlife in a variety of ways. For example, the Condor scheduler is highly adept at maximizing resources efficiently. Given enough tasks or projects, we should be able to use all the resources available to Nightlife efficiently. The challenges will come from finding enough good projects and work for which people can donate their computing capacity. As long as we've got a good queue of work, we should be able to ensure that all the computers donating to Nightlife are doing something worthwhile and not just sitting around.

There are also many things that we can do at Fedora to increase further our ability to utilize resources efficiently. For example, we could explore waking computers to execute tasks that the owners of those computers deem worthwhile; otherwise, those computers will be in a suspended or low/no-power mode. At Fedora, we can drive the Linux operating system to be much more efficient in how it uses power while doing computations. And, Fedora's patron, Red Hat, has strong relationships with and influence over major hardware manufacturers and customers of grids. As commercial enterprises also look at how to save energy while doing their own grid computations, we have an opportunity to lead the way in developing and demonstrating the best techniques for doing this in an earth-friendly way.

Cycle Harvesting Can Save Energy
Much of the work that would run on Fedora Nightlife is going to be computed one way or another. A project like Nightlife, however, can not only help speed these computations by providing additional processing power, it can also help save total energy usage in the long run.

If you've ever visited a large data center, then you know that the energy usage of of the individual computers in that data center is only a fraction of the total energy the data center consumes. When you put tens of thousands of computers together in a single room, then many other energy hogs come into play. Foremost is cooling--large data centers require massive amounts of redundant air conditioning systems to prevent the computers from overheating as they process in close proximity to each other. There are also many other devices that draw power: the numerous network switches and routers connecting the computers, all the devices that monitor the data center's health and security, the redundant power supplies that keep the data center operating in the event of a power failure, and so on.

If a project were to distribute its computations over many individual, geographically dispersed computers and didn't need to build out a large data center for all its work, then it would no longer have to use as large a cooling center or provide as much backup power or do any of the other energy-consuming things that putting so many computers close together requires. Instead, by distributing its work over a number of individual machines through Nightlife, a project could cut down on its total energy required per computation.

Another way that Nightlife can provide energy benefits over a dedicated data center is by avoiding a concentrated usage of power in a single geographic location. I once visited a large Internet company in a power crisis because its host city's power grid could provide it with no additional electricity to grow--the company had totally maxed out the available electricity to it. Even if Nightlife didn't save total energy usage but increased the amount of energy required per calculation (which, as I've argued above, it doesn't have to do), this could still provide a better overall environmental impact. Rather than concentrating all its energy use in one place, a project could distribute and amortize its energy impact across a much larger area by leveraging Nightlife.

You don't have to participate, but you can contribute
Finally, maybe you fundamentally believe that there is nothing worthwhile for running on a large computer grid--no matter how noble the task--because of the energy required for running a grid. That's fine--you don't have to donate capacity to Nightlife. But, pragmatically, you have to agree that people are going to compute certain things one way or another. At Fedora, we have a tremendous opportunity to improve the power usage of grid computing in general. So, even if you don't donate idle capacity to Nightlife, please consider helping Fedora as a whole become the most energy-efficient platform for computation.

Wednesday, May 28, 2008

Introducing Fedora Nightlife

I've recently started a new project at Fedora called Nightlife. Here's the text of the e-mail I sent to the newly-created Fedora Nightlife mailing list:

Fedora Nightlife is a new project for creating a Fedora community grid. People will be able to donate idle capacity from their own computers to an open, general-purpose Fedora-run grid for processing socially beneficial work and scientific research that requires access to large amounts of computing power. Given the large number of Fedora users, I hope that we will eventually be able to build a community grid of over a million nodes at Fedora. This will be a great example of the power of the Fedora community, give people new and meaningful ways to contribute to Fedora, advance the development of large-scale grid software, and lead to real benefits for the world.

Fedora Nightlife will leverage the Condor project, which was ( created and hosted by the University of Wisconsin Madison, for scheduling and harnessing donated computing power. Last year, Red Hat and the University of Wisconsin signed a strategic partnership around Condor. Part of this partnership entailed releasing Condor's source code under an OSI-approved open source license. As a result, we now have Condor packaged at Fedora, and upstream development continues to happen at the University of Wisconsin repository in an open manner.

Some of the immediate next steps for Fedora Nightlife are:
-create a Wiki page for this project
-get a Condor scheduler hosted at Fedora up and running
-work out what are the requirements for a project to be able to run on Fedora Nightlife (e.g. its software must be open source, it must be safe, it should have some kind of open policy around its results, etc)

We've already started working on getting a scheduler up and running. I
should have a wiki setup relatively soon so that we can start mapping out more plans there.

Then, we can focus on growing the Nightlife community of projects and
solicit Fedora users to donate capacity. Hopefully, enabling donation of compute power to Nightlife can eventually become a first-boot option for Fedora installs.

I welcome everyone to contribute to and participate in the Fedora
Nightlife project!
If you'd like to subscribe to the Fedora Nightlife mailing list, you can do so at

Fedora Nightlife is going to build on the work I do in my day job at Red Hat around Red Hat Enterprise MRG--it'll be based on the same technology we use for MRG's grid capabilities. This is great for me for a couple reasons: Fedora Nightlife will be a powerful and public example of the scale that's possible with Red Hat Enterprise MRG, and the work we do to drive Nightlife/Condor to the 1 million node count will directly benefit MRG. Also, it's great to be at a place like Red Hat where I can work on my product management job and do some good in the world at the same time.

Saturday, May 17, 2008

Creating a Wireless 3G Network Connection on Fedora 9 With a Novatel Ovation U727

One of my favourite features of Fedora 9 is NetworkManager's new support for wireless 3G modems. I just recently got a Novatel Ovation U727 EVDO Rev A USB Modem for Sprint's network because this modem explicitly supports Linux. Sprint provides instructions for using the U727 on Linux from its Web site. But, since Fedora 9 makes this process much easier, here is how to do it:

  1. Have your laptop always load the proper drivers for the modem by adding the following lines to /etc/rc.local:
    #load driver for Sprint Novatel u727 wireless modem
    rmmod usbserial
    modprobe -v usbserial vendor=0x1410 product=0x4100
  2. Insert your U727 into your laptop.

  3. The U727 has built-in flash storage for which Fedora will mount on your machine, launch a file browser, and show a link on your desktop. Close the file browser, and right-click the link to your flash storage and select to eject the device (note that unless you eject the flash storage, your modem won't work).

  4. Right-click on NetworkManager and select Edit Connections.

  5. Click on the Add button to create a new connection for your U727.
  6. Fill in the new dialog box with the name of your modem's connection and the number to dial. In my case, I named the connection Sprint Novatel U727. Type in #777 for the number to dial.

  7. Hit OK and then close the dialog box
  8. Now, click on NetworkManager, and you should see your new USB modem connection show up as a connection option.
  9. Select your new connection, and you'll be online!
Here are instructions for using your modem in the future now that it's setup:
  1. Insert your U727 into your laptop
  2. Eject the mounted flash storage device in your modem (unless you eject the flash storage, your modem won't work)
  3. Go to NetworkManager to select your U727 connection

I'm currently writing this post while online with my Sprint U727 modem. As a side-note, I selected Sprint's 3G service for mobile broadband even though I don't use Sprint for my cell phone service because Sprint has truly unlimited data usage (Verizon and AT&T cap at 5GB/month) with good terms of service (Verizon restricts things like streaming media), and its EVDO rev A network is fairly fast. Here are the results of a speed test that I just ran:

Update 5/19/2008:

Sprint is updating its Terms of Service to cap data usage at 5GB/month too. Given that, I will likely switch from Sprint to Verizon, which I prefer for cell phone service. Verizon also sells a U727 modem, so these instructions will work for Verizon too

Wednesday, March 12, 2008

JBoss Developer Studio For Mac OS Now Available

Hi, I'm happy to announce that JBoss Developer Studio for Mac OS is now available. So, now you can get all the benefits of fantastic certified tools and an integrated JBoss Enterprise Application Platform with native Mac support. Many JBoss developers use Macs, and we know that many in our community use Macs, so we're excited to make this available. And, of course, if you're a Windows or Linux user, JBoss Developer Studio has been available for those platforms as well.

You can get JBoss Developer Studio for Mac OS from

Note that right now, due to an issue in Eclipse, we are only supporting JBoss Developer Studio on Mac OS Tiger 10.4.x and earlier right now. There is a workaround available for Leopard, but this isn't a supported configuration. We'll add formal Leopard support in our next update.