Max Transfer rates help

after swapping out my cheap chinese 16gb CF card for a 16gb Sandisk , i was checking the max transfer settings via hd toolbox and they are as follows.

DH0:PFS\03
Mask 0x7ffffffe
MaxTransfer 0x1fe00
block size 512

DH1:PFS\03
Mask 0x7ffffffe
MaxTransfer 0xffffff
block size 512

DH2:PFS\03
Mask 0x7ffffffe
MaxTransfer 0xffffff
block size 512

DH3:PFS\03
Mask 0x7ffffffe
MaxTransfer 0xffffff
block size 512

been reading around and to say the least its rather confusing for a n00b lol
should the max transfer be the same on all drives ? or just the boot drive DH0: ?
blocksize of 512 ok on all drives? seems to b the default..

everything seems to be working just fine, but be nice to know its getting best speed it can.
and it seems to be on PFS\03 v19.2 i think.
any suggestions to improve here or is it all fine as is?

thanks muchly

[lesta_smsc]

In a nutshell. Set all drives to the correct max transfer value. This is needed due to read times being much faster on CF/SD card in comparison to mechanical drives.

[Jope]

This is needed to circumvent a change in the IDE command specification that older versions of scsi.device do not know about. It has to do with transferring of large blocks of data in one IDE command.

If you have an old scsi.device and have the incorrect max transfer size, you will get data corruption. It's a good idea to adjust it even with the OS3.1.4 scsi.device.

[thomas]

First of all MaxTransfer is not a rate, it is a chunk size. It has nothing to do with speed.

Mask and MaxTransfer are controller attributes, so they should be set to the same value on all partitions.

[supaduper]

Originally Posted by xubidoo

after swapping out my cheap chinese 16gb CF card for a 16gb Sandisk , i was checking the max transfer settings via hd toolbox and they are as follows.

DH0:PFS\03
Mask 0x7ffffffe
MaxTransfer 0x1fe00
block size 512

DH1:PFS\03
Mask 0x7ffffffe
MaxTransfer 0xffffff
block size 512

DH2:PFS\03
Mask 0x7ffffffe
MaxTransfer 0xffffff
block size 512

DH3:PFS\03
Mask 0x7ffffffe
MaxTransfer 0xffffff
block size 512

been reading around and to say the least its rather confusing for a n00b lol
should the max transfer be the same on all drives ? or just the boot drive DH0: ?
blocksize of 512 ok on all drives? seems to b the default..

everything seems to be working just fine, but be nice to know its getting best speed it can.
and it seems to be on PFS\03 v19.2 i think.
any suggestions to improve here or is it all fine as is?

thanks muchly

Don`t lose sleep over it as the Filesystem is pfs3-aio and it is latest version and it safely handles max transfer values, but by all means change the other partitions to 0x1fe00 if it will make you feel better

Never had one crash on this system in over 12 months so I leave mine as is

[lesta_smsc]

Awesome. I take it the CF you sent me has the latest FS

I hadn't known that it was for file chunks. I thought it was literally to correct speed lol

[supaduper]

Originally Posted by lesta_smsc

Awesome. I take it the CF you sent me has the latest FS

I hadn't known that it was for file chunks. I thought it was literally to correct speed lol

Yep

[lesta_smsc]

Originally Posted by supaduper

Yep

Hehe only the best

Working ace BTW and saved me a headache lol. Speaking of which... I'll PM you later lol.

[Thomas Richter]

Originally Posted by Jope

If you have an old scsi.device and have the incorrect max transfer size, you will get data corruption. It's a good idea to adjust it even with the OS3.1.4 scsi.device.

Why? Just tell me why... MaxTransfer is only required for broken drivers or broken hardware. If you have an indication that the Os 3.1.4 scsi.device *requires* maxtransfer to operate properly, I would be curious to know. In general: *Do not touch these values*. They can only make the I/O transfer slower, not faster.

[Jope]

Originally Posted by Thomas Richter

Why? Just tell me why... MaxTransfer is only required for broken drivers or broken hardware. If you have an indication that the Os 3.1.4 scsi.device *requires* maxtransfer to operate properly, I would be curious to know. In general: *Do not touch these values*. They can only make the I/O transfer slower, not faster.

When you swap the drive to a machine without 3.1.4, you will have a problem. I'm concerned with interoperability and always try to give as generic and harmless advice as I can.

If someone knows what they're doing, they are not asking questions anyway, and know where the maxtransfer will and will not be a problem.

I am aware of 3.1.4 having this issue fixed, but was too lazy to be more verbose when posting.

[MartinW]

From the PFS3 documentation on MaxTransfer:

This setting indicates how much data can be sent to the device in one go. Some drives cannot handle very large blocks of data. By specifying the maximum the device can handle here, problems are prevented.

There is more, but...

How do we know the maximum that a compact flash card can handle? I'm sure this info was probably hard enough to find back in the days of 90's spinning disks.

Or alternatively, is this documentation out of date and all this is no longer needed which is what people seem to be saying here?

[Jope]

Originally Posted by MartinW

From the PFS3 documentation on MaxTransfer:



There is more, but...

How do we know the maximum that a compact flash card can handle? I'm sure this info was probably hard enough to find back in the days of 90's spinning disks.

Or alternatively, is this documentation out of date and all this is no longer needed which is what people seem to be saying here?

You can run Thomas' maxtransfertest to verify that you are within the limits of your hardware/software combo.

[MartinW]

Ah cool, thanks.

So basically given then that the info about masks and interfaces is also in that documentation, coupled with being able to use that tool, it's going to be possible to know you've got decent values in there regardless of whether they are ignored or taken into account, like you say, good if you were to move the CF card around or install a different version of OS without re-partitioning.

[MartinW]

Sorry, one question - where is maxtransfertest? I don't see it on Aminet. Apologies if I'm being thick!

[Jope]

https://thomas-rapp.homepage.t-online.de/download.html maxtranstest.lha

[Daedalus]

Originally Posted by MartinW

How do we know the maximum that a compact flash card can handle? I'm sure this info was probably hard enough to find back in the days of 90's spinning disks.

Just to clarify, by "device", the documentation will generally be referring to the device driver (e.g. scsi.device), not the physical hardware. So you don't need to worry about CF cards etc., just what the driver can handle.

[MartinW]

Where's that 'slaps forehead' icon when you need it

Thanks for that

I have to say that after my reading earlier in the week and stumbling across this thread I finally feel like I have a proper grasp on the settings. Hopefully other people will feel the same. It's only taken me about 10 years.

[Thomas Richter]

Originally Posted by MartinW

How do we know the maximum that a compact flash card can handle?

You don't need to know. Really. An IDE device has to be able to read 255 blocks (yes, really 255) through one command. The *only* reason why you had to set a mask is because the 3.1 scsi.device had this limit wrong (256 instead of 255). MaxTransfer is *not* dependent on the hardware. As said, it *only* works around faulty device drivers. Same as Mask and BufMemType. A non-broken device driver can take any memory type and any buffer alignment.

[thomas]

Actually 256 is correct. There is a one byte length field and 0 means 256.

The problem is something else. After reading or writing 256 sectors scsi.device expects some registers have automatically changed which was true by the old ATA specs, but is no longer in the new specs. Toni Wilen found the details, there is a thread about it somewhere on this forum.

Edit: here is a quote from the ATA-2 specs:

6.2.4. Cylinder Low register

In CHS Mode, this register contains the low order bits of the starting cylinder address for any media access. In LBA Mode, this register contains Bits 15-8 of the LBA for any media access.

This register shall be updated to reflect the media address of the error when a media access command is unsuccessfully completed.

Implementor’s Note: Prior to the development of this standard, this register was updated at the end of every media access command to reflect the current media address.

[thomas]

Originally Posted by Jope

You can run Thomas' maxtransfertest to verify that you are within the limits of your hardware/software combo.

You can run it, but you must not rely on its result. The only info it can give you is "Yes" or "No", but not the actual value.