Linux-Hardware Digest #426, Volume #12            Wed, 8 Mar 00 02:13:06 EST

Contents:
  VIA vs Intel chipsets - which is better? (Jim Cochrane)
  PIII vs PIII E - which is faster? (Jim Cochrane)
  Re: Parrallel port not found ([EMAIL PROTECTED])
  Digital Cameras and Linux (Tom Rosso)
  Re: PIII vs PIII E - which is faster? (Zamboni)
  NEC Superscript 660 Plus printer compatible with Red Hat 6.0? (Dan Werner)
  Re: NeoMagic MagicMedia 256XL+ ---- IT WORKS ([EMAIL PROTECTED])
  SMP how to benchmark them ("gongtow")
  Re: PIII vs PIII E - which is faster? ("MW")
  Ensoniq Soundscape VIVO in RH5.2 (Teryk Morris)
  Re: HP DDS Tape ("Gene Heskett")
  Re: SCSI tape drive ("Gene Heskett")
  Re: SCSI tape drive, device not ready ("Gene Heskett")
  Re: VIA vs Intel chipsets - which is better? ("Dean_Kent")
  Re: VIA vs Intel chipsets - which is better? (Dave Simmons)

----------------------------------------------------------------------------

From: [EMAIL PROTECTED] (Jim Cochrane)
Crossposted-To: comp.sys.ibm.pc.hardware.chips,comp.sys.ibm.pc.hardware.systems
Subject: VIA vs Intel chipsets - which is better?
Date: 7 Mar 2000 21:33:06 -0700

While calling a couple computer shops today to look into upgrading my
current system to a PIII motherboard, I came across an interesting
dilemna - essentially, two shops I talked to gave two different
opinions on chipsets available for Pentium III motherboards.

I'm posting here to get y'all's opinions on these issues, but I think
it may also serve as an interesting (and possibly controversial) topic
of discussion.  (Perhaps it has already been covered here and is old
hat; but unfortunately, my main machine is in the shop and I can't
access the web to look at dejanews with my 486.)

The disagreement is on the quality of the non-Intel VIA chipset
versus the quality of the Intel chipsets.  According to one shop, the
VIA chipset is much more buggy than the Intel chipsets (BX3 and I820, I
believe) and that this can potentially cause problems running a Linux
kernel (my intended OS).  The fellow with this point of view stated
that the kernel has a lot of patches applied to work around bugs in the
VIA chipset.  He acknowledged that the Intel chipsets had some bugs,
but not nearly as many as the VIA chipset.

The fellow with the opposite opinion stated that this was false.  He
essentially stated that there may be some bugs in both the VIA chipset
and the Intel chipsets, but that these bugs should not affect the linux
kernel and thus will not cause problems.  (He also said he had
installed Linux on several such systems (VIA) and had not run into any
problems with respect to the chipset.)

Which of these opinions is correct?  Or are they both partly right and
partly wrong?  (With respect to my hardware upgrade, the questions, of
course, boils down to whether to purchase a VIA-based board, such as
Tyan, or an Intel-based board, such as a Supermicro.)

[For those interested, I have also posted a question about another issue
I came across with the same two shops - see the subject line "PIII vs PIII
E - which is faster?"]

[Apologies for any errors in terminology - as you can tell, I'm not a
hardware dude.]
-- 
Jim Cochrane
[EMAIL PROTECTED]

------------------------------

From: [EMAIL PROTECTED] (Jim Cochrane)
Crossposted-To: comp.sys.ibm.pc.hardware.chips,comp.sys.ibm.pc.hardware.systems
Subject: PIII vs PIII E - which is faster?
Date: 7 Mar 2000 21:38:48 -0700

While calling a couple computer shops today to look into upgrading my
current system to a PIII motherboard, I came across an interesting
dilemna - essentially, two shops I talked to gave two different
opinions on two different types of Pentium III processors.

I'm posting here to get y'all's opinions on these issues, but I think
it may also serve as an interesting (and possibly controversial) topic
of discussion.  (Perhaps it has already been covered here and is old
hat; but unfortunately, my main machine is in the shop and I can't
access the web to search at dejanews with my 486.)

The basic disagreement is on the E series of Pentium III processors (E
and EB chips) versus the non-E series (Pentium III and Pentium IIIB).
The fellow at the first shop stated that the E series chip is a socket
370 (PPGA - flip) and that it was a lower-end chip than the non-E
series and that the E chips were slower than the non-E chips.

The fellow at the second shop pointed out that there are two versions
of the E series chip - the socket 370-type chips and, like the non-E
chips, slot-1-type chips.  He also stated that the E series is not
lower end - that these chips are faster than the non-E chips.  The
reason he gave was that the E chips, although they have a smaller
(256K) cache, have a bus speed (CPU register to cache RAM) that is the
same as the processor speed (e.g., 600MHz for a PIII E 600 chip), while
the non-E chips have a bus speed that is half the processor speed.
(Also, to add more confusion to the issue, another shop I talked to
said that Intel had switched from socket 370 to slot 1 chips, but that
they have recently switched back to socket 370 chips - so that the
newest motherboards (not sure if any are available yet) will need to
support the socket 370 rather than the slot 1 chips.)

Does anyone have any informed opinions or, better yet, hard facts
supporting either side of the issue?  Or is the issue more complex and
are both sides right on some aspects and wrong on others?  I find this very
confusing, but I also find it fascinating - that the details are so
complicated that not even "experts" are able to discern them accurately.

[For those interested, I have also posted a question about another issue
I came across with the same two shops - see the subject line "VIA vs
Intel chipsets - which is better?"]

[Apologies for any errors in terminology - as you can tell, I'm not a
hardware dude.]
-- 
Jim Cochrane
[EMAIL PROTECTED]

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: Parrallel port not found
Date: Tue, 07 Mar 2000 22:41:48 -0600

Do you have parport lines in your conf.modules?

I needed to add:
alias parport_lowlevel parport_pc
options parport_pc io=0x378 dma=1 irq=3

after this is correct run as root:
modprobe parport_probe
cat /proc/parport/0/hardware
cat /proc/parport/0/autoprobe

if the output from hardware looks like your port then parport is working.
if the output from autoprobe looks like your printer then it's talking to it.

this should give you an idea of where the problem is.

the port will be 0 even though it used to be 1, the new kernel numbers them in the 
order they are started


 
In article <ifdx4.24$[EMAIL PROTECTED]>, "David S. DeWitt" 
<[EMAIL PROTECTED]> wrote:
> Parrallel port problems:
> 
> I'm running Redhat 6.1 and it is having problems find the parrallel port.  I
> am unable to print directly to the port, the printer setup utility in
> Control panel can not detect any port.  It check lp0,lp1,lp2.  If I put in a
> bootable dos disk I can print.  So this eliminates bad hardware.  I was able
> to print when this machine ran RH5.2.  I check the bios settings.  the port
> was set at i/o 0x378  (lp1)  type I don't remember what it was at but I
> change it to standard. (to no avail)   So Hopefully some has an inspiring
> thought on this.
> 
> Thanks for any help
> David DeWitt
> 
> PS has anyone been able to get an adaptec 1520b scsi card to work?
> 
> 



------------------------------

Subject: Digital Cameras and Linux
From: Tom Rosso <[EMAIL PROTECTED]>
Date: Tue, 07 Mar 2000 20:43:42 -0800

Hello,
I have a Fujifilm MX-1200 digital camera that connects to the
back of my computer via a serial port.  The software for this
camera has Windows 98/NT and Mac versions, but the authors didn't
have the forsight to include Linux software.  Basically, from
what I can tell, it connects using some kind of Twain driver so
it can be accessed from Photoshop and Corel Draw and all of those
other wonderful expensive and buggy graphics programs.  Does
anybody have any experience hooking up this camera, or any
Fujifilm MX-series camera, or any digital camera in general, to
Linux.  I'm currently running Mandrake 7, which is compatable
(sort of) with RedHat.  Any input would be appreciated.  Thanks!
-Tom


* Sent from RemarQ http://www.remarq.com The Internet's Discussion Network *
The fastest and easiest way to search and participate in Usenet - Free!


------------------------------

From: Zamboni <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.sys.ibm.pc.hardware.chips,comp.sys.ibm.pc.hardware.systems
Subject: Re: PIII vs PIII E - which is faster?
Date: Tue, 07 Mar 2000 21:22:29 -0800

Jim Cochrane wrote:
> 
(snipped)
> 
> Does anyone have any informed opinions or, better yet, hard facts
> supporting either side of the issue?  Or is the issue more complex and
> are both sides right on some aspects and wrong on others?  I find this very
> confusing, but I also find it fascinating - that the details are so
> complicated that not even "experts" are able to discern them accurately.
> 

First step would be to find another shop to buy parts from. If they
can't give straight answers about their stock, they don't deserve your business.

(still working on the rest of the answer, unless someone beats me to it)

--
Zamboni

------------------------------

From: Dan Werner <[EMAIL PROTECTED]>
Subject: NEC Superscript 660 Plus printer compatible with Red Hat 6.0?
Date: Wed, 08 Mar 2000 00:32:41 -0500

I saw in the printing howto that my NEC Superscript 660 Plus is
imcompatible
with Red Hat.

I"m hoping that someone has found a way to make it work since the howto
was written.  Has anyone had success with this printer on Red Hat?

I thought I'd check before I threw it out the window.

Thanks for any help,
Dan Werner


------------------------------

From: [EMAIL PROTECTED]
Subject: Re: NeoMagic MagicMedia 256XL+ ---- IT WORKS
Date: Wed, 08 Mar 2000 05:28:20 GMT

After re-installing tonight with Redhat 6.1, and it not setting up X
correctly, I decided to give XF86Setup a shot... It probably would have
worked if I had let it probe for video memory, but I told it I had
6mb... so no luck right away.

BUT... after messing around with the XF86Config file, I was able to get
X running on my XG18!! Right now, it is basically configured as the
256AV chipset would be.

For all of you out there, X doesn't seem to like 6mb of memory
specified in the XF86Config file. This is what made me think none of it
would work. However, commenting out the video memory line, X starts. I
did some testing also, and it seems the driver can only handle up to
4mb specified in the setup file for some reason...

BTW, thanks to Jason Grenier for the tip.

--jason



In article <[EMAIL PROTECTED]>,
  Jason Grenier <[EMAIL PROTECTED]> wrote:
> This is a multi-part message in MIME format.
> --------------DB7230716B6DDC736B94895B
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> Run XF86Setup. Choose under card the neomagic notebook/laptop. Then
click
> detailed. Choose the NM2200 Chipset.
>
> Steve Molitor wrote:
>
> > Does anyone know if the XFree people plan to support this card in
4.0?
> >
> > Laptop:
> >         Sony VAIO PCG-XG18
> > Chipset:
> >         NeoMagic MagicMedia 256XL+
> >         6MB VRAM
> >         1024x786 24bpp
> >         (128-bit Accelerator and MPEG Playback Acceleration)
> >
> > Thanks!
> >
> > --
> > Steve Molitor
> > [EMAIL PROTECTED]
> > "Emacs is the Computer"
>
> --------------DB7230716B6DDC736B94895B
> Content-Type: text/x-vcard; charset=us-ascii;
>  name="jasong.vcf"
> Content-Transfer-Encoding: 7bit
> Content-Description: Card for Jason Grenier
> Content-Disposition: attachment;
>  filename="jasong.vcf"
>
> begin:vcard
> n:Grenier;Jason
> tel;work:613-728-0826 ext 1739
> x-mozilla-html:TRUE
> url:linux.corel.com
> org:Corel Corporation;Emerging Technologies
> adr:;;1600 Carling Ave;Ottawa;Ontario;K1Z 8R7;Canada
> version:2.1
> email;internet:[EMAIL PROTECTED]
> title:Corel Linux OEM Engineering
> fn:Jason Grenier
> end:vcard
>
> --------------DB7230716B6DDC736B94895B--
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

------------------------------

From: "gongtow" <[EMAIL PROTECTED]>
Subject: SMP how to benchmark them
Date: Wed, 8 Mar 2000 13:49:08 +0800

Hello all linuxer:

I am new in this field. My company want to install a web server.
I am in charge of this project. I am trying to convice my boss to
use  dual CPU system.

O.K. he ask me a question:
Give me the performance benchmark report and I will make decision!!!

I convinced him to use Linux. But, how to benchmarking a SMP
system and a single CPU system on linux platform.

I found nbench program on the web. But it only test the performance
of single CPU system.

I can only wrote shell script. What can I do now?

Willis chen



------------------------------

From: "MW" <[EMAIL PROTECTED]>
Crossposted-To: comp.sys.ibm.pc.hardware.chips,comp.sys.ibm.pc.hardware.systems
Subject: Re: PIII vs PIII E - which is faster?
Date: Tue, 7 Mar 2000 21:55:19 -0800

The second shop-keeper was correct.

E series (Intel codename "Coppermine") has smaller, but faster cache which
"usually" makes it faster.  Intel moved from the Socket7 PGA package to the
SECC package with the advent of the Pentium II to allow integration of the
Level 2 cache with the CPU, and with the Coppermine integrated the cache on
the same die as the CPU circuitry, thus obviating the need for a card-type
carrier.  To save money, intel is going back to a socket design called
socket370. For the time being, E series is available in PGA and SECC
packages.

Lots more info on the packages available at
http://developer.intel.com/design/PentiumIII/prodbref/

Jim Cochrane wrote in message <8a4lgp$[EMAIL PROTECTED]>...
>The basic disagreement is on the E series of Pentium III processors (E
>and EB chips) versus the non-E series (Pentium III and Pentium IIIB).
>The fellow at the first shop stated that the E series chip is a socket
>370 (PPGA - flip) and that it was a lower-end chip than the non-E
>series and that the E chips were slower than the non-E chips.
>
>The fellow at the second shop pointed out that there are two versions
>of the E series chip - the socket 370-type chips and, like the non-E
>chips, slot-1-type chips.  He also stated that the E series is not
>lower end - that these chips are faster than the non-E chips.  The
>reason he gave was that the E chips, although they have a smaller
>(256K) cache, have a bus speed (CPU register to cache RAM) that is the
>same as the processor speed (e.g., 600MHz for a PIII E 600 chip), while
>the non-E chips have a bus speed that is half the processor speed.


>(Also, to add more confusion to the issue, another shop I talked to
>said that Intel had switched from socket 370 to slot 1 chips, but that
>they have recently switched back to socket 370 chips - so that the
>newest motherboards (not sure if any are available yet) will need to
>support the socket 370 rather than the slot 1 chips.)




------------------------------

From: Teryk Morris <[EMAIL PROTECTED]>
Subject: Ensoniq Soundscape VIVO in RH5.2
Date: Tue, 07 Mar 2000 22:00:33 -0800
Reply-To: [EMAIL PROTECTED]

I'm fairly new to Linux and am trying to configure the sound card
mentioned in the subject. sndconfig recognizes the card as "Ensoniq
Soundscape" but gets device busy errors when attempting to configure it.
Manually configuring it(using sndconfig) doesn't allow me to set the
right DMA for channel 0. The card requires 0x534 according the the
refman (this is also what it uses in NT). pnpdump gives the same
results. 

I tried modifying /etc/isapnp.conf to specify (IO 0 (BASE 0x534)) and
reran ran isapnp. I also modified conf.modules to specify the correct
address, but I still get device busy errors on boot.

One last thing the HCL for 6.1 doesn't say anything special about a
SoundScape VIVO card but I found this screenshot of 6.1 sndconfig.

http://www.redhat.com/support/manuals/RHL-6.0-Manual/getting-started-guide/gsg/doc037.html

Is there a new module for this card in 6.1? If so is it possible to load
this module in the 2.0.x kernal or do I need to upgrade?

-Teryk

------------------------------

Date: 8 Mar 2000 0:43:23 -0500
From: "Gene Heskett" <[EMAIL PROTECTED]>
Subject: Re: HP DDS Tape

Unrot13 this;
Reply to: <[EMAIL PROTECTED]>

Gene Heskett sends Greetings to Agust� Vil�;

 AVi> Hi,

 AVi> I am using one HP Surestore 2000 external SCSI tape with a SuSE
 AVi> 6.3 linux box. All run ok except that I have to boot the PC with
 AVi> the tape turned on. If I have the tape turned off when booting,
 AVi> it is no detected. Can I detect it later ?

 AVi> Please, can anyone help me ?
 AVi> Thanks

I'd like to do this 'after the fact' too, but RH6.0 etc also has to see
it at bootup time.  Then of course, you can turn it off till needed, or
at least I can.  Be aware that any attempt to access it when its been
turned off will result in a 'device not configured' message good until
the next reboot.


Cheers, Gene
-- 
  Gene Heskett, CET, UHK       |Amiga A2k Zeus040, Linux @ 400mhz 
    Ch. Eng. @ WDTV-5          |This Space for rent
         RC5-Moo! 350kkeys/sec, Seti@home 16 hrs a block
                        email gene underscore heskett at iolinc dot net
This messages reply content, but not any previously quoted material, is
� 2000 by Gene Heskett, all rights reserved.
-- 


------------------------------

Date: 8 Mar 2000 0:48:25 -0500
From: "Gene Heskett" <[EMAIL PROTECTED]>
Subject: Re: SCSI tape drive

Unrot13 this;
Reply to: <[EMAIL PROTECTED]>

Gene Heskett sends Greetings to Gunnar Lindholm;

 GL> Hello.
 GL> I will soon install a HP Sure Store T70 in a Linux box, so I have
 GL> two questions:

 GL> 1) Can someone tell me something (in general) about how to manage
 GL> a SCSI tape drive. Can I rewind, multiple sessions on one tape, 
 GL> etc,...

 GL> 2) Does any body know anything about this  HP Sure Store T70. It
 GL> is scsi, that is all I know right now. Please respond with email
 GL> aswell to [EMAIL PROTECTED]

 GL> Best wishes
 GL> Gunnar.

Not about the surestore, but a backup driver for it.  taper-6.9b.tar.gz
from www.e-survey.net/au/taper looks like what I've been looking for for
a long time.  There are pretty good tutorials in the manpages for dump
and restore, and the routines described are valid proceedures for any
backup regimen.  Taper has the best 'utility' IMO.

Cheers, Gene
-- 
  Gene Heskett, CET, UHK       |Amiga A2k Zeus040, Linux @ 400mhz 
    Ch. Eng. @ WDTV-5          |This Space for rent
         RC5-Moo! 350kkeys/sec, Seti@home 16 hrs a block
                        email gene underscore heskett at iolinc dot net
This messages reply content, but not any previously quoted material, is
� 2000 by Gene Heskett, all rights reserved.
-- 


------------------------------

Date: 8 Mar 2000 0:40:25 -0500
From: "Gene Heskett" <[EMAIL PROTECTED]>
Subject: Re: SCSI tape drive, device not ready
Crossposted-To: comp.os.linux.setup

Unrot13 this;
Reply to: <[EMAIL PROTECTED]>

Gene Heskett sends Greetings to Paul Lew;

 PL> Some "older" type scsi adapters ""always"" assume that id 0 and 1 are for
 PL> hard disks....

Its an oddity I would not have thought of, probably preserved by some
POS in the elderly category of the pc world.

The reason I wouldn't even have considerd it is because I always put the
removable stuff like the cdrom and tape at 0 or 1, and the drives above
that.

Why?  Simple (on this machine).  Its bootup time includes the time to
scan all devices and luns on a scsi bus if one is found.

Now, to  speed this up since they waste a second each, or potentially 49
seconds just doing that, there is in the Rigid Disk Blocks area of each
*disk* device, a flag that says there are no more luns on this device, so
it doesn't scan the rest of this one, but goes on to the next higher
addressed device.  There is also a 'last device' flag which if set, says
the scan is over, no more devices are attached.

If I put the tape or cdrom above the disks, then it would not get these
flags, (or it would, and stop the scan before it found the tape or
cdrom) and would scan the remaining addresses and luns wasting all that
time.  So here, the cdrom is 0, and the tape is 1 when on this machine,
or zero on the linux box which has a small scsi disk at 1, but which is
now on the old card, with the tape drive on the new one.  Works
flawlessly.

I might add, FYI, that it appears a part of my problem was an expired
bru.  When expired, its thoroughly busted without telling you its
expired. 

Once I had a decent card, not that there should be anything wrong with
the *next* aha1540, but now with the advansys ABP930u dump/restore is
working without any problems that I can see other than the limitations
of dump/restore itself.  Dump seems to work ok, but is limited to one
partition per command line issued.  Scripting will of course get around
that, and I have one written now.  But...  Next I'm gonna try
taper-6.9b, it looks pretty good in the readme's at least.  It appears
to have a basic framework that resembles Diavolo Pro on this amiga, and
thats one plumb decent program.

>>I don't understand it either, Gene, but it worked.  I changed the
>>Dat address (SCSI ID) from 0 to 4, now it works fine :)

Mine did work at address zero for several months on that driver card.
Dump and tar now also fail _on that card_.  Disks work great. Odd indeed.

Cheers, Gene
-- 
  Gene Heskett, CET, UHK       |Amiga A2k Zeus040, Linux @ 400mhz 
    Ch. Eng. @ WDTV-5          |This Space for rent
         RC5-Moo! 350kkeys/sec, Seti@home 16 hrs a block
                        email gene underscore heskett at iolinc dot net
This messages reply content, but not any previously quoted material, is
� 2000 by Gene Heskett, all rights reserved.
-- 


------------------------------

From: "Dean_Kent" <[EMAIL PROTECTED]>
Subject: Re: VIA vs Intel chipsets - which is better?
Date: Tue, 7 Mar 2000 22:07:34 -0800
Crossposted-To: comp.sys.ibm.pc.hardware.chips,comp.sys.ibm.pc.hardware.systems

Jim Cochrane <[EMAIL PROTECTED]> wrote in message
news:8a4l62$[EMAIL PROTECTED]...
> While calling a couple computer shops today to look into upgrading my
> current system to a PIII motherboard, I came across an interesting
> dilemna - essentially, two shops I talked to gave two different
> opinions on chipsets available for Pentium III motherboards.

Let me guess...

>
> I'm posting here to get y'all's opinions on these issues, but I think
> it may also serve as an interesting (and possibly controversial) topic
> of discussion.  (Perhaps it has already been covered here and is old
> hat; but unfortunately, my main machine is in the shop and I can't
> access the web to look at dejanews with my 486.)

Um, I'll bet one said VIA is buggy and the other said VIA is not-so-bad...

>
> The disagreement is on the quality of the non-Intel VIA chipset
> versus the quality of the Intel chipsets.  According to one shop, the
> VIA chipset is much more buggy than the Intel chipsets (BX3 and I820, I
> believe) and that this can potentially cause problems running a Linux
> kernel (my intended OS).  The fellow with this point of view stated
> that the kernel has a lot of patches applied to work around bugs in the
> VIA chipset.  He acknowledged that the Intel chipsets had some bugs,
> but not nearly as many as the VIA chipset.
>
> The fellow with the opposite opinion stated that this was false.  He
> essentially stated that there may be some bugs in both the VIA chipset
> and the Intel chipsets, but that these bugs should not affect the linux
> kernel and thus will not cause problems.  (He also said he had
> installed Linux on several such systems (VIA) and had not run into any
> problems with respect to the chipset.)

Yup.   Sounds like one of the religious wars fought here in the past...

>
> Which of these opinions is correct?  Or are they both partly right and
> partly wrong?  (With respect to my hardware upgrade, the questions, of
> course, boils down to whether to purchase a VIA-based board, such as
> Tyan, or an Intel-based board, such as a Supermicro.)

Here is my opinion - VIA had some problems with AGP implementation (don't
know all the details) with their SS7 chipset, but worked them out
eventually, AFAIK.   Unfortunately, once a reputation is gained, it is near
impossible to shake (just ask AMD).    The current crop of Apollo Pro
chipsets (133 and 133A) also had some AGP issues, but that was before they
were released to the public (OEM samples only).   These have been all but
completely fixed.   The only issue left is that the video transfer rates are
slightly slower than Intel's (BX and i820).

When you consider that almost 50% of all Pentium II/III motherboards shipped
today to OEMs are VIA Apollo Pro based, it should tell you something...

Now, here are your choices, IMO:

Intel 440BX - tried and true.  Currently fastest of all chipsets, overall.
Limited to 2x AGP and UDMA/33 (though some manufacturers have 3rd party IDE
controllers to add UDMA/66).   Officially supports only 66MHz and 100MHz
FSB, and takes PC100 SDRAM (though many manufacturers implement 133MHz FSB -
some with 1/4 PCI divisor).  If overclocking, AGP speed is 2/3 of CPU speed,
so that could cause problems.

Intel i820 - almost as fast as the BX and has 4x AGP and UDMA/66 support.
Supports 133MHz FSB.  Unfortunately, it only accepts RDRAM in it's 'natural'
state.   To support SDRAM, it requires a 'Memory Translator Hub' chip, which
slows down perfomance and only officially supports 100MHz FSB.    More
expensive than BX solutions.

VIA Apollo Pro133 or Pro133A - Almost as fast as BX (about the same as the
i820, even at 100MHz FSB).   Supports AGP 4x and UDMA/66.   Also officially
supports 133MHz FSB, and has a better 'PCI/AGP divisor' scheme for
overclockers.   If the system is primarily for 3D games, it will be slightly
slower than a BX based board because the video transfer rate is a bit
slower.   Depending upon application, it could be 5% to 10% slower than BX
based board.

Can't speak to the Linux issue.   I can't imagine why it would be a problem,
considering Intel licensed the P6 design to VIA so there shouldn't be any
compatibility problems to speak of...

>
> [For those interested, I have also posted a question about another issue
> I came across with the same two shops - see the subject line "PIII vs PIII
> E - which is faster?"]

I'll render an opinion on that here as well...

The Coppermine processors have a 256K full speed L2 cache that is 'wider'
than the Klamath processors 512K 1/2 speed cache.  It has a higher initial
latency, but better overall throughput.  Net result is that the Cu
processors are faster.   FSB is the same (memory to CPU), it is the cache
speed that is different (BSB).

Intel went to Socket 370 for Celeron early, because that was the 'low-end'
processor, and Socket 370 saves bucks over the Slot 1 design.   They are now
going to Socket 370 for *all* processors - and very soon, reportedly.
PIII processors using Socket 370 have a lower voltage than the Celerons
(1.6v vs. 2.0 v, I believe).

>
> [Apologies for any errors in terminology - as you can tell, I'm not a
> hardware dude.]

I'm sure that others will give their input, and correct any errors I may
have made (as well as give any opinions that differ from mine)... :-)

Regards,
    Dean

> --
> Jim Cochrane
> [EMAIL PROTECTED]



------------------------------

From: [EMAIL PROTECTED] (Dave Simmons)
Crossposted-To: comp.sys.ibm.pc.hardware.chips,comp.sys.ibm.pc.hardware.systems
Subject: Re: VIA vs Intel chipsets - which is better?
Date: Tue, 7 Mar 2000 22:21:49 -0800

For many apps, BX with PC100 actually tests better than
820 (with SIMMs) and VIA with PC133.  Since BX motherboards
have gone through several revisions there also has been 
plenty of time to get the kinks out.  So BX is a win-win
situation for you.

A good source of reviews that might help you:
        www.anandtech.com

Of course someone here will point out you can get an
Athlon 700 for less than an Intel 600.

---Dave

------------------------------


** 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
******************************

Reply via email to