AmigaOne DMA Problem

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

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

[KennyR]

Mikeymike wrote:
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.

Pegasos-1 is ATA100 enabled, same as the Pegasos 2. Both use UDMA Mode 5. The throttling of the IDE bus is not caused by a lower transfer mode.

The Marvell northbridge is the only real difference between Pegasos 1 and 2. That's what makes comparisons viable.

Something is fishy with Articia, and PPC *ix kernel experts don't like the smell of it either. In fact, to quote WrongPlanet's unique turn of phrase, anyone who's adopted Articia has dropped it like a snowball they found a dog turd in.

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

[Floid]

I'd like to keep better score here, but:

The Via 686A is a UDMA66 part.
The Via 686B is a UDMA100 part.
The Via 8231 is a UDMA100 part.

If I remember correctly, the first (or possibly the UDMA33 686-no-letter) two are in use on AmigaOnes, and the last is in use on the Pegasos1.

However, not all drives can support the maximum speed of the controller.  If you party people are playing around in Linux, there are a ridiculous number of variables that will effect your results.

Am I wrong in thinking that UDMA drivers are absent from the OS4 DP?

There are also a number of horrible things that can happen to corrupt "DMA" IDE transfers that don't necessarily have much to do with DMA itself -- good hardware won't save you from an off-by-one condition or similar in driver code, or perhaps subtle bugs elsewhere in the particular Linux kernel version.  

....

It seems that the Articia S's 'problems' are almost but not totally unlike the horrible Athlon speculative-write 'bug' that obviously crippled the use of Linux on it forever and put AMD out of business.*  They may be worse, to the extent that all DMA might have to be 'non-coherent,' but if I understand correctly, coherent DMA will only give you a benefit if you're going to access the data in-place more than once... which, with modern kernels (Linux), you probably aren't getting a whole lot of benefit from... yet at the same time, previous to 2.6, most drivers in the Linus tree were assuming all the world's a VAX, and there may not have been a framework in place (or attention paid) to ensure that everything plays nice with "non-coherent architectures."

When AMD hit their bug (which was lucky enough to be caused by, and actually part of the normal operation of a beneficial feature), they had the benefit of a lot of smart and cooperative people puzzling it out and solving it.  When Mai and Eyetech hit their bug (which is not necessarily a 'bug' if Mai had it mentioned in the real spec sheets from the get-go), they had the benefit of... a few confused hobbyists, whatever kernel hackers Mai at one point employed (who apparently were isolated from the LKML?), a planet not very concerned about small-volume hardware that had yet to really be seen in the wild, and of course, a smear campaign from Genesi (who were probably 'right' to the extent that normal Linux 2.4 -- as pulled from kernel.org -- wouldn't be able to get up and go on the hardware... and to the extent that Mai never stepped up to the plate and left the problem to their customers, April 1 may've been the expedient thing to do... If it didn't have to be followed by April 2).

Now, is this Mai's problem alone?  There are tons of other non-coherent designs on the market... and like the AmigaOne-Linux team, those vendors would have to (and possibly have had to) rewrite some fairly important chunks of 2.4 (or maybe just every mis-assumptive driver) to support the array of peripherals the AmigaOne does.  Why don't we hear much about it?  Because most of those designs are embedded, and either don't take advantage of things like Via IDE controllers that heretefore were only used on the "desktop"-style chipsets Herrenschmidt prefers (and he no-doubt prefers them in part because they already run Linux properly; bit of a chicken-and-egg there)... or do so in a device-specific tree that it's easy to overlook the existence of.  (After all, it's all "Linux," right?)

So with Linux being IBM's pony, and 2.4 being the stable version at the time that little chart was published, it makes sense that Mai would remove the little check next to "DMA."  It could work perfectly -- albeit in a way the world might not have expected -- but it didn't with the OS they were themselves pushing it for.  Could it have?  Sure, if someone played ball and put a professional effort behind the "port," which in turn could've had its costs (in time and effort) lowered through better collaboration in public... While on the same token, it may well be that Mai knew 2.6 was coming and decided to lay low and let someone else invent the wheel.**  (My apologies if Mai did in fact fund or support 2.6 development in some way.  But if they did, I'd expect they'd be crowing about it.)

---

Now, I would like to know the story of what happened to the AC97 support... and I'm still trying to figure out what exactly Herrenschmidt was on about as regards AGP, since I'm not sure how that's supposed to work "normally," let alone what difference would be on Articia.

---

*This is sarcasm.

**In the sense that it's a bit ridiculous to embark on, say, a 7 month overhaul of 2.4 as a special Mai kernel tree, when 2.6 was expected in 6 and make it that much easier to have things work 'officially.'  Remember, BSD users call it a fork if it opens a new CVS tree; Linux users call it a 'patchset' if the diffs can fit on three CDs.  :flame:

[itix]

The Via 686A is a UDMA66 part.
The Via 686B is a UDMA100 part.

686A was used in A1-SE dev boards, production board got 686B (SE and XE).

a smear campaign from Genesi

Genesi just told the truth.

When Mai and Eyetech hit their bug (which is not necessarily a 'bug' if Mai had it mentioned in the real spec sheets from the get-go)

Could be just easier replace that NB? Why should Eyetech rely on MAI btw?

Now, is this Mai's problem alone?

Dont forget TerraSoft.

[Floid]

itix wrote:
686A was used in A1-SE dev boards, production board got 686B (SE and XE).

...and it's hard to tell who's got what, especially when bouncing numbers around.  Eyetech never took back the "dev" boards, right?

a smear campaign from Genesi

Genesi just told the truth.

Hm, rude choice of phrasing on my part, but, y'know, interchangeable with "FUD."  Or "marketing."  There's no right to demand altruism, but then, there's no reason not to buy a Mac.

On the one hand, if parties could've somehow got along on the "software" route (unpossible ;-)) ... maybe a mature patchset for 2.4 would've appeared quicker, however many hundred board-exchanges wouldn't have had to happen, and "this market" (and the global market) as a whole would be stronger for both vendors, while whatever's going on with this supposed paid-in-boards strategy (though it seems to be doing the job of moving a few dozen Pegs by the sympathy vote?) wouldn't have come to pass... and who the heck knows what went on with OpenBSD, but, y'know, maybe.

Or maybe everyone would've still been screwed either way.  What's done is done, good game, but the obfuscating aftershocks are getting tiring... while the record this leaves in Google is, of course, that both sides are completely insane, and it's a much safer bet to buy a plain old iBook or C3.

When Mai and Eyetech hit their bug (which is not necessarily a 'bug' if Mai had it mentioned in the real spec sheets from the get-go)

Could be just easier replace that NB? Why should Eyetech rely on MAI btw?

Heck if I know, but at this point, nothing necessarily wrong with diversity, and with things understood, rather than hostage to PR on both sides, there's a fair chance for market forces to go to work.

Mai appear responsible to the extent that both sides seemed equally surprised when teh Lunix golly done not work, and since it's their product, they're left holding the bag... if it didn't work, what the heck did they have to lose by resolving the issue?  Did they know 2.6 would be a potential lifesaver, or did they luck out and a miracle occurred?  If it was too expensive to polish Linux, why not give a boost to NetBSD instead? :-D

Dont forget TerraSoft.

Well, it was amusing to see how much commitment they had to the PowerPC scene when Mai seemed to be the only game going.  Or we could just blame Bush or The Terrorists for the economy.

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

[itix]

...and it's hard to tell who's got what, especially when bouncing numbers around. Eyetech never took back the "dev" boards, right?

I don't know but there are probably only few A1-SE boards with 686A. I don't know further details but those were sold for early adopters etc.

On the one hand, if parties could've somehow got along on the "software" route (unpossible )

Impossible. Both parties hate each others. (This all started from PUP vs WUP war.)

maybe a mature patchset for 2.4 would've appeared quicker, however many hundred board-exchanges wouldn't have had to happen

Linux is not the only OS.

and who the heck knows what went on with OpenBSD, but, y'know, maybe.

http://www.openbsd.org/pegasos.html

[KennyR]

Mikeymike wrote:
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.

Well, whether or not Genesi told the truth several blunt facts do exist and can't be mistaken. Firstly, Genesi retooled their whole production line and set themselves back maybe a whole year and presumably lost rather a large amount of money to get rid of Articia. So they were pretty sure there was something wrong with it, hype or not. Certainly it was horribly useless for what Genesi were marketing Pegasos as - a multiple OS board.

Secondly, the AmigaONE market base is flattering itself to think that Genesi would try to lie or underprice their boards to undercut A1 sales. Even if every single A1 owner, potential or present, had bought a Pegasos, there would probably only be about 1500 more sales - 2500 looking at it VERY optimistically. That's just not worth the expense. Pegasos may compete with A1 in the mind of users, but in a business sense it's in a whole different league. Why would Man United try to smear Layton Orient? :-P MorphOS is a toy OS in the world of computing and Genesi know that as well as anyone. Genesi's ambition is far bigger than MOS. As the slogan goes, MOS is a free gift. Smearing a tiny outfit like the A1 for the sake of a tiny OS like MOS is a total waste of effort.

Yet, it has happened, but not out of good business sense. If Genesi have clashed with Hyperion and Eyetech in the past, it's certainly more a clash of egos and unfinished vendettas. There are people behind MOS/OS4/Genesi/AInc who really don't like each other.

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

[Floid]

The HDParm benchmark is mostly just proving that disk platters can't consistently saturate a bus... which we already knew.

I need to get around to looking at what the HDParm and SCSIBench (well, *NIX SCSIBench, which nobody's using yet) benchmarks actually do to determine if this is a concern or not, but another "problem" is that the Linux I/O layer keeps getting rewritten, leading to marked improvements on the same hardware between kernels (or to look at it another way, marked reductions in Linux-induced degradation).  Meanwhile, nobody in this thread is specifying their drives, dmesg info/hdparm tunings, etc...

Note that /proc/ide/via may also contain useful (and easily readable) information about negotiated speeds -- so if a drive is picked up at 33MB/s instead of 66 or 100, that's less likely to be a 'bug' than a misconfiguration of some form or another.  Assuming drivers on both platforms support this nicety, it should be included with all Linux benchmarks taken.

Really, nearly everyone's methodologies right now are... "poor."  (A real-world device-to-device copy is a good way to do an initial test for corruption, and a good way to test real-world performance... but a bad way to test peak bus throughput, if that's the question du-jour.  These are all important data points, but let's try to go in order here... and for that matter, not forget that the Peg II should be reaping the benefit of much faster RAM.)

Sadly, I'm not finding any HDParm numbers from KT133A/686B users with ATA100 drives (and the KT133/A bugs put a wrench in that thought, too.)  Still, look at these numbers from the 2.4 kernel era, with good, standard hardware... they 'suck!'

I bothered someone at random (thanks, Al!), and got the following for a modern x86 with "two 120GB SATA drives," kernel 2.6.5 (running processes but quiescent disk, which I assume is how most of y'all are testing):

Timing buffer-cache reads:   1244 MB in  2.00 seconds = 620.85 MB/sec
Timing buffered disk reads:  168 MB in  3.02 seconds =  55.58 MB/sec

...not quite the magic 100MB/s everyone wants to see.    This talk of the 90MB/s PegII sounds pretty specious now, but off the right area of a 15,000RPM  drive -- or a software RAID device (for which hdparm isn't 'trusted,' and the buffer cache should be sneakily at work below) -- sure, why not?

===

(Okay, I know this is in reply to itix, but I decided to try to be informative instead of rehashing the old arguments again.  We've all heard the gonzo stories from every side, and we all have our own opinions of them.  Linux is not the only OS... but it's the only OS that sort-of-could-have run on the hardware while both parties' alternatives were in development.  Other than *BSD, which, just maybe, may've been less of a headache overall. ;-))

[Off-topic, I hate to think how many long and reasoned posts the forums are losing from people who don't know how to get around the login timeout.]

[minator]

I was at bplan one of the days they were developing April 1, they'd set up a test set it running and a while later the machine would just lock up.  That was just the first bug, Gerald found several and told me himself.

The guys in the Thendic-France office had nothing but problems with the non-April machines, they were constantly crashing.

Mai did do a revision of the Articia based in part on Geralds fixes but according to Gerald it didn't work.  To my knowledge there has been no subsequent revision.

At the time (late 2002) this was all under NDA, IIRC Fleecy then Eyetech were the first to say anything in public.

April 1 did seem to get around the main problem but not all as April 2 was later released, both were offered as free upgrades to existing users but some didn't change April 1 to April 2 as they were happy with them.

Genesi promptly gave up on Articia and went with Marvell instead, that took a lot of time and money and meant there was nothing to sell for months.

Now, do you really think Genesi did that for the sheer hell of it?
If it was just "working differently" don't you think Mai would have told Gerald? He was at their offices for a couple of weeks...
It is in Mai's interest to acknowledge and fix problems, otherwise they lose customers.

There does seem to be a way to at least mitigate the bug with a software workaround but the performance impact remains to be seen.
My guess is that it will work sufficiently for AOS 4.0 so those users will be happy.

The problem is more likey to affect Eyetech when they try and sell embedded boards - which they need to do if they want the A1 etc. project to continue.
Embedded customers tend to be rather picky, we had one who took an April2 machine and left it running for a few weeks to test it (yes, it worked).  Desktop users don't put their machines through that sort of abuse so machines don't need to be so reliable (if they did Microsoft would have gone out of business years ago), the embedded market is a different ball game.

--

For the record:

I worked for Thendic-France, I don't work for anyone right now.
I own neither a Peg or A1, I just blew a heap of cash on a Mac.

I don't really see Eyetech and Genesi as being competitors except in the Amiga space which I wonder is big enough for even one company to live off (survive maybe but nobody is going to get rich).

[KennyR]

Mikeymike wrote:
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...

My allagory loses its meaing if I use teams from the 4th division and the Vauxhall conference you never heard of. :-P

[itix]

This talk of the 90MB/s PegII sounds pretty specious now

It only suggest max transfer rate over ATA interface. Like benchmarking ethernet :-)

[Floid]

itix wrote:

This talk of the 90MB/s PegII sounds pretty specious now

It only suggest max transfer rate over ATA interface. Like benchmarking ethernet :-)

Actually, my bad (unless there's a grand conspiracy to re-edit everyone's posts when I'm not looking) ... I was still having my coffee, and I misread that as a claimed HDParm result.

The same-sector-read methodology is a sound one for this question, so now I have to wonder what Mikeymike's on about.  Not knowing how the system really plumbs together, I can't really trust numbers from MorphOS (not to say it's cheating, but I don't know how/if it implements a buffer cache) ... but that is what should be expected yoinking the same sector over and over from the disk's cache.

I don't think I see anyone claiming accurate, recently-trialed numbers for the same type of test off a Mai'd board of any sort (if, again, we're trying to figure out whether *something,* bugs, fixes, or user-misconfiguration pushes down the peak theoretical throughput on the A1), so I'll try to hold off speculation while I doublecheck the thread.