So, I've got a SIL680 in my A1 and it's working fine.

The thing is though, that I've heard that PCI DMA is not enabled in OS4 yet which is why we don't have overlay yet. Am I correct?

This would also mean that the SIL680 card doesn't do DMA to the memory, only "UDMA" between the card and the actual disks, but plain PIO between the card and the CPU. This is my guess why it doesn't perform so very well, only about 20MB/s for a 160GB UATA133 disk.

So my question is: Is this true? Is all PCI activity done by PIO, and no DMA on the motherboard what so ever?? Is the tricky Articia the reason for this not being implemented yet? (sorry for bringing up the NB again....)

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

You need to refer to the article at IntuitionBase and make sure you have the correct settings in UBoot or OS4.0.

Regards
Roy Leith

@Deniil715

If by overlay you mean video overlay, then it's most certainly supported, for the Voodoo only as there's not overlay support in the Radeon drivers yet, and it has nothing to do with DMA.

The SIL680 does DMA to memory if you tell the drivers to use DMA. The main cause for bad performance is sofware which doesn't align the memory to a cache line, and as a result, the drivers must DMA to a buffer and then copy the data to the correct location. (OS3.x software obviously doesn't know about this requirement, OS4 software hopefully have been written with this in mind.)

Last edited by AmiDog on 30-Jan-2005 at 12:26 PM.

@royleith

I have the correct setting, but that's not the issue here.

@AmiDog

Quote:

If by overlay you mean video overlay, then it's most certainly supported, for the Voodoo only as there's not overlay support in the Radeon drivers yet, and it has nothing to do with DMA.

If overlay has nothing to do with DMA, that what separates it from direct VMEM access and using WPA? My impression of video overlay was that you can write to a part of RAM and at the same time have the gfx-card on continuous DMA from that same area directly into (a part of) its own display. This would free the CPU from inserting waitstates while accessing the slow (compared to RAM) PCI-bus and just have it write directly to RAM instead, and have the gfx-card read asynchronously from this same area using DMA while the CPU works in its cache.

Quote:

The SIL680 does DMA to memory if you tell the drivers to use DMA. The main cause for bad performance is sofware which doesn't align the memory to a cache line, and as a result, the drivers must DMA to a buffer and then copy the data to the correct location.

I got the impression that the SIL680 only did DMA from the disk to it's own buffer and then required the CPU to emptying (or filling) the buffer on the SIL680.

But the alignment may explain why DiskSpeed tell me 26MB/s in UATA133 mode but I only get about 10MB/s (20MB/s from each direction) max in real life when copying large files. (Yes I use SFS.) I did however expect a bit more from my SIL680 + UATA133 7k2 rpm disk....

Last edited by Deniil715 on 30-Jan-2005 at 03:29 PM.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

Quote:

If overlay has nothing to do with DMA, that what separates it from direct VMEM access and using WPA?

Well, overlay is basically a picture ("window") in a picture which can have a different colordepth or colorformat than the main picture. This may allow hardware YUB to RGB colorspace conversion, 32bit video on 8bit screens, color keying to show a movie behind the normal windows without using any additional CPU resources, etc, depending on the hardware.

AGP, as I have understood it, should be able to DMA to/from main memory by itself, but overlay has been there long before AGP was even thought about.

Quote:

I got the impression that the SIL680 only did DMA from the disk to it's own buffer and then required the CPU to emptying (or filling) the buffer on the SIL680.

This is what happends if the buffer isn't properly aligned, that is, the buffer to read to must start at a cache line and completely fill a number of cache lines to allow direct DMA. DOS is supposed to handle this correctly and should give full performance. If you copy between partitions on the same disk, it will never get maximum performance because of all the seeking. Unless you copy really large files and the OS use a really large buffer, then you may come quite close...

@AmiDog

Quote:

Well, overlay is basically a picture ("window") in a picture which can have a different colordepth or colorformat than the main picture. This may allow hardware YUB to RGB colorspace conversion, 32bit video on 8bit screens, color keying to show a movie behind the normal windows without using any additional CPU resources, etc, depending on the hardware.

Hmmm, thats sounds a lot like the old Amiga principle of draggable screens, except that it's in 2D instead of 1D (up and down). I wonder if the Friedens could implement draggable screens (only better) using overlays?

@Deniil715

Quote:

Deniil715 wrote: The thing is though, that I've heard that PCI DMA is not enabled in OS4 yet which is why we don't have overlay yet. Am I correct?

DMA is not enabled for CD/DVD-ROMS, the hard drives fully use DMA.

Firbodi

_________________
MicroA1 G3, 512MB RAM, DVD-RW; and A1-SE G3,512MB RAM, CD-RW & DVD-ROM
Avatar: Perspolis, Capital of Achaemenid Empire 500 B.C.

@AmiDog

Quote:

.....without using any additional CPU resources, etc, depending on the hardware.

That's the essense of DMA alright....

Quote:

AGP, as I have understood it, should be able to DMA to/from main memory by itself, but overlay has been there long before AGP was even thought about.

Ok. I'd say I'm sure AGP can do DMA, as can PCI and even ISA can do it. The Zorro-bus must be able to do DMA aswell or f.ex. the fast SCSI-controllers wouldn't have been possible to do on the Amiga.

Quote:

If you copy between partitions on the same disk, it will never get maximum performance because of all the seeking. Unless you copy really large files and the OS use a really large buffer, then you may come quite close...

I have tried with both the same disk and between two disks. I've tried C:Copy, DOpus and my program BackUp which uses a 512k buffer. DOpus is the slowest but they all come close to, or just about succeding 10MB/s copying speed which means I get 20MB/s from each disk. Perhaps the A1 in its current form can't do any better. My brothers "twice" as fast Wintel machine could get about 30MB/s out of one of these disks.


@firbodi

Quote:

DMA is not enabled for CD/DVD-ROMS, the hard drives fully use DMA.

Yea, I know. But I was speculation more about DMA on the motherboard than between the IDE-controller and the IDE-devices.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

Hi,

#define JOKE
to asnwer the topic, lets say 17,432% :)
#undef JOKE

-> "I've heard that PCI DMA is not enabled in OS4 yet"

Who told you such nonsense ?

PCI DMA is enabled in OS4 since day 1. We have a lot of drivers which do use PCI DMA, like Ethernet (which you are probably using), USB (which you may be using too), sound (do you use an sblive or any other supported sound card ?) and the IDE drivers, sii0680ide, sii3112ide and a1ide (but for this one, only the betatester's version).

Why is the DMA-capable a1ide only available for betatesters ? Because it can fail on unfixed XE's when Ethernet is active too, like said many times.

Reminder : DMA is the situation where another bus actor than the CPU deals directly with memory, without going through the CPU. This happens to be the case for the Ethernet chip, the USB chip, the sound chips, the IDE chips etc.

By the way, among those chips, only the IDE chips can be operated in another mode than DMA. This other mode is PIO, where the CPU acts as a data pump between the chip and the memory.

The A1 Ethernet and sound and USB chips can only be operated in PCI DMA.

Thus, I guess the friend who told you that "PCI DMA is not enabled in OS4 yet" must be one of those claiming that OS4 is coded 100% in photoshop (let me tell you a secret, it actually is, and that asked a /huge/ training effort for the dev team).

-> "PCI DMA is not enabled in OS4 yet which is why we don't have overlay yet"

The friend seems to be very much aware.

1 - We do have overlay on OS4, since long, at least with the voodoo boards (I have no radeon, I cant say for radeons).

2 - There would anyway be absolutely no relationship between us having PCI DMA or not, and having overlay or not.

-> "This would also mean that the SIL680 card doesn't do DMA to the memory, only "UDMA" between the card and the actual disks, but plain PIO between the card and the CPU."

Wow. Now thats creative ! Tell me where would the data pumped from the disk in UDMA end up "on the card" ?

If this is yet another statement from the helpful friend, I'd suggest to start considering his opinions as questionable :)

Let me fix those nonsensitical statements.

1 - the sii0680 (and the other IDE drivers, for that matter) do real UDMA, from disk to memory or from memory to disk, without anything faking anything. This happens on the A1 as it happens on any other computer.

2 - there /is actually an sii0680 mixed PIO/UDMA mode/ ! Thats a scoop, tell that to friend !

But. It just happens to work the other way :) It allows using older UDMA-disabled harddisks (thus in PIO mode) without using any CPU ! This is what Silicon Image (the Siixxxx chip maker) calls Virtual DMA. The chip is able to receive an UDMA command, do a PIO transfer on the disk side (ie simulating what the CPU would do if it was a PIO transfer) and store or fetch data to/from memory without requiring any CPU cycle !

So if that mixed mode was used at all, it would be all benefit for OS4, since it would give one of the two UDMA advantages (low CPU usage, the other one being speed) even to slow PIO-only drives !

But. Thats not the case, the Sii0680 acts with hdd's either in PIO or in UDMA, depending on the drive's capabilities, and your uboot or idetool settings. There is no more to it.

-> "This is my guess why it doesn't perform so very well, only about 20MB/s for a 160GB UATA133 disk."

Mmh.

1 - what benchmarck tool did you use ? Could you please state here what an OS4-native "scsispeed sii0680ide.device:n FAST NOCPU buf1=65536 buf2=0 buf3=0 buf4=0" says, where n is your drive unit number ? (os4 scsispeed can be found on os4depot, in the recent diskspeed archive).

You should expect anything between 35 and 55 MB/s.

If you are talking at file level, then please state the filesystem in use, its settings (buffers, blocksize), and for FFS2, if you run the cache plugin or not, and if you change the write cache strategy to relaxed mode or not.

2 - is that a Maxtor 160 GB ? In case it is, let me state that those drives are slow as hell, they rotate at 5.400 rpm, and I have a lot of faster drives here.

3 - Well. No 3 :)

Kind regards,
--
Stéphane Guillard

PS : excuse the ironic tone, but those things have been addressed litterally zllion times already

Last edited by sg2 on 31-Jan-2005 at 09:58 PM.

@sg2

Quote:

Thus, I guess the friend who told you that "PCI DMA is not enabled in OS4 yet" must be one of those claiming that OS4 is coded 100% in photoshop (let me tell you a secret, it actually is, and that asked a /huge/ training effort for the dev team).

What ??
Ok, that's way too much. As a fellow developer, I must warn you that revealing such secret details in public is CLEAR breach of the NDA we all signed! We'll lose any technical lead we could have vs. the other OS's!






Oh, BTW: I've recently found out that, to obfuscate your code, you can just cut a portion of code, apply a gaussian blur, and paste it back. It works!

@sg2

Quote:

Could you please state here what an OS4-native "scsispeed sii0680ide.device:n FAST NOCPU buf1=65536 buf2=0 buf3=0 buf4=0" says, where n is your drive unit number ?

No he can't. Not if he does not have any more luck than me!

I tried the line you suggested and then followed with the drivename from Partition Wizard.

scsispeed si680ide.device:1 FAST NOCPU buf1=65536 buf2=0 buf3=0 buf4=0

I even tried with HD0:. I always get the command template. Just typing scsispeed gives an error - incorrect drive specification.

Can you give any more help?

Regards
Roy Leith

@royleith
oops...

i just noticed u tried that...

use scsibench then..

Last edited by Toaks on 01-Feb-2005 at 01:36 PM.

_________________
See my blog and collection website! . https://www.blog.amigaguru.com

@AV

Quote:

Oh, BTW: I've recently found out that, to obfuscate your code, you can just cut a portion of code, apply a gaussian blur, and paste it back. It works!

Coool. Must try

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@royleith

Hi,

Indeed I'm unable to run the diskspeed.lha stuff from os4depot (which anyway does not seem to contain an scsispeed binary).

Please try my port of scsispeed, also found on os4depot.

The syntax is 'scsispeed drive=[device]:[unitnum] fast buf1=65536 buf2=0 buf3=0 buf4=0'.

Regards,
--
Stéphane

Last edited by sg2 on 01-Feb-2005 at 09:41 PM.
Last edited by sg2 on 01-Feb-2005 at 09:35 PM.
Last edited by sg2 on 01-Feb-2005 at 09:35 PM.

@Toaks

I have always used scsibench in the past, but Stephane promised me I could get higher numbers if I used his program.

Regards
Roy Leith

@sg2
Quote:

Indeed I'm unable to run the diskspeed.lha stuff from os4depot (which anyway does not seem to contain an scsispeed binary). Please try my port of scsispeed, also found on os4depot. The syntax is 'scsispeed drive=[device]:[unitnum] fast buf1=65536 buf2=0 buf3=0 buf4=0'.

Hah! And they call me confused! Anyway, thanks for the advice. Your original note gave the incorrect device name and omitted the drive= keyword entry. The following line worked a treat.

scsispeed drive=si680ide.device:1 fast buf1=65536 buf2=0 buf3=0 buf4=0

It gave similar results to scsibench of around 33-34 MB/s for both my drives. I think both of my drives have an 8MB cache, so this is probably the best this class of drive can produce. You mentioned getting much better results with some drives. Would that be with higher spindle speeds? Does this give a real life performance boost or is this just something to boast about down at the pub?

BTW I also had a go at the other tip you gave in the earlier note. I used the command 'make AmigaOS4.1' in the Photoshop scripting language, but all I got was a strange system requestor with a red, chequered beachball symbol. I really need to move on to OS4.1 as soon as possible so, could you say what I am doing wrong?

Regards
Roy Leith

@CodeSmith

Quote:

I wonder if the Friedens could implement draggable screens (only better) using overlays?

Ahem, you are aware of the fact that OS4 is an effort of roughly 50 or more people ? And that neither Hans-Jörg nor me are invovled in video drivers (only 3d) ?

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

@royleith

33/34 MB/s is an acceptable figure, but it can be one of two different scenarii :

- either this is really what the driver pumps up from your drive in optimal conditions (ie 32 byte aligned buffers), and with unaligned buffers you'd only get 25 MB/s

- or this is the suboptimal situation with unaligned buffers, and you'd get 45 or more with aligned buffers

My scispseed port does not force 32 byte buffer alignment, its just a recompile of Michael Sinz's orginal code. This is why I pointed you to Daniel's more recent diskspeed archive, because he once told me he added proper alignment to my original port. As there is no scsispeed binary in his archive, I'll see to do that myself.

There is no way to tell if a bench run gets aligned buffers or not, except looking at cpu usage which is higher when its not the case. Some times, two consecutive runs differ on that matter ;)

Nota bene :
- there is absolutely no caching in my drivers
- you can't draw any extrapolation from those driver-level figures, to file-level performance (because there is a filesystem above my drivers). This is the purpose of diskspeed. Typically, if a filesystem does massive caching, you could get much better file level performance.

As for real life expectations for sustained transfer rate from drives, I would say that afer having spent "some" time on benchmarking a "somewhat pupolated" drive collection on various systems (both hw & sw), I consider that without driver-level caching, a sustained performance in the 50 MB/s is already very good. There are only very few IDE drives that can do better.

You may wonder how some drivers reach 80 or 90 MB/s transfer rate ; answer is in this post ;)

As for your unsuccessful photoshop experience, I think that you probably do not have the proper binutils for your version of photoshop, because here os4 builds very nicely, and is even very much usable under photoshop animation player !

Kind regards,
--
Stéphane

Last edited by sg2 on 02-Feb-2005 at 01:12 PM.

@sg2

Seagate HDs are fast:

ST340014A
Benchmark results

Information from Seagate's website seem to be quite accurate.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

Indeed, its amazing to see such a close match between the drive specs and the results you got (58 MB/s).

This drive is obviously in the 'very few' fast drives category that I mentioned in my post.

Regards,
--
Stéphane

Last edited by sg2 on 02-Feb-2005 at 03:01 PM.