PC Review


Reply
Thread Tools Rate Thread

Re: Intel Or AMD?

 
 
Tony Hill
Guest
Posts: n/a
 
      20th Dec 2006
On Tue, 19 Dec 2006 19:47:40 +0000, Lexusan
<(E-Mail Removed)> wrote:
>Which processor is better?


Can you make that a bit more of an open-ended question?! </sarcasm>
Seriosuly, both AMD and Intel make quite a range of processors at
various performance levels and price points.

> Im currently using a intel celeron (i know )
>But am looking to the new 4's with hyper-threading.


The Pentium 4, of any stripe, is a VERY poor choice these days. Their
performance is pretty weak as compared to either AMD's Athlon64 line
or Intel's own Core 2 Duo line. P4 chips also consume a LOT of power.

As for Hyperthreading, at best it's a poor-mans excuse for dual-core
that offers slight improvements in multithreaded performance. At
worst it makes the system slower, which is why it's often disabled.
Given that true dual-core processors start at under $100 these days,
it's something that can very safely be ignored.

>Ive seen this amds that are quite good but i heard the semperons are
>bad.


Sempron chips are quite reasonable for their price. They compete
against Intel's Celeron chips and offer very competitive performance
for the price. For example, a Sempron 3000+ will set you back $43
(prices according to www.newegg.com) and will give you similar to
slightly better performance as compared to a Celeron 336 that costs
$48.

Of course, both of these are low-end solutions. Spending a small
amount more will get you a MUCH faster processor. At $93 you could
get a dual-core Intel Pentium D 805. That will perform about the same
as the Celeron or Sempron mentioned above in single-threaded
applications, but it has a whole other processor available allowing
for MUCH faster performance in multi-threaded applications and/or much
better multitasking performance. This is probably the absolute
cheapest chip that I would recommend unless you absolutely need a
computer now and can't afford the extra $50 or so.

The next step up from that would be AMD's Athlon64 X2 3800+ at $131.
Again this is a dual-core chip, but it's much faster than anything
from Intel with the "Pentium" name on it. It will be faster than any
of the chips mentioned above in either single-threaded or
multi-threaded applications and have much better performance in
multitasking. The Athlon64 X2 4200+ ($165) also isn't bad, though
going beyond that the price/performance ratio starts to drop off on
these chips.

Going up to the high-end of things, Intel currently holds the crown
with their Core 2 Duo line. The Core 2 Duo 6300 sells for $181 and
from that point on up the only question is what speed grade you want.

So, recommendations? Well that depends on what you want to spend:

High-end: Intel Core 2 Duo 6600
Mid-range: Intel Core 2 Duo 6300 or 6400
Low-end: AMD Athlon64 X2 3800+ or 4200+
"I can just BARELY afford a computer": Intel Pentium D 805
"I really CAN'T afford a computer": AMD Sempron 3000+
--
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
 
Reply With Quote
 
 
 
 
Spoon
Guest
Posts: n/a
 
      20th Dec 2006
Tony Hill wrote:

> As for Hyperthreading, at best it's a poor-mans excuse for dual-core
> that offers slight improvements in multithreaded performance. At
> worst it makes the system slower, which is why it's often disabled.


Moreover, it's a security risk.

http://www.daemonology.net/hyperthre...dered-harmful/
 
Reply With Quote
 
 
 
 
Tony Hill
Guest
Posts: n/a
 
      21st Dec 2006
On Wed, 20 Dec 2006 09:52:01 +0100, Spoon <(E-Mail Removed)>
wrote:

>Tony Hill wrote:
>
>> As for Hyperthreading, at best it's a poor-mans excuse for dual-core
>> that offers slight improvements in multithreaded performance. At
>> worst it makes the system slower, which is why it's often disabled.

>
>Moreover, it's a security risk.
>
>http://www.daemonology.net/hyperthre...dered-harmful/


I remember reading about that security risk back when it first came
out and thinking that the author was just being a jackass. Exploiting
this security hole is ridiculously difficult, to the point that it
would probably be easier to brute-force crack the RSA keys he claims
to be able to get from it. You need a VERY specifically crafted
situation for this to be remotely possible at all, ie the attacker
would pretty much need 'root' access on the system to execute this
exploit, by which point you're security is already shot all to hell.

What's more, the same "risk" almost certainly exists in any case where
the cache is shared (Core Duo and Core 2 Duo chips) and possibly even
any case where cache is snooped (basically all multiprocessor systems.

Long story short, this one should be way *WAY* down on your list of
security concerns. Maybe if you're running a super-top-secret
military system it might be an issue, but then again, you probably
wouldn't be using anything at all resembling standard hardware.
--
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
 
Reply With Quote
 
Michael Daly
Guest
Posts: n/a
 
      21st Dec 2006
Tony Hill wrote:

> I remember reading about that security risk back when it first came
> out and thinking that the author was just being a jackass. Exploiting
> this security hole is ridiculously difficult, to the point that it
> would probably be easier to brute-force crack the RSA keys he claims
> to be able to get from it.


I was wondering about this - how, in general, does process A on one CPU know
what's running on the other CPU and know where in the cache the data is? (I
didn't bother to read the 12 page stuff at the link). There's a big difference
between possible and probable.

> What's more, the same "risk" almost certainly exists in any case where
> the cache is shared (Core Duo and Core 2 Duo chips) and possibly even
> any case where cache is snooped (basically all multiprocessor systems.


I was going to ask about this - unless shared cache has protected memory areas,
either processor can read the other's data. Even if a virus manages to hog one
CPU and scan everything in the cache all the time, it would still need intimate
details of the memory content organization to make sense of the data. That
implies a much more serious security breach than just reading cache - it implies
that all your source code has been compromised. Wouldn't it also need to know
how chunks of memory get swapped in and out of cache at any point in time as
well? I only have an "overview" notion of how these processor caches work, so I
have an expectation that the placement of a bit of data in the cache at any
point in time to be more or less random.

Mike
 
Reply With Quote
 
Spoon
Guest
Posts: n/a
 
      21st Dec 2006
Tony Hill wrote:

> Spoon wrote:
>
>> Tony Hill wrote:
>>
>>> As for Hyperthreading, at best it's a poor-mans excuse for dual-core
>>> that offers slight improvements in multithreaded performance. At
>>> worst it makes the system slower, which is why it's often disabled.

>>
>> Moreover, it's a security risk.
>>
>> http://www.daemonology.net/hyperthre...dered-harmful/

>
> I remember reading about that security risk back when it first came
> out and thinking that the author was just being a jackass.


Perhaps you should tell all the people working on side-channel attacks
(such as Adi Shamir (the S in RSA), and Daniel Bernstein (timing attack
against AES)) that you consider their work to be worthless? ;-■

It is an active field of research.
cf. the References in http://eprint.iacr.org/2006/351

> Exploiting
> this security hole is ridiculously difficult, to the point that it
> would probably be easier to brute-force crack the RSA keys he claims
> to be able to get from it. You need a VERY specifically crafted
> situation for this to be remotely possible at all, ie the attacker
> would pretty much need 'root' access on the system to execute this
> exploit, by which point you're security is already shot all to hell.


The 'spy' process is run as a normal user. No root access required.

> What's more, the same "risk" almost certainly exists in any case where
> the cache is shared (Core Duo and Core 2 Duo chips) and possibly even
> any case where cache is snooped (basically all multiprocessor systems.
>
> Long story short, this one should be way *WAY* down on your list of
> security concerns. Maybe if you're running a super-top-secret
> military system it might be an issue, but then again, you probably
> wouldn't be using anything at all resembling standard hardware.

 
Reply With Quote
 
Robert Redelmeier
Guest
Posts: n/a
 
      22nd Dec 2006
In comp.sys.ibm.pc.hardware.chips Spoon <root@localhost> wrote in part:
> Perhaps you should tell all the people working on side-channel
> attacks (such as Adi Shamir (the S in RSA), and Daniel Bernstein
> (timing attack against AES)) that you consider their work to be
> worthless? ;-■


Of course not! But it's easy to add keystroke combining to a client
like `ssh` to drastically reduce the amount of information available
from timing analysis as well as reduce the number of packets sent.

There is a small cost in latency which can be rendered less
noticable by careful design.

-- Robert

 
Reply With Quote
 
Tony Hill
Guest
Posts: n/a
 
      22nd Dec 2006
On Thu, 21 Dec 2006 22:23:18 +0100, Spoon <root@localhost> wrote:

>Tony Hill wrote:
>
>> Spoon wrote:
>>
>>> Tony Hill wrote:
>>>
>>>> As for Hyperthreading, at best it's a poor-mans excuse for dual-core
>>>> that offers slight improvements in multithreaded performance. At
>>>> worst it makes the system slower, which is why it's often disabled.
>>>
>>> Moreover, it's a security risk.
>>>
>>> http://www.daemonology.net/hyperthre...dered-harmful/

>>
>> I remember reading about that security risk back when it first came
>> out and thinking that the author was just being a jackass.

>
>Perhaps you should tell all the people working on side-channel attacks
>(such as Adi Shamir (the S in RSA), and Daniel Bernstein (timing attack
>against AES)) that you consider their work to be worthless? ;-■
>
>It is an active field of research.
>cf. the References in http://eprint.iacr.org/2006/351


Worthless? Not quite, but more academic than practical. The timing
requirements of this sort of attack are so extreme that they are
virtually impossible to control. Unless I'm reading this wrong, the
attack you're quoting involves trying to determine the processing
behaviour of one process by monitoring the branch mispredictions of
another. This requires that you know exactly when the encryption key
is going to be generated, you need to know when and how your thread's
branches are going to get mispredicted according to things happening
in another thread, and to top it off, you need to have NOTHING else
running on the system at the same time since that throws all your
calculations out the window.

It's not that these attacks are not possible, they're just so
incredibly inprobable that it's not worth worrying about. Almost any
normal system will be hacked a thousand times over before anyone ever
manages to successfully hack it using this method. It's worthwhile
keeping an eye on for people that do the actual writting of SSL
encryption software and the like, but hardly something that 99.999%+
of the population need get concerned about.

>> Exploiting
>> this security hole is ridiculously difficult, to the point that it
>> would probably be easier to brute-force crack the RSA keys he claims
>> to be able to get from it. You need a VERY specifically crafted
>> situation for this to be remotely possible at all, ie the attacker
>> would pretty much need 'root' access on the system to execute this
>> exploit, by which point you're security is already shot all to hell.

>
>The 'spy' process is run as a normal user. No root access required.


It's not the 'spy' process that they need root access for, it's the
process providing the RSA keys in the first place! Trying to do this
with any sort of normal system behaviour is excrutiatingly difficult,
hence my comment that it would probably be easier to brute-force hack
the keys (perhaps a slight exaggeration, but not by much).
--
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca
 
Reply With Quote
 
 
 
Reply

Thread Tools
Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
INTEL DRIVER CHIPSET INF Update Utility - Primarily for Intel« 4, 3, 900 Series Chipsets (2455KB) 9.0.0.1008 6/2/2008 are the same Intel Driver Chipset for Vista and XP? rebelscum0000 Windows Vista General Discussion 5 25th Jun 2008 05:32 AM
The latest intel chipset drivers caused problem on Intel Desktop U =?Utf-8?B?UGV0ZXI=?= Windows XP Hardware 0 6th May 2005 01:14 PM
intel 845 and intel 865 Jeff Windows XP Embedded 1 8th Jun 2004 09:59 PM
Dell 170L Intel Pro LOM Intel Pro VE w/ XP and Server 2003 (partial solution) Todd-H Microsoft Windows 2000 Deployment 1 14th Apr 2004 06:20 PM
intel.inf (intel 82371 eb pci to usb universal host controller error) tuan Microsoft Windows 2000 Applications 0 26th Aug 2003 05:40 PM


Features
 

Advertising
 

Newsgroups
 


All times are GMT +1. The time now is 05:17 AM.