Intel Core 2 Updates, QX6850 and E6750

An anonymous reader writes "As AMD's Barcelona approaches, the price war between AMD and Intel continues. To spice things up a bit this week, Intel is throwing into the ring a number of new processors, refreshing the Core2 line-up. HEXUS reviews the high-end QX6850 and mid-range E6750: 'Now is a golden time for anyone looking to buy a new CPU, whether Intel or AMD. The latest round of price cuts means you can now get an incredible level of processing performance for little more than £100. But if your need to buy is not urgent, remember that Intel and its big rival are each promising new processors before the end of the year — AMD with K10 quad-core and Intel with 45nm Penryn-derived CPUs.'"

Comments

Unasked, unanswered question

[ceeam]

Have they fixed those bugs?

Re:Unasked, unanswered question

[Kjella]

Unasked, unanswered, uninteresting question. It has bugs, and so's every consumer CPU since before the infamous Pentium floating point bug because as the fix some, they get some new. Most of those are worked around in BIOS or in basic OS routines, and the Core 2 processors are neither worse nor better than the rest (AMD or Intel). I'm happy to keep AMD around for competition but this is just FUD against Intel.

Re:Unasked, unanswered question

[kestasjk]

So, I suppose you will blame the BIOS or the OS or anything _but_ _your_choice_ of CPUs when the security-related bugs that promise to allow any script kid to compromise your servers in unprecedented ways are exploited.

For me, choosing any CPU that has known security bugs to be used on any connected computer is reason enough to be fired. What security bugs? I don't know where people get the idea that there were security bugs in the errata Intel released. Theo said that out of 50 bugs "2-3" were "potentially exploitable", but as far as I know no-one has given so much as a proof of concept.

Saying that these bugs "allow any script kid to compromise your servers in unprecedented ways" is totally over the top.

• No-one has shown that any of the bugs contain any sort of vulnerability,
• no-one has shown that any of the hypothetical vulnerabilities allow remote code execution,
• no-one has shown that any of the hypothetical remote code execution vulnerabilities could be exploited in realistic scenarios,
• certainly nothing has been made available to script kids,
• and I don't even know what "in unprecedented ways" means in this context.

It is just FUD, until someone can actually point out a realistic code execution vulnerability, or even a PoC, even one that could be exploited in unrealistic scenarios, even a DoS, an idea, anything!

Also to be included: New DRM technology

[ProdigySim]

What they don't mention is that just about every new processor they're releasing (or dropping prices on) comes with their new "Trusted eXecution Technology" built in.
This will be the on-die partner of Trusted Platform Module, which is already built into motherboards of this generation.

From Wikipedia:

Trusted Execution Technology (TET or TXT), formerly known as LaGrande Technology is a key component of Intel's initiative of "safer computing" . Intel claims that it will be very useful, especially in the business world , as a way to defend against software-based attacks aimed at stealing sensitive information. Although commonly advertised by Intel as security technology, the Free Software Foundation claims that it can also be used to enable development of more advanced, tamper-resistant forms of DRM, and can be abused to achieve vendor lock-in.

(Link) Personally, I'm going to avoid this technology if I possibly can.

I wouldn't mind an AMD X2 BUT...

[TheLink]

But, the AMD X2s in the office have got the unsync'ed TSC problem (which causes stuff like time appearing to go backwards aka nonmonotonic time, which can cause programs to have problems). Sure in theory you're not supposed to assume they're in sync. BUT in practice on consumer-grade motherboards there's not much choice - often you don't get stuff like HPET or it's broken. Plus if your TSCs are synced, they are a better choice - the other timing methods are actually quite crappy[1].

So the workaround I use at work is to never let the cores idle and always run them at full speed. Boot linux with idle=poll.

Ironically, the AMD X2s supposedly use less power than the Core 2 Duos while idle...

Apparently AMD say they're going to fix the TSC stuff, and though it's been quite a while since they said that, AFAIK I don't think it's been fixed. So if I had to buy a CPU today for a desktop computer, it'll be a Core 2 Duo. The alleged Core 2 Duo security bugs don't appear to be being exploited by hackers all the time, whereas this AMD X2 TSC problem is always there.

I believe there are Windows gamers who are having problems with their AMD X2s and end up running the game/app only on one core and it's probably due to this TSC problem. Yeah the programmers shouldn't use TSC etc etc. But really what are their choices? See [1]

[1] Why can't the CPU + hardware + OS people get together and come up with something good for something as basic as time keeping?

As Vojtech Pavlik summarizes:
RTC: 0.5 sec resolution, interrupts
PIT: takes ages to read, overflows at each timer interrupt
PMTMR: takes ages to read, overflows in approx 4 seconds, no interrupt
HPET: slow to read, overflows in 5 minutes. Nice, but usually not present.
TSC: fast, completely unreliable. Frequency changes, CPUs diverge over time.
LAPIC: reasonably fast, unreliable, per-cpu

http://lkml.org/lkml/2005/11/18/261

Re:Real Benefits on the Low End

[Almahtar]

Maybe if they merged...
Then we'd have a monopoly and both bus and CPU would suck! Sweet!