AmigaOne DMA Problem

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

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

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

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