On Mon, Mar 27, 2000 at 10:53:28PM +0200, Manuel Bouyer wrote:
> On Mon, Mar 27, 2000 at 09:40:07AM +0200, Thomas Michael Wanka wrote:
> > Hi,
> > 
> > that statement needs to be cleared! It depends upon what one wants 
> > to do with the computer. As ide drives still need the processing 
> > power of the CPU to do transferrs there are many environments 
> > where SCSI is still more performant. Looking at these reviews will 
> > show, that ide disks have equal or higher ransferrates than SCSI 
> > disks, but most reviews do not consider CPU utilisation. From what I 
> > know ide drives do not come close to scsi drives for latency. 
> > 
> > So a general rule was that when the pc has a high CPU utilisation 
> > ide drives just dont get it. For the typical office environment ide 
> > hardware was just fine.
> 
> No, this is not true. Ultra/33 DMA disks (with Ultra/33 controllers) use
> DMA for data transfers, and don't need CPU work, just like SCSI.
> Now there is the command setup and end; for this IDE beats SCSI:
> just a few registers write for starting the command. IDE latency is much
> better than SCSI (SCSI command startup has more overhead), and depending on
> your SCSI board the IRQ load may be much higther (need to deal with
> disconnect/reselect messages, etc ....).

Nonetheless, it's been my experience that since shortly before the 1.4
release, our IDE subsystem has been prone to misbehave in the face of high
levels of I/O in ways which do make the whole system feel rather slow.

I don't understand quite what's going on, but doing things like rsync or
find or ls -lR or dump that hit the IDE disks with huge numbers of requests
do, in fact, from the statistics, get huge numbers of xfers/sec and very
high bytes/sec throughput, and CPU utilization does not, in fact, seem to
be particularly high.  On the other hand, in the midst of this type of
activity even keyboard input can seem sluggish, and if I do something that
generates *new* I/O requests to the IDE disk (e.g. 'ls' while an rsync is
running in the background) those requests take a *long* time to complete.

The first behaviour suggests that too much time is being spent at high SPL,
but from examination of the IDE code that doesn't seem correct.  The second
seems almost as if disksort is broken, but I see no reason to believe that
that is the case either.

Interestingly, using LFS, which makes almost all disk I/O asynchronous,
pretty much makes both problems go away.  With SCSI disks, they don't
seem to appear in the first place.  I'd suspect some kind of odd barrier
condition with !B_ASYNC buffers, but since we don't do disconnection or
multiple command queueing on IDE that doesn't seem likely, either.

Stranger still, as of pre-1.4 current, when the IDE DMA code originally
went in, this symptom did not seem to exist.

I know this isn't much by way of a bug report, but the symptom isn't
precise enough for me to describe it much better. :-(

-- 
Thor Lancelot Simon	                                      tls@rek.tjls.com
	"And where do all these highways go, now that we are free?"