AmigaOne DMA Problem

[DrBombcrater]

Why do they not put DMA among the features for the Articia S northbridge?

When you see 'DMA' mentioned on the spec sheet of a North Bridge it is referring to a seperate controller used to run high-bandwidth devices (such a Gb ethernet) that would saturate the PCI bus. This was't a popular feature when the ArticiaS was designed, so it doesn't have one.

DMA over the PCI bus is handled by the North Bridge's PCI bus mastering unit. The BM unit in the ArticiaS can handle up to 5 bus masters at one time and I've seen nothing to indicate that it doesn't work just fine.

Uh, DMA in -->SOFTWARE<--?!??

Well, no, not really. Actual DMA transfers on the ArticiaS work just the same as they do on any another North Bridge. The 'software' part comes when the transfer has completed. Most systems have hardware that will flag the CPU to do a partial cache-flush at ths point, in order to make sure the caches reflect the new data just DMAed into memory. The ArticiaS can't do this, so after DMA activity the driver must explicitly call an OS function that does the cache updating.

This isn't exactly an elegant approach (I'd go as far as to say it was a rather stupid design decision on the part of Mai) but for OS4 is should be a moot point. Performance and stability should be just as good as a system with hardware cache-coherency provided the driver writers are paying attention.

Just a quick note about this; from what I understand, some TV-cards use IRQ/CPU to transfer data from the TV-card to the Graphics card, while other uses direct PCI->AGP DMA for its transfer (which completely leaves the CPU out of the picture). Some cards can perhaps even use both ways, I don't know. I am glad that your particular TV card is usable on your system!

Most TV cards are based on BT848/849 chips which do use DMA to push picture data into memory. I've seen one of these cards (a Hauppauge WinTV-Go to be exact) working on an A1 under Linux without any apparent issues.

Anyway, the absolutely best fix against the Articia issues was the Marvell DiscoveryII (and I am SOO glad for that one)!  

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.

My only real gripe about it is the memory compatibility problems. It's rather insane that there are no widely available Dimms guaranteed to work with it, and even if you buy the exact module recommended by Eyetech there's still a chance it won't work.

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

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

[DrBombcrater]

May I ask how you benchmarked this?

HDParm under Linux.

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