28-Mar-2024 23:01 GMT.
UNDER CONSTRUCTION
Anonymous, there are 427 items in your selection [1 - 50] [51 - 100] [101 - 150] [151 - 200] [201 - 250] [251 - 300] [301 - 350] [351 - 400] [401 - 427]
[Events] Notes about my presentation at the Alchimie 4 showANN.lu
Posted on 29-Sep-2004 10:40 GMT by Stéphane Guillard427 comments
View flat
View list
The html pages I made available was only a starter slideshow for my presentation. Here are a few words about what I shown, and what I said. Hi Gentlemen,

The html pages which are available at my site are just an introduction slideshow that I presented as a starter, it does not relate what I shown and said afterwards. Please find below a couple of notes about my presentation at Alchimie show.

Here is a quick summary of the presentation I did :

- I booted with boot delays set to 1 second for UBoot and for SLB (second level booter), thus less than 20 seconds after power on, we were with a fully loaded Workbench with Amidock.

- I started with the small html slideshow, presented on IBrowse. You can find those pages at the URL above. IBrowse loaded in 2 seconds with its About: page fully displayed. Browsing through the pages of the slideshow was instantaneous.

- While we were at it, I browsed the OS4 install guide, also as fast as can be, must say I also find this responsiveness impressive myself :)

Then I demoed as many things as I had time to during the 2 hours I had. Everything worked, fast & stable, and was smooth and impressed. I showed mainly:

- All os4 system, tools, utilities, prefs & stuff

- MUI, IBrowse, Amitradecenter

- Yam, SimpleMail

- ClassAction (M. Elsner's file manager)

- MakeCD

- MooVid running a DivX

- DVPlayer running an mpeg2

- AudioEvolution 4 with the demo project, cursors auto moving smoothly, the playback was smooth also, with mostly no CPU usage.

- AmiPDF with the AE4 manual and another heavy PDF file, very fast

- USB. I plugged a Microsoft IntelliMouse Optical into my USB hub, and we had 2 mice to control the system

- Crisot's slach5 winning demo (got applauses which it deserved)

- chip's rayrace realtime raytracer demo. When the juggler appeared, audience was impressed, but really took measure of what they were watching when I moved the mouse. Wait for the Altivec version !

- FPSE, AmiDog's PS1 emulator, with an oldskool game which ran nicely ('Cotton')

- some other visual toys I had at hand

The demos only grimreaped twice, and I anticipated the grims before they popped up :

- One was native glsokoban / w3d, when I launch it does a base page access (a “null pointer” bug in glsokoban). I didactically shown the disassembly which is available in the grimreaper window, was a store to r4, r4 was null etc. I clicked on continue, and it all went fine & fast.

- One was frying pan 0.3.1, I shown the app, and at one point I said 'now it should grim’ and it did. It still loaded fine though. I quit the app, clicked on reboot and less than 4 secs after, wb was up with amidock. That was the only reboot of the show.

I forgot to show (because of short time):

- Petunia... Almos, sorry, I had prepared something for that (side by side windowed jit & nonjit runs of voxelspace), but i both forgot, and was asked to stop at this point by the party organizers cause it was already 5:30 pm while I was scheduled until 4pm.

- ArtEffect

- USB with MassStorage (ie USB key or digital camera)

At the end, I had many fair questions to which I answered; my feeling is that the audience really appreciated the effort behind what I shown, and was conscious that we are not far away from a releasable 4.0.

Then came the expected question, 'and why doesn’t DMA work ?'

I said 'All what you saw was DMA since the 1st boot'.

I copied a few 100 MB files in a snap, with zero CPU (thanks to Pete Gordon for the clock/CPU docky, helps a lot). Then I switched to PIO, they saw 4 x slower and 80% CPU.

The audience understood that it was indeed DMA, and that was fast, and that was part of the overall smoothness of what I shown.

Then I explained the things below (this is the reference for my statements, please don’t rephrase or extrapolate or invent or whatever):

- IDE UDMA works on VIA and Articia on AmigaOne SE / XE / µA1 MK2 (as I demoed) ...

- ... except when the Ethernet chip goes online and is used.

- the Ethernet chip only triggers the problem, but it is not at all related to it (a test using a PCI Ethernet shows the same behaviour)

- We have made a driver for a Silicon Image 680 PCI IDE UDMA133 controller chip, this does UDMA 133 nicely, including when Ethernet is used at full speed.

- The fact that a PCI IDE controller solution works, shows that the problem is *not* related to Articia, since PCI DMA is *also* handled by the Articia, and that works.

- The full Alchimie show demo was done using UDMA, both from the VIA and from the Si680, without problem (but with Ethernet off, would the Ethernet have been turned online, I would have had to revert the VIA into PIO before).

- Things are currently under more investigation

In the meantime there are 2 options for existing A1 board owners:

- Use the VIA IDE controller in PIO mode when using Ethernet, and UDMA at other times,

- Purchase a faster (UDMA133) Silicon Image 0680 IDE PCI card (from around $20). This is my personally recommended option as the delivered speed is noticeable faster than the on-board VIA controller in UDMA mode.

Notes about my presentation at the Alchimie 4 show : Comment 1 of 427ANN.lu
Posted by Nicolas Sallin on 29-Sep-2004 08:57 GMT
Some time ago, it was proved the corruption problem also happens when using a PCI SCSI card (there was a screengrab on ANN, so nobody can deny it). Any new theory to explain it ?

And what happened to the previous theory (presented as a fact) of a bug into the linux IDE driver ?

And to the other previous theory (also presented as a fact) of a misusage of the ArticiaS features ?
Notes about my presentation at the Alchimie 4 show : Comment 2 of 427ANN.lu
Posted by Menthos on 29-Sep-2004 09:20 GMT
"- IDE UDMA works on VIA and Articia on AmigaOne SE / XE / µA1 MK2
(as I demoed) ...
- ... except when the Ethernet chip goes online and is used. "

This was a little dissapointing. Hopefully something will be done to address this!

Wonder where one can find that IDE controller in Sweden...
Notes about my presentation at the Alchimie 4 show : Comment 3 of 427ANN.lu
Posted by itix on 29-Sep-2004 09:26 GMT
Interesting report. But "- Use the VIA IDE controller in PIO mode when using Ethernet, and UDMA at other times," Why? Buggy ethernet driver/chip?
Notes about my presentation at the Alchimie 4 show : Comment 4 of 427ANN.lu
Posted by itix on 29-Sep-2004 09:31 GMT
"- We have made a driver for a Silicon Image 680 PCI IDE UDMA133 controller chip, this does UDMA 133 nicely, including when Ethernet is used at full speed." Or instead of buying PCI UDMA controller one could buy PCI ethernet card instead? If problem is triggered by on-board ethernet buying PCI ethernet card could be cheaper and easier. (Just thought, I don't know details.)
Notes about my presentation at the Alchimie 4 show : Comment 5 of 427ANN.lu
Posted by Stefan Burström on 29-Sep-2004 09:35 GMT
In reply to Comment 4 (itix):
No, the problem is the wiring to the VIA controller on the motherboard. We already tried the external ethernet card with no success.
We have been able to patch XE rev 1 boards to get working VIA DMA, but I am
still waiting for patch instructions for my rev 2 board before I can verify
that the lockup problem is gone on that board too.

rgds,
Stefan
Notes about my presentation at the Alchimie 4 show : Comment 6 of 427ANN.lu
Posted by Stefan Burström on 29-Sep-2004 09:36 GMT
In reply to Comment 3 (itix):
>Why? Buggy ethernet driver/chip?

No, a simple error in the design that lead to bus collisions between the ethernet chip and the via chip.

rgds,
Stefan
Notes about my presentation at the Alchimie 4 show : Comment 7 of 427ANN.lu
Posted by hooligan/dcs on 29-Sep-2004 09:38 GMT
Seems like it was very thoroughly done demonstration. Res
Notes about my presentation at the Alchimie 4 show : Comment 8 of 427ANN.lu
Posted by iwonder on 29-Sep-2004 09:39 GMT
@Stéphane
- Does this mean that AmigaONE hardware does not work as advertised?
- Will Eyetech provide this IDE card for all AmigaONE owners?
- What is causing the problem exactly? Ethernet chip? IDE chip? Do you know what the problem really is?
- If you don't know what the problem is, what makes you so sure it's not Articia?
- Why is VIA IDE controller slow on AmigaONE with Articia, when it's fast with Pegasos II and Marvell?
Notes about my presentation at the Alchimie 4 show : Comment 9 of 427ANN.lu
Posted by Menthos on 29-Sep-2004 09:42 GMT
In reply to Comment 8 (iwonder):
"- Why is VIA IDE controller slow on AmigaONE with Articia, when it's fast with Pegasos II and Marvell?"

Where did you read that? I'm just wondering, because I could not find any mention of this in the text (not counting when ethernet was in use as that is another issue).
Notes about my presentation at the Alchimie 4 show : Comment 10 of 427ANN.lu
Posted by Peter Gordon on 29-Sep-2004 10:00 GMT
In reply to Comment 8 (iwonder):
" - Why is VIA IDE controller slow on AmigaONE with Articia, when it's fast with Pegasos II and Marvell?"

It is not slow. If you're not using the ethernet, then it works as expected. It is also known that it is not an Articia problem, since with the SIL680 card installed, you can do full on UDMA with ethernet and sound without problem, all of which is using Articia DMA. The other reason they KNOW its not the articia is that they fixed it on the new batch of XE boards being made and the MicroA1.

It is sad that there is such a problem with the existing boards, but at least new boards will be OK.
Notes about my presentation at the Alchimie 4 show : Comment 11 of 427ANN.lu
Posted by Nicolas Sallin on 29-Sep-2004 10:17 GMT
In reply to Comment 10 (Peter Gordon):
It is an ArticiaS bug. Stéphane Guillard already indirectly admited on the french IRC his IDE driver was playing with CPU caches. He also explained to *me* a northbridge couldn't handle cache coherency and that was absolutly impossible, only to prove the driver has to take care of it. He also didn't know other northbridges do it since years.
So, the ArticiaS just doesn't work as advertised AND as documented.
Perhaps it would be time to admit the truth and end all this stupidity instead of creating a new theory every 6 months.
Notes about my presentation at the Alchimie 4 show : Comment 12 of 427ANN.lu
Posted by Peter Gordon on 29-Sep-2004 10:18 GMT
In reply to Comment 11 (Nicolas Sallin):
How do you explain using high speed SI680 UDMA, ethernet and sound at the same time, then?
Notes about my presentation at the Alchimie 4 show : Comment 13 of 427ANN.lu
Posted by Stéphane Guillard on 29-Sep-2004 10:23 GMT
In reply to Comment 1 (Nicolas Sallin):
@henes

Usual bullshit being published everywhere right now, as expected. I'm not going to spend any effort on countering all those worthless claims, I'll do it only once for this comment, just because it was so fast, as an acknowledgement of the huge efforts he makes to spill his acid.

>Some time ago, it was proved the corruption problem also happens when using a PCI SCSI card (there was a screengrab on ANN, so nobody can deny it). Any new theory to explain it ?

I wont deny that corruption can happen with a scsi pci board, given that you don't deny that it was done under Linux, with a driver that does not take into account the fact that the snoop signals from the articia are not propagated properly to the CPU (his problem is the so called 'coherency' one), neither the other two things mentioned below (prd allocation into noncached ram, i8259 code fix needed). You see, mate, I'm kinda aware that there is no SCSI driver for a PCI card under OS4, so...

>And what happened to the previous theory (presented as a fact) of a bug into the linux IDE driver ?

The stock Linux driver cannot be used on a1 for VIA dma because it does not take into account the manual cache flush (write) or invalidate (read) necessary before a transfer, this being due to the coherency problem mentioned above.

Plus, it relies on some features of the HAL on which the Linux kernel runs, which has not always been rightly implemented for the A1. Example : the PRD tables need to stay in noncached memory (the linux code does not explicitly flush cache for the PRD area before starting the DMA transfer). The PRD allocation is done using memory allocation functions that are to be adapted to each platform, to allocate uncached (etc) memory, this has not always been safe in the linux kernel hal for A1. There is nothing wrong hardwarewise, here, its a software issue.

Finally, the linux interrupt controller code (i8259) needs a fix to work properly on the A1. Nothing wrong hardwarewise either, but cannot work without this fix.

Anyway, even when those two issues are taken care of (PRD is allocated in uncached RAM, manual cacheflush for the coherency problem, i8259 code fixed), the linux code runs into the same hardware problem as the OS4 code : VIA IDE DMA cannot run reliably as soon as ethernet is used. Fact.

In my opinion, an scsi driver with those 3 sw fixes (cacheflush for coherency, make sure prd is uncached, i8259 fix) should just run fine.

You see, I dont deny anything, I state facts. I just dont like when they are distorted to death by people who dont have a clue.

> And to the other previous theory (also presented as a fact) of a misusage of the ArticiaS features ?

I suppose that you might be referring to the much-touted floating buffer, guess what : this thing has never been any issue. There is not a single line of code anywhere in my drivers that takes care of it.

Kind regards,
--
Stéphane
Notes about my presentation at the Alchimie 4 show : Comment 14 of 427ANN.lu
Posted by Anonymous on 29-Sep-2004 10:38 GMT
Why lockup is in OS4 only? In Debian everyone UDMA ad ethernet worked at a same time - WITHOUT LOCKUPS! (The downside is random DMA trash.)
Notes about my presentation at the Alchimie 4 show : Comment 15 of 427ANN.lu
Posted by Peter Gordon on 29-Sep-2004 10:53 GMT
BTW, i'm guessing this topic will hit 400 comments ;-)
Notes about my presentation at the Alchimie 4 show : Comment 16 of 427ANN.lu
Posted by Stéphane Guillard on 29-Sep-2004 10:57 GMT
In reply to Comment 14 (Anonymous):
Same problem. Linux happily generates trash, os4 has a different event and interrupt handling that ends up in something else, but its the same problem.

Regards,
--
Stéphane
Notes about my presentation at the Alchimie 4 show : Comment 17 of 427ANN.lu
Posted by hooligan/dcs on 29-Sep-2004 10:59 GMT
In reply to Comment 15 (Peter Gordon):
My guess, 450 ;) (samface, im counting on you!)
Notes about my presentation at the Alchimie 4 show : Comment 18 of 427ANN.lu
Posted by Peter Gordon on 29-Sep-2004 11:03 GMT
In reply to Comment 17 (hooligan/dcs):
Haha.. he would probably say its a feature. "Enforced teabreak every few megabytes!"
Notes about my presentation at the Alchimie 4 show : Comment 19 of 427ANN.lu
Posted by Anonymous on 29-Sep-2004 11:04 GMT
21-nov-2003
http://amigaworld.net/modules/features/index.php?op=r&cat_id=3&rev_id=41&sort_by

"9) royleith: There still seem to be questions about reliable operation of DMA with the Via Northbridge. Is this finally sorted with UBoot, yet, or is there more work to do?"

"The biggest problem was that the VIA interrupt controller was missing interrupts on high loads, such as those generated by DMA transfers. The solution turned out to be a requirement to program an undocumented register in the VIA southbridge."
...
"AmigaOne developer Adam Kowalczyk working together with Bill Mueller 's team at MAI Labs sorted this out by some significant inspiration and a great deal of perspiration."
Notes about my presentation at the Alchimie 4 show : Comment 20 of 427ANN.lu
Posted by Peter Gordon on 29-Sep-2004 11:09 GMT
In reply to Comment 19 (Anonymous):
Yes, and it does work. The bus collisions with ethernet are an unfortunate design problem with these boards, but it DOES work even under stress as long as you're not using the ethernet. Its really crappy, and i'm quite disappointed. I'll be interested to see what happens next for the existing userbase, though.

As said, new boards don't have this problem anyway.
Notes about my presentation at the Alchimie 4 show : Comment 21 of 427ANN.lu
Posted by Andrea Maniero on 29-Sep-2004 11:23 GMT
In reply to Comment 13 (Stéphane Guillard):
> with a driver that does not take into account the fact that the snoop signals
> from the articia are not propagated properly to the CPU (his problem is the so
> called 'coherency' one)

Well, you call it a *problem* right now. We were told there are not "problems" (i.e. "bugs" in my book) with the present ArticiaS design. So, bottom line, lacking of cache coerency is part of a "feature" (the so called "floating buffer") and therefore wanted, or is it something gone wrong while designing the chip?

> The stock Linux driver cannot be used on a1 for VIA dma because it does not
> take into account the manual cache flush (write) or invalidate (read)
> necessary before a transfer, this being due to the coherency problem mentioned
> above.

Now, I'm gonna ask a more "philosophical" question, to say so. DMA means Direct Memory Access, and is a transport protocol where a peripheral device transfers information directly to or from memory, without the system processor being required to perform the transaction. Now, if manual cache flush or invalidate is required, the CPU (that we tried to took out of the picture switching from PIO modes to DMA/UDMA ones, in order to leave it to other tasks) suddenly reappears.
We can, of course, discuss wether the overhead over proper DMA has been minimized, and if such an overhead has been brought down to an acceptable (or even unnoticeable) level, but can we safely state that the ArticiaS *cannot* *handle* *proper* *DMA* transfers (i.e. with the CPU out of the picture)?

> VIA IDE DMA cannot run reliably as soon as ethernet is used. Fact.

I was under the impression that there was no bug that couldn't be solved in SW. Even more unexpected were problems with the ethernet, since ethernet was always mentioned in the past as an example that DMA works on the A1.
Are there any plans to "fix" this for existing A1 owners, or, just like with the on board audio should they buy the n-th additional PCI card at their own cost?

> You see, I dont deny anything, I state facts. I just dont like when they are
> distorted to death by people who dont have a clue.

How do you comment this:
http://www.ann.lu/comments2.cgi?show=1067709954&category=web&number=64#comment

> I suppose that you might be referring to the much-touted floating buffer,
> guess what : this thing has never been any issue. There is not a single line
> of code anywhere in my drivers that takes care of it.

Strangely enough, since the floating buffer was brought into the picture by the AmigaOS4 team, and never mentioned by henes or anyone else on "the other side", to justify the strange behaviour of the Articia as a feature. Thanks, we now know it was not the case. It's a bit clearer now...

Kind regards,
Andrea
Notes about my presentation at the Alchimie 4 show : Comment 22 of 427ANN.lu
Posted by priest on 29-Sep-2004 11:25 GMT
In reply to Comment 8 (iwonder):
" - Why is VIA IDE controller slow on AmigaONE with Articia, when it's fast with Pegasos II and Marvell?"

It's a different controller.
It's not "slow". (even if the other VIA in Pegasos2 is a little bit faster)
Notes about my presentation at the Alchimie 4 show : Comment 23 of 427ANN.lu
Posted by Christophe Decanini on 29-Sep-2004 11:29 GMT
In reply to Comment 13 (Stéphane Guillard):
Your post is very welcome.
You have the honesty to admit problems and post relevant information on a public forum. It clears the noise (clueless people claiming it is working / not working without explaining why) we have daily about the DMA issues.

It is unfortunate that the design problem was found so late and that users will have to use a workaround such as a PCI card to fix this hardware issue.
People may wonder if some other problems will be found later.

I wonder how it affected the plans for Linux. Eyetech is the exclusive distributor for Europe and some vendors were supposed to make money in the Linux market. If the OS and every DMA driver must have special code to handle the Amigaone it may/will never work properly.

I also wonder how accurate were the tests done by users in the last months. There were hundreds of them using Linux on the Amigaone and I can not believe that nobody used ethernet and UDMA at the same time.
Notes about my presentation at the Alchimie 4 show : Comment 24 of 427ANN.lu
Posted by Anonymous on 29-Sep-2004 11:29 GMT
In reply to Comment 13 (Stéphane Guillard):
Your explanation makes me dizzy and gives me the feeling one should better wait for all fixes to be in place before seriously thinking about making the investment.
Notes about my presentation at the Alchimie 4 show : Comment 25 of 427ANN.lu
Posted by Anonymous on 29-Sep-2004 11:34 GMT
In reply to Comment 18 (Peter Gordon):
>Haha.. he would probably say its a feature. "Enforced teabreak every few megabytes!"

Even with teabreak this is the fastest Amiga ever - and if someone complains about the price, just remember the costs of A4000 (or PowerUP!), right? ;-)
Notes about my presentation at the Alchimie 4 show : Comment 26 of 427ANN.lu
Posted by Johan Rönnblom on 29-Sep-2004 11:35 GMT
Well, to repeat myself. In the autumn of 2002, I demoed a Peg1,
without april. I showed:

- Frogger (MorphOS), AmigaAmp (PowerUP) and AMP2 (WarpUP), running at
the same time.

- ImageFX (68k)

- ScummVM

..and many other programs that I don't remember now after 2 years. I
had *no* crashes, *no* problems whatsoever. Except that I started one
app with a screenmode the projector couldn't handle, and I rebooted
the machine to get rid of the screen.

Does this prove that the Peg1 didn't have any bug related to DMA? You
really think so?
Notes about my presentation at the Alchimie 4 show : Comment 27 of 427ANN.lu
Posted by Peter Gordon on 29-Sep-2004 11:36 GMT
In reply to Comment 26 (Johan Rönnblom):
Did you have UDMA on? Did you stress the DMA controller for a period of time? On more than one board?
Notes about my presentation at the Alchimie 4 show : Comment 28 of 427ANN.lu
Posted by Johan Rönnblom on 29-Sep-2004 11:43 GMT
My stance on the A1 DMA issue:

- The Articia has a bug (a deviation from MAI's own specifications)
which means that DMA transfers are not handled properly.

- This bug can be worked around in software, but only with
considerable effort (heavily increased time to produce reliable
drivers) and a heavy speed penalty.

However: Even with this penalty, it should be possible to make a
DMA-driver for the A1 that performs much better (less bad) than the
current PIO mode. It should also be better than what most people
are used to on classic systems. Also, as Amiga-style apps are usually
efficient (and not very demanding, to be honest), slow hard disk
access is not so much of a penalty as it would be on many other
systems. So all in all, OS4 users should be able to live with it.
Their main expected problem is probably that due to the complexity of
the driver, it will take a lot of time before it gets reliable (we've
already seen that, I think that's obvious) and that there will be
similar problems with other DMA drivers.

However, for any other use of the A1, the bug should be quite fatal.
For such applications, the penalty would not be tolerated and the lack
of drivers would also be a very big disadvantage compared to other
systems.
Notes about my presentation at the Alchimie 4 show : Comment 29 of 427ANN.lu
Posted by Peter Gordon on 29-Sep-2004 11:50 GMT
In reply to Comment 28 (Johan Rönnblom):
> and a heavy speed penalty.

We'll see... ;-)
Notes about my presentation at the Alchimie 4 show : Comment 30 of 427ANN.lu
Posted by Anonymous on 29-Sep-2004 11:51 GMT
In reply to Comment 28 (Johan Rönnblom):
The transfers shown used the CPU not at all during DMA transfers, and the data rate was very very fast so where is this "can only be worked around by being very slow" coming from?
Notes about my presentation at the Alchimie 4 show : Comment 31 of 427ANN.lu
Posted by Anonymous on 29-Sep-2004 11:55 GMT
In reply to Comment 28 (Johan Rönnblom):
Why didn't you be there watching that show instead of talking here ?

Did you even read those notes ? The shown transfer was wery fast and it did not use CPU time at all. So why are you still insisting that there would be big speed penalty ?

Guys like you seem to never admit that they are wrong.
Notes about my presentation at the Alchimie 4 show : Comment 32 of 427ANN.lu
Posted by Stéphane Guillard on 29-Sep-2004 11:55 GMT
In reply to Comment 28 (Johan Rönnblom):
Obviously you understood approximately zero.

The articia handles dma fine, as shows the working si680 driver.

This driver works at nominal speed.

There is no software workaround for the via/articia integration problem, at any speed cost at all.

Regards,
--
Stéphane
Notes about my presentation at the Alchimie 4 show : Comment 33 of 427ANN.lu
Posted by Johan Rönnblom on 29-Sep-2004 11:56 GMT
In reply to Comment 27 (Peter Gordon):
There was no way to turn UDMA off in MorphOS, so yes. Yes, I
"stressed" it, many times. No, I personally only had one board.
And btw: Like Stéphane, I couldn't get the on-board ethernet to work
reliably, so I got a cheap PCI card.

Anyway, it would be interesting to know whether IDE DMA will be
included in the long-rumoured OS4 update, or not. If it won't, I guess
I'll have to put up with your "faith" for at least another six
months..
Notes about my presentation at the Alchimie 4 show : Comment 34 of 427ANN.lu
Posted by Anonymous on 29-Sep-2004 11:58 GMT
Who remember eth & ide lockup in non-fixed peg1 board?
Notes about my presentation at the Alchimie 4 show : Comment 35 of 427ANN.lu
Posted by Christophe Decanini on 29-Sep-2004 11:58 GMT
In reply to Comment 30 (Anonymous):
I think that the "very slow" comes from users of Pegasos 1 that went to pegasos 2 assuming that the Amigaone will be at least as limited as was the pegasos1.
Users that have upgraded to the Pegasos 2 have seen much faster HD read / write speed with using the same HD.

Of course as Johan said for most of the classic users (except for those using fast SCI HW on cyberstorm boards) it will be much faster anyway.
However if you compare this to Peg2 or Amithlon setup it looks that it is "very slow"
Notes about my presentation at the Alchimie 4 show : Comment 36 of 427ANN.lu
Posted by Johan Rönnblom on 29-Sep-2004 12:00 GMT
In reply to Comment 32 (Stéphane Guillard):
Stéphane, we'll see what is working and not when Hyperion will
actually release their IDE DMA driver. Until then, how do you want me
to show that it's not working?

Btw, what is this "nominal" speed? Four times faster than the
ultra-slow PIO mode (which seems to give *very* different speeds on
different systems, btw)? Make a test and give numbers in bytes/second,
and it's worth something - but of course, we also have to test that
the driver doesn't cause data corruption. And we can't make that test
until the driver is released.
Notes about my presentation at the Alchimie 4 show : Comment 37 of 427ANN.lu
Posted by Anonymous on 29-Sep-2004 12:00 GMT
In reply to Comment 26 (Johan Rönnblom):
Pegasos-I might have problem with DMA, but if that problem is really related to Articia is completely different issue. It seems to me that it is not related to Articia as that OS4/AmigaOne show showed.
Notes about my presentation at the Alchimie 4 show : Comment 38 of 427ANN.lu
Posted by Davy Wentzler on 29-Sep-2004 12:01 GMT
In reply to Comment 21 (Andrea Maniero):
@andrea

You're basically saying that all 'classic' Amiga's didn't to proper DMA either as they also needed cache flushing.
Notes about my presentation at the Alchimie 4 show : Comment 39 of 427ANN.lu
Posted by Johan Rönnblom on 29-Sep-2004 12:02 GMT
In reply to Comment 35 (Christophe Decanini):
No, I mean slow even compared to the (fixed) Peg 1. Of course even
slower compared to the Peg 2, and we don't want to compare with other
systems out there. ;-)
Notes about my presentation at the Alchimie 4 show : Comment 40 of 427ANN.lu
Posted by Christophe Decanini on 29-Sep-2004 12:02 GMT
In reply to Comment 31 (Anonymous):
Because "very fast" in the eyes of some OS4 supporters sounds as right as "I have used my Amigaone under heavy load for months without any problem".
Notes about my presentation at the Alchimie 4 show : Comment 41 of 427ANN.lu
Posted by Johan Rönnblom on 29-Sep-2004 12:04 GMT
In reply to Comment 38 (Davy Wentzler):
Davy Wentzler wrote:
> You're basically saying that all 'classic' Amiga's didn't to proper
> DMA either as they also used cache flushing.

That's right. DMA on classic machines is definitely quite crippled
compared to any reasonably modern system.
Notes about my presentation at the Alchimie 4 show : Comment 42 of 427ANN.lu
Posted by Stefan Burström on 29-Sep-2004 12:04 GMT
In reply to Comment 36 (Johan Rönnblom):
>Stéphane, we'll see what is working and not when Hyperion will
>actually release their IDE DMA driver. Until then, how do you want me
>to show that it's not working?

Do you have any idea who you are talking to?
Notes about my presentation at the Alchimie 4 show : Comment 43 of 427ANN.lu
Posted by Chip on 29-Sep-2004 12:05 GMT
In reply to Comment 28 (Johan Rönnblom):
" The Articia has a bug (a deviation from MAI's own specifications)
which means that DMA transfers are not handled properly."

Which Articia?

"- This bug can be worked around in software, but only with
considerable effort (heavily increased time to produce reliable
drivers) and a heavy speed penalty. "

Do you have an example code, or you are just speaking some PR text?
Notes about my presentation at the Alchimie 4 show : Comment 44 of 427ANN.lu
Posted by Christophe Decanini on 29-Sep-2004 12:07 GMT
In reply to Comment 39 (Johan Rönnblom):
Who knows, maybe a software solution with a faster CPU can be up to the Peg1 performance. Anyway discussing the onboard A1 UDMA controller performance now seems useless considering it is not working in UDMA when using ethernet.
Notes about my presentation at the Alchimie 4 show : Comment 45 of 427ANN.lu
Posted by Anonymous on 29-Sep-2004 12:07 GMT
Well, PIO (4) is some 16MB/s, and 4x that (as PIO apparently was 4x slower) would give some 60MB/s, which is about the limit of most harddrives when they're not reading from their cache anyway... Ofcourse some actual numbers would be interesting as this is just guessing...
Notes about my presentation at the Alchimie 4 show : Comment 46 of 427ANN.lu
Posted by Anonymous on 29-Sep-2004 12:07 GMT
In reply to Comment 40 (Christophe Decanini):
Are you also one of those guys I mentioned ?
Notes about my presentation at the Alchimie 4 show : Comment 47 of 427ANN.lu
Posted by Anonymous on 29-Sep-2004 12:13 GMT
"- This bug can be worked around in software, but only with
considerable effort (heavily increased time to produce reliable
drivers) and a heavy speed penalty."

The fix would look like this:

void do_read(dst, src, size) {
#if CACHEFLUSHNEEDED
CacheFlush(dst, size, flags);
#endif
TellControllerToRead(dst, src, size);
}

Adding that single line of CacheFlush code doesn't seem to be a "considerable effort" to me...
Notes about my presentation at the Alchimie 4 show : Comment 48 of 427ANN.lu
Posted by Stéphane Guillard on 29-Sep-2004 12:15 GMT
In reply to Comment 36 (Johan Rönnblom):
For the si680 driver, here are figures that show xfer speeds only slightly under the sustained uncached specs of the used drives : http://s.guillard.free.fr/OS4/si680ide.jpg

Other people have either better or worse figures depending on their drives.

The driver is the very first binary produced for the si680, figures will go up to specs.

As for PIO speed, our current a1ide does in the 11 to 14 MB/s in PIO4. Where would that be bad, given PIO4 max. theoretical bw is 16 MB/s ?

Kind regards,
--
Stéphane
Notes about my presentation at the Alchimie 4 show : Comment 49 of 427ANN.lu
Posted by Don Cox on 29-Sep-2004 12:18 GMT
In reply to Comment 10 (Peter Gordon):
"It is sad that there is such a problem with the existing boards, but at least new boards will be OK."

Sad but not unusual. I think just about every classic Amiga model had some hardware problems in the first production batch.

If AmigaOnes were being produced at the rate of several thousand per month, layout faults would have been fixed ages ago. It is the usual problem of small production.
Notes about my presentation at the Alchimie 4 show : Comment 50 of 427ANN.lu
Posted by Christophe Decanini on 29-Sep-2004 12:20 GMT
In reply to Comment 46 (Anonymous):
Your argument of being an user at the show does not proove anything as users at the show do not have the same conclusion and that depending on how it is shown it may lead them in one way or another.

I't better have information on tests with documented and reproducable test procedure.
I know Stephane did several of them and had them online for a while. It looked to me that even if the UDMA drivers made it much faster / less CPU intensive than the PIO drivers it was considerably slower than similar tests on Peg2.

Unfortunately for some reasons Stephane took these tests offline. Maybe the results are much better now but we will only know once something is tested / published. Certainly not with reading user comments on what they saw at a show.

Anyway it does not have any importance anymore as it seems that UDMA + ethernet is not working. I would assume that most of the users want to use the combination of the 2.
Anonymous, there are 427 items in your selection [1 - 50] [51 - 100] [101 - 150] [151 - 200] [201 - 250] [251 - 300] [301 - 350] [351 - 400] [401 - 427]
Back to Top