TNC: Robert Collins, welcome to the show.

RC: It's a pleasure to be here.

TNC: Let's first talk about your site. You're the curator of x86.org.

RC: Yes. That's the URL for the site. The formal name is "Intel Secrets: What Intel Does Not Want You to Know".

TNC: The site has been really controversial with Intel. You had to change the name and the logo --

RC: It's been up and down. Yes, the site is very controversial. Inside of Intel, they have disputed everything from the name of the site to the logo of the site. We got into a heated dispute over the logo.

TNC: I noticed the dropped e in Intel is backwards.

RC: Yes. They did not appreciate that.

TNC: They spent millions of dollars developing the Intel Inside ad program, and then you come along and just invert the e.

RC: Make fun of it, right?

TNC: And they're a multi-billion dollar company and you are yourself.

RC: That's right.

TNC: Just the power of the individual the Internet brings.

TNC: One of the things I also noticed about the site, one of the little details concerning the site, is that you have a best graphic of the week or month.

RC: Yes. I call it the Intel Art of the Month.

TNC: I just urge everyone to check that out, because there's some really interesting things.

Another thing, and this is just another funny detail, is that your daughter on the site?

RC: Yes, it is.

TNC: Now, clicking the picture of your daughter brings us to a cyber safari awards program.

RC: Yes. They enlisted me to be part of what's called the cyber safari. That was a one-month adventure where people could go around the Internet and find different clues. It was kind of like, I think, a cyber whodunit. And if you collected all of these clues, then you were eligible for prizes.

And they asked me to hide my clue somewhere in my Web site, preferably on the front page, and that was where I chose it on my site, was the picture of my daughter.

TNC: And it's still there.

RC: Yes. I haven't disabled it.

TNC: Now, seriously, Robert, your site is a resource for developers and Intel watchers. The reason it's so valuable is that it provides information that Intel either doesn't want to be readily available or is not quick to document.

RC: That's correct. I try to specialize on both areas, areas where Intel has not been forthcoming in documenting things. I mean, there's many details of their microprocessors that just aren't known by the public, everything from undocumented instructions to tricks in programming that can actually make an engineer a more productive person.

The other side that I try to, I try to point out flaws in their documentation. Because it's my assertion inaccurate documentation is collectively wasting engineers hundreds of man hours worth of time, if not thousands of man hours of time, every year. This is a result of just relying on the documentation, writing programs based on the documentation, and then debugging them, only to find out that the documentation led them astray.

So those are some of the two primary focuses of the Web site.

TNC: You were actually called in at one point by Intel to evaluate some of their documentation?

RC: Yes, a publisher sent me advance copies of an Intel manual and asked me if I would proof read it. And I did.

I found, you know, that there were still numerous things missing and mistakes in the manual. And I, you know, I did my part to the publisher and pointed all those things out in hopes that Intel would correct them.

I have no idea what the name of the manual was going to be that I was proofreading, because it wasn't exactly provided, you know, with a cover sheet or anything. But I can tell you that the latest version of the manuals have not been fixed.

TNC: Obviously, they paid you for the service.

RC: Yes, it was like 500 bucks or something like that.

TNC: People are going to try to reverse engineer these undocumented, or mis-documented, features. Eventually they are going to be documented, incorrectly in some cases. There will also be a lot of time lost trying to reverse engineer these features.

RC: That's correct. But the people that are going to be reverse engineering them are primarily Intel's competitors. And the reason they do that, obviously, is because they need to provide compatibility in those areas of their microprocessors.

It's unknown how many engineers actually would use undocumented features or undocumented instructions in any of their codes. Personally, I would not do it. I use them primarily for interest purposes. There are times when I put undocumented instructions in my own personal code because it helps me debug my code.

There's hooks in some of these undocumented instructions that actually allow you to debug your code much more effectively. And that's where I use it personally.

TNC: Can you give us an example here?

RC: Yes. There's an instruction called the IBP, or ice break point instruction. And if you have an in-circuit emulator, a $10,000 tool that helps you debug things at the lowest level of the microprocessor. simply inserting this instruction in your code somewhere will cause the ice to halt.

Now, what are your choices if you didn't have this instruction? If you didn't have this instruction, then what you would have to do is, let's say you wrote a program and you need to break and examine your code at the entrance to routine XYZ. You've got to compile it, you've got to break out your map files, you've got to figure out where DOS or where Windows loaded it in memory. Then you've got to set a break point on your ice corresponding to that memory location.

That's a very time consuming task. I'd say it probably takes between five and ten minutes each time you need to do that. And that's just, you know, to break at the entrance to routine XYZ.

If you just simply insert this instruction at the beginning of that routine, then the ice will automatically break for you. And it just makes you much more productive as an engineer.

TNC: Now, putting aside mistakes in the documentation, doesn't Intel have a right to withhold documentation on some features, if they want to?

RC: It depends on, when you say withhold documentation. First of all, when it comes to undocumented details, yes, I believe they absolutely have a right to withhold whatever information they want and deem it proprietary information.

But, on the other hand, they cannot fault sites like mine for choosing to document it. I recognize that it's their right to leave it undocumented, but then, on the other hand, as long as I'm not breaking any laws, I believe that I would have a right to document it. So, yes, I do believe that they have that choice.

When it comes to information that they intentionally withhold so that -- and this is where we get into a little bit of a gray area on this very subject -- there are cases where they intentionally withhold information that is invaluable to the engineering community.

I have, even though they may call it proprietary, I have a really hard time with their choice, with their decision to leave that not documented, because it withholds information from the engineering community.

There are classes of engineers and there are classes of developers out there that cannot get, for one reason or another, cannot get the non-disclosure agreement from Intel to use those advance features. And if Intel won't give them a non-disclosure agreement, then Intel is selectively choosing who can competitively, who can compete in this market and who cannot compete in this market. And that gives certain developers an unfair market advantage.

And so, for that reason, I would disagree with many of the decisions that they have to leave things undocumented.

TNC: What is the state, what is the current state of your relations with Intel, and is their documentation getting better? Has there been effort on their part as a result of your own efforts?

RC: I have pointed out documentation errors to them many times. And those changes are those corrections do work their way into their manuals. I've seen at least half a dozen corrections that I've made to them that work their way into their manuals.

So, yes, their documentation is getting better. However, it is still sorely lacking in its quality. And one of the reasons why it's so lacking in its quality is because they have college interns writing this. They've acknowledged this to me. They've said, "Hey, Robert, give us a break. We just have interns writing this."

And, you know, what I say is, when you have something as important as a manual that 86 percent of the computing world needs to depend on, you know, to do their development, then you can't afford to have college interns writing it and not have it go through some rigorous peer review process.

TNC: Nothing against college interns.

RC: Nothing against college interns.

TNC: Oh, you mean Monica was working on this? That explains a lot.

RC: But there has to be some kind of valid and rigorous peer review process for the documentation.

As far as my relationship with them goes, it's a love-hate relationship. You know, there are times when we do communicate and I sometimes do give them a heads up and say, hey, look, I'm going to document a bug in your processor this month. Here's maybe an advance warning of what it is.

Or maybe I won't be so forthcoming and I'll say, "Hey, look. I've got some bugs. I really can't tell you what they are right now because, you know, maybe somebody else told me about it and I gave them my oath not to tell. But just be aware that something's going to happen."

But we do occasionally talk.

TNC: Intel Secrets, the site, is something of a crusade.

Take us a little back in time and give us some of the background of the origins of this site. When did you start doing this and how did you come about it?

RC: I started the site in July 1995, and it's not going to be nearly as glamorous as many people might think. It pretty much started when -- I had been disconnected from the Internet for about three years. And during that three-year absence the World Wide Web was created.

TNC: Where were you, Robert?

RC: Well, I was actually here in Silicon Valley, but I was working for a company that didn't have an Internet access.

So when I went to work, I went to work at Texas Instruments out in Dallas, and they had access to the Internet, of course, and so I started perusing the Internet for things that interested me. And naturally I gravitated on things about undocumented processor details.

And during that time I started noticing Web sites that had many things about processor details and if we back up to about 1990, I had reverse engineered just a ton of stuff about Intel processors and collected that research into one big document that I maintained.

And occasionally, during those three years that I was off of the Internet, people would send me e-mail and say, hey, do you have an answer to this. And I would send them that whole book of research.

Now let's fast forward back to TI again. I get out on the Internet and I start seeing what appeared to be bits and pieces of that research. And none of it was with any attribution to me whatsoever.

And then the straw -- and, you know, I'm thinking, gosh, this isn't right. And then the straw that broke the camel's back is, I opened up a guy's book one day and it had one of the undocumented instructions that I had discovered, it had a description of it. And in my own description I realized I had made a mistake in how I had described it, and this book had the same mistake.

TNC: This is similar to Microsoft writing their TCP stack after the original UNIX stack, and the same bugs that are in that Berkeley sockets implementation are in the Microsoft implementation.

RC: Right, it would be a similar situation.

So at that point I decided, you know what, I need to take credit for my own work. People are writing books, people are starting Web sites. And they're basing it on what I felt was my work and I wanted to take credit for it.

So I needed to do two things. I needed to convert all my stuff to HTML and I needed to create a name. And I wanted the name to evoke a particular response and be representative of the type of information that you would find at the site. I also intentionally wanted the name to cause a neck jerk response so you provoked just by the controversy of the name to come look at the site.

I'm not a marketing guy, but at least I had that much marketing savvy.

TNC: Once I typed x86.com by mistake. And there is another site that looks suspiciously like yours.

RC: Yes. I've seen that site.

TNC: Is that an imitator?

RC: You know, I kind of thought that it might be somebody run by Intel. But it's out of New Hampshire or something like that.

TNC: Somebody's farm.

RC: And last time I was there, it didn't really have any content in it at all. It just said, oh, top secret. But there's no links there that you can click on. And I'm at the site right now and it's still the same thing.

TNC: You're right. None of these images are links.

RC: Nothing's there.

TNC: It's just basically somebody capitalizing on the name.

RC: Could be.

TNC: Now, let's talk about some of Intel's reactions to some of the more notorious Pentium bugs that were discovered throughout the the last few years.

How has Intel reacted to these bugs, reports?

RC: Well, starting with the FDIV bug, you know, that's the most famous case. Obviously, they reacted very poorly to it.

Personally, I thought the FDIV bug was no big deal. In many ways, technically speaking, I was on Intel's side on that. In fact, to exemplify that fact, I have not even traded in my own Pentium processor for one that's been fixed.

TNC: Because it was such a rarely occurring problem.

RC: That's correct. But where Intel went awry is when they took this really arrogant attitude that said, hey, look, you know, if you think that you're affected by it, then you need to prove it to us before we'll replace your chip.

Well, that was obviously a marketing blunder, you know, to take that type of attitude. So that's really kind of where they went, where they went awry.

The next big bug that came out actually was another floating point bug. This is one that I reported at my Web site and it was in the Pentium II processor. And I reported this bug about five days before the Pentium II was even announced. And it was pure coincidence, the timing of the thing was pure coincidence, but I had managed to get a Pentium II some six weeks before it was released.

Now, Intel handled that bug completely different from the way they handled the FDIV bug. You know, they put a task force on it. I mean, I heard stories that some people were working close to 48 hours without going home. And, you know, they put close to 100 engineers on it and wanted to characterize it and wanted to get something out to the public as quickly as possible.

Now, where they still played the marketing hype with this business, with this Pentium II math bug, was they intentionally didn't disclose anything they knew about it until after the stock market closed on Friday.

Now, you know, I mean, it's very significant that they do this, because over the weekend the whole story is going to get lost. The stock market is not going to be affected come Monday morning, because come Monday morning everyone will have forgotten about the bug. When they waited until the markets closed before announcing it, it turned out that the bug was actually much more severe than I had even thought it was. I had only discovered a handful of cases where this bug manifested itself. And in Intel's full disclosure, which came, like I said, after the market closed on that Friday, it turned out that the bug was much more severe.

Now, does that mean that many people's programs are going to be affected by it? No, it doesn't. It just meant that the cases in which this bug would manifest itself was an order of magnitude greater than I had discovered.

TNC: Just to recap, this is the Pentium II chip.

RC: Yes. We called it, at my Web site I called it the Dan 0411 bug. And it was named after a guy named Dan and the 0411 was the date he reported it to me. So we thought we'd kind of play this astrology discovery game with it.

TNC: Like naming stars. And what were some of the side effects of the bug?

RC: When you tried to do a floating point store on an integer that was too big, or I should say on a number that was too big to be represented in an integer format, all Pentiums are supposed to raise an exception and give a bit in the status word that says that this error condition occurred.

In this case, however, no exception was raised and the bit was not set, either. So the program could happily go along and never know that this error ever occurred, which could ultimately lead to data corruption. They never recalled the chip on this one. But they did provide a fix. They provided numerous software work arounds for the various compiler writers and OS people. But they eventually fixed it in the silicon itself.

TNC: Before we get to your article, there's been some Intel news this week. Specifically they announced some marketing strategies. And I guess the key word here is segmentation.

RC: Yes. Their marketing strategy is, you have to understand it's brilliant, it's genius, it's dirty, it's all of those things.

TNC: Basically what they're doing is presenting several lines of processors, each suited to different tasks and price ranges, something quite different from their previous marketing strategies.

RC: Right. I believe that they were completely caught off guard by the success of the $1,000 P.C. I've been saying for at least a year and a half or so that if the public ever figured out that they don't need the ever faster Intel processor, then Intel's market plan, their strategy is toast. Because Intel has pretty much based their market strategy on the premise that they can convince you, the consumer, that you need the ever faster and faster processor.

And the way that they've tried to accomplish that is by putting more and more burden, more and more software burden into the microprocessor. You've seen initiatives from their native signal processor. You see soft modems, soft DVD. In fact, in one of the articles that I read quoting Patrick Gelsinger, Intel's vice president, he says, "Soft modem, soft DVD and soft audio. Most of these technologies will start appearing in products in a year, with broad availability."

He's talking about incorporating all of these things that are now done in hardware into software. And what this does is, this puts the burden on the microprocessor, so that your microprocessor actually becomes a bottlenecking system. And then they can sell you that ever faster processor.

TNC: This is also a point that you address in the article, as well, as that with peripherals you can actually increase the performance of your computer without spending more money on the ever faster chip.

RC: That's correct. And the peripherals are much more cost effective than going out and buying a new computer system every six to 18 months. They need to kill off the socket seven. Because once they kill off socket seven, then that's going to make it very difficult for the mother board manufacturers to make a choice, "Do we support Intel or do we keep supporting the AMDs and the Cyrix's, which are using the socket seven?"

So Intel desperately needs to kill off socket seven. So that's why they're coming out with this processor called Covington, which is, it's a slot one processor.

TNC: This is the so-called kludgy processor.

RC: Yes, it's a kludgy processor that has no second level cache in it. It's going to perform like garbage, but it's going to go into the sub-thousand dollar PC, the PC that caught Intel completely by surprise.

TNC: You refer to this as a wimpified Pentium II.

RC: That's correct. It's a wimpified Pentium II.

TNC: Don't hold back, Robert. Just say what you feel.

RC: Then in the middle range, you're going to see the standard Pentium II processor, and then at the upper end you're going to see this thing called Katmai, which is going to have the MMX2 instruction set on it and all of these video enhancements.

Actually, that's probably going to be more middle range also, the Katmai processor. Then at the upper end you're going to see this thing called Slot 2. It's going to be real high speed. It's going to have 100 MHz bus.

Now, there's one thing very interesting about their decision to kill off socket seven. If you go back 18 months when Intel said, "Gosh, you know what? We really need to do the slot one thing because we just cannot figure out a way to have a second level cache" -- I'm referring to the Pentium Pro here -- "we just can't figure out a way to have a second level cache run any faster than 200 MHz." And that's why you've seen the Pentium Pro top out at 200 MHz.

Well, with Slot 2, remarkably, they've figured out how to make a second level cache run up to 450 megahertz. And they've killed off the Pentium Pro, they've killed off the socket seven processors. If you ask me, it looks like a trick to get the public into thinking that Intel's being honest and forthright with their marketing strategy, when the real goal is to kill off their competitors.

TNC: Now, the spin on Slot 2, at least following the links from your site, is quite optimistic. It seems like the Slot 2 device is going to be very powerful.

RC: Well, what I've seen is that it can support up to eight symmetric processors. I believe that the articles I've read about it say that it's going to have up to two processors on each Slot 2 module. If that's the case, then, of course, it's going to be a very powerful but probably pretty pricey solution for servers and high-end workstations. It sounds pretty powerful.

TNC: You spell it Slit 2 on your site. I wonder, is that --

RC: It's not a typo.

TNC: Okay.

TNC: How about the 64-bit processor, Merced?

RC: Merced. Merced's going to be an interesting piece because it's going to have dual instruction sets supported simultaneously in hardware. It's going to have the Merced native instruction set, the IA64, as it's called. And it's also going to support the standard IA32 or the x86 instruction set.

However, from everything Intel has said about it so far, it appears that the native performance of the x86 part of Merced is going to be only 40 to 50 percent the performance of the IA64 part of it.

Translated, what that means to the end user is that your Slot 2 or your Slot 1, your Pentium II, the fastest Pentium II is still going to be about 20 to 25 percent faster than your Merced running your X86 code.

TNC: Now, in light of the Digital Intel alliance, how is Intel going to market the Digital, the Alpha chip, and how is the Alpha chip different from Merced?

RC: I guess I don't know. I couldn't say a whole lot about Alpha because I haven't followed it that much. But speaking on how Intel might market that chip, I think they'll market it with a hammer and a nail and a coffin. I can't see them marketing that chip at all. I just see them wanting to kill it.

TNC: It's seems foreign to everything they're doing right now. So why would they push it?

RC: Right. I mean, right now Alpha can run at 700 MHz, 6-700 MHz, and, you know, that's supposedly the introduction speed of Merced. You know, actually 800 MHz is the projected introduction speed of Merced. But that's still another 12 to 18 months out. Alpha does that right now.

So I just can't see much benefit other than buying it to kill it. You know, I just can't see much benefit to Intel, other than just killing it.

TNC: Okay, Robert. Let's move on to your article, "Benchmarks: Fact, Fiction or Fantasy.", in the March issue of DDJ. What point are you trying to make?

RC: What I was trying to emphasize is, "don't trust benchmarks". Because you don't know how those benchmarks were tuned.

If you go into the Ziff-Davis benchmarks, which is the Winstone and WinBench, there are so many knobs that you can tweak, and all of those knobs have a direct effect, have a direct performance effect on how the benchmark is going to turn out. And when a magazine does these benchmarks, you know, like a 64 PC shootout, you just don't know how they set this stuff up. And you don't know how they compared this stuff. You don't even know if it's the same chip set with the same type of memory. All of that stuff has an effect on overall system performance. You just don't know if they're comparing apples to apples, apples to oranges. I just don't put much faith into them. And I might add that, likewise, I don't put much faith in some of the benchmarking Web sites that I've seen out there, either.

You know, when you start digging under the hood of the benchmarking Web sites, you start realizing that they're, some of their methodology is just completely whacked out.

I know there's one Web site, and what they do, their approach to benchmarking is tweak a system as far as it can go. I mean, overclock the bus, overclock the CPU, overclock the memory, until it fails, back off one notch, benchmark it, and that's what's representative of the benchmarks for the system.

TNC: Well, it's almost malicious at that point.

RC: Yes. I don't find that as a valid approach, because it doesn't represent what the end user is going to do. It may represent what the ultimate game freak might want to do, but it's just not representative of what the ordinary user does.

TNC: In this article you set out to prove a very specific point.

RC: Yes. What I wanted to prove was that I could take a standard, off-the-shelf Pentium P54, running at 166 MHz, and compare it against a Pentium II, running at 300 MHz on the same baseline, and then simply enhance the P54 computer without doing anything malicious, without doing something like disabling the cache on the Pentium II or anything that you might consider malicious, and just upgrade two components. And my premise was that I could get it to benchmark better than the Pentium II 300.

And I was able to prove that very successfully in this article. It was very easy to do. And I chose the Pentium P54 for a very specific reason. The P55 has a bigger cache. Yes, it has the MMX instructions. The benchmarks weren't going to use those, anyway. But it has a bigger cache. And I didn't want to give the older processor even the remotest benefit of the doubt. I wanted it to be the underdog so that I could then enhance these two components and make it out benchmark, the state of the art Pentium II running at 300 megahertz.

TNC: The benchmark suites you used were Winstone, which you already mentioned, and which has a lot of different options that you can configure. And you also used SYSmark?

RC: Yes, SYSmark, which is released by BABCo. And actually, when it came to running the benchmarks, I found the methodology used by BABCo to be much more to my liking. It seemed to be more scientific.

And there's a big irony in what I'm about to tell you in that. The way the BABCo suite worked is it had very few tweaks and knobs. And in between every test there were eight programs that ran as part of the suite. And to do an official run, the suite had to run three times.

In between every test and in between every suite, it would reboot the computer, so that you were always guaranteed a constant memory configuration, page file system. So it was very scientific in its approach.

The irony is, nobody in the industry likes to use that benchmark because it's supported and help maintained by Intel. That's the irony.

TNC: So Intel is producing the one of the most objective benchmarking suites available today.

RC: To me, the most objective system benchmark. Let's be specific about that.

TNC: Don't magazine benchmarks measure overall system performance of ready-to-ship PCs, rather than raw CPU power? And this makes them valid?

RC: Right. And that's where these types of benchmarks do have a valid point. I mean, that's what they're intending to do.

And one of the reasons why I disagree with having so many knobs and buttons to turn is that they can dramatically affect performance.

For example, do you want to test your video with 256 color, you know, with 256 colors or eight-bit color or 24-bit color?

Well, there's a three times level, there's a three times difference in the amount of data that's going to be sent to your video card if you start testing with 24-bit color. And so it can dramatically affect the video performance, or the overall performance, for that matter.

TNC: What should the reviewers do? Should they test every possible configuration? Maybe they should just be more honest about what their results indicate.

RC: Being more forthcoming with the methodology is essential. It's absolutely essential. It's like conducting a Gallup poll and not knowing what the questions were. If you don't know what the questions were you have no idea how they were asked and how they may have influenced the results.

TNC: Have you had any experience with some of the labs that provide benchmarking for the bigger PC magazines?

RC: Not exactly, no. I've not had any direct contact with them. I have contacted them about some problems that I've had with their benchmark programs.

The latest Ziff-Davis benchmark is distributed with an indio driver -- at least, this is what I'm told. I haven't actually seen this in action yet, but I have contacted them about it. It's allegedly distributed with an indio driver written by Intel that detects whether or not you are an Intel processor. And, if you are not, it kills your performance. Ziff Davis said, "Well, we don't distribute that driver." And that seems to be contrary to what I've heard, but we're getting into the realm of hearsay and I prefer to stay out of the hearsay realm.

TNC: One of the points you make is that benchmark results can be influenced by tweaking the peripherals. Many companies beef up the peripherals so as to get a better reading on benchmarks.

RC: Absolutely. It's an absolute fact of life. That's what they do. I mean, I've been at companies when they are preparing a system to send to a magazine, and it is a huge effort to find the fastest video card, the fastest disk card.

When I was at Acer, we would typically send computers to magazines with peripherals that we had no plans of ever shipping with that computer. And it was all to make the benchmarks look good. We would send a computer to the magazine that had like a caching SCSI controller. And we were never going to ship that to a consumer.

TNC: It's the responsibility of the magazine to insure that the system that's being tested is the one that's actually going to go out.

RC: I believe that's true. And, unfortunately, the magazines do not adhere to that.

TNC: Why? They don't have the competence to determine that?

RC: No. Some of them may be as simple as, they're too heavily influenced by the advertising dollars. I give in my article the example of a specific magazine whose name I won't mention on the air. This magazine complained that the K6 computer they received had a Seagate Cheetah in it. And a Seagate Cheetah, for the benefit of your listeners, is the highest performance disk drive on the market today, bar none. It's a 10,000 rpm ultra-wide SCSI drive.

Well, the inherent discrepancy between the Pentium MX and the K6 machine that they received was in that SCSI disk drive subsystem. Intel had shipped them a similarly configured system that had a Barracuda, which some eight weeks earlier, was the pinnacle of performance.

So both companies did the same thing, and I found it quite disingenuous of the magazine to complain about it. As Intel was one of their biggest advertisers, I couldn't help but wonder about the conflict of interest.

TNC: Very quickly, is there a place where consumers can go to actually get more reliable benchmarks?

RC: I don't know of any. I really don't. The only thing that I can say is to try and do it themselves. Unfortunately, that is a burden too great for the consumer.

TNC: You mentioned now a couple of times that the rush for the ever-faster chip set is not necessarily the wisest way to go. Is there an optimum configuration you can recommend for the person you refer to as Joe Consumer?

RC: I think the 800 to $1,000 PC is perfect for Joe Consumer. The guy that's running Quicken, the guy that's running Word. The CPU's idle 95 percent of the time. So, you know, you don't need that 300 megahertz Pentium II.

Now, if you're going to start doing some 3-D gaming and stuff, yes, get a really good video controller. Go for maybe a 266 MHz Pentium II.

TNC: What does the system running on your desktop right now look like, Robert?

RC: I've got a 300 MHz Pentium II. But I have a reason for it. I do audio restorations on my computer. It's very floating point intensive.

TNC: Thanks for being on the show, Robert.