PT-Logo
Forgot your password?
BenchmarkXPRT Blog banner

Category: HDXPRT Development Community benefits

As we get close to the release

As we get close to the release of HDXPRT 2012, I wanted to let you know how it compares with the original design specification. You’ll find the complete list of differences below.

In any software project, there are differences between the original design and the final product. Generally, things have stayed pretty close with HDXPRT 2012. A number of these changes were discussed on the HDXPRT blog. We’ve noted in parentheses the title and date of the relevant blog entry.

We’re looking forward to the release of HDXPRT2012. We can’t wait to hear what you do with it!

Eric

  • HDXPRT does not support 32-bit operating systems. (“Bye, bye 32 bits?” March 2, 2011)
  • Because of difficulties with scripting, Picassa is not part of HDXPRT 2012. (“Change is inevitable,” April 27, 2012)
  • Audacity 2.0 with Windows 7 debuted after we released the design document, so we are using that version rather than Audacity 1.3.14beta in HDXPRT 2012. (“Change is inevitable,” April 27, 2012)
  • We removed the video playback tests from HDXPRT 2012. (“More HDXPRT 2012 changes,” May 11, 2012) Consequently, Adobe Flash Player 11, which was only used in the playback tests, is not part of HDXPRT 2012.
  • Simplified Chinese is not supported.
  • The specs for the calibration system are below. The design spec had recommended changing to Intel Pentium G860.
    • Processor: Intel E6800, 3.3 GHz
    • Graphics:  Intel G45 Express Chipset
    • Memory: 4 GB
    • Hard disk: 1 TB HDD
    • OS: Windows 7 Ultimate Service Pack 1
  • During testing, we were able to reduce the minimum requirements from those in the Design Document. The current minimum requirements are as follows:
  • Processor: Intel dual-core 2.0GHz processor or equivalent
  • Memory: 2 GB
  • Free disk space: 40 GB
  • Video display settings: 1,024 x 768, 24-bit color
  • DVD ROM to install HDXPRT
  • Microsoft Windows 7, 64-bit (Language: US English)

Comment on this post in the forums

Keep them coming

At the beginning of June we mailed out the HDXPRT 2012 beta to the members of the Development community. This has been an exciting week, as the feedback has started coming in. We want to thank everyone who’s been using the benchmark.

We really appreciate the results you’ve been sending. Obviously, we can’t test every possible configuration in our lab, and it’s very reassuring to see good results coming from configurations we haven’t tried.

Of course it is a beta, and there are still wrinkles to iron out. The error logs we’ve been getting may not be gratifying, but they are enormously helpful. The more problems we see now, the better we can make the release version of HDXPRT 2012.

One of our members asked about the terms of use for HDXPRT 2012. For the final version, the terms will be the same as for HDXPRT 2011—it is free for download and you are free to publish results.  The beta, however, is only available to community members. You cannot publish the results from the beta because things could still change. (If you haven’t joined the community yet, click this link <a href=”http://hdxprt.com/includes/join_us_2.php”>Register for HDXPRT</a>)

If you have questions, please do send them. We’ll get you an answer, and post the answers on the forum.

The comment period ends June 29th, so there’s still a week left. Please send compliments, complaints, results, errors—anything you think would make for a better benchmark. We take every comment seriously, and appreciate them more than we can say.

Eric

Comment on this post in the forums

Back to the future of source code

Today I’m spending a good chunk of the day participating in a panel discussion on the Kermit file transfer protocol as part of an oral history project with the Computer History Museum. A little over 30 years ago, I worked at Columbia University on the original versions of Kermit. In preparing for the panel discussions, I’ve been thinking about projects with available source code, like Kermit and HDXPRT.

Kermit was a protocol and set of programs for moving files before the Internet. We designed Kermit to work between a wide variety of computers—from IBM mainframes to DEC minicomputers to CP/M microcomputers. As such, we wrote the code to accommodate the lowest common denominator and assume as little as possible. That meant we could not assume that the computers all used ASCII characters (IBM mainframes used EBCDIC), that 8-bit characters would transmit over a phone line, or that packets of more than 100 characters were possible (DEC-20 computers specifically had an issue with that). The pair of Kermit programs negotiated what was possible at the beginning of a session and were able to work, often in situations where nothing else would.

We developed Kermit before the open-source movement or Gnu. We just had the simple notion that the more people who had access to Kermit, the better. Because we did not want incompatible versions of Kermit or the code to be used for the wrong purposes, we retained control (via copyright) while allowing others to use the code to create their own versions. We also encouraged them to share their code back with us so that we could then share it with others. In this way, Kermit grew to support all sorts of computers, in just about every corner of the planet as well as outer space.

In many ways, what we are doing with HDXPRT and its source code is similar. We are working to create a community of interested people who will work together to improve the product. Our hope is that by having the HDXPRT source code available to the Development Community, it will encourage openness, foster collaboration, and spark innovation.

I believe that what made Kermit successful was not so much the design as it was the community. I’m hoping that through the Development Community here, we can make just as successful HDXPRT, TouchXPRT, and who knows what else in the future. If you have not already joined, please do—the more folks we have, the better the community and its resulting benchmarks will be. Thanks!

Bill

Comment on this post in the forums

Tentative TouchXPRT plan and schedule

Since the beginning of the year and especially in the last couple of weeks, I’ve been discussing in the blog our thoughts on what should be in TouchXPRT. Based on those thoughts and on feedback we’ve gotten, we are working on scenarios, apps, and workloads for two of the seven possible roles I mentioned in an earlier blog—consuming and manipulating media and browsing the Web. These seemed like two of the more important and common roles and ones where performance might have a noticeable impact.

For the consuming and manipulating media portion, we are working on building a limited app (or apps) that can do some of the functions in the scenario I described in last week’s blog. We’re also working on the necessary content (photos, videos, and sound clips) for TouchXPRT to manipulate and show using the app(s). For the Web browsing role, we are putting together Web pages and HTML5 that emulate sites and applications on the Web.

The goal is to release both of these roles as the first Community Build (CB1) of TouchXPRT by the end of April. As the name implies, CB1 will be available only to members of the Development Community. If you have not joined the Development Community, hopefully TouchXPRT CB1 will give you some additional incentive!

Once we have CB1 ready to release to the community, we will need your help with debugging, results gathering, and general critiquing. As always, thanks in advance for whatever help you are able to offer.

Bill

Comment on this post in the forums

Quick HDXPRT 2012 status update

Between talking about CES, the new touch benchmark, and sausage making, it seems like it’ has been a while since I’ve said anything about HDXPRT. Here’ is a quick status update. The short form is that folks are heads- down coding, debugging, and testing. We still have some significant hurdles to overcome, such as trying to script Picassa. We also are going to have to make some difficult decisions in the near future about possibly swapping out one or two of the applications due to either licensing or scripting issues. (Sausage making at its best!) We’ll keep you posted in the forums when we have to make those decisions.

There is still a lot to get done, but things still appear to be on schedule. That schedule means that we are still hoping to have a beta version available for the Development Community to test in late March. At that point, the beta version will be available to our members and we will really need your help to try and shake things out. (Join at http://hdxprt.com/forum/register.php if you are not yet a member of the Development Community and want to help in our effort.) The more different systems and configurations we can all test together, the better the benchmark will be. There will also be at least some time for feedback on whether HDXPRT 2012 matches the design specification and if there are any last- minute tweaks you think would help make for a better benchmark.

So, stay tuned! We look forward to continuing to work with you on making HDXPRT 2012 even better than the current version.

Bill

Comment on this post in the forums

Art or sausage?

I discussed in my previous blog how weighing the tradeoffs between real science and real world in benchmark is a real art. One person felt it was more akin to sausage making than art! In truth, I have made that comparison myself.

That, of course, got me thinking. Is the process of creating a benchmark like that of creating sausage? With sausage, the feeling is that if you knew what went into sausage, you probably wouldn’t eat it. That may well be true, but I would still like to know that someone was inspecting the sausage factory. Sausage that contains strange animal parts is one thing, but sausage containing E. coli is another.

We are trying with the Development Community to use transparency to create better benchmarks. My feeling is that the more inspectors (members) there are, the better the benchmark will be. At least to me, unlike making sausage, creating benchmarks is actually cool. (There are probably sausage artisans who feel the same way about sausage.)

What do you think? Would you prefer to know what goes into making a benchmark? We hope so and hope that is why you are a part of this community. If you are not part of the Development Community, we encourage you to join at http://hdxprt.com/forum/register.php. Come join us in the sausage-making art house!

Bill

Comment on this post in the forums

Check out the other XPRTs: