Linux-Hardware Digest #728, Volume #10 Sat, 10 Jul 99 22:13:26 EDT
Contents:
Re: Celeron, what's the catch? (Chris Robato Yao)
Re: Video Card Recommendation? (Jim)
MGE UPS ESV 11+ ("Johan Fredrik Øhman")
Re: UDMA 66 Support (Byron A Jeff)
Re: Celeron, what's the catch? (Chris Robato Yao)
Re: SCSI v. IDE boot conflict (Linux-only system) (JeremyDunn)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Chris Robato Yao)
Crossposted-To: comp.sys.ibm.pc.hardware.chips,comp.sys.intel
Subject: Re: Celeron, what's the catch?
Date: 11 Jul 1999 00:42:05 GMT
Reply-To: [EMAIL PROTECTED] (Chris Robato Yao)
In <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (kls) writes:
>In article <7m674j$441$[EMAIL PROTECTED]>, [EMAIL PROTECTED] says...
>>>>Not really. Like I said, the K6-3's performance is much more consistent
>>>>than a dual Celeron, where sometimes you're faster, but a lot of times,
>>>>you're much slower as well.
>>>
>>>Now, now, Chris, much slower?:) "got my Celeron oc'ed to 550 is when the
>>>Celeron more or less starts feeling a bit equal".
>>
>>Celeron oc'ed at 550 doing SMP are not consistent. I've seen reports of
>>problems.
>
>single vs single, as you've pointed out, isn't that bad. & then smp
>kicks in... & btw, how 'bout those reports url's.
Try the usenet for one thing. Nobody makes URLs of failures, although
Sharky's Extreme I think has a "statistic" on overclocked Celerons.
I do question the extremely low success rate on Celeron 366s on
his stat though (5%).
>
>>>>It does. You need to particularly look for week 14-25 Malay PPGA
>>>>Celeron 366, and many retailers are not interested to inform you what
>>>
>>>week 14-25 Malay PPGA are already known to be good overclockers which does
>>>not imply all others aren't. It's just those are the known ones from people
>>>buying them & reporting back.
>>
>>Slot 1 366s are forgetable. Overclocking 400-466 Celerons with 75 and
>>83MHz bus speed is for me considered unacceptable due to the long term
>>damage on hard drives and file systems from overclocked IDE bus.
>>People don't report failures as they do with successes,
>
>Can't say I've ever heard of damaged hard drives from overclocking
This happens. This happened already to me, and this can
happen to anyone trying to risk their drives, for example, 83MHz. File
system damage is already a common known fact for overclocking hard
drives. You can reduce damage by turning off UDMA and going down to PIO
2, but that will take performance off your hard drive.
>People/sites report success & failure all the time(try storagereview).
>& % of successful overclocking could just as easily be worded as % of
>unsuccessful overclocking by subtracting the first % from 100. r-a-t-i-o:)
>
>>so reading the newsgroup is not a good indication of ratio.
>
>I wasn't basing a ratio off newsgroup responses but refering to polls & tests
>on websites(not MY ratio's either). Anybody remember that one site where
>the guy was a vendor & was testing the celerons he was selling? He had made
>a chart of speed grades crossed with voltage settings & % of success/fail.
>
Careful with this people.
>>Many dealers are not
>>cooperative as to why the hell you want to view the chip numbers at the
>>back, and it's hard to get that information out from mail order firms.
>>I tracked my Celeron by tracking which local dealer running out of their
>>Celeron inventory, so I would know that when their next Celeron shipment
>>arrives, it would be new stock.
>
>It's also been said that newer cpu's are good as a general case. Some people
>have estimated 80%. but then it's just an estimation.
>
>>Some dealers are no longer stocking 333s and 366s.
>
>& many still are. no issue here.
>
>>>>exactly is their stock. You also need a slotket with adjustable
>>>>voltage, and even there, you still have to take a crap shot.
>>>
>>>Not if one went with an abit bp6(which is damn appealing even w/o it's dual
>>>capability).
>>
>>I don't consider Abit to be an alternative for my uses. For me, FIC and
>>Abit are unacceptable due to their relatively high RMA rates (returns).
>>I'll put Soyo, Asus, Chaintech, and AOpen ahead of Abit for reliability,
>>especially since I eventually move my platforms into business
>>deployment.
>
>Poopooing again Chris?:) Abit havn't been/aren't the only ones coming out with
>socket 370 boards you know:)
Abit has a higher return rate than other motherboard brands. One can
understand it a bit with Super 7, but BX?
Abit is the only brand out there with programmable voltages for socket
370. The rest has none. Without programmable voltages, the success
rate of oc'ing Celeron 366s to 550 is not very good. One has to be very
lucky if you can oc a Celeron 366 to 550 on standard voltage (class it a
"gold" Celeron.)
>
>>>>You practically have to burn in your Celeron at 2.3v or 2.4v for a period of
>>>>time, before you can back down to 2.2v. And of course, if you burn it
>>>>out, there is no warranty from overclocking is there.
>>>
>>>If we're already at the point of overclocking, the risk of increased voltage
>>>is moot as far as warranty is concerned(already decided we don't need no
>>>stinkn warranty:)
>>
>>Not an alternative for recommendation for other users.
>
>Your the one who recommends one practically has to burn in ones celeron:)
I won't recommend this with new users. Only to the techno geeks out
there.
I got my voltage down now to 2.2v. Perhaps I'll let it stay that way
because the reliability factors of 2.2v vs 2.0v on .25 micron process is
neglible.
>
>>>>and you will see that on many benchmarks, particularly
>>>>with games
>>>
>>>Ooo-who:) games, do you really wanna go there?
>>
>>Yes. Besides Q3Test is just an alpha. I will admit the value of SMP
>>for game servers for lan parties, but forget about SMP for the rest of
>>the games.
>
>I'm not even talking about smp, but single vs single. Are you going to claim
>that the k63 vs celeron agregate game performance is comparable? Burden of
Only a Celeron 400 and above. 366 and below without overclocking is
questionable.
>proof on you. Not a few instances, but on the whole(agregate). #'s where k63
>is even in spitting distance is good enough. But I'll say it now: the celeron
>is easily the better gaming cpu. I can't count the # of times where my k6-2
>300 sucked air where it shouldn't have if it had been up to p2 performance
>level.
Don't compare a K6-2 300 to a K6-III 450. The K6-III 450 belongs to a
new level of performance.
I can tell you that my K6-III 450 easily blows away my PII-300
which I owned before.
>
>>>>and ZDNet application benchmarks among others, dual
>>>>processing meant squat.
>>>
>>>yep, word proccessing & it's ilk. Now, are they speed limited? & then you
>>>ask, well then, which apps are? & then you ask, well, do duals help THOSE
>>>apps out? & as we've already gone over, for many of them, yes. This applies
>>>to the consistency issue you speak of.
>>
>>No. For most of them, just no. Look at those ARSTechnica benchmarks
>>again. Note that these are recent ZDNet benchmarks, which often run
>>multiple processes simultaneously, and these benchmarks are well known
>>to have evolved to this manner from earlier, single processing ZDNet
>>benches, primarily suspected aimed to give an advantage for PII caches.
>>What advantage does SMP have there? ZDNet benches are supposed to
>>represent the average Windows enviroment with its most commonly used
>>applications.
>
>1st single threaded bus. winstone 99: no speed gain, no suprise.
>2nd, multi threaded winstone 99: 29.5%
>3rd, single threaded high end: no gain.
>4th, list of individual apps performance: 3 multithreaded, 4 single. guess.
> vc mp: 39.8%
> sound forge: minute
> premiere: minute
> photoshop mp: 35.5%
> microstation se mp: 22%
> frontpage 98: minute
> avs/express: minute
>5th, cpumark: not benching 2nd cpu.
>6th, fpumark: not benching 2nd cpu.
>7th, disk, slight gain.
>8th, graphics, no gain.
>9th, photoshop 30mb file, multi threaded: 30%
>10th, || 100mb file, ||: 3%
>11th, || 30mb lighting effect: none
>12th, || 100mb ||: 2%
>13th, linux compile: 71%
>14th, quake 2 8x6: none
>15th, || 10x7: none
>
>Four out of seven is pretty thin ratio to try to pull off a comment like "No.
>For most of them, just no." don't ya think?:) Doesn't matter, as these are NOT
And out of all 15, only six has benefit, five at 20-30% and only one has
71%. 9 has no practical difference at all. The five 20-30% does not
justify the cost and complexity of SMP either, since you might as well
buy a single faster processor.
So tell me how dual Celeron 333s and 366s can be consistently faster
than a single K6-III 450 again with an estimated integer performance
better than a Cel 500?
>run in multiple processes like you claim but are benchmark results of the
>individual apps performance. Guess what happens when you multitask? you
>guessed it, those single threaded apps running in their own process gets
>shuffled off to one on each processor. btw, I saw a discussion about how k63
Perhaps you're a bit dim. Doesn't give shit when these processes or
threads are going to be synchronization, user or I/O bound. In this
case, the processor is only made to wait on a process or thread that is
essentially blocked or placed in a wait state.
There is a monumental book about multiprocessing. It's "In Search of
Clusters" by Pfister, who did a lot of MP research for RS/6000s in IBM.
Why don't you read it.
>256k cache is better at multitasking because of it's size. vs a single celeron
>that should be true, but we're talking about a dual celeron here & that not
>only means two processing cores but 2x128k cache, the same as a k63.
>
Two seperate caches on different processors are not the same as a single
unified cache on one processor, which in addition has an L3 to boot.
>btw, cpureview got around to putting up a dual celeron linux compile time:
>http://cpureview.com/art_smp_f.html. 77.4%(183% utilization) vs k63's 23.5%:)
>The test is compiling the linux kernal but the performance is indicative of
>everything that's compiled or assembled using a makefile. & his system only
>had 64MB of memory!(I seem to recall an argument that one would have to spend
>extra $ on a larger amount of memory than a k63 would need in order to attain
>such performance(acutally, I also seem to recall it was argued such performance
>wasn't realistic or obtainable:) moot point regardless with such low memory
>prices. btw did everyone notice 128MB pc100 dimms just jumped +$10
>recently!?).
>
>>>>Plus there is no 100% guarantee that a dual Celeron will work reliably
>>>>everytime and without problems, so again, that's a crap shot.
>>>
>>>Yeah, but by user reports, they're good odds.
>>
>>You cannot deny a K6-III 450 working on its rated
>>speed and delivering its vaunted performance is practically a guaranteed
>
>Don't think anyone ever has. That is, no one's argued 'a k63 is not as
>fast as a k63!':)
>
>>and much better odds than dual Celerons,
>
>Well, there's overclocking odds & odds that there's multithreaded &/or
>multiprocess enhancements for the type of apps you want to use or will be
>helped out in general from the os being smp aware. That a k63 is as fast as a
Don't expect to see such applications except for expensive, workstation
class types that work on NT, and nobody would take the chance of working
such applications on unproven unsupported platforms like dual Celerons.
Other than this, the best utilization for SMP right now is being a LAN
party game server using LInux and Linux compiles.
There is plenty of heavy kinds of Windows applications out there, and
most of them are basically single process.
>k63 one would regard as a baseline. Odds come into play with betting you'll
>get astoundingly better performance(dual oc'd), much better performance(dual),
>roughly the same(oc'd), or 23.5% less than(can't oc, doesn't take advantage of
>duals) with inbetween gradients of performance where duals come into play
>depending on how well dual support is implemented.
Overclocking and using the processors beyond their specification is
unacceptable on a workplace enviroment. Keep the hobbies to yourself;
they have no place on business.
>
>With oc odds as good as they are, dual potential as great as it is, & with
>worst case scenario performance nothing to cry about, no wonder so many find it
>appealing. In short, the highs are higher & lows aren't that low; & I would
>argue, has a much better average. What would take some of the 'wind out of
>duals sails' is if the k63's low(fpu) wasn't LOW. But it is, so bring on the
>duals or bring on the k7.
>
>>which I won't even touch for a business enviroment.
>
>'Not an alternative for recommendation for other users':)
Anything thats recommended for a business enviroment makes a much more
valid ground for recommendation that your opinion about taking chances
on warranty and doing things out of spec. A business enviroment
recommendation will cover far more users out there, than one for a
fringe geek group.
Rgds,
Chris
(And the NUMBER ONE top oxy-MORON
1. Microsoft Works
---From the Top 50 Oxymorons (thanks to Richard Kennedy)
------------------------------
From: Jim <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc,comp.os.linux.x
Subject: Re: Video Card Recommendation?
Date: Sun, 11 Jul 1999 00:27:11 +0000
Michael Wellman wrote:
> A TNT or TNT2 card might be what your looking for but you'll have to
> get the drivers from nVidea's sight. I'v got a Creative Labs graphics
> blaster (TNT based card) coming in the mail from shopping.com for
> around $75.
>
> >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
>
> On 7/8/99, 6:26:21 PM, [EMAIL PROTECTED] (Flash) wrote regarding
> Video Card Recommendation?:
>
> > Hi, I m finally getting around to replacing my 2Mb video card, and I
> am
> > looking for a recommendation.
>
> > This is what I run on the machine
>
> > Windowmaker 0.60.0 on XFree86
> > RH Linux 5.2, kernel 2.2.x
> > Viewsonic 19" Monitor
> > Pentium 200
> > 64Mb RAM
> > PCI Bus only.
>
> > I would like to get the most out of my new, beautiful Viewsonic G790,
> and
> > increase my resolution to maybe 1280x1024, 24bit color.
>
> > I would like to stick to around $150.
>
> > If anyone can give me a good recommendation for a card that is very
> > XFree86-friendly, PCI, and will support high refresh rates and
> > resolutions, I would be most grateful.
>
> > --
Iwould advise you to stay away from ATi video cards. I tried one and it
was inferior in every way to the card I replaced it with. (Matrox
Millenium II PCI).
Matrox hardware and especially their drivers are great for linux
------------------------------
From: "Johan Fredrik Øhman" <[EMAIL PROTECTED]>
Subject: MGE UPS ESV 11+
Date: Sun, 11 Jul 1999 03:30:23 +0200
Hi there, I have a strange problem. I have just bought the MGE UPS ESV 11+
(uninteruptable power supply).
It works perfect under windows, but I have major problems in linux.
I'm using www.mgeups.com own linux software, but I keep getting "Connection
lost" message after some minutes.
Personally I suspect the software to be outdated, (its using cua0 instead
if ttyS0.....)
Anyway, I would like to know is there is anybody out there who uses this or
a similar model under linux, it will become easier for me to track down the
bug.
--
JFO
------------------------------
From: [EMAIL PROTECTED] (Byron A Jeff)
Subject: Re: UDMA 66 Support
Date: 10 Jul 1999 21:31:21 -0400
In article <YE4h3.38$[EMAIL PROTECTED]>,
Bryan <Bryan@[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
-: Thanks for the link, it was very helpful. Does this mean that anyone
-: using Abit's BP6 is forced to use UDMA/33 (if it works) or slower? With
-: all the people talking about dual celerons with UDMA/66 based on this
-: board, I hope they check out that how-to. They said that 2.3.? was
-: including UDMA/66 support, so hopefully that will come around. As an
-: aside, does anyone know how UDMA/33 or UDMA/66 will compare with SCSI?
-: I'm putting together a file server for 10 users, and I'd like to avoid
-: the SCSI expense if possible, and UDMA seems tantalizingly like the
-: solution.....if it works :-)
-
-file server: that means scsi to me. ANY kind of ide is suboptimal for
-that many users - scsi is still much better for multiprocessing.
-
-for single task uses, udma is probably ok. for servers, its a
-nobrainer - go scsi.
Why?
It's a rhetorical question. I'll give two answers.
1) You can easily attach a lot more disks to the SCSI controller. 15 vs. 4
in the average case.
2) The SCSI has disconnect which means that you can issue a command to a
SCSI device and disconnect it from the bus until it's completed the request.
In the meantime other requests can be issued to other devices. This I/O
overlap can give a huge performance advantage over IDE.
However if UDMA/33 is working effectively, and if you need only one disk
or less per IDE controller, then IDE can be extremely attractive vs. the
costs of SCSI disks. IDE disks will always be in the price "sweet spot"
but SCSI's never ever will because the volume isn't high enough.
BAJ
------------------------------
From: [EMAIL PROTECTED] (Chris Robato Yao)
Crossposted-To: comp.sys.ibm.pc.hardware.chips,comp.sys.intel
Subject: Re: Celeron, what's the catch?
Date: 11 Jul 1999 00:48:48 GMT
Reply-To: [EMAIL PROTECTED] (Chris Robato Yao)
In <[EMAIL PROTECTED]>, Marc Mutz <[EMAIL PROTECTED]> writes:
>Chris Robato Yao wrote:
>>
><snipped>
>> One must also remember that the K6-III is also unequal in terms of the
>> *L1* size, which is 64K, and double of that of the Celeron, <interrupted>
>
>That may be a point I have not thought of before. This may well be the
>_only_ reason for the K6-3 to outperform an equally-clocked cel.
Not good enough, unless you would assume that a K6-2 would also
outperform an equally clocked Cel.
Just remember the architectural differences as well---the K6-2 seems to
have faster backend execution units, better branch prediction and
possibly out of order execution, as well much lower latencies on jumps
due to its shorter pipeline.
>
>>and the
>> K6-III enjoys the presence of an L3 cache from the motherboard, which
>> can be as big as a 1MB. <interrupted + rest snipped away>
>
>Disable the L3 cache via the BIOS.
>Benchmark both settings (on and off).
>Notice _no_ difference above measurement uncertainity...
If you have a benchmark that specifically measures memory performance,
you may see your figures cut in half. I can't remember where I saw this
benchmark.
Rgds,
Chris
>
>Marc
>
>--
>Marc Mutz <[EMAIL PROTECTED]> http://marc.mutz.com/
>University of Bielefeld, Dep. of Mathematics / Dep. of Physics
>
>PGP-keyID's: 0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)
>
>
(And the NUMBER ONE top oxy-MORON
1. Microsoft Works
---From the Top 50 Oxymorons (thanks to Richard Kennedy)
------------------------------
From: [EMAIL PROTECTED] (JeremyDunn)
Subject: Re: SCSI v. IDE boot conflict (Linux-only system)
Date: 10 Jul 1999 23:53:07 GMT
Ok, thanks to all who provided what seemed like the right solution. (I actually
found this myself after my initial posting). I did finally get something to
work, but not what I thought. So, for those of us who really like to
understand what's going on, can anybody describe why the first few solutions I
tried *didn't* work, but the last one did?
Background: brand new Socket-7 motherboard (Epox) with new (3/1/99) Award BIOS.
K62/400. Originally, 1 SCSI disk (IN-2000 controller) with LILO in MBR of
/dev/sda. BIOS boot order set to SCSI, A, C. Only Linux (SuSE 6.0) on this
machine. Boots fine.
(Note, after each step below, as appropriate I did of course run /sbin/lilo. )
1. Added IDE drive on secondary/master IDE. Left boot sequence as SCSI, A, C.
On boot, BIOS says "no active partition on HDD". I assume it means the IDE.
2. changed lilo.conf, using the disk/bios args, to tell LILO hard drive
sequence is swapped at boot. same thing as above, BIOS can't find any active
partition.
3. formatted IDE drive, partitioned into 4. Removed disk/bios stuff from
lilo.conf, and put boot=/dev/hdc (MBR of IDE drive). Changed BIOS boot
sequence to C, SCSI, A. On boot, same thing, BIOS *still* can't see the MBR of
*either* drive, despite the fact that LILO is in both of them.
4. Since I have IDE on secondary IDE controller, tried boot sequence of D,
SCSI; E, SCSI; F, SCSI. Same thing. BIOS can't find any bootable partition.
5. Using fdisk, made 1st partition of IDE bootable. Changed lilo.conf to put
LILO on /dev/hdc1. Left boot sequence as C, SCSI. This time, got 'LI' then
failure. Couldn't get past it.
6. (finally!) Made 1st partition of SCSI bootable, using fdisk. Put the
disk/bios stuff back in lilo.conf. Put lilo in /dev/sda1. (now it is in 4
places!) Switched BIOS to boot SCSI, C, A. Now it works.
So the question is, why wouldn't the dumb BIOS see the MBR of either the SCSI
or the IDE drive, with both drives installed (even with the lilo args set to
match the switched BIOS disk order)? And why wouldn't it boot from the first
partition of the IDE drive? Of course, I have a working, bootable system at
this point using (6), but don't understand what went wrong in (3, 4, or 5).
Chris, Rich, and/or others, your insghts awaited....
- Jeremy
==========
>The problem is that with both IDE and SCSI present LILO (and therefore
>Linux) maps the IDE drives first unless you tell it specifically otherwise.
>A nice description of the LILO parameters to use is here:
>http://www.suse.de/Support/sdb_e/ke_eide-scsi.html
>Chris Kuhi
========
>Jeremy,
>I am surprised at the number of times this question comes up!
>Try reading:
>http://metalab.unc.edu/LDP/HOWTO/mini/LILO-4.html
>and see if that solves your problem. The answer is towards the end of the
page.
>Rich Piotrowski
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.hardware) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Hardware Digest
******************************
