mSATA to 44 pin IDE adapter?

[Liqourice]

Originally Posted by patrik

0xFE00 MaxTransfer is unnecessary limiting, 0x1FE00 is enough to avoid the bug in 3.1 scsi.device.

Also verify that your Mask isn’t set to something really strange. It should be default 0x7FFFFFFE, but can even be completely unlimited at 0xFFFFFFFF with the C= IDE scsi.device, it has no memory region or alignment access bugs as it copies all the data using the CPU.

Changed maxtransfer to 0x1FE00 and mask to 0xFFFFFFFF (which was at default). No dramatic change. Without using MuFastRom and MuFastZero writing got a little bit faster, reading no change. Same thing with them active, writing a little bit faster (0.04 instead of 0.02) and reading pretty much the same again.

I have no oddities started through S-S or U-S, I used to back in the day when I ran a BBS but they're all commented out so shouldn't have any impact.

This will have to be left like this until I get 3.2, I'll make a fresh install then and just make a backup of this old one.

Block size shouldn't have an impact, or? Currently I'm on 4096 but I read somewhere that you shouldn't use higher than 512 with FFS?

[patrik]

4kB blocksize should not make it slow atleast

[patrik]

Originally Posted by Liqourice

Above is without, below is with. Sysspeed and Diskspeed shows pretty much the same figures.

Taking a closer look at your SysSpeed numbers some things can be noted:

1. MuFastROM has increased the speed of scsi.device as you get ReadFile 0.64->2.60MB/sec (read through filesystem) and RAWRead 0.78-> 2.34MB/sec (direct device read). Don't understand how the RAWRead can be slower, it should always be faster, but never mind that, SysSpeed is not perfect. So if you check SysInfo now, it should give way better results than before too - it also does raw reads.

2. The odd part as you say is that your writes used to matched the reads, but now they are super slow for no good reason. With MuFastROM, scsi.device is performing as it should, but can it be that your SD card for some reason handles writes really really bad and now when the computer attempts writing at a far faster pace, the SD card reacts really bad to it? Do you have another card to try with?

[Liqourice]

Originally Posted by patrik

Taking a closer look at your SysSpeed numbers some things can be noted:

1. MuFastROM has increased the speed of scsi.device as you get ReadFile 0.64->2.60MB/sec (read through filesystem) and RAWRead 0.78-> 2.34MB/sec (direct device read). Don't understand how the RAWRead can be slower, it should always be faster, but never mind that, SysSpeed is not perfect. So if you check SysInfo now, it should give way better results than before too - it also does raw reads.

2. The odd part as you say is that your writes used to matched the reads, but now they are super slow for no good reason. With MuFastROM, scsi.device is performing as it should, but can it be that your SD card for some reason handles writes really really bad and now when the computer attempts writing at a far faster pace, the SD card reacts really bad to it? Do you have another card to try with?

I'm inclined to believe it's either the SD card or the adapter that's causing this. I really can't find any other explanation.

I don't have any other SD-card to try with atm. The 4GB one I bought to use didn't work at all, no matter how I tried the settings wouldn't stick after partitioning, so I tried with this 8GB one I've had for years. Seems it's a bit of hit and miss with them. Not sure I want to buy a bunch of cards I have no use for if they don't work. That's the main reason why I'm considering an SSD solution.

[Jope]

Originally Posted by patrik

It doesn't really matter if the first number of 7FFFFFFC is a 7 or F. The difference would be that 7 does not allow direct transfers above the lower 2GB of address space, but no Amiga has memory above that, so thats why it does not matter.

Heh, you're right. I don't remember sizes in hex by heart and didn't bother checking this time.

This speed difference is only seen if tested through filesystem access. SysInfo, SCSISpeed, RSCP etc does direct device access. You need say DiskSpeed (found on aminet), which also can test speed at different alignment - watch speed of WORD and BYTE transfers in DiskSpeed decrease enormously if you change Mask 7FFFFFFF -> 7FFFFFFC for example.

If we're in the Commodore IDE controller territory, F as the last number should be totally fine. Some other controllers might want something else.

I guess we've established in this thread that the mask is there to work around bugs in different storage controllers.

[alexh]

I thought the mask is there to describe the region of memory the SCSI DMA controller can DMA to? So the filesystem knows where to allocate buffers? I don't think it has a purpose with non DMA controllers like Gayle?

[Jope]

True. Maybe sometimes you can see a speedup with a non-DMA controller if you adjust the alignment, but that's down to everyone's personal benchmarking/min-maxing needs I guess..

[ShK]

Originally Posted by Jope

Maybe sometimes you can see a speedup with a non-DMA controller if you adjust the alignment

Do you mean changing 7FFFFFFC to 7FFFFFFF?

[Jope]

Yes.. But just prepare to be underwhelmed :-)

[alexh]

I'm airing towards the uSD card he has being terrible.

[Liqourice]

Originally Posted by alexh

I'm airing towards the uSD card he has being terrible.

Gonna buy a new one tomorrow. Gonna go for a Samsung card and see how that works. Not sure what the brand is with the one I have, doesn't say so it's probably some cheap card.

[patrik]

Originally Posted by alexh

I thought the mask is there to describe the region of memory the SCSI DMA controller can DMA to? So the filesystem knows where to allocate buffers? I don't think it has a purpose with non DMA controllers like Gayle?

Mask is kind of opposite: it allows you to restrict what memory address and alignment the filesystem does direct transfers to/from with the device. I am saying transfer here as the device can do it using DMA or PIO (with the CPU), the filesystem does not know and will apply the same safe and very slow method mentioned earlier if the address doesn’t match the Mask, so with a too restrictive Mask you will see the same slowdown for non DMA controllers.

With address I mean for example the address passed by an application to the filesystem via dos.library/Write() or dos.library/Read()

[patrik]

Originally Posted by Jope

Yes.. But just prepare to be underwhelmed :-)

Yep, most of the time the applications will send very well aligned and nice addresses for the write and reads and will not be restricted by the alignment part of the Mask - this surely is the case drive speed test software in general.

Only drive speed software I know which has a function to test with alignment is DiskSpeed with its LONG (4-byte aligned), WORD (2-byte aligned) and BYTE read/write tests. With 0x7FFFFFFC, LONG will be normal speed and WORD and BYTE will be very slow as filesystem safe/slow method with is used.

Depending on your controller, even with 0x7FFFFFFF, BYTE and possibly WORD can be slower than LONG because the device or hardware cannot handle that alignment as efficiently, but it will generally be way faster than the filesystem safe/slow method.

Example of controllers with slower handling of some alignment:
- A3000 cannot do DMA below LONG/4-byte alignment (latest DMAC can do WORD), but immensely faster to have the device handle this instead of fs via Mask.
- GVP HD8+/HC+8 cannot do DMA for BYTE alignment, same comment as A3000 about speed.

[ShK]

How about of align cylinders to SD-card erasable block size and file system blocks to a writable page size? Each block gets more often erased and rewritten twice if misaligned. Standard SD cards typically have erase block sizes of 4KB. SDHC (Secure Digital High Capacity) and SDXC (Secure Digital eXtended Capacity) cards usually have larger erase block sizes, ranging from 4KB to 512KB or more, with common values being 128KB or 256KB.

HDToolBox:
Cylinders (cylinders per HDD or tracks per layer)
Heads (Tracks per cylinder)
Blocks per Track (This will aligns erase block size)
Blocks per Cylinder (Heads * Blocks per Track)

So, ideally RDB to beginning of SD-card and First partition should be start after next even erase block size and size should be dividable for erase block size.

IDE commands (ATA5 or lower) have "sector count" field which is 8-bits, so MaxTransfer can have a maximum value of 255 (e.g. 255 * 512 = 130560b = $1FE00). MaxTransfer must also be divisible by the sector size (512) due to a bug in the WorkBench format code. Ideally MaxTransfer size should also be dividable with the writable page size.

Mask 7FFFFFFF, like discussed above.

Ideally the BlockSize (Not to be confused with Bytes Per Block) should be divisible by the writable page size of the SD card. This alignment will improve read and write speed with larger files at the cost of some space waste by smaller files. Typical SD card writable page sizes are 512 bytes or 2KB (2048 bytes).

Buffers are used mainly for directory and meta data and have no relation to the hardware. More buffers will give a better performance by costs of ram. How much buffers are needed dependent on the largest number of files that is in one directory. In case of PFS3 recommended is to use between 200 and 300, using larger values for larger partitions. If the partition contains large directories (more than 2000 files), use 350 to 500 buffers. Each buffer in the cache is 1024 byte (1K), independent of blocksize.

[Liqourice]

Just to mention it. Increasing buffers did absolutely nothing, with or without the MMULib tools.

[Liqourice]

Now I don't know what to do.

Bought a new 64GB (smallest I could find) Samsung microSDXC UHS-1 A1 V10. Same thing as the other card, though a little bit faster at writing (0.05) with the MMULib tools active.

So I'm at a loss here now.

Wonder if I should try to install some other filesystem and see if that helps. What's the best to try?

[idrougge]

PFS3AIO is the modern alternative, but refer to the original PFS3 archive for documentation.

[ShK]

I would go also with PFS3AIO. If you initialize the SD card with WinUAE (run as administrator) and A600 IDE is selected, you can easily see the SD card's total block size. For me, e.g., 32GB cards show 62333952 blocks.

Because 512 bytes per block is a fixed value in HDToolBox, we know that one block is 0.5KB. If we rely on the erase block size being 512KB, it makes 1024 blocks. That will be our Blocks per Track value.

To keep all HDToolBox values under 32768 (to be safe), we can increase the Heads count to two. That will give us 30436 Cylinders (block size / Heads / Blocks per Track = Cylinders):

Cylinders = 30436
Heads = 2
Blocks per Track = 1024
Blocks per Cylinder = 2048 (Heads * Blocks per Track)

When you add PFS3AIO, give a DosType 0x50445303 ("PDS" 3 in hex values).
In File System, select now "PDS\03" from the drop-down menu and give:

Mask: 0x7FFFFFFF
MaxTransfer: 0x10000

Ideally MaxTransfer value of 64KB (0x10000) should provide optimal alignment with both the writable page sizes and erase block sizes of modern storage devices, while still complying with the 0x1FE00 limitations of the IDE/ATA interface.

Default File system block size 4096 (4096 blocks * 512 Bytes / 1024 = 2048 Kilobytes) is divisible by the 512KB erase block sizes and by the writable page size of 512 bytes. Also, all remaining values can be left as default.

Size of one cylinder is 1024KB (2048 blocks * 512 bytes per block), so the default first partition's Start Cyl 2 after RDB is also divisible by 512KB erase block sizes.

PFS3 recommends using buffers between 200 and 300 when having approximately less than 2000 files in directories. Using e.g., 300 buffers will take 300KB of memory (Number of buffers × 1KB).

[ShK]

Pro tip: No matter how you initialize the hard drive with the HDToolBox, always press the "Enter"-button in each field.

[Liqourice]

Originally Posted by ShK

I would go also with PFS3AIO. If you initialize the SD card with WinUAE (run as administrator) and A600 IDE is selected, you can easily see the SD card's total block size. For me, e.g., 32GB cards show 62333952 blocks.

Because 512 bytes per block is a fixed value in HDToolBox, we know that one block is 0.5KB. If we rely on the erase block size being 512KB, it makes 1024 blocks. That will be our Blocks per Track value.

To keep all HDToolBox values under 32768 (to be safe), we can increase the Heads count to two. That will give us 30436 Cylinders (block size / Heads / Blocks per Track = Cylinders):

Cylinders = 30436
Heads = 2
Blocks per Track = 1024
Blocks per Cylinder = 2048 (Heads * Blocks per Track)

When you add PFS3AIO, give a DosType 0x50445303 ("PDS" 3 in hex values).
In File System, select now "PDS\03" from the drop-down menu and give:

Mask: 0x7FFFFFFF
MaxTransfer: 0x10000

Ideally MaxTransfer value of 64KB (0x10000) should provide optimal alignment with both the writable page sizes and erase block sizes of modern storage devices, while still complying with the 0x1FE00 limitations of the IDE/ATA interface.

Default File system block size 4096 (4096 blocks * 512 Bytes / 1024 = 2048 Kilobytes) is divisible by the 512KB erase block sizes and by the writable page size of 512 bytes. Also, all remaining values can be left as default.

Size of one cylinder is 1024KB (2048 blocks * 512 bytes per block), so the default first partition's Start Cyl 2 after RDB is also divisible by 512KB erase block sizes.

PFS3 recommends using buffers between 200 and 300 when having approximately less than 2000 files in directories. Using e.g., 300 buffers will take 300KB of memory (Number of buffers × 1KB).

Thanks. I'll give that a go and see if it makes things better.