– By Jeff Field –

AMD has been a fierce competitor in the low-end market since the release of its first K6 CPU. Since then, it has fought Intel on all fronts, high and low. With its position in the high-end market fairly secure, AMD once again set its sight on its old enemy, the Intel Celeron. In order to compete with Intel on the same level, it released a new Athlon-based low-end CPU, the Duron, with speeds now reaching up to 950MHz at low prices, giving it a chance to be an ideal Linux CPU.
The chip

The Intel Celeron is essentially a Pentium III-Coppermine with half of the L2 cache disabled, running with a 66MHz front side bus speed. This is good for Intel because if a chip has problems with the L2 cache Intel can disable half of the cache and repackage the chip as a Celeron. However, because of the fact Intel just disabled half of the L2 cache on a Pentium III instead of redesigning the core, the cache goes from being eight-way set associative to four-way. The set associative cache is used to make the L2 cache more efficient, so the CPU spends less time waiting for data from system RAM. By cutting it in half for the L2 cache on the Celeron, Intel cut the cache hit rate. With a low hit rate, it means more time wasted finding data in system RAM.

The Duron, however, is very much its own CPU. Designed from the ground up as a low-end processor, it is not “crippled” like a Celeron. It has half the L2 cache of a Celeron, 64KB, but features 128KB of L1 cache compared to 32KB on a Celeron. The L2 cache on the Duron is 16-way set associative, allowing it to have a high hit-rate for the L2 cache. This proves crucial, because it allows the Duron to outperform a comparably clocked Celeron by large amounts.

The chip itself is similar to the Thunderbird CPUs, because it uses the same “flipchip” configuration (with the CPU core on the top) and the same interface — Socket A. The Duron, however, has a much smaller core than the Thunderbird, using 12 million fewer transistors (25 million on the Duron, 37 million on the Thunderbird), thanks to the reduction of the amount of cache on the chip. This greatly decreases the heat produced by the CPU, which is always good for a CPU targeted toward lower-end machines, which tend not to be as spacious and well cooled as machines on the higher end.

Performance
System Specifications

AMD Duron 950MHz

256 Megs DDR PC2100 SDRAM from Crucial.com

Western Digital 7200 RPM 10.2 Gig Hard Drive

3Com 3C905TX-C 10/100 NIC (PCI)

300-watt AMD-approved ATX Power Supply
Abit Siluro GeForce 2 MX400 64MB AGP

Mandrake 8.0 with Kernel 2.4.3

For performance comparison purposes, similarly configured systems are used, where only the memory type (PC133), the processor type and the motherboard are different.

Kernel compiles

To test both the board’s stability and speed, I ran three sets of Linux kernel compiles on this board. One is a normal, “uniprocessor” make, or make -j1, which is the default. This uses one process, and does not always maximize system usage. I then did make -j2, which spawns a second process. The last test I run is with make -j3, spawning two extra processes. I do this for several reasons — to find the “sweet spot” for the board/CPU, as well as to stress the system as much as possible when trying to rate its stability. Also, the kernel is extremely useful as a measure of integer performance. In order to compile the kernel, I untarred kernel 2.4.6, ran ‘make config’ and used the default values (In other words, I held down the ‘Enter’ key)

Kernel 2.4.6 Compile Times (Minutes:Seconds)
Board	-j1	-j2	-j3
Duron 950 – DDR	7:34	7:27	7:27
Athlon 1.4 – DDR	4:37	4:32	4:28
Athlon 1.4 – PC133	4:44	4:39	4:41
Athlon 1.0 – PC133	5:52	5:49	5:46
Athlon-Classic 750	8:39	8:36	8:35
Pentium III 933	6:07	6:09	5:59

Here we see results that aren’t really a surprise — the Duron is slower than the other CPUs here, with the exception of the old Athlon-Classic 750. However, it certainly holds its own in compiling — especially when you consider the 950 is available for half the cost of most of these CPUs, and that the Durons just just below this are considerably cheaper than the 950, with similar performance. Certainly, if you are a big-time coder, it would be worth it to get a faster CPU, but for those who only compile once in a while, or not at all, a Duron should be an excellent option.

POVRay Benchmarks

POVRay is a multi-platform raytracing program. It is a floating point intensive task and serves well to help measure the floating point performance of a CPU. For more information on this benchmark, head to the official POVBENCH homepage. The command to run for this benchmark, once you obtain POVRay, is povray -i skyvase.pov +v1 +ft -x +mb25 +a0.300 +j1.000 +r3 -q9 -w640 -H480 -S1 -E480 -k0.000 -mv2.0 +b1000 from the command prompt. Results are in seconds.

POVRay
Board	Result
Duron 950 – DDR	22
Athlon 1.4 – DDR	15
Athlon 1.4 – PC133	15
Athlon 1.0 – PC133	20
Athlon-Classic 750	28
Pentium III 933	30

POVRay does well with the Duron, with scoring that is in line with Athlons of similar clock. On-screen rendering would require more of the CPU’s other facilities, such as L2 cache, but rendering to file such as what POVRay does depends a lot more on the FPU power of the CPU than anything else, and the Duron Floating Point Unit is just as good as the Athlons.

Quake 3 Arena Timedemos (Frames Per Second)
Board	640×480	800×600	1024×768	1200×1024	1600×1200
Duron 950 – DDR	127.4	118.5	84.4	52.6	36.7
Athlon 1.4 – DDR	175.4	129.3	85.1	52.8	36.8
Athlon 1.4 – PC133	159.1	127.4	85.1	52.8	36.8
Athlon 1.0 – PC133	136.2	122.4	85.0	52.8	36.8
Athlon-Classic 750	104.0	101.5	82.1	52.3	36.6
Pentium III 933	132.4	121.8	85.4	52.8	36.8

Here we find the Duron is an excellent gaming CPU — most new games are more video-card intensive than CPU intensive. The work of rendering the game is loaded onto the 3D processor while background tasks such as AI and network communications are handled by the CPU. As this progression continues, it depends less what CPU you run and more what video card you use. If you put a GeForce3 into this system, you could very well find it to have similar top speeds to the highest-end Athlon, at an extremely reduced cost.

Conclusions
For those looking for a value processor, you cannot beat the Duron line of CPUs. The 950MHz model is plagued by a problem that all top-of-the-line CPUs face, increased cost. The Duron 950 is $24 dollars more on Pricewatch than its 900MHz version, yet the chips will score almost identically in benchmarks. Because most users looking at Durons want value, this should be taken into account.

However, the Duron performs as well it was intended to, and perhaps better, in some tests performing similar to its more expensive sibling, the Athlon. For those looking for an upgrade from older systems, such as K6 or lower-MHz Pentium II/III based systems, the Duron allows you a quick upgrade path. For $24, you can pick up a Duron 700MHz CPU, and a few months down the road pick up a 1.33 or 1.4 GHz Athlon as they drop in price. Duron certainly fits in the class of a lot of value for a little cost. The Duron 950MHz is available on Pricewatch for $76, and the 900 for $52.

ZDNet reports that Intel may be the only company to believe that the high-tech industry’s market will soon pick up, after a several month long slump.

Anonymous Reader writes “One major obstacle to a widespread usage of computers in developing countries has been the high cost of hardware and software leading to high levels of software piracy. Although Linux and other open source “free” software has meant that such countries can now afford to use legal software, hardware costs still remain a multiple of the common man’s monthly salary. Against this background, we now have the “Simputer” a low cost computing device from India that promises to usher in a new era of computing for the masses who otherwise would never be able to afford access to computers.
http://freeos.com/articles/4343”

Kelly McNeill writes “When it comes to ‘Code Red,’ Microsoft is winning the media spin battle. Microsoft seems to be riding out the Code Red debacle pretty well so far. By jointly issuing warnings with the government, Microsoft is identifying itself with the solution –perhaps more so than with the problem. Almost without exception, the mainstream media is minimizing Microsoft’s complicity in Code Red through its shoddy security. Instead, everyone is focusing on the need to apply Microsoft’s patch. I’m sure the automakers in Detroit would love to get off so easily the next time there’s a defect in one of their car models.”

Slashdot discusses the true purchasing costs of Linux versus Windows, started by the comment that many Linux users buy the latest distributions at full retail costs as they come out, whereas copies of Windows are generally bought with a computer.

O’Reilly.net reports that “Eric Raymond treated a roomful of attentive geeks to an overview of his latest writing at the O’Reilly Open Source Convention in San Diego, along with a peppering of observations on the Linux kernel, Sendmail, libertarianism, and economics.”

Alan Cox has released Linux kernel 2.4.7-ac4. Changelog and links below.

ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/

                 Intermediate diffs are available from
                        http://www.bzimage.org

*
*       Treat this one with a bit of care. The ext3 code I trust, the -ac
*       code I trust but the merge of the two could always include suprises
*

2.4.7ac4
o       Fix inode cache shrinkage problems in 2.4.7     (Al Viro)
        | This should cure the problem where it gets 
        | really slow over time. Its not the final fix
o       Make aironet compile again                      (Arjan van de Ven)
o       Fix an incredibly stupid i2o_scsi bug causing   (me)
        crashes with the adaptec 2100 and other stuff
o       Fix memory corruption if using gcc 3 and serial (Thomas Hood)
        probing fails
o       Fix out of memory handling with raid            (Neil Brown)
o       Fix a raid mishandling bug on errors            (Neil Brown)
o       Add promise 20268 software raid card idents     (me)
o       Fix leaktek winview601 problems                 (Leandro Lucarella)
o       Merge ntfs 1.1.16                               (Anton Altaparmakov)
o       Avoid panic when reiserfs attempts to mount     (Nikita Danilov)
        invalid superblock
o       Error rather than panic on journal replay I/O   (Chris Mason)
        error in reiserfs
o       Update atp870u driver                           (Wittman Lee)
o       First batch of superblock handling cleanup      (Al Viro)
o       Restore module oops dumping                     (Kai Germaschewski)
o       NFSD update                                     (Neil Brown)
o       Fix ieee1394 sleep with spinlock held           (Andi Kleen)
o       Add AMD 760-MP to the Agp table                 (me)
o       Rip out zillions of duplicated -ESPIPE          (Christoph Hellwig)
        llseek methods for a common one
o       Fix qlogic direction flag handling in 2.4       (Jeff Andre)
o       Clear inode->i-blocks on deletion in reisefs    (Nikita Danilov)
o       Merge rest of S/390 tty driver fixes            (Ulrich Weigand)
o       Finish adapting S/390 to new softirq code       (Ulrich Weigand)
o       Remove accidental duplicate block in Makefile   (Ulrich Weigand)
o       Update DASD drivers                             (Ulrich Weigand)
o       Further pnpbios fixes                           (Andrey Panin)
o       Switch pnp to use slab not malloc.h     (Arnaldo Carvalho de Melo)
o       Switch parport_cs to slab not malloc.h  (Arnaldo Carvalho de Melo)
o       Further config cleanups                         (Steven Cole)
o       Fix make spec with no .version                  (Keith Owens)
o       Further ipchains fixes                          (Rusty Russell)
o       Add procfs info option for reiserfs stats       (Nikita Danilov)
o       Remove dead code from the reiserfs tree         (Jeff Mahoney)
o       Quota updates                                   (Jan Kara)
o       FreeVxFS leak fixes, allow block sizes != 1024  (Christoph Hellwig)
o       Improve serial_cs reporting                     (Jonathan Corbet)
o       Add v7 fs sanity checks to the sys5 fs code     (Linus Torvalds,
                                Christoph Hellwig, Al Viro, Andries Brouwer)

ZDNet reports that Samsung is planning to make products that use Sony’s ‘Memory Stick’ flash memory format, which the company has up until now not done in spite of having a license to do so.

Kelly McNeill writes “I was cleaning out an old desk the other day and I happened to find some intriguing technology articles from the mid-1990s. Aside from a few laughs at the ridiculous claims of the talking parrots who obediently repeated the Microsoft party line, there were several cases of anti-OS/2 articles full of FUD-raking that were quite amazing.”

Segfault: “”God holds a monopoly on the Universe,” says one of the developers working on FreeVerse, “and He’s
withholding information about His system which could be used by its users to learn more about it.” ‘God’ here does
not mean Linus. It does not mean RMS. It means God. The Supreme Being. Creator Of All Things.

One group of people angry with God’s non-disclosure policy on His source code are physicists. They argue that it
would be much easier to write a Grand Unified Theory if they could only get a peek at the source code. FreeVerse
means to change that. “We’re using no proprietary code,” says another FreeVerse developer, “it’s all done from
scratch.”” Ha.