11 July 2024, 13:10 | #21 | |
Registered User
Join Date: Jul 2018
Location: Stockholm / Sweden
Posts: 253
|
Quote:
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? |
|
11 July 2024, 15:04 | #22 |
Registered User
Join Date: Jan 2005
Location: Umeå
Age: 44
Posts: 962
|
4kB blocksize should not make it slow atleast
|
11 July 2024, 15:35 | #23 | |
Registered User
Join Date: Jan 2005
Location: Umeå
Age: 44
Posts: 962
|
Quote:
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? |
|
12 July 2024, 01:09 | #24 | |
Registered User
Join Date: Jul 2018
Location: Stockholm / Sweden
Posts: 253
|
Quote:
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. |
|
12 July 2024, 07:59 | #25 | ||
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 43
Posts: 9,949
|
Quote:
Quote:
I guess we've established in this thread that the mask is there to work around bugs in different storage controllers. |
||
12 July 2024, 09:07 | #26 |
Thalion Webshrine
Join Date: Jan 2004
Location: Oxford
Posts: 14,589
|
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?
|
12 July 2024, 09:56 | #27 |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 43
Posts: 9,949
|
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..
|
12 July 2024, 10:00 | #28 |
Registered User
Join Date: Mar 2013
Location: Lahti / Finland
Age: 53
Posts: 474
|
|
12 July 2024, 18:40 | #29 |
-
Join Date: Jul 2003
Location: Helsinki / Finland
Age: 43
Posts: 9,949
|
Yes.. But just prepare to be underwhelmed :-)
|
12 July 2024, 21:38 | #30 |
Thalion Webshrine
Join Date: Jan 2004
Location: Oxford
Posts: 14,589
|
I'm airing towards the uSD card he has being terrible.
|
12 July 2024, 23:58 | #31 |
Registered User
Join Date: Jul 2018
Location: Stockholm / Sweden
Posts: 253
|
|
13 July 2024, 01:36 | #32 | |
Registered User
Join Date: Jan 2005
Location: Umeå
Age: 44
Posts: 962
|
Quote:
With address I mean for example the address passed by an application to the filesystem via dos.library/Write() or dos.library/Read() |
|
13 July 2024, 01:54 | #33 |
Registered User
Join Date: Jan 2005
Location: Umeå
Age: 44
Posts: 962
|
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. |
13 July 2024, 07:11 | #34 |
Registered User
Join Date: Mar 2013
Location: Lahti / Finland
Age: 53
Posts: 474
|
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. Last edited by ShK; 14 July 2024 at 07:55. |
13 July 2024, 10:31 | #35 |
Registered User
Join Date: Jul 2018
Location: Stockholm / Sweden
Posts: 253
|
Just to mention it. Increasing buffers did absolutely nothing, with or without the MMULib tools.
|
13 July 2024, 21:55 | #36 |
Registered User
Join Date: Jul 2018
Location: Stockholm / Sweden
Posts: 253
|
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? |
14 July 2024, 01:43 | #37 |
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,366
|
PFS3AIO is the modern alternative, but refer to the original PFS3 archive for documentation.
|
14 July 2024, 09:17 | #38 |
Registered User
Join Date: Mar 2013
Location: Lahti / Finland
Age: 53
Posts: 474
|
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). Last edited by ShK; 14 July 2024 at 10:14. |
14 July 2024, 09:23 | #39 |
Registered User
Join Date: Mar 2013
Location: Lahti / Finland
Age: 53
Posts: 474
|
Pro tip: No matter how you initialize the hard drive with the HDToolBox, always press the "Enter"-button in each field.
|
14 July 2024, 12:45 | #40 | |
Registered User
Join Date: Jul 2018
Location: Stockholm / Sweden
Posts: 253
|
Quote:
Thanks. I'll give that a go and see if it makes things better. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
44-pin IDE pin header for A600/A1200 part number | Firestone | support.Hardware | 2 | 25 May 2024 23:41 |
IDE 40/44 pin adapter to work in Amiga 1200,a bit "dirty" hack. Possible? | hda | support.Hardware | 4 | 11 September 2020 00:05 |
Long 44 pin ide cable | Dustyarddog | support.Hardware | 13 | 28 January 2020 11:32 |
44 pin ide edge connectors | xraynorm | support.Hardware | 3 | 02 February 2019 21:43 |
Running multiple drives/Devices on 44-Pin IDE - Amiga 1200 | antiriad76 | support.Hardware | 8 | 28 December 2017 00:58 |
|
|