23-Apr-2024 09:53 GMT.		 UNDER CONSTRUCTION
Anonymous, there are 427 items in your selection (but only 77 shown due to limitation) [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 351 of 427ANN.lu
Posted by Stéphane Guillard on 01-Oct-2004 14:14 GMT
In reply to Comment 346 (Bernie Meyer):
Hi Bernie,

(I'm sorry if I broke your heart ;)

>No, the only thing you can do if you don't have hardware cache coherency
> (which would deal with all of these scenarios without problem) and are
> provided with non-cacheline-aligned buffers (which, judging by my experience
> of writing the zero-copy IDE stuff for Umilator, is most of the time), is to
> use bounce buffers

I'm not sure I used the right words, after all, english is not my native language, but I think I explained exactly that : when I get non aligned buffers in the IDE code, I use my own and copy to/from it.

Here is a copy/paste of a few lines of my comment 318 :

"- for the ide drivers, they usually get buffers from the filesystems that are properly aligned. If that was not the case for whatever reason like a caller not being a filasystem but whatever application like a benchmark tool that feeds a CMD_READ with an even aligned buffer (!), this would still not be a problem, because in this case my code uses its own properly aligned buffer, dma's to it, and then memcpy()'s to the caller's buffer. "

Can you read that ? Now rename "its own buffer" in my text by "a bounce buffer" if that fits your taste :)

I will still go thru your scenarii, and maybe improve my code if needed, I have no problem acknowledging a bug if any.

Kind regards,
--
Stéphane
Notes about my presentation at the Alchimie 4 show : Comment 352 of 427ANN.lu
Posted by Luca Diana on 01-Oct-2004 14:36 GMT
In reply to Comment 350 (Christophe Decanini):
>Did you move back to Italy ?

No, I'm bounced between Wyoming and Hollywood. Horses, Grizzlies, great spaces and movies. There is life after Amiga ;-)
Notes about my presentation at the Alchimie 4 show : Comment 353 of 427ANN.lu
Posted by Bernie Meyer on 01-Oct-2004 14:59 GMT
In reply to Comment 351 (Stéphane Guillard):
Apologies, I did not mean to imply that your driver was going to corrupt data; I suspect I didn't make that as clear as I should haveYes, I saw that you are using bounce buffers. I have rather strong views about the idea of having each byte of DMA'ed data being read from and written back to main memory by the CPU, especially if that main memory is as slow as PC-133 is these days. It seems to me to be contrary to the whole idea of DMA.However, what I took objection to was not your (necessity-driven) decision to use bounce buffers to overcome the deficiencies of the hardware at hand, but rather your explanations of why non-cacheline-aligned buffers would not, in fact, present a problem. Considering that they would (unless you make the CPU copy each byte from a temp buffer somewhere else), and considering you are the guy who is writing the driver that has to deal with this stuff, and to which people may entrust important data at some point, I found those explanations rather frightening.(Oh, and as explanation for why I feel so strongly about this --- I was recently told "the software update you made before going on leave contained a bug which made the machines hang several times a day".... Only to find, when I was investigating, that what caused the hang was a race condition where multiple accesses to the same object weren't properly synchronized; The race condition was in code which predates my involvement, and which I in fact inherited from the very guy who put the blame at my update.... when all the update did was to add a print statement in one of the threads, which often resulted in a thread-switch and thus massively increased the chance of the existing race condition being harmful. So I really don't like it when people gloss over potential problems resulting from multithreading :)
Notes about my presentation at the Alchimie 4 show : Comment 354 of 427ANN.lu
Posted by Fabio Alemagna on 01-Oct-2004 15:00 GMT
In reply to Comment 344 (Luca Diana):
Luca! How long since last time we had a conversation, even longer since we had a friendly one, after you got so mad at me because I dared criticizing Amiga Inc...

> Time goes by but Fabio Alemagna never grows up. I wonder if you'll ever
> realize that there's more to life than petty bickering. I'm not too sure you
> do.

Well, have no fear, I know pretty well what there's to life other than flaming on ANN :-)

> I left the community long time ago because of people like YOU, there's only so
> much a mature person is willing to put up with.

Too bad you used to think it differently, once. Do you remember when we were "friends", and we both cheered for Amiga Inc.? Time went by, and I came to realize that to be your friend one had to have exactly your same ideas. Don't fool yourself, Luca, you never disliked an healthy flame on public fora (usenet holds hundreds of messages by you and me defeding the "Amiga cause" against the "infidels"), what you don't like, as said, are people who have different opinions than yours, and who dare challenge you on topics you are sensitive about.

It's sad, but true.

> I'm here just because Mike brought your email to my attention and you can be
> certain that once I said what I have to say I will not reply, nor read, any of
> the spoiled-kid-stomping-his-feet-on-the-ground insults you will throw at me.

Luca, all this time and you haven't come to realize yet that cheap insults are not part of my style? I'm sure Mike Bouma will forward to you this message too, so I won't have to bear with the bad feeling that I might not be giving you the opportunity to reply ;-)

> > Again, the Amiga community to me is dead.

Well, for being dead it kicks and screams a lot! Perhaps a proper term would be rotten ;-)

> What was discussed on ACCM was far less important than you think, obviously
> your conspiracy theorist mania dictates differently.

Well, Luca, I've had emails sent by you that speak for themselves. I'm not sure I've ever stated that there were "important" things discussed on the ML, what's certain, though, is that one of the main reasons for that list to exist was to at one time bash Amiga Inc for whatever you demed they did wrong, and at the same time bash the outsiders who dared to say that Amiga Inc was doing certain thing wrong. At the best there was damage control being performed, for whatever bad news would suddendly come out.

Luca, I'm not saying you didn't have your reasons to do so, I was with you until a certain point, do you remember? Your problem is that you took the issue way too personally. You considered people at AInc your friends, and defended them as such, in spite of their faults. I won't fault you for this, Mc Ewen, to name one, was indeed your friend, or at least you thought so, and it's remarkable that you went to great lenghts to defend him in spite of everything, however you went way too far, at least for my tastes. And that's were our relationship got broken.

I was one of the most active AmigaDE fans, my translations and hours of hard, often nightly, work on Quantum Leap testify it. You should reflect on the motives that led me to change my mind about the people I was cheering for, rather than simply attack me.

Again, Luca, I once was with you, now I'm not on your side of things anymore, and there's a reason for it. And no, it's not because someone in the AROS Team got a free pegasos board to port AROS to it, as more than once you alleged - which is the saddest thing someone who's supposedly a friend of mine could have done.

> The rest of your claims
> come from your fear that there's alays someone out there to get you.

Uh? Darn, are you saying than the shadow I see when I walk at night is not of someone who's following me?!

> And I still don't understand what's this obsession you have with me, it's been
> what...? 2 years since we stopped talking? Just drop me and get on with your
> life.

Hmmm... I didn't think that mentioning your name in a discussion was a sign of my "obsession" for you... To think that all I wanted to do was giving things a proper context... But now I learned the lesson: next time I will not substantiate my claims. :-)

> Overall, once again let's give way to sensationalism because that's all the
> "community" (all 20 of you) wants. Infinite threads over the same old
> arguments, not even the C64 vs Amstrad or Amiga500 vs Atari ST wars were so
> boring.

How to respond to that... hum... well, there's really nothing to respond, I'm afraid. I don't even know the reason for this outburst of yours here, on ANN, since you've spent all of your words so far to simply say bad things about me, as if I had said anything bad about you. And then you claim I'm obsessed with you...

> I don't have harsh feelings toward anyone (after all, we all took a side, even
> those who claim they didn't. Everybody had his beliefs and acted accordingly,
> it's just human nature.

Believe it or not, I not only don't have bad feelings about you, I even still have feelings of friendship torwards you, and I won't forget the moral support you've given me during my "bad moments".

In any case, I think all this talk is pretty out of place here... you could have sent me a private email, it would have been far much better.

> I don't even have bad feelings toward Gabriele Favrin,
> I might not understand him, but I know he has a big heart), only exception is
> Bill Buck. He lied and he plotted with malevolent intentions since the
> beginning and ultimately I hold him responsible for splitting the community
> and eating resources on both sides just like a cancer, resources that would
> have made a huge difference in the medium and long terms, but everyone was too
> busy throwing mud to notice his plan, which ultimately led to the distruction
> of both sides, sides that could have peacefully coexisted. Ultimately I
> compare him very much to George Bush.

And that's were we strongly disagreed, and where our relationship got broken. I won't comment on that, 'cause you know what I think.

> Go on with your lives guys, let the dream remain a dream before it's too late,
> there's nothing wrong with it

I wouldn't wish anyone to waste his dreams on anything Amiga-related...
Notes about my presentation at the Alchimie 4 show : Comment 355 of 427ANN.lu
Posted by Christophe Decanini on 01-Oct-2004 15:28 GMT
In reply to Comment 353 (Bernie Meyer):
So at this point if we imagine that the next A1 motherboard has no cache issues why did Hyperion presented this as a feature instead as a bug ?
Notes about my presentation at the Alchimie 4 show : Comment 356 of 427ANN.lu
Posted by syrtran on 01-Oct-2004 15:28 GMT
In reply to Comment 339 (Don Cox):
"Give examples. I'm sure there were one or two, but I have about 600 floppies of original Amiga programs here, and I can't think of any that stopped working in 2.0."

Okay, I'm getting tired of this.

Let's try the BIG one: I assume you don't have Amiga Basic (the M$ one) on one of those 600 floppies. I remember reading -lots- of complaints in magazines and on Compuserve's Amiga forum about this. Many people had written games and small utilities in it. I even tried it myself when I upgraded from the 500 to the 3000. Complete lock-up of the 3000.

Another example of OS upgrade incompatibility (2.0x to 3.x, this time): I don't suppose you have a copy of AmigaVision anywhere? If you do, try running it on an OS 3.x machine. The interface will work, but none of the projects will display properly. This upset a lot of people simply because AV was a Commodore product! This one was a particular pain to me after I upgraded the 3000 as I used AV for a couple video projects. (Bought a Toaster then and never looked back.)
Notes about my presentation at the Alchimie 4 show : Comment 357 of 427ANN.lu
Posted by Fabio Alemagna on 01-Oct-2004 15:44 GMT
In reply to Comment 356 (syrtran):
> Let's try the BIG one: I assume you don't have Amiga Basic (the M$ one) on one
> of those 600 floppies. I remember reading -lots- of complaints in magazines and
> on Compuserve's Amiga forum about this. Many people had written games and small
> utilities in it. I even tried it myself when I upgraded from the 500 to the
> 3000. Complete lock-up of the 3000.

Aside from the fact that AmigaBasic was utter crappily coded (it even had issues with floating point values, among the other things), it worked just fine on AmigaOS2.04, as I could test myself. I used to program a lot in AmigaBasic, so I should know. It had some issues with screens, if I remember correctly (I think AmigaBasic's screens used to "wrap" around monitor's borders), but aside from that, there was nothing that didn't work.

You can probably fault the A3000 itself for your lock-ups. Or rather, fault AmigaBasic for locking on the A3000: evidently it assumed things about the hardware, not about the software.
Notes about my presentation at the Alchimie 4 show : Comment 358 of 427ANN.lu
Posted by Anonymous on 01-Oct-2004 15:57 GMT
In reply to Comment 357 (Fabio Alemagna):
AmigaBasic won't work on workbench 2.0 or above, but there is a patch
available that makes it work again.
Notes about my presentation at the Alchimie 4 show : Comment 359 of 427ANN.lu
Posted by smithy on 01-Oct-2004 15:57 GMT
In reply to Comment 310 (MikeB):
>It was an Amiga community advisory mailing list, used by Amiga Inc *and* its
>partners and several community representatives.
>
>[...]
>Don't remember. I do know the list was meant to be confidential though.

What's this? A secret mailing list setup to direct policy? And supposedly to represent the Amiga community, although the representees weren't allowed to see how they were being represented?! This stinks!

Actually I have suspected something like this for a long time now, but never had it confirmed until now. Big changes happened in the Amiga community after McEwen and Moss took over. Things had never been as nasty until these 2 came along. It seems to me they, with help from this secret group, attempted some social engineering in the Amiga community.

My suspicions are now even stronger that this social engineering happened, with the attacks and FUD against MorphOS, attacks anyone who said anything unfavourable about the new owners of Amiga Inc, hounding of people out of IRC channels by supporters (happened to me), and all the reports of behind the scenes intimidation . This only re-enforced the split in the Amiga commmunity caused by Amiga Inc's decision to kill off AmigaOS.
Notes about my presentation at the Alchimie 4 show : Comment 360 of 427ANN.lu
Posted by syrtran@compuserve.com on 01-Oct-2004 16:12 GMT
In reply to Comment 357 (Fabio Alemagna):
As has been already pointed out, I wasn't the only one with problems.

I agree AmigaBasic was crappily coded. Most versions of MS-Basic were (/are- VB has some bugs, too). I believe (IMO) its problems were due to MS using internal OS structures that C= said not to. But, still, it is an example of the interface changing between 1.3 and 2.0x. (Don asked for -any- examples ;-) )

Another "fun" thing that wasn't a problem was that Workbench on 2.0 swapped the black and white pens. This didn't affect me much personnally, but it was wierd the first time I pulled up an icon from 1.3 on 2.0.
Notes about my presentation at the Alchimie 4 show : Comment 361 of 427ANN.lu
Posted by Johan Rönnblom on 01-Oct-2004 16:21 GMT
In reply to Comment 359 (smithy):
Well, it was even worse in that this "representation" took place in a
body whose very existence was kept secret from the "represented".

Now, I don't think the importance of this particular mailinglist
should be overstated. It was very ugly, and totally unacceptable, and
no doubt the source of some problems. But it was hardly the beginning
or the end of unacceptable tactics and hostility.
Notes about my presentation at the Alchimie 4 show : Comment 362 of 427ANN.lu
Posted by Fabio Alemagna on 01-Oct-2004 16:26 GMT
In reply to Comment 358 (Anonymous):
> AmigaBasic won't work on workbench 2.0 or above, but there is a patch
> available that makes it work again.

Really? Then I wonder how come mine worked just fine, as I've said. It came from the Extras 1.3.3 disk.
Notes about my presentation at the Alchimie 4 show : Comment 363 of 427ANN.lu
Posted by Nicolas DET on 01-Oct-2004 16:45 GMT
In reply to Comment 318 (Stéphane Guillard):
> because in this case my code uses its own properly aligned buffer,
dma's to it, and then memcpy()'s to the caller's buffer.

it's even worse to don't have DMA in this case.
-> you have to use CPU copy + the DMA operation on all you unaligned
buffer...

real chipset with HW cache coherency takes care of unalign cache
flush.
Notes about my presentation at the Alchimie 4 show : Comment 364 of 427ANN.lu
Posted by Richard Drummond on 01-Oct-2004 16:45 GMT
In reply to Comment 362 (Fabio Alemagna):
> Really? Then I wonder how come mine worked just fine, as I've said. It came
> from the Extras 1.3.3 disk.

If I remember correctly - and it's been a long time so I could be wrong - the problem with AmigaBASIC was not with newer OS revisions, but with machines with 32-bit address busses. Perhaps the programmes naughtily used the upper 8-bits of pointers for something.
Notes about my presentation at the Alchimie 4 show : Comment 365 of 427ANN.lu
Posted by Don Cox on 01-Oct-2004 17:10 GMT
In reply to Comment 356 (syrtran):
Right, we have one example of a program that stopped working between 1.3 and 2.0 - Microsoft's BASIC. IIRC the problem was that it would only work if you had less that 1 Meg of RAM - or was it 500k?

If only one program stops working between 3.9 and 4.0, that will be OK. If a dozen stop working, that is not OK.
Notes about my presentation at the Alchimie 4 show : Comment 366 of 427ANN.lu
Posted by Don Cox on 01-Oct-2004 17:14 GMT
In reply to Comment 364 (Richard Drummond):
"Perhaps the programmes naughtily used the upper 8-bits of pointers for something."

That is what I remember being the problem. I only coded a couple of little programs with the Microsoft BASIC, so it didn't bother me when it gave problems with extra RAM.
Notes about my presentation at the Alchimie 4 show : Comment 367 of 427ANN.lu
Posted by Fabio Alemagna on 01-Oct-2004 17:27 GMT
In reply to Comment 364 (Richard Drummond):
> If I remember correctly - and it's been a long time so I could be wrong - the
> problem with AmigaBASIC was not with newer OS revisions, but with machines with
> 32-bit address busses. Perhaps the programmes naughtily used the upper 8-bits of
> pointers for something.

Yes! Now I remember what was the issue with ABasic. As said it made assumptions about the hardware, not about the software.
Notes about my presentation at the Alchimie 4 show : Comment 368 of 427ANN.lu
Posted by Anonymous on 01-Oct-2004 18:16 GMT
In reply to Comment 363 (Nicolas DET):
Usual nonsense.

PIO 4 eats 80% CPU and does 14 MB/s, UDMA100 (example) *with* CPU copy eats less than 3% CPU and does 40 to 50 MB/s. Without CPU copying (ie when buffer is properly aligned) we get an extra couple of MB/s, and 1 to 2% CPU.

Please don't ask why we need CPU when doing DMA, would be badly comic.

Obviously you know nothing at all anout those things, and keep throwing half baked arguments, the more you give, the more you make it clear as to what you (dont) understand.

Kind regards,
--
Stéphane
Notes about my presentation at the Alchimie 4 show : Comment 369 of 427ANN.lu
Posted by Fabio Alemagna on 01-Oct-2004 18:36 GMT
In reply to Comment 368 (Anonymous):
> PIO 4 eats 80% CPU and does 14 MB/s, UDMA100 (example) *with* CPU copy eats less
> than 3% CPU and does 40 to 50 MB/s. Without CPU copying (ie when buffer is
> properly aligned) we get an extra couple of MB/s, and 1 to 2% CPU.

Simple diskspeed tests are not able to accurately measure the speed loss coming from the cache flushing/invalidating caused by the bounce buffer usage.
Notes about my presentation at the Alchimie 4 show : Comment 370 of 427ANN.lu
Posted by Nicolas DET on 01-Oct-2004 18:40 GMT
In reply to Comment 368 (Anonymous):
>UDMA100 (example) *with* CPU copy eats less than 3% CPU and does 40 to 50 MB/s
You mean CPU copy of 40 to 50 MB/s of data eat less than 3% of the CPU ?

>Obviously you know nothing at all anout those things, and keep throwing half >baked arguments, the more you give, the more you make it clear as to what you >(dont) understand.

Obiously, I am "un petit scarabé" who doesn't undertand anything about computer science :-).

Nevertheless, I usually think that people who start to be a bit insulting during a debat are the one who lack of real arguementation.

"If I sounded a bit irritating and insulting to this small group of obscurantists who will recognize themselves... Well, then I succeeded."

There is no need to be irrating nor insulting in a normal debat.
What did I do to you ?

See you soon.
Nico
Notes about my presentation at the Alchimie 4 show : Comment 371 of 427ANN.lu
Posted by Anonymous on 01-Oct-2004 18:41 GMT
In reply to Comment 369 (Fabio Alemagna):
Be sure I kinda took time to experiment and measure with some accuracy ;) (and i did not use the 68k scsispeed to evaluate those figures, obviously).

Kind regards,
--
Stéphane
Notes about my presentation at the Alchimie 4 show : Comment 372 of 427ANN.lu
Posted by Johan Rönnblom on 01-Oct-2004 18:46 GMT
In reply to Comment 368 (Anonymous):
Stéphane Guillard wrote:
> UDMA100 (example) *with* CPU copy eats less than 3% CPU and does
> 40 to 50 MB/s.

Ok, let's average that to 45 MB/s. Then let's ignore the time taken
for the actual DMA stuff, and calculate how much you could copy using
100% CPU time:

(100/3) * 45 MB/s = 1500 MB/s. Hmm, I recognise this figure.. ;-)
Notes about my presentation at the Alchimie 4 show : Comment 373 of 427ANN.lu
Posted by Johan Rönnblom on 01-Oct-2004 19:02 GMT
Well, for the people who no nothing at all about those things (no I'm
not talking about you, Nicolas), let's do some more basic
multiplication:

Memory bus width of the G4: 64 bits = 8 bytes
Frequency: 133MHz = 133000000 Hz
Theoretical max transfer: 8 bytes * 133000000 /s = 1GB/s.

This is of course very theoretical, even with a perfect implementation
there would be serious losses. And we know for a fact that the
Articia cannot sustain anywhere near this theoretical max.
Notes about my presentation at the Alchimie 4 show : Comment 374 of 427ANN.lu
Posted by Anonymous on 01-Oct-2004 19:02 GMT
In reply to Comment 372 (Johan Rönnblom):
>(100/3) * 45 MB/s = 1500 MB/s. Hmm, I recognise this figure.. ;-)

SDRAM 133 Mhz 64bit bus -> 133 * 8 bytes (64bits) = 1064 MB/s.
Theses OS4 guy are really god-like codes: they make CPU Copy + DMA operations faster than the memory bus!

We can see here that there might be a load of bullshit in their argumentation...

Remind me, Hermans saying AOne can do several GB/s to main memory !
Notes about my presentation at the Alchimie 4 show : Comment 375 of 427ANN.lu
Posted by Richard Drummond on 01-Oct-2004 19:12 GMT
In reply to Comment 374 (Anonymous):
Where are you getting this bollocks from?

Where did Stéphane say that he could copy 1500MB/s a second?

If the IDE bus is transferring 45MB/s and all of that has to go through a bounce buffer, then surely all the CPU has to do to sustain that is to copy 45MB every second.

Or am I missing something?
Notes about my presentation at the Alchimie 4 show : Comment 376 of 427ANN.lu
Posted by Fabio Alemagna on 01-Oct-2004 19:12 GMT
In reply to Comment 371 (Anonymous):
> Be sure I kinda took time to experiment and measure with some accuracy ;) (and i
> did not use the 68k scsispeed to evaluate those figures, obviously).

Perhaps I wasn't clear... you can measure the (alleged) loss of performance due to cache flushing/invalidating only if you run a memory intensive program whilst reading from/writing to disk. the performance loss should come from cache misses, obviously.

You should firs run a memory intensive program, and benchmark its execution.

You should then run the program together with, say, scsispeed, and benchmark the program again. If all goes well, the performance loss of the program shouldn't be higher than 3%. If it is higher than that, you've hit the problem we've been talking about all along.
Notes about my presentation at the Alchimie 4 show : Comment 377 of 427ANN.lu
Posted by Anonymous on 01-Oct-2004 19:12 GMT
In reply to Comment 374 (Anonymous):
Again, nonsense.

You extrapolate the 3% cpu needed for cpu ram2ram copy after dma, with a PIO transfer performance... If you still don't understand what DMA is about, time to resume reading comment 219.

Additionnally, did it only pass through your head, that the ram2ram copy happens *in cache* ?

Kind regards,
--
Stéphane
Notes about my presentation at the Alchimie 4 show : Comment 378 of 427ANN.lu
Posted by Johan Rönnblom on 01-Oct-2004 19:54 GMT
In reply to Comment 377 (Anonymous):
Nope, that is not the theoretical max for ram to ram. It's the
theoretical max through the bus.

I'm not sure if you think that the DMA data somehow magically ends up
in the cache, without a transfer over the bus, or if you think that
you can copy it from one cached area to another without counting that
this needs to be written back to ram, over the bus. Or both. In either
of these three possibilities you're wrong though.

Now, of course I can extrapolate your figures, as it would be quite
useless to give a performance measurement that could not be scaled to
larger transfers.
Notes about my presentation at the Alchimie 4 show : Comment 379 of 427ANN.lu
Posted by Georg Steger on 01-Oct-2004 20:09 GMT
In reply to Comment 375 (Richard Drummond):
> Where are you getting this bollocks from?
>
> Where did Stéphane say that he could copy 1500MB/s a second?

I think what Johan means is that "UDMA100 (example) *with* CPU copy eats less than 3% CPU and does 40 to 50 MB/s." would mean that this 40 to 50 MB/s needs to be CPU copied inside this 3 % cpu usage. So if the machine can cpu copy 40/50 mbs per second with 3 % cpu usage, then the with 100 % cpu usage it would mean that it can copy (100/3) times as much.
Notes about my presentation at the Alchimie 4 show : Comment 380 of 427ANN.lu
Posted by Anonymous on 01-Oct-2004 20:29 GMT
In reply to Comment 369 (Fabio Alemagna):
Oh really fabio, care to enlighten us as to why and how, instead, you should test?

How incredibly constructive of you.
Notes about my presentation at the Alchimie 4 show : Comment 381 of 427ANN.lu
Posted by Anonymous on 01-Oct-2004 20:38 GMT
In reply to Comment 379 (Georg Steger):
And thus demonstrated his entire lack of understanding of the calculation he has done.

If fact what he has demonstrated (very crudely) is that you would *need* a device that can transfer 1500Mb/s before the CPU is unable to keep up. A totally pointless measure by any streach of the imagination.

A retarded abuse of maths and lack of understanding to try and bolster a pathetic agenda.
Notes about my presentation at the Alchimie 4 show : Comment 382 of 427ANN.lu
Posted by Anonymous on 01-Oct-2004 20:39 GMT
In reply to Comment 381 (Anonymous):
If=In
Notes about my presentation at the Alchimie 4 show : Comment 383 of 427ANN.lu
Posted by Johan Rönnblom on 01-Oct-2004 21:13 GMT
In reply to Comment 381 (Anonymous):
Which part of "let's ignore the time taken for the actual DMA stuff"
is it that you don't understand? Yes, DMA and memcopy can happen at
the same time. For simplicity, I'm assuming that the DMA takes no
extra time at all.

But the fact remains: If you can copy 45MB/s using 3% of the CPU time,
you can copy 1.5GB/s using 100% CPU time.

As the real throughput should be somewhere between 250MB-300MB at the
very most, this means Stéphanes benchmark is off by at least 500%
(using a very optimistic calculation still, for sure).
Notes about my presentation at the Alchimie 4 show : Comment 384 of 427ANN.lu
Posted by CnlPepper on 01-Oct-2004 22:15 GMT
In reply to Comment 383 (Johan Rönnblom):
> "But the fact remains: If you can copy 45MB/s using 3% of the CPU time,
you can copy 1.5GB/s using 100% CPU time."

(Taking your crude estimate to be accurate) That value could only be reached if *no other* systems (such as memory bandwidth etc..) limit the transfer rate, which is not the case - you'll hit other limitations long before you can reach 1.5Gb/s and as such long before you could reach 100% CPU use. ie 100% CPU would never be reached and thus your estimate is utterly wrong.

Stéphane presented the following:

> "PIO 4 eats 80% CPU and does 14 MB/s, UDMA100 (example) *with* CPU copy eats less than 3% CPU and does 40 to 50 MB/s. Without CPU copying (ie when buffer is properly aligned) we get an extra couple of MB/s, and 1 to 2% CPU."

He never suggested 1.5Gb/s throughput could be reached, none of those benckmarks say that. *You* took the UDMA100 figures and nievely multiplied up the transfer rate - deliberately ignoring the fact that there are a large number of other systems that would limit the bandwidth before you could actually reach 100% CPU - and then tried to argue he stated it.

In essence you are comparing a bullshit value you created with a real value in a desperate attempt to demonstrate that there is something wrong with Stéphane's benchmarks when there is nothing wrong with them. The only problem here is that demonstrated by your lack of understanding.

CnlPepper
Notes about my presentation at the Alchimie 4 show : Comment 385 of 427ANN.lu
Posted by Christophe Decanini on 01-Oct-2004 23:08 GMT
In reply to Comment 343 (Luca Diana):
I have to apologize to Mike on this one.
I remember seing the list and being told who was there and I could have sweared that Alan was part of it but I have no other evidence than my memory.
It was a long time ago and Luca may have told me about Alan possible participation which I may have taken for granted.
Notes about my presentation at the Alchimie 4 show : Comment 386 of 427ANN.lu
Posted by Fabio Alemagna on 02-Oct-2004 00:41 GMT
In reply to Comment 380 (Anonymous):
> Oh really fabio, care to enlighten us as to why and how, instead, you should
> test?

Oh mum, look, an anonymoys coward who doesn't even know how to scroll down a page!
Notes about my presentation at the Alchimie 4 show : Comment 387 of 427ANN.lu
Posted by Fabio Alemagna on 02-Oct-2004 00:46 GMT
In reply to Comment 383 (Johan Rönnblom):
> But the fact remains: If you can copy 45MB/s using 3% of the CPU time,
> you can copy 1.5GB/s using 100% CPU time.

Your calculation is right, but there's one thing which you don't consider: Stephane said that the driver doesn't always use the bounce buffer, it only uses it when the buffer given by the user is unaligned at either ends, which is probably not the case with scsispeed.

Which however is another reason for not trusting scsispeed's benchmark in this case: what's being tested is nothing but the best possible scenario, certainly not the average one, let alone the worse one.
Notes about my presentation at the Alchimie 4 show : Comment 388 of 427ANN.lu
Posted by Fabio Alemagna on 02-Oct-2004 00:56 GMT
In reply to Comment 384 (CnlPepper):
> (Taking your crude estimate to be accurate) That value could only be reached if
> *no other* systems (such as memory bandwidth etc..) limit the transfer rate,
> which is not the case - you'll hit other limitations long before you can reach
> 1.5Gb/s and as such long before you could reach 100% CPU use. ie 100% CPU would
> never be reached and thus your estimate is utterly wrong.

That is totally irrelevant. IF Stephane has benchmarked the driver while using the bounce buffer, then it means that, beside the time taken by the DMA operation, there would have to be the time taken by the cpu to copy data from one memory location to the other. That is, the CPU should be doing read+write for each and every word read from disk. Obviously this cannot be faster than simply doing the DMA operation, as I hope you understand.

Now, however, for sake of simplicity, let's assume the DMA operation took no time at all. This simplification in no way makes things worse for Stephane, as we're doing a low estimate here. In other words, whatever result we come up with doing this assumption, will never be worse than reality, so we can do it.

So, I was saying, let's assume the DMA transfer took no time at all. What's left is the CPU transfer, that is the read+write operation.

Let's do another simplification here, let's assume that the CPU is going to write stuff to a cached memory location. Let's even assume that this operation takes zero time. It's of course not the case, but it won't hurt our low estimate, it will just make it even lower, thus it's all good for Stephane's benchmark.

What's left, then, is CPU's read operation. Supposedly, this operation takes up 3% of the whole CPU time, and it's able to transfer, during this time, data at about 50MB/s. Now, do your own math, and calculate how much fast it is REALLY (supposedly, of course) going. Johan did the calculation, which is flawless, and you know the impossible result.

So, either Stephane's was lying (very unlikely), or the CPU-free meter was borked (possibily), or simply scsispeed doesn't trigger the bounce buffer usage i the driver (most likely).

In either of those cases, the benchmark was borked and not a proof of real life performances. It's certainly not a benchmark to base one's decisions for driver's improvements and optimizations upon.
Notes about my presentation at the Alchimie 4 show : Comment 389 of 427ANN.lu
Posted by Bernie Meyer on 02-Oct-2004 04:38 GMT
In reply to Comment 368 (Anonymous):
Please, if you don't know what you are talking about, don't talk!You state that with CPU-copying of bounce buffers, the DMA driver does 40-50MB/s at 3-4% of CPU load. Let's say 40MB/s at 4% CPU load.... that would require a copy-bandwidth from/to main memory of 1GB/s.The A1 uses PC133 memory, IIRC. You would be hard pressed to even get 200MB/s copy bandwidth, let alone 1000MB/s. More realistically, you are probably looking at roughly 100-150MB/s, which means that at 40-50MB/s from the disk, your CPU spends about 25-35% of its time copying data.If your benchmark program shows something different, then your benchmark program is lying to you. Wouldn't be the first time, won't be the last. That's why you should always look at numbers you get from benchmarks, and wonder whether they can possibly be correct.(Of course, there is another issue here, which is more subtle --- depending on the size of the bounce buffer, you will get lots and lots of interrupts. For example, if it is 64kB, you are looking at almost 1000 interrupts per second. During each of those interrupts, 64kB get copied from main memory to main memory, completely thrashing the data cache. Depending on what else is going on in the machine at the same time, after each such copy the whole data cache may need to be reloaded, adding another 40-50MB/s of main memory reads which wouldn't be necessary in a cache-coherent system).
Notes about my presentation at the Alchimie 4 show : Comment 390 of 427ANN.lu
Posted by Anonymous on 02-Oct-2004 08:35 GMT
In reply to Comment 377 (Anonymous):
Does your ScsiSpeed port align the buffer address?
Notes about my presentation at the Alchimie 4 show : Comment 391 of 427ANN.lu
Posted by pixie on 02-Oct-2004 10:22 GMT
In reply to Comment 383 (Johan Rönnblom):
> But the fact remains: If you can copy 45MB/s using 3% of the CPU time,
> you can copy 1.5GB/s using 100% CPU time.

How much Pegasos does with UDMA!? I've heard about 60MB/s, I presume by your words that it's normal that it does it by using 50% to 90% and not this 'magic number of about 3%...
Notes about my presentation at the Alchimie 4 show : Comment 392 of 427ANN.lu
Posted by Johan Rönnblom on 02-Oct-2004 10:53 GMT
In reply to Comment 391 (pixie):
The Pegasos has working DMA hardware, so it doesn't need to do this
copy operation at all.
Notes about my presentation at the Alchimie 4 show : Comment 393 of 427ANN.lu
Posted by pixie on 02-Oct-2004 14:10 GMT
In reply to Comment 392 (Johan Rönnblom):
So you are assuming AmigaOne hasn't... after all it has or has not DMA? It's said:
> - IDE UDMA works on VIA and Articia on AmigaOne SE / XE / µA1 MK2 (as I demoed)

It doesn't work on none of them, it works on all of them, it only work on µA1s... There's so much ambiguity, and much from people who aren't even remotely interesteed in Amiga at all...
Notes about my presentation at the Alchimie 4 show : Comment 394 of 427ANN.lu
Posted by Bernie Meyer on 02-Oct-2004 14:49 GMT
In reply to Comment 393 (pixie):
Oh, come on! 393 comments later, and you still don't understand?(a) The Articia S, as used on the A1, does not provide hardware cache coherency. Call it a feature (Ben Hermans), a bug (Bill Buck) or a problem, but don't argue over it.(b) There is a *second* problem with most if not all A1s produced so far, which makes the DMA on the inbuilt IDE controller effectively unusable (yes, strictly speaking you supposedly can use it unless you also use ethernet; But considering that the problem isn't the ethernet, but the IDE, would you *really* want to trust your data to that IDE controller? Who knows what else, other than ethernet, can trigger the problem....)(b) is what is supposedly fixed on new A1s from now on. However, bounce buffers are not required because of (b), but rather because of (a).
Notes about my presentation at the Alchimie 4 show : Comment 395 of 427ANN.lu
Posted by JKD on 02-Oct-2004 15:31 GMT
In reply to Comment 394 (Bernie Meyer):
Someone please simplify for me:

SO after all this time and all these pointless threads, does it
reallyl come down to the conclusion reached aeons ago that the
Articia S is either:

a) Broken - depending on your definition of broken
b) Does not support a feature required for optimal performance of a
desktop or server OS?

...all the rest inbetween is fluff?
Notes about my presentation at the Alchimie 4 show : Comment 396 of 427ANN.lu
Posted by Don Cox on 02-Oct-2004 16:11 GMT
In reply to Comment 395 (JKD):
"SO after all this time and all these pointless threads, does it
reallyl come down to the conclusion reached aeons ago that the
Articia S is either:

a) Broken - depending on your definition of broken
b) Does not support a feature required for optimal performance of a
desktop or server OS?"

No, it comes down to "this is still a matter for argument".
Notes about my presentation at the Alchimie 4 show : Comment 397 of 427ANN.lu
Posted by Johan Rönnblom on 02-Oct-2004 16:13 GMT
In reply to Comment 395 (JKD):
Reading carefully, Stéphane does not admit that the bug is in the
Articia, but claims that it is some other, unspecified, hardware
error in the AmigaOne. Well, that detail can be left aside I guess.

Also, he actually claims that the next AmigaOnes released will have
all problems fixed. Of course, this is what has been claimed for years
now, and it hasn't happened so far. So I think this claim can safely
be disregarded until such systems are actually available, at which
time it will of course be a simple matter to test whether the standard
Linux distributions using standard Linux drivers do work properly, or
not.

But yes - the AmigaOnes, as sold so far, are defect. That much should
be clear now.
Notes about my presentation at the Alchimie 4 show : Comment 398 of 427ANN.lu
Posted by Richard Drummond on 02-Oct-2004 16:21 GMT
In reply to Comment 395 (JKD):
> a) Broken - depending on your definition of broken

If your definition of broken includes no hardware cache coherency then yes. I don't think anyone's disputing that. ;-)

> b) Does not support a feature required for optimal performance of a
> desktop or server OS?

All this wrangling over the bounce buffers is interesting - and it does appear that the benchmark for CPU usage that Stéphane posted is inaccurate.

BUT if bounce buffers are only used when transferring to/from unaligned memory, and Stéphane said earlier that filesystems usually give the ide driver aligned memory. If that is true, then the CPU usage hit caused by the CPU copy is going to be rare in normal operation, and all the rest of the "fluff", as you say, seems to be for people who care about benchmarks rather than real world performance.
Notes about my presentation at the Alchimie 4 show : Comment 399 of 427ANN.lu
Posted by pixie on 02-Oct-2004 18:44 GMT
In reply to Comment 394 (Bernie Meyer):
> (b) There is a *second* problem with most if not all A1s produced so far, which
> makes the DMA on the inbuilt IDE controller effectively unusable (yes, strictly
> speaking you supposedly can use it unless you also use ethernet; But considering
> that the problem isn't the ethernet, but the IDE, would you *really* want to
> trust your data to that IDE controller? Who knows what else, other than
> ethernet, can trigger the problem....)

I don't want to nit picking here, but it seems after at present date:
a) DMA works, it 'just' doesn't work with ethernet in the worst case, but tests can still be made without ethernet cards showing that 'weird' number of 3% o cPU usage, without cheating at all;
b) the new batch of AmigaONEs are said to have overcome this very same problem...

By a) I mean that I understand that it can have some flaws, but tests can still be made giving those figures without being false, but I know there are the ones who'll argue until the end of the world that AmigaONE has no DMA *at all* and never will, after all BBRV still brings MAI at every ocasion despite all the time it went bye.

After all A1 have or not DMA, ever/never/on some setups and does µA1 has overcome it or no!?
Notes about my presentation at the Alchimie 4 show : Comment 400 of 427ANN.lu
Posted by pixie on 02-Oct-2004 18:44 GMT
In reply to Comment 397 (Johan Rönnblom):
"So I think this claim can safely be disregarded until such systems are actually available, at which time it will of course be a simple matter to test whether the standard Linux distributions using standard Linux drivers do work properly, or
not. "

I love this... guikty until proven!!!
Anonymous, there are 427 items in your selection (but only 77 shown due to limitation) [1 - 50] [51 - 100] [101 - 150] [151 - 200] [201 - 250] [251 - 300] [301 - 350] [351 - 400] [401 - 427]
Back to Top