Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: captainmoomoo on June 28, 2004, 10:44:28 PM
-
Hi - what is the deal with the DMA problem in the AmigaOne hardware? Will this also be an issue for the microA1? If so, what are the implications? Is this a problem for AmigaOS4 as well as Linux?
I've tried searching around on the net for info on this, but havent really found a coherent explanation. Any help on this matter here would be greatly appreciated, as it is a factor in me deciding whether or not to buy an AmigaOne/microA1.
Thanks
-
For a full explanation read here. (http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=5471&forum=2) But suffice to say that the DMA bug only affects Linux not AmigaOS 4.
-
OS4 has workarounds for the Articia bugs. Whether or not they give full performance is yet to be seen. MicroA1 also has Articia. Linux doesn't have these workarounds, which is why UDMA on A1/Linux doesn't work properly.
-
The A1 "hardware issues" derives from the MAI Articia S Northbridge. But there seems to be split opinions whether the "issues" are good or bad.
Some people thinks that it's an unknown/undocumented *feature* of the Northbridge hardware, and that it's the LinuxPPC operating system that is problematic and unstable, and that is the explanation to why the OS crashes and files gets corrupted.
Other people thinks that it's a bug in the Northbridge hardware and has either dropped development of the boards based on this chip and/or developed hardware patches (in plural) for it. The LinuxPPC operating system works fine with these patches, and even better when the Articia northbridge is completely left out of the picture in favour of another one.
Some people has also observed that even the MAI data-sheets about the Articia S (http://www.mai.com/products/BRA660R2.0.pdf) no longer mentions DMA support, nor did the Article about MAI products in "IBM PowerPc News" (http://www-3.ibm.com/chips/products/powerpc/newsletter/jun2003/ppc_process_at_work.html) (compare the different chips in the "Miscellaneous" row of the table, two has DMA, one has not (guess which one)). So to some people it seems obvious that not even the manufacturer themselves is prepared to sell the Articia northbridge used in the A1 as DMA capable anymore. You asked: "Hi - what is the deal with the DMA problem in the AmigaOne hardware"? The answer would be: There is none! No DMA that is! :lol: :-P At least if you should believe the manufacturers themselves ...
The Articia S has a lot of other issues too; it is very picky when it comes to peripheral hardware (and the way you connect them), such as memory, CD-ROM drives, etc. It also uses a kind of memory that is getting quite old, expensive, rare and hard to get. Only to mention a few things ...
-
There are no bugs only claims. I've read the specs for the Atricia S since some months back (allmost a year) and I haven't seen DMA mentioned for the Atricia S. It's handled in software, not in hardware.
The AOS 4 driver works. It is 100% reliable.
It is picky about the RAM-chips being used. Except from that I haven't seen any problems and I use regular PC-stuff with different brands. I've tried three different gfx-cards, different soundcards, network-cards and so on and they have all worked.
There are more claims than truth. The only thing that is true is that it's picky about the kind of RAM-chips being used. That is easily solved. Just buy the brand that works.
-
There are no bugs only claims.
How about tv cards?
-
HotRod wrote:
The AOS 4 driver works. It is 100% reliable.
But at what speed? I'd venture to guess that sofware DMA is slow and CPU hungry. Also, I see a few posts about very slow CD-ROM speeds on OS4. Is this due to not having DMA?
-
adolescent wrote:
But at what speed? I'd venture to guess that sofware DMA is slow and CPU hungry. Also, I see a few posts about very slow CD-ROM speeds on OS4. Is this due to not having DMA?
If the DMA mode used was CPU hungry it would defeat the purpose of Direct Memory Access, wouldn't it?
-Jamie
-
itix wrote:
There are no bugs only claims.
How about tv cards?
My tv card works fine here.
-
There are no bugs only claims.
How about tv cards?
My tv card works fine here.
Bug (http://www.morphzone.org/modules/newbb/viewtopic.php?topic_id=2260&forum=11#17749) or not?
-
itix wrote:
Bug (http://www.morphzone.org/modules/newbb/viewtopic.php?topic_id=2260&forum=11#17749) or not?
[/quote]
Don't know, I can't speak for PegI owners ;-) . All I know is that I can view tv (yes, before you ask, with sound) on my A1 under Linux.
-
everything i read seems to make me lean towards a pegasos2 rather than an amigaone.
but then i also read somewhere that MorphOS might be released for the Mac, in which case I might just be better off getting a cheap one of those.
too much choice...
- announcement by mikeymike: off-topic -
-
> everything i read seems to make me lean towards a pegasos2 rather than an amigaone.
> but then i also read somewhere that MorphOS might be released for the Mac..
Naa, IF it will happen, this will happen NOT TOMORROW, neighter the day after tomorrow..
So buy a PegasosII, it's cheap, damn fast and it has MorphOS. Believe me, when you will try MorphOS on Peg you will want one immediately! ;-)
- announcement by mikeymike: off topic -
-
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.
-
The original poster himself "drew" Pegasos into this thread.. sort of... too...
-
Don't know, I can't speak for PegI owners . All I know is that I can view tv (yes, before you ask, with sound) on my A1 under Linux.
It indicates Articia used on Peg1 and A1 is buggy.
-
everything i read seems to make me lean towards a pegasos2 rather than an amigaone.
There is no working Linux for AmigaOne. They have been trying to implement working UDMA for A1/Linux for 2 years and counting.
but then i also read somewhere that MorphOS might be released for the Mac, in which case I might just be better off getting a cheap one of those.
It is not going to happen very soon but if you can wait an year or two...
-
itix wrote:
It indicates Articia used on Peg1 and A1 is buggy.
I thought the April chip fixed all the issues for the PegI :-?.
With reagrds to the tv cards, quite a few users (of those that I know) seem to have them working fine with their A1's. You can draw your own conclusions (and something tells me we won't agree :lol:).
-
itix wrote:
All I know is that I can view tv (yes, before you ask, with sound) on my A1 under Linux.
It indicates Articia used on Peg1 and A1 is buggy.
:-D
Makes me wonder what it would indicate if TV viewing would not work.
-
captainmoomoo wrote:
everything i read seems to make me lean towards a pegasos2 rather than an amigaone.
Buying amigaone you would support AmigaOS platform. Buying pegasos2 you support MOS or at least Genesi & Mr Buck.
Today, peg2 might give you more Amiga"fun", though.
but then i also read somewhere that MorphOS might be released for the Mac,
IIRC, genesi has not said they will release MOS for Mac.
MOS is developed by a HW company to help to sell pegasos HW.
What ever some Genesi head says, releasing MOS for Mac would hurt pegasos2 sales. (a little bit like releasing it for CSPPC/BPPC)
IIRC, Buck has said that there could be CD's with some MOS runtime to run some MOS application/game (from that CD) on Mac HW.
On the other hand... AmigaOS4 is being developed by a SW company. Their plan/strategy is to get it running on several third party HW platforms, as long as it makes market sense in general (more in the KMOS interview) (http://amigaworld.net/modules/features/index.php?op=r&cat_id=3&rev_id=50&sort_by). Untill AOS4 has matured a year or two I do not think we will see AOS running on other platforms than A1 and classic PPC equipped Amigas.
Check through the alternatives, listen to your conscience etc... and then get the best HW for you.
If you want to use Linux, most likely neither A1 or Pegasos is the best option (and especially not A1).
If you want to use AOS4.x, A1 would be the only option currently.
If you want to use MOS, Peg2 would be the only option...
About the DMA problem. It seems that it's not a problem for AOS4.
Only time will tell if the "SW cache coherency" affects AOS performance. So far AOS4 DMA drivers have not been released outside beta tester group (betatesters indicate that it works well), so it's too early to tell.
Looking outside AOS world: MAI really messed up. They have pretty much lost all their Linux market possibilities for ArtisiaS equipped HW.
-
@ HotRod
I've read the specs for the Atricia S since some months back (allmost a year) and I haven't seen DMA mentioned for the Atricia S.
You would have to go much further back in time than that. A year ago, both the April1 and April2 patches had been released, and also the Articia based Pegasos 1 motherboard had officially been dropped altogether in favour of the DiscoveryII based Pegasos II. These issues was put forward to MAI much long before that.
Besides, I think it's rather funny that you claim that DMA is there and it's working flawlessly, when the manufacturer themselves does not even put this among the features for this particular product (they certainly do for their other (vapor since 4 years) northbridges, since DMA is a too important feature to leave out of a product description if you want to sell northbridges today). Why do they not put DMA among the features for the Articia S northbridge?
It's handled in software, not in hardware.
:-o :-o :-o
Uh, DMA in -->SOFTWARE<--?!??
The AOS 4 driver works. It is 100% reliable.
I actually have an A1 with OS4 pre-release right here, right now. Perhaps this rather unique "software implementation of DMA" would explain the "speed" in file transfers? :-D
@ Bodie
Don't know, I can't speak for PegI owners . All I know is that I can view tv (yes, before you ask, with sound) on my A1 under Linux.
...
With reagrds to the tv cards, quite a few users (of those that I know) seem to have them working fine with their A1's. You can draw your own conclusions (and something tells me we won't agree ).
I am happy for you! :-)
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! :-)
I thought the April chip fixed all the issues for the PegI
Sure, it fixes most of the issues. However, it can not "fix" things that was not implemented in the first place (like PCI->AGP DMA for instance). Anyway, the absolutely best fix against the Articia issues was the Marvell DiscoveryII (and I am SOO glad for that one)! :lol: :-D
-
KimmoK wrote:
If you want to use Linux, most likely neither A1 or Pegasos is the best option (and especially not A1).
It depends on the application! If you want to run Linux and *real silence* is important, but without compromising too much with horse power, for instance in a media box for your living room (http://www.morphzone.org/modules/newbb/viewtopic.php?topic_id=2457&forum=11), and real fast network speed with one (and possibly two? (http://www.morphzone.org/modules/newbb/viewtopic.php?topic_id=2455&forum=11):-o) Gigabit Ethernet lines straight into the fast Northbridge (without going through the PCI bus) and one "traditional" 100Mbit PCI based ethernet (how is that for a home server/router/firewall for your 24/7 home network/Direct Connect efforts? ;-) :-P ), then the Pegasos is an EXCELLENT choice! All major Linux distros runs fine, and it's only getting better all the time! :-)
-
Talking of bridges.. was I the only one who was VERY sceptic towards Marvell-Pegasos2 solution back then? Really... I thought it would never work.
One could say now, afterwards, that it was a good decision to switch to Marvell's product..
(it's us sceptics who make the world worse ;-))
-
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.
-
I actually have an A1 with OS4 pre-release right here, right now. Perhaps this rather unique "software implementation of DMA" would explain the "speed" in file transfers?
How about writing a review, comparing MOS and OS4? :-)
-
for a machine intended to run just one OS that is specifically designed for it the ArticiaS works okay.
Marvell is over 100% faster with HD DMA than ArticiaS. Same southbridge, same HD.
I am no expert, but to me it seems as if Articia was seriously crippled.
-
DrBombcrater wrote:
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 ...
This doesn't sound too healthy to me. BTW, isn't the point of DMA to keep the CPU out of the transfer process?
Anyway, perhaps both "feature+driver" and "bug+workaround" could be used to describe this (depending on your point of view I guess)! ;-)
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.
I am in no way an expert on TV cards, but as you said, it seems like many of them are based on Brooktree/Rockwell/Connexant chipsets Bt848, Bt849, Bt878, Bt879 (at least according to the "overview" at http://www.tv-cards.com/faq.php (http://www.tv-cards.com/faq.php), click on "Are all PCI TV-Cards the same?"), and at least the Bt848, Bt848A and Bt849A seems to support DMA transfer. But they should all still be able to (at least it looks that way in my ignorant eyes) fall back to IRQ/CPU transfer, righ (DMA is of course the best, but not *required*)?
"What is the minimum PC specification to use a PCI TV-Card?
TV-Cards based on the Brooktree/Rockwell/Connexant chipsets require the following minimum spec:
- PCI slot
- Pentium 133Mhz Processor
- DirectX Compatible sound card
- Graphics card supporting DirectDraw and Overlay
- Available IRQ
TV-Cards usually require an IRQ and a memory range but NOT an I/O address or DMA channel."
(This was from the same site (http://www.tv-cards.com/faq.php (http://www.tv-cards.com/faq.php)), click on "What is the minimum PC specification to use a PCI TV-Card")
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?
BTW, "Frostwork" in this thread (http://www.morphzone.org/modules/newbb/viewtopic.php?topic_id=2260&forum=11#17753) has a BT878 based TV card working fine in his Pegasos 1 too, so ... ;-)
Anyway, thank you for your clarifications regarding the Articia DMA. When some people talk about it, it really sounds to be a great chip! Many people seems to be really happy about it (Amiga - back for the future ;-)), and I don't want to be a party pooper here. If you people are happy about it and thinks that it's a solid ground to build an Amiga future(?) on, then I won't disturb you! But personally, I am very glad that the Pegasos moved away from it. ;-)
Have a nice day people! :-)
-
smithy wrote:
I actually have an A1 with OS4 pre-release right here, right now. Perhaps this rather unique "software implementation of DMA" would explain the "speed" in file transfers?
How about writing a review, comparing MOS and OS4? :-)
Hmm, that sounds like a plan, doesn't it? ;-)
-
KimmoK wrote:
Buying amigaone you would support AmigaOS platform.
How?
The AmigaOS platform is now the users: UAE, Amithlon, MorphOS, OS4, original Amiga, AROS. How is buying an AmigaONE going to support anything? The hardware is owned by Eyetech and Mai, the software by Hyperion and "KMOS"*, the label by the now-for-all-intents-and-purposes defunct AInc. I really don't see how buying an A1 supports the 'Amiga platform' any more than buying a Pegasos or a copy of Amiga Forever, or downloading AROS.
* No proof that KMOS is an actual company yet, and likewise no proof that they are not just a cynical Amiga Inc. investor trick. Supporting them could be the same as supporting Amiga Inc - DAMAGING the Amiga platform.
-
@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
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]
-
@ Piru
Transfers from what to what? And of what exactly...
My PC (UDMA100) (http://www.mikeymike.org.uk/mikes/mypc.txt) 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
Transfers from what to what?
HD to memory, raw same sector read.
HD is Seagate ST3120026A 120GB.
And of what exactly...
SCSIBench V1.0 (http://www.aminet.net/util/moni/SCSIBench.lha)
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 (http://www.iki.fi/sintonen/pics/scsibench-1.png).
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]
-
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.
-
@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
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]
-
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
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]
-
May I ask how you benchmarked this?
HDParm under Linux.
-
@DrBombcrater
Ah great. Mind pasting the hdparm command used and command output? I'd like to reproduce the test.
-
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.
-
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.
-
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
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.
-
@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.
-
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 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.
-
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.
-
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. (http://www.uwsg.iu.edu/hypermail/linux/kernel/0201.3/0662.html)* 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:
-
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.
-
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.
-
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.
-
...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
-
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.
-
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...
-
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 (http://mark.foster.cc/blog/archives/000023.html) 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 (http://www.storagereview.com/articles/200304/20030429MAS3735_2.html) -- 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.]
-
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).
-
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
-
This talk of the 90MB/s PegII sounds pretty specious now
It only suggest max transfer rate over ATA interface. Like benchmarking ethernet :-)
-
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.
-
Floid wrote:
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 (http://mark.foster.cc/blog/archives/000023.html) from the 2.4 kernel era, with good, standard hardware... they 'suck!'
I got interested in the numbers for my system, and at first found them despicably low (around 4.5 MB/s for the buffered disk read). I have been using the system for well over a year, and never really noticed this very low value... Duh. Turns out my 2.4.18 kernel did not support the VIA chipset in my PC; I could not even enable DMA manually. So one upgrade to 2.4.26 later, I see 272.34 and 50.00 MB/s on the one hard disk, and 261.22 and 40.00 MB/s on the other. I am genuinely impressed :-). (The system is a KT333/8235-machine, by the way.)
-
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?
-
(if they did Microsoft would have gone out of business years ago), the embedded market is a different ball game.
Refer to www.windowsfordevices.com for examples of embedded Windows devices i.e. Microsoft applies market segmentation for its products. It would be unrealistic for Microsoft and is its value adding partners to offer a full Windows XP install on a limit role computer.
PS; They made "small" profit on embedded related activities (minus XBOX).
Desktop users don't put their machines through that sort of abuse so machines don't need to be so reliable
What kind of abuse?
-
@KennyR
"How is buying an AmigaONE going to support anything?"
According to AlanRedhouse. AOS4 licence is being paid to AOS4 developers for every sold AmigaOne.
"I really don't see how buying an A1 supports the 'Amiga platform'"
See above.
And I was talking about AmigaOS platform.
" any more than buying a Pegasos "
Buying Pegasos supports the competition of AOS4 and funds the court actions of Genesi trying to get the hold of AOS4. (in the end Genesi would have no reason to let AOS4 live to help the sale of competing HW)
OK that came from my perhaps biased twisted mind ... or pehaps I'm just too DISGUSTED from BBRV actions.
"or a copy of Amiga Forever,"
That is supporting AmigaOS. (kind of, especially if licence money go to right address)
"or downloading AROS."
That is not supporting AOS.
-
@takemehomegrandma
"then the Pegasos is an EXCELLENT choice! All major Linux distros runs fine, and it's only getting better all the time!"
So is the x86 competition, I think.
But yes someone might choose Peg2 for that low power consumption but rich media / powerfull telecom use.
-
@Piru
"Marvell is over 100% faster with HD DMA than ArticiaS. Same southbridge, same HD."
But different motherboard, different HW glues / fixes.
And if one compares peg1 to A1:
Different motherboard, different HW glues / fixes, different drivers, (different OS), different southbridge.
"I am no expert, but to me it seems as if Articia was seriously crippled."
It could be.
IIRC: genesi did not try to get ArtisiaS weirdnesses fixed by SW, because it would have been against their strategy.
I have understood that Pegasos1 does not have drivers that can do reliable DMA without April chip's help.
It will be very interesting to compare (A1, Peg1, Peg2) HDD performance with CPU usage when there exist AOS4 with DMA.
-
@KennyR
"Even if every single A1 owner, potential or present, had bought a Pegasos, there would probably only be about 1500 more sales"
A lot of people chose Pegasos pecause it's cheaper than A1. (I could giv a lot of names)
"That's just not worth the expense."
Still Genesi made heavy push to get Amiga developers and users.
"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."
That is something for MorphOS users and AmigaOS fans to think about.
If pegasos prices some miraculously way cover the cost of niche (about 1000 units per board) HW R&D and production, how are the MOS R&D costs covered?
-
KimmoK wrote:
"Even if every single A1 owner, potential or present, had bought a Pegasos, there would probably only be about 1500 more sales"
A lot of people chose Pegasos pecause it's cheaper than A1. (I could giv a lot of names)
And? This is how market economics works. The A1 loses out to a better deal, just as the Pegasos usually loses out to an even better one - a PC. The A1 is ridiculously priced and has lost out on many developers and users.
If pegasos prices some miraculously way cover the cost of niche (about 1000 units per board) HW R&D and production, how is the MOS R&D costs covered?
Who says they are?
If we take it in man-hours payment for code, MOS is not being paid for. But then, the funds from selling A1 won't pay Hyperion's wages either. Both systems are developed part time by the coders with real jobs to bring income.
"How is buying an AmigaONE going to support anything?"
According to AlanRedhouse. AOS4 licence is being paid to AOS4 developers for every sold AmigaOne.
"I really don't see how buying an A1 supports the 'Amiga platform'"
I'm sorry, but I don't consider supporting Eyetech or Hyperion supporting the Amiga platform any more than it would Elbox and Titan or Genesi and bPlan. They're just companies. Hyperion got the permissing to use this miraculous name, but the OS is becoming very unlike OS3 in the way its being designed and the A1 is just a Teron. I'm afraid to me supporting it alone is only supporting the marginilisation of the amiga platform - and marginalised in its own niche!
Buying Pegasos supports the competition of AOS4 and funds the court actions of Genesi trying to get the hold of AOS4. (in the end Genesi would have no reason to let AOS4 live to help the sale of competing HW)
Well, even if it was, so? You'd rather have shadow companies owning this OS? KMOS the mysterious don't-know-anyone-except-GarryHaretheCEO could-be-a-IP-laundering tool?
No... I'd rather have a company that can actually deliver hardware, who I know works for it, and I can speak to anyone on its ranks. KMOS are not that. KMOS, for all I can see, have all the flaws of Amiga Inc, and I will never support such a company on faith ever again. They sell stuff with good prices, I buy it. Else the Amiga name isn't going to dazzle me into buying substanard stuff.
"or downloading AROS."
That is not supporting AOS.
It's supporting the Amiga platform. The potential amount of software from AROS could be staggering, and easily ported to any other AmigaOS flavour - yes, even OS4. If AROS users want to call it AOS, who's to stop them? Amiga Inc?
Seeing the difference from supporting the platform proper and just from supporting name-leeching companies is the first step in actually being able to really support it.
-
KennyR wrote:
but the OS is becoming very unlike OS3
Err yes. Thats why it is called OS4
Sorry couldn't resist.
:lol: :-D
-
@KennyR
"Hyperion got the permissing to use this miraculous name,"
Affect of the blue pill I assume. :)
Hyperion made a deal to continue AmigaOS development.
AmigaOS4 is based on AmigaOS code.
"but the OS is becoming very unlike OS3 in the way its being designed"
It's more like OS3 than how MOS is, especially the design.
(I agree there are things that make wonder how the end result will work, time will tell if the Amiga-like feeling is lost, so far it seems to function OK (according to those who have tried it), same for MOS. )
"and the A1 is just a Teron."
(nothing to do with the AmigaOS platform, but)
And peg is just a CHRP / POP ?
"I'm afraid to me supporting it alone is only supporting the marginilisation of the amiga platform - and marginalised in its own niche!"
Well, people are ofcourse free to support what ever they want. (I was planning to, but I'm not sure I will get peg+mos any more, not untill some changes are made @ Genesi)
I've heard that some have bought M$ products even.
>Buying Pegasos supports the competition of AOS4 and funds the court actions of Genesi trying to get the hold of AOS4. (in the end Genesi would have no reason to let AOS4 live to help the sale of competing HW)
"Well, even if it was, so? You'd rather have shadow companies owning this OS? KMOS the mysterious don't-know-anyone-except-GarryHaretheCEO could-be-a-IP-laundering tool?"
KMOS does not have any reason to kill AmigaOS (or to kill the multi-HW strategy). ( again fully personal opinnion after applying my common sense )
"No... I'd rather have a company that can actually deliver hardware, who I know works for it, and I can speak to anyone on its ranks."
I rather have companies that can deliver hardware and a company that deliver AmigaOS.
"KMOS are not that. KMOS, for all I can see, have all the flaws of Amiga Inc, and I will never support such a company on faith ever again."
To me KMOS does not have the flaws of Amiga Inc. But it neither has any merits either. It's pretty neutral. Perhaps the CEO seems too sane for Amiga market. (no, wait, I forgot the business card grazyness)
"They sell stuff with good prices, I buy it."
They also say cow meat from UK is cheap. I do not buy it.
"If AROS users want to call it AOS, who's to stop them? Amiga Inc?"
No. KMOS has that option. They already acted when the threat against AOS became apparent in the thendic-Amiga court issue.
"Seeing the difference from supporting the platform proper and just from supporting name-leeching companies is the first step in actually being able to really support it."
I think helping AOS4 in any way is the best way to help to keep AOS alive.
Other than that, supporting MOS (without supporting Genesi, if possible), AROS, Amiga SW/HW developers is far better thing to do than supporting Amiga.Inc.
yet one update...
btw. "supporting name-leeching companies" made me build the following reminder of who might get money when one buys A1/AOS4:
- KMOS: AOS defence in court & something else that is not visible yet
- Hyperion: AOS development
- Eyetech: the first company to arrange new AOS4 compatible desktop HW
IMHO: it is better option for Amiga OS fan than the main alternative ( why support AOS imitator OS that is planned to be "something else" if the "original" is also there, why support "other than AOS HW platform" rather than the existing AOS HW platform etc. )
Anyway... I have my opinnion, I let people have theirs. (correction: I try to let people have theirs, sometimes I fail. Sorry for that.) :-(
-
@gadgetmaster
No, it's called OS4 because the people behind it hated bPlan and weren't content to see MorphOS become the only Amigalike system being marketed, and so put up with AInc's horrible licencing to make an OS which is now almost totally superfluous.
-
Hyperion made a deal to continue AmigaOS development.
AmigaOS4 is based on AmigaOS code.
A deal with Amiga Inc, a proven con outfit. I see no connection with the real AmigaOS here.
And OS4 is not based on AmigaOS code, that's just a stupid claim from years back. It's engineered from the ground up using autodocs to be OS3 compatible, just like MOS and AROS. That has become very clear from its greater compatibility to autodocs than to actual OS3, which breaks a lot of software. Eventually Hyperion will fix this I don't doubt, but it shows straight away that OS4 was not based on original, hardware dependent OS3 68k C/ASM code.
It's more like OS3 than how MOS is, especially the design.
Nope. MOS is more like OS3 in every way. OS4 is rather incompatible, uses the MMU like crazy (Commodore NEVER used the MMU), and is furthermore incompatible in other conceptual ways (like renaming all the language catalog dirs in ENGLISH, breaking all old installers). OS4 has departed from OS3 in MANY ways. It's probably the most alien to the OS3 structure of all the current AOS clones.
I rather have companies that can deliver hardware and a company that deliver AmigaOS.
That's a pointless argument, because if tomorrow Hyperion lost the right to call OS4 AmigaOS and Genesi got it, I'm damn sure most of the now-KMOS4 users wouldn't suddenly buy Pegasos just to run AmigaOS.
As for Eyetech...they don't deliver hardware. They simply rebadge it and resell it.
What is the actual name worth, except hype and marketing? What is it worth to the user? Consider that.
To me KMOS does not have the flaws of Amiga Inc. But it neither has any merits either. It's pretty neutral. Perhaps the CEO seems too sane for Amiga market. (no, wait, I forgot the business card grazyness)
That's the whole point - what do you actually know about KMOS? Even less than you did about Amiga Inc, I'm pretty sure. How can you possibly trust them?
They also say cow meat from UK is cheap. I do not buy it.
Irrelevant. It would be relevant of the Pegasos hardware were horribly buggy. It's not.
No. KMOS has that option. They already acted when the threat against AOS became apparent in the thendic-Amiga court issue.
I'm willing to bet KMOS has just as little court power as Amiga Inc. I could be wrong, but they don't seem to be clamping down on small entrepreneurs using the Amiga OS4 name without royalties yet, do they?
I think helping AOS4 in any way is the best way to help to keep AOS alive.
Other than that, supporting MOS (without supporting Genesi, if possible), AROS, Amiga SW/HW developers is far better thing to do than supporting Amiga.Inc.
Well, we differ in the first point. I have the genuine feeling OS4 was introduced just to spike bPlan's plans early on. I agree with the second point - supporting actual developers and trustworthy companies supports the Amiga. Sadly, the list of trustworthies is rather short.
btw. "supporting name-leeching companies" made me build the following reminder of who might get money when one buys A1/AOS4:
Let me amend that a bit. Who gets money when you buy A1/OS4: Amiga Inc (licencing fees); Mai logic; Eyetech; Hyperion. None of which are particularly deserving.
IMHO: it is better option for Amiga OS fan than the main alternative ( why support AOS imitator OS that is planned to be "something else" if the "original" is also there, why support "other than AOS HW platform" rather than the existing AOS HW platform etc. )
OS4 is an imitator OS too. :) Try to think of it as if no-one had the Amiga name. You have HyperionOS, bPlanOS, and OpenROS. Which is most 'Amiga'?
-
@Hammer
I was being sarcastic!
In any case I was referring to the difference in reliability between older MS desktop OSs and embedded stuff. If a computer crashes you reset it, if your CD player did the same you probably take it back. We do not expect a high level of reliability from desktop computers, they are getting better but that's why I said "years ago".
What kind of abuse?
Being on 24/7 for months if not years.
The Win NT/2K/XP line is much better at this of course but even then I've seen crashed ATM machines running NT embedded, I've never seen one with OS/2 crashed...
-
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.