AmigaOne DMA Problem

[mikeymike]

The original poster wasn't asking about the Peg, but about the A1.

Regarding the A1 and DMA, what I would really like to see now is someone who is as unbiased as possible to run lots of practical and synthetic tests on it running OS4 and post the results/their findings.

As a potential customer, I would feel a lot more comfortable about an A1 purchase once I had seen both official and unofficial reports that sound sane and essentially agree with each other.  I'm not implying the opposite (or near opposite) has happened at any point either.

[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.

[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.

[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.

[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.

[mikeymike]

From the evidence/rumours available, there does appear to be a problem with the Peg1 and the A1 wrt DMA.  But the first question is, what is the nature of the problem?  The last question is how that the situation created will affect the end-user.

It appears to be a generally-accepted fact that something isn't quite right about the Peg1 and A1 wrt DMA.  They share the same (ArticiaS) northbridge chip, and they both have a Via southbridge chip.  IMO, chances are they are going to be the same Via chip on the southbridge.

Alan Redhouse says here that the DMA issue is irrelevant under OS4:
http://amigaworld.net/modules/features/index.php?op=r&cat_id=3&rev_id=41&sort_by
He also implies that a throttling solution hasn't been employed under OS4, but one thing that worries me there is that the OS4 IDE drivers weren't DMA capable until some time this year IIRC, and that article was dated last year.  I'm not going to accuse him of lying, and IMO it would be out of order for anyone to without proof that some sort of DMA issue exists under the release version of OS4.  One possibility is that they knew exactly what would have to be done, and had no doubts about the implementation.  There are probably other possiblities, but I'm getting tired.

Back to the problem.  There's not a lot of point in me hypothesising much as there is so little to go on, and frankly I would only be inclined to place much trust in an independent source's testing, such as a hardware review site which had access to a recent OS4 build as well.

One possibility is that there's a hardware-based DMA issue which is catastrophic, as in there is no workaround and the machine just hangs.  Anyone who shipped a motherboard with an issue like this should be hung, drawn and quartered.  I strongly doubt anyone would be stupid enough to ship a motherboard with such an issue, for one reason:  Big fat lawsuit.

Another possibility is that there's a hardware-based DMA issue which requires some sort of software hack or bandwidth limitation to work around.  Not catastrophic, unless the motherboard were reduced to below UDMA33 capabilities.  The manufacturer should admit this outright if such an issue still existed at the point of starting to sell the product.

Another possibility is that the issue is purely software, in which case just fix the software.  Hurray.

[mikeymike]

Marvell is the only real difference between Pegasos 1 and 2. That's what makes comparisons viable. Something smells fishy with Articia, and PPC *ix kernel experts don't like the smell of it either.

I'd guess there's a southbridge difference as well given that the northbridge is different.  I can't find that info on the Pegasos site.  I'm inclined to agree with you about the ArticiaS, but what Alan Redhouse has said *is* plausible and does also fit the circumstances of slackening PPC Linux development.

As I said, I'd like to see an A1, a Peg1 and 2 in the hands of a decent, as independent as possible hardware reviewer like say www.aceshardware.com or www.techreport.com with appropriate versions of MorphOS/AmigaOS/Linux.

Also, I imagine kernel development on a platform with no fully-functional reference OS to play with (and preferably source code access to) must be a tad more difficult.

[mikeymike]

a smear campaign from Genesi

Genesi just told the truth.

 :roll:

Considering that the situation is by no means concluded or resolved, how you can possibly say that with any level of seriousness is beyond me.

[mikeymike]

Articia does sound a tad too much like ALi for me to be that comfortable with it, but I'd be willing to accept reputable sources saying it's an ok/stable/reliable chipset.

@ KennyR

I just noticed your "why would Man U smear Leyton Orient" comment... Amiga Inc and Genesi are both small startups (and both in my view look like they're struggling to survive).  Your comparison is way off on either yardstick I can think of, visibility, success...

[mikeymike]

The same-sector-read methodology is a sound one for this question, so now I have to wonder what Mikeymike's on about.

In what respect?  Testing whether DMA works 100% properly?

[mikeymike]

Ok guys we're in danger of going well off-topic to the point of no return.  I'm going to lock the thread for 24 hours, please think about whether your planned/intended replies to current posts are on-topic or not (ie. is it about the A1 apparent DMA issue... not Pegasos, not x86, not Windows embedded, not mindless advocacy...).

If the thread continues to go off topic after the 24 hour lock, it'll be locked permanently.