AmigaOne DMA Problem

[DrBombcrater]

@Piru

Marvell is over 100% faster with HD DMA than ArticiaS. Same southbridge, same HD.

Since the UDMA driver for OS4 is still in development and not publically available, I fail to see how you can state this with any authority.

The speed of UDMA transfers depends mostly on the efficiency of the PCI controller anyway (which is why Intel chipsets often worked faster than VIA ones in years past) but the software/hardware coherency issue should not be much of a factor.

@takemehomegrandma

This doesn't sound too healthy to me. BTW, isn't the point of DMA to keep the CPU out of the transfer process?

The CPU is kept out of the transfer process. It's only after the transfer has completed that a cache update needs to be performed. The only difference between the two architectures is that on software coherency systems like the A1 you need to make an OS call after the transfer. The overhead for this is minimal and probably not detectable even using specific benchmarks.

I may be wrong (crappy memory) but I'm pretty sure 68k Amigas use a software cache coherency system.

How do you know that the A1 you saw was really using DMA and not falling back to using the IRQ to ask for CPU-time for it's transfer? How did you tell the difference?

Because it can't work without PCI DMA. The 'DMA' the TV card spec sheet talks about is a legacy ISA DMA channel and is quite different from DMA on the PCI bus. In the days of ISA PCs a controller on the motherboard (its implmented in the South Bridge now) was used to pull data out of expansion cards, and every card needed to be allocated its own channel.

The PCI bus doesn't use this hardware as it has its own bus mastering system, and you'll never see 'DMA' demanded on the specs of a PCI card because it is an integral part of the PCI specification.  The ISA DMA channels are just a hang over and don't get used on PPC systems at all unless they implement an LPC bus. Even on a modern PC they mostly get ignored: the sound card, graphics card and HD controllers on my Windows box all function without a legacy DMA channel.

[Piru]

@DrBombcrater

I fail to see how you can state this with any authority.

Pegasos1 (ArticiaS) vs Pegasos2 (Marvell). Under Linux and MorphOS. Pegasos1 transfers about 36-37MB/s, whereas Pegasos2 transfers 88-89MB/sec.

As far as I understand AmigaONE delivers same speed as Pegasos1 (at least Linux), albeit with possibility of errors. Correct me if I am wrong.

[EDIT]added some speed figures for reference[/EDIT]

[mikeymike]

@ Piru

Transfers from what to what?  And of what exactly...

My PC (UDMA100) could probably at best burst at ~40MB/sec, and that's if it had a second identical disk in, and probably on the same IDE chain, and if the both disks were defragged and the file(s) were huge (like 100MB+ each).  Normally though I'd expect 20 - 30MB/sec for the conditions I've just stated.

Benchmark utilities on my disk suggest ~35MB/sec best throughput.  Internal disk transfer synthetic benchmarks (which IMO are by no means practically true) suggest ~300MB/sec.

There's all kinds of factors that could throw the figures I've stated, filesystem decent/cleverness for one (if internal disk transfers), disk cache is another...

I don't think there's an IDE disk that can even do 90MB/sec transfer speed to a destination that isn't the same disk, currently available at the moment, let alone if it were in a Peg1/2.

[Piru]

@mikeymike

Transfers from what to what?

HD to memory, raw same sector read.
HD is Seagate ST3120026A 120GB.

And of what exactly...

SCSIBench V1.0
Transfer Size: 256 k
Transfer Type: Same Sector

These settings benchmark the transfer speed off the disk cache, not continuous disk transfer speed. Thus, the IDE bus is benchmarked.

My PC (UDMA100) could probably at best burst at ~40MB/sec, and that's if it had a second identical disk in, and probably on the same IDE chain, and if the both disks were defragged and the file(s) were huge (like 100MB+ each). Normally though I'd expect 20 - 30MB/sec for the conditions I've just stated.

Benchmark utilities on my disk suggest ~35MB/sec best throughput. Internal disk transfer synthetic benchmarks (which IMO are by no means practically true) suggest ~300MB/sec.

We're interested about the IDE bus performance, not about particular disk performance. BTW my ST3120026A does 54 MB/s sequental access (Peg2).

I don't think there's an IDE disk that can even do 90MB/sec transfer speed to a destination that isn't the same disk, currently available at the moment, let alone if it were in a Peg1/2.

Well you think wrong then. When we're comparing IDE DMA (peak) performance we want to compare readspeed from cache.

Peg2 + ST3120026A does close to 90MB/s.

PS. CPU Usage is 97% because I run distributed.net client on the background. CPU Usage is around 13% without it
[EDIT] SCSIBench's internal CPU Usage meter seems 'slightly' broken, it reports 70% CPU Usage. [/EDIT].

PPS. This is not supposed to mean that I claim I get 90MB/s generic performance. This is not the case, I'm trying to compare peak performance, which with ATA-100 limits to theoretical 100MB/s.

[EDIT] Added some clarifications [/EDIT]

[Fats]

DrBombcrater wrote:
The Marvell is certainly a nice North Bridge and a better choice than the ArticiaS if you want a system capable of running multiple operating systems, but for a machine intended to run just one OS that is specifically designed for it the ArticiaS works okay.

The problem I have is that the A1 was marketed as a linux machine and an OS4 machine.

Staf.

[DrBombcrater]

@Piru

Pegasos1 (ArticiaS) vs Pegasos2 (Marvell). Under Linux and MorphOS. Pegasos1 transfers about 36-37MB/s, whereas Pegasos2 transfers 88-89MB/sec.

A Pegasos is not an AmigaOne. They may use the same bridges but the board layouts and firmware are radically different.

With a 40GB Maxtor +8 drive my own A1 has hit 60MB/sec transfer speed (physical transfers from disk, not cache) under Linux. That's almost exactly the same speed the drive gives under Amithlon and Linux/x86.

@Fats

The problem I have is that the A1 was marketed as a linux machine and an OS4 machine.

Yes, that was a seriously bad move. I guess Eyetech believed Mai's promises that they could make Linux work correctly on the ArticiaS.

[Piru]

@DrBombcrater

A Pegasos is not an AmigaOne.

I didn't claim that. I suggested that to my knowlege AmigaONE IDE (peak bus-) performance is identical (or close) to Pegasos1 one.

With a 40GB Maxtor +8 drive my own A1 has hit 60MB/sec transfer speed (physical transfers from disk, not cache) under Linux.

Wow. That's nice.

May I ask how you benchmarked this?

[EDIT] Some rewording to deliver the idea better [/EDIT]

[mikeymike]

Transfer Size: 256 k

My mind is literally boggling at this point.

You're claiming 90MB/sec based on a 256KB transfer.  Are you aware of the fact that every currently available storage device has significantly variable limitations depending on the size of the transfer?  Any benchmark site which is considered even slightly respectable will do a series of tests of different size transfers in order to build a picture of a hard disk's limitations.

I would regard tomshardware.com as 'slightly respectable', and here's an example of the minimal tests they run:
http://www.tomshardware.com/storage/20040525/samsung-160gb-03.html

We're interested about the IDE bus performance

Considering that it has been the disk which is the first limiting factor, not the bus, you're hardly going to be pushing the bus's potential at any point soon.

I don't think there's an IDE disk that can even do 90MB/sec transfer speed to a destination that isn't the same disk, currently available at the moment, let alone if it were in a Peg1/2.

Well you think wrong then. When we're comparing IDE DMA performance we want to compare readspeed from cache.

I'm sorry, what do you want to do, masturbate over benchmarks or get some practical results?  And which cache?  256KB is a drop in the ocean of modern day disk cache, what's the point?  Yeah, great, you made a bit of data go from one cache to another via a few bits of wire and you're getting really impressive results.  Now how about testing the actual device (ie. disk platters + drive heads + electronics) the data has to originally come from?

If you want to know whether DMA works, you need to go from one storage device to another and run analyses from that.  Two reasons: one is data integrity (DMA isn't very useful if it toasts the data in transit) and the other is system stability/performance.  If the DVD/CD drive is DMA capable, then CD -> disk transfers are an acceptable means of testing whether DMA is working in a stable, non-retarded fashion.  Get a large file on a CD, get up some monitoring on the transfer speed, plus some on the CPU and the load on a reasonably-performing ~800MHz CPU should be minimal, certainly less than 10%, and with a decent DVD/CD drive I would expect over 10MB/sec.  Unless of course you'd like to throw that test by making a CD drive with a 700MB cache and go wow at memory <-> memory transfers.

DMA is not some single, standalone module in operating system design.  In the context of storage devices, it has to be highly integrated into the storage control driver.  There are lots of dependencies.  DMA would be utterly useless if it didn't deliver particularly with regard to data integrity and system reliability.  The original poster was asking if there is an issue with DMA on the A1.  Your test might not even give the slightest indicator on a system that cannot stabily handle DMA transfers!

And, to be blunt, there is no single IDE hard disk that can do 90MB/sec in any practical scenario.  And transferring a 256KB file and doing a bit of theoretical maths does not cut it, neither does transferring the same 256KB file 360 times in a row.

I'm not even sure there's a SCSI disk that can do 90MB/sec in any practical scenario, but I could be wrong about that, and wouldn't be greatly surprised if I was.  A little surprised, perhaps.

[Piru]

@mikeymike

Now hold your horses. I am not attempting to benchmark my harddisk, or compare this harddisk to any other harddisk. Nor am I claiming 90MB/sec practical speed.

I am speaking of the interface speed, the absolute maximum speed the drive can deliver data from the cache to host system. I am trying to find the maximum speed possible thru the IDE interface. For that, reading 256k buffer repeatedly seems best generic test (sizes 128k and 512k are quite close too, but as fast as 256k).

May I remind you the peg1 and peg2 systems were identical, except motherboard (northbridge), CPU and memory. Same NIC, same gfxcard, same southbridge, same harddisk.

Peg1 does 36-37 MB/s, whereas peg2 does 88-89MB/s, same environment, same testprogram, same parameters.

I'm sorry to upset you.


[EDIT] Indeed, as someone was kind enough to point out, the cpu indeed is different too. That probably explains some of the difference in speed, aswell. :-) [/EDIT]

[DrBombcrater]

May I ask how you benchmarked this?

HDParm under Linux.

[Piru]

@DrBombcrater

Ah great. Mind pasting the hdparm command used and command output? I'd like to reproduce the test.

[mikeymike]

Piru wrote:
@mikeymike
Now hold your horses. I am not attempting to benchmark my harddisk, or compare this harddisk to any other harddisk. Nor am I claiming 90MB/sec practical speed.
I am speaking of the interface speed,

But, it's a pointless statistic.

the absolute maximum speed the drive can deliver data from the cache to host system. I am trying to find the maximum speed possible thru the IDE interface. For that, reading 256k buffer repeatedly seems best generic test (sizes 128k and 512k are quite close too, but as fast as 256k).

But, it's a pointless statistic :-)  The main factors that need to be looked into, especially with the A1, but any system really, is the storage devices and the operating system/drivers.  You're not going to tax the IDE bus with a cache <-> memory transfer incredibly, nor will it help diagnose potential DMA issues.

May I remind you the peg1 and peg2 systems were identical, except motherboard (northbridge) and memory. Same NIC, same gfxcard, same southbridge, same harddisk.
Peg1 does 36-37 MB/s, whereas peg2 does 88-89MB/s, same environment, same testprogram, same parameters.

I'd hazard a guess at the Peg1 being UDMA33 and the Peg2 being UDMA100.  If you pair up a decent UDMA33 disk with a UDMA33 bus, the bus is over-spec'd for the job.  Same goes for a UDMA100 disk - UDMA100 bus.  In short, there is no point in trying to test the bus throughput on its own.  For starters, there's no practical method, and secondly it's not a practically useful statistic.  It would be like devising a test that somehow tested bandwidth between two PCI slots and nothing else.  The data still needs to end up somewhere.  Test the whole process.  Unless it's your job to design motherboards, then that's a different story.

I'm sorry to upset you.

The possibility that you were just blowing the Peg's trumpet, and in a way that is (as far as the average user and decent benchmark is concerned) totally inaccurate did annoy me.  Some guy who does a decent benchmark on an A1 with OS4 or Linux is going to get extremely differing results from yours through no fault of their own, and potentially no failing or issue with the hardware, is likely to be pointing at the wrong factor as the cause of the 'problem'.

In a practical disk throughput test, ie. a few hundred megs of data from one device to another storage device, your Peg2 cannot do anywhere near 90MB/sec.  30MB - 40MB/sec I'd be mildly impressed with (provided no data integrity issues), because that would suggest the MorphOS IDE drivers have been worked on significantly to ensure the best performance.  Same goes for A1/OS4, AROS/x86 respectively.

[KennyR]

Mike, it's not a pointless statistic. The point was to show that Articia UDMA IDE bus performance is adversely effected by fixes to preserve data integrity, regardless of drivers. Piru just proved that point. There is no other issue worth discussing here.

And if you don't think a ceiling of 40 MB/s for *total* IDE transfer is a problem, well, try it one day.

[mikeymike]

KennyR wrote:
Mike, it's not a pointless statistic. The point was to show that Articia UDMA IDE bus performance is adversely effected by fixes to preserve data integrity. Piru just proved that point. There is no other issue worth discussing here.

I'm not sure he has proven that point, if I'm right about the Peg1 being UDMA33 and the Peg2 being UDMA100, then the last stats he posted co-incide perfectly with my expectations for any comparison of a UDMA33 and UDM100 motherboard.  If however the Peg1 is supposed to be UDMA100 capable, then something definitely odd is going on (the Peg).  You could run a similar test comparing the A1 to a properly UDMA100 capable motherboard (could be a decent x86 mobo for example), but if I wanted to be certain things weren't going bump in the night wrt IDE DMA, I'd be doing disk to disk transfers!

And if you don't think a ceiling of 40 MB/s for *total* IDE transfer is a problem, well, try it one day.

I wasn't making a "640KB should be enough for anyone" comment, obviously storage device/bus performance needs to improve as it is the worst bottleneck in any modern system.

What I am saying is that currently, with today's hardware, you're not going to see in any practical scenario more than 40 - 60MB/sec, and the 60MB/sec is me being generous.

For starters, when you're loading typical applications, you're not getting anywhere near the maximum throughput for a decent UDMA100 disk, or the bus.  The system loads lots of tiny files, and not in some clever batch job either.  Each of those tiny files might be getting through to memory at 200KB/sec.  The big performance bottleneck straight away is platter spin speeds and disk head latency, not the IDE bus and not the disk cache, if you could get load monitoring on those specific components, they'd all be sitting back and relaxing, especially in comparison to the gymnastics the disk heads are doing!

Then there's the nature of the average user's data files.  Browser cache, lots of tiny files.  Any office app, again how often is it that people are throwing around office-type documents that are in the tens of megs let alone hundreds.  I know one person who does professional audio work and does need decent disk throughput and so he uses RAID.

My system has probably done 20 - 30MB/sec over the IDE bus several times in its entire existence, and the majority of those occasions were probably when I was testing it.  What do I use my machine for?  Gaming, office + internet apps, DVD playback, CD/DVD ripping.  That's about it methinks.

PS: And something slightly off-topic to throw into the mix here, 90MB/sec was the exact figure that an Intel P4 motherboard I had the misfortune of trying to get working that the motherboard would crap out completely when that data throughput speed was attempted over the PCI bus.  Yeah, great! 90MB/sec throughput!  Oh, it crapped out again.

[Piru]

@mikeymike

I've gone OT, which I apologize for. I mainly compared peg1 G3 and Peg2 G4, while also suggesting that I believe A1 (with same CPU config) is closer to Peg1 than Peg2.

This isn't exactly on topic, again sorry about that.

But, it's a pointless statistic.

Mostly yes. However, if the peak performance is capped by the northbridge it's quite serious. I believe this to be the case with ArticiaS.

The possibility that you were just blowing the Peg's trumpet

Let me assure you this was not my intention.

Some guy who does a decent benchmark on an A1 with OS4 or Linux is going to get extremely differing results from yours through no fault of their own, and potentially no failing or issue with the hardware, is likely to be pointing at the wrong factor as the cause of the 'problem'.

Valid point. I probably should have pointed out that SCSIBench and hdparm results are not comparable.

In a practical disk throughput test, ie. a few hundred megs of data from one device to another storage device, your Peg2 cannot do anywhere near 90MB/sec.

Which I never claimed. I wanted to test the max peak performance of the IDE implementation.

[DrBombcrater]

@Piru

Ah great. Mind pasting the hdparm command used and command output? I'd like to reproduce the test.

Going from memory here as I don't have a working Linux install right now, but I'm pretty sure it was "hdparm -t /dev/hda".

Mostly yes. However, if the peak performance is capped by the northbridge it's quite serious. I believe this to be the case with ArticiaS.

No doubt the maximum throughput is capped by the North Bridge. That's quite common on x86 chipsets of a similar technology level to the ArticiaS - some implementations of the VIA KT133 and Apollo 133 couldn't get past 75MB/sec total PCI throughput.

One thing that occured to me is that G3 processors don't support write-combining when doing I/O, so any realistic tests for transfer speed limits would have to be done on G4 systems.