xorg +XGI Volari XP5

[Hummel Tom]

r.dragonflybsd.org> <426e9cc1$0$719$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <426eb372$0$720$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <426eb372$0$720$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
X-Enigmail-Version: 0.91.0.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 44
Message-ID: <426eda17$0$717$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 84.139.212.80
X-Trace: 1114561048 crater_reader.dragonflybsd.org 717 84.139.212.80
Xref: crater_reader.dragonflybsd.org dragonfly.users:3165

> I don't have any numbers yet on the Turion64 specific, but it's just a 
> Athlon64 with some adjustments so you can make pretty solid claims about 
> Turion64 performance when you compare the Athlon64 with the Pentium-M.

agreed, I've been looking a few tests, and the Pentium-M is no match for 
an A64 at the same clock-speed.
This has alot of reasons, e.g. little memory bandwidth of the P-M and HT 
on the Turion64.

> The difference here is between measured thermal power dissipation when 
> running a certain task (i.e. BurnK7), and maximum thermal power 
> dissipation. First, I measured total CPU power usage. Second, a task

AFAIK the tests i gave you did the same :)

> like BurnK7 never stresses the CPU to it's fullest. A large part of the 
> CPU die consists of cache (L1, L2) which gets little to do when running 
> a synthetic 'benchmark' like BurnK7. With intensive cache invalidation 
> and reloading action, a lot of energy is consumed, and logically a lot 
> of heat generated. Third, of course you can't ever get the caches to 
> update completely every clock cycle, due to memory slowness and the 
> serial nature of cache invalidation in current x86 (and other?) CPU 
> designs (which results in cache invalidation taking a lot of CPU cycles).

Agreed none of this programs are able to stress the CPU at 100%.
AFAIR those programs however forced _all_ of my pcs to higher 
temperatures than I achieved normally, with real-life tasks, thus I 
expect those programs to deliver a fairly real situation.

So IMHO it's a good point to start at, but this completly my experience, 
because I always tested how slow I could turn down my fans, and tasks 
like games, video encoding, and rendering (a friend of mine is doing 
that alot and he used quite many different machines over the years) 
never put the temperatures higher than Prime,Burn-cpu SuperPI or whatever.

> However, in this field politics are concerned as well. There is truth in 
> your words about differing policies on TDP values for both AMD and 
> Intel, but you look the wrong way. AMD actually specifies a true real 
> maximum TDP, whereas Intel specifies an average maximum TDP based on 
> stresstests. However, this doesn't mean AMD rates it's TDP too high, but 
> rather Intel too low.

Well to quote somebody I don't like very much:"don?t worry about whether 
the cat is white or black as long as it catches the mouse" den xiao ping. ;)