Sign in with
Sign up | Sign in
Your question

SATA performance vs standard IDE for small database server

Last response: in Storage
Share
May 5, 2004 7:22:20 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

I'm looking at building a small database box for departmental use and
am curious if anyone has looked into if SATA would work better than
standard IDE for an application with a good number of simultaneous
read/write requests. There's a box doing something similar right now
in the office with regular IDE and I am very dissatisfied with its
performance. At certain times of the day it'll seem to freeze (even
in a shell!) for 2-3 seconds while it processes a lot of drive I/O.
Is this partially alleviated with SATA, or not really?

SCSI would be the way to go, but it's not in the budget for the spec,
sadly.

Thanks
Barclay McInnes
Anonymous
a b G Storage
May 6, 2004 2:34:47 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Bib" <bib@soreo.com> wrote in message
news:10qi901a8sj7rqe22o1b2kthps66lj0l8g@4ax.com...
> I'm looking at building a small database box for departmental use and
> am curious if anyone has looked into if SATA would work better than
> standard IDE for an application with a good number of simultaneous
> read/write requests.

SATA vs std IDE isn't the issue. The speed of the HD is the issue. The
fastest ATA HD is the WDC Raptor and it happens to be SATA. Use Raptors.

> There's a box doing something similar right now
> in the office with regular IDE and I am very dissatisfied with its
> performance. At certain times of the day it'll seem to freeze (even
> in a shell!) for 2-3 seconds while it processes a lot of drive I/O.
> Is this partially alleviated with SATA, or not really?

Use Raptors.

> SCSI would be the way to go, but it's not in the budget for the spec,
> sadly.
>
> Thanks
> Barclay McInnes
>
Anonymous
a b G Storage
May 6, 2004 3:11:04 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Previously Bib <bib@soreo.com> wrote:
> I'm looking at building a small database box for departmental use and
> am curious if anyone has looked into if SATA would work better than
> standard IDE for an application with a good number of simultaneous
> read/write requests. There's a box doing something similar right now
> in the office with regular IDE and I am very dissatisfied with its
> performance. At certain times of the day it'll seem to freeze (even
> in a shell!) for 2-3 seconds while it processes a lot of drive I/O.
> Is this partially alleviated with SATA, or not really?

Not with the current generation. Command queuing is only in the next
SATA standard. It is also doubtful whether it will reach SCSI's
performance level, IMO. Today SATA gives you about the performance of
IDE, with some problems thrown in for a not entirely mature
technology.

> SCSI would be the way to go, but it's not in the budget for the spec,
> sadly.

More memory could also help. Or splitting the database over several
disks. Maybe also move to a different OS or differend database software.
What are you using?

An other problem is that good server performance and good interactive
responsiveness are two different things.

Arno
--
For email address: lastname AT tik DOT ee DOT ethz DOT ch
GnuPG: ID:1E25338F FP:0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
"The more corrupt the state, the more numerous the laws" - Tacitus
Related resources
Anonymous
a b G Storage
May 6, 2004 3:11:05 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Arno Wagner" <me@privacy.net> wrote in message
news:c7bsa8$25rpq$4@ID-2964.news.uni-berlin.de...
> Previously Bib <bib@soreo.com> wrote:
> > I'm looking at building a small database box for departmental use and
> > am curious if anyone has looked into if SATA would work better than
> > standard IDE for an application with a good number of simultaneous
> > read/write requests. There's a box doing something similar right now
> > in the office with regular IDE and I am very dissatisfied with its
> > performance. At certain times of the day it'll seem to freeze (even
> > in a shell!) for 2-3 seconds while it processes a lot of drive I/O.
> > Is this partially alleviated with SATA, or not really?
>
> Not with the current generation. Command queuing is only in the next
> SATA standard. It is also doubtful whether it will reach SCSI's
> performance level, IMO. Today SATA gives you about the performance of
> IDE, with some problems thrown in for a not entirely mature
> technology.

Native command queuing is available on current SATA drives. SiI has it in
their 3114 and 3124 controllers.

> > SCSI would be the way to go, but it's not in the budget for the spec,
> > sadly.
>
Management incompetence. You have to pay for performance. But not much more
than SATA Raptors.

> More memory could also help. Or splitting the database over several
> disks. Maybe also move to a different OS or differend database software.
> What are you using?
>
> An other problem is that good server performance and good interactive
> responsiveness are two different things.
>
Anonymous
a b G Storage
May 6, 2004 3:37:58 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Bib wrote:

> I'm looking at building a small database box for departmental use and
> am curious if anyone has looked into if SATA would work better than
> standard IDE for an application with a good number of simultaneous
> read/write requests. There's a box doing something similar right now
> in the office with regular IDE and I am very dissatisfied with its
> performance. At certain times of the day it'll seem to freeze (even
> in a shell!) for 2-3 seconds while it processes a lot of drive I/O.
> Is this partially alleviated with SATA, or not really?

Check that box and make sure that DMA is enabled for the drive that is
showing that response.

Now, that said, if you are using single SATA drives there's not going to be
a whole lot of difference due to SATA. However, there are some other
considerations--first, 10,000 RPM ATA drives are available only with SATA
interfaces, not PATA. Second, the latest generation of ATA RAID
controllers is available only for SATA--their performance should be better
than the previous generation. Between the two, you can get somewhat better
performance out of SATA than out of PATA.

> SCSI would be the way to go, but it's not in the budget for the spec,
> sadly.
>
> Thanks
> Barclay McInnes

--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)
Anonymous
a b G Storage
May 6, 2004 4:48:04 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Previously Eric Gisin <ericgisin@graffiti.net> wrote:
> "Arno Wagner" <me@privacy.net> wrote in message
> news:c7bsa8$25rpq$4@ID-2964.news.uni-berlin.de...
>> Previously Bib <bib@soreo.com> wrote:
>> > I'm looking at building a small database box for departmental use and
>> > am curious if anyone has looked into if SATA would work better than
>> > standard IDE for an application with a good number of simultaneous
>> > read/write requests. There's a box doing something similar right now
>> > in the office with regular IDE and I am very dissatisfied with its
>> > performance. At certain times of the day it'll seem to freeze (even
>> > in a shell!) for 2-3 seconds while it processes a lot of drive I/O.
>> > Is this partially alleviated with SATA, or not really?
>>
>> Not with the current generation. Command queuing is only in the next
>> SATA standard. It is also doubtful whether it will reach SCSI's
>> performance level, IMO. Today SATA gives you about the performance of
>> IDE, with some problems thrown in for a not entirely mature
>> technology.

> Native command queuing is available on current SATA drives. SiI has it in
> their 3114 and 3124 controllers.

Since it is the HDD that has to do the command queuing for it to be
effective (only the HDD knows its geometry and can improve performance
by reordering access), having it in the computer-side controller does
not help performance-wise. RAID-access optimisation (what I deduce
the Sil chips you mention have) is something else, since it is not HDD
specific.

>> > SCSI would be the way to go, but it's not in the budget for the spec,
>> > sadly.
>>
> Management incompetence. You have to pay for performance. But not much more
> than SATA Raptors.

Agreed here. Get SCSI or stay slow. It is something else if you have
mostly linear access. For heavy random access, SCSI is massively ahead
of (S)ATA.

Arno
--
For email address: lastname AT tik DOT ee DOT ethz DOT ch
GnuPG: ID:1E25338F FP:0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
"The more corrupt the state, the more numerous the laws" - Tacitus
Anonymous
a b G Storage
May 6, 2004 5:14:26 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Arno Wagner" <me@privacy.net> wrote in message news:c7bsa8$25rpq$4@ID-2964.news.uni-berlin.de...
> Previously Bib <bib@soreo.com> wrote:
> > I'm looking at building a small database box for departmental use and
> > am curious if anyone has looked into if SATA would work better than
> > standard IDE for an application with a good number of simultaneous
> > read/write requests. There's a box doing something similar right now
> > in the office with regular IDE and I am very dissatisfied with its
> > performance. At certain times of the day it'll seem to freeze (even
> > in a shell!) for 2-3 seconds while it processes a lot of drive I/O.
> > Is this partially alleviated with SATA, or not really?
>
> Not with the current generation.

> Command queuing is only in the next SATA standard.

Nonsense.

> It is also doubtful whether it will reach SCSI's performance level, IMO.

Your opinion obviously isn't worth a thing when you say things like that above.

> Today SATA gives you about the performance of IDE, with
> some problems thrown in for a not entirely mature technology.
>
> > SCSI would be the way to go, but it's not in the budget for the spec, sadly.
>
> More memory could also help. Or splitting the database over several
> disks. Maybe also move to a different OS or differend database software.
> What are you using?
>
> An other problem is that good server performance and good interactive
> responsiveness are two different things.
>
> Arno
Anonymous
a b G Storage
May 6, 2004 8:41:36 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Bib <bib@soreo.com> wrote in news:10qi901a8sj7rqe22o1b2kthps66lj0l8g@4ax.com:

> I'm looking at building a small database box for departmental use and
> am curious if anyone has looked into if SATA would work better than
> standard IDE for an application with a good number of simultaneous
> read/write requests. There's a box doing something similar right now
> in the office with regular IDE and I am very dissatisfied with its
> performance. At certain times of the day it'll seem to freeze (even
> in a shell!) for 2-3 seconds while it processes a lot of drive I/O.
> Is this partially alleviated with SATA, or not really?
>
> SCSI would be the way to go, but it's not in the budget for the spec,
> sadly.

Have you logged any system activity with perfmon?

Some databases can be optimized by using multiple disks. For example,
Microsoft has recommendations for configuring a SQL database, backups, and
logs across multiple disks.

I've seen SQL database performance improve by enabling caching on controllers
as well, specifically compaq scsi and fiberchannel arrays. But, caching is
sometimes not recommended for some applications.
Anonymous
a b G Storage
May 6, 2004 10:35:48 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Arno Wagner" <me@privacy.net> wrote in message news:c7c204$256md$1@ID-2964.news.uni-berlin.de...
> Previously Eric Gisin <ericgisin@graffiti.net> wrote:
> > "Arno Wagner" <me@privacy.net> wrote in message news:c7bsa8$25rpq$4@ID-2964.news.uni-berlin.de...
> >> Previously Bib <bib@soreo.com> wrote:
> >> > I'm looking at building a small database box for departmental use and
> >> > am curious if anyone has looked into if SATA would work better than
> >> > standard IDE for an application with a good number of simultaneous
> >> > read/write requests. There's a box doing something similar right now
> >> > in the office with regular IDE and I am very dissatisfied with its
> >> > performance. At certain times of the day it'll seem to freeze (even
> >> > in a shell!) for 2-3 seconds while it processes a lot of drive I/O.
> >> > Is this partially alleviated with SATA, or not really?
> >>
> >> Not with the current generation. Command queuing is only in the next
> >> SATA standard. It is also doubtful whether it will reach SCSI's per-
> >> formance level, IMO. Today SATA gives you about the performance of
> >> IDE, with some problems thrown in for a not entirely mature technology.
>
> > Native command queuing is available on current SATA drives. SiI has it in
> > their 3114 and 3124 controllers.
>
> Since it is the HDD that has to do the command queuing for it to be
> effective (only the HDD knows its geometry and can improve performance
> by reordering access),

What exactly did you not get in:
"Native command queuing is available on current SATA drives"?

> having it in the computer-side controller does not help performance-wise.

It does when it keeps tag (pun intented) of the outstanding IO instead of
the CPU.

> RAID-access optimisation (what I deduce the Sil chips you mention have)
> is something else, since it is not HDD specific.

Deduce all you want.

>
> >> > SCSI would be the way to go, but it's not in the budget for the spec, sadly.
> >>
> > Management incompetence. You have to pay for performance. But not much more
> > than SATA Raptors.
>
> Agreed here. Get SCSI or stay slow.

The second Raptor is just as fast as any other 10k rpm SCSI.
You won't get 15k rpm SCSI for 10k rpm prices.

> It is something else if you have mostly linear access. For heavy random access,
> SCSI is massively ahead of (S)ATA.

LOL. Time for bed, Arnie, you're obviously loosing it.

>
> Arno
Anonymous
a b G Storage
May 8, 2004 4:37:35 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

In article <10qi901a8sj7rqe22o1b2kthps66lj0l8g@4ax.com>,
bib@soreo.com says...
> I'm looking at building a small database box for departmental use and
> am curious if anyone has looked into if SATA would work better than
> standard IDE for an application with a good number of simultaneous
> read/write requests. There's a box doing something similar right now
> in the office with regular IDE and I am very dissatisfied with its
> performance. At certain times of the day it'll seem to freeze (even
> in a shell!) for 2-3 seconds while it processes a lot of drive I/O.
> Is this partially alleviated with SATA, or not really?
>
> SCSI would be the way to go, but it's not in the budget for the spec,
> sadly.
>

SATA/PATA really won't make a diff. Specs that matter
are access times (under 8ms is best) along with 8MB
caches. RPMs matter more for long-duration transfer
rates (which may or may not matter).

Raptors are probably a good bet (I don't know their
specs off hand).

3 year warranty is also a must.

The problems with "freezing" that you're experiencing is
a problem with your motherboard chipset (most likely).
I have a VIA motherboard here that is *horrible* about
doing multiple things at once when compared to my older
Abit KT7-RAID which handles multiple PCI activities
without a hitch.

RAID1 is a must for a departmental file server...
ideally with a hot spare drive.

So make sure you get a good quality motherboard (Tyan),
preferably with 64bit PCI slots to match up with a
*quality* PATA/SATA raid controller (e.g. the 3Ware
Escalades). A good server motherboard will cost $250 or
so (anyone seen cheaper?) and the 3Ware 2-port Escalade
7000-2 PCI raid card can be had for $100. Or get the 4-
port SATA PCI card ($300 or so) along with the hot-swap
bays ($250) and do a RAID5 setup with a hot-spare.

Pricing for all that will probably run around $2500-
$3000 for a 4 drive system, good case, good motherboard,
drives and the RAID card. Equivalent SCSI solution
would be more like $5500-$7500.
Anonymous
a b G Storage
May 9, 2004 4:22:34 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Toshi1873" <toshi1873@nowhere.com> wrote in message
news:MPG.1b06d6785d7bb08c9898b7@news-50.giganews.com...
> In article <10qi901a8sj7rqe22o1b2kthps66lj0l8g@4ax.com>,
> bib@soreo.com says...
> > I'm looking at building a small database box for departmental use and
> > am curious if anyone has looked into if SATA would work better than
> > standard IDE for an application with a good number of simultaneous
> > read/write requests. There's a box doing something similar right now
> > in the office with regular IDE and I am very dissatisfied with its
> > performance. At certain times of the day it'll seem to freeze (even
> > in a shell!) for 2-3 seconds while it processes a lot of drive I/O.
> > Is this partially alleviated with SATA, or not really?
> >
> > SCSI would be the way to go, but it's not in the budget for the spec,
> > sadly.
> >
>
> SATA/PATA really won't make a diff. Specs that matter
> are access times (under 8ms is best) along with 8MB
> caches. RPMs matter more for long-duration transfer
> rates (which may or may not matter).

NO, RPM matters most for average access time and NOT for STR..
!