CopyHugeBlockSizeOther

[Hacker]

From the wincmd.ini help:

CopyHugeBlockSizeOther= Sets the block size when copying very large files, between different disks. Minimum: 256 kB.

Recommended values (try others yourself):
CopyBlockSize=1024
CopyHugeBlockSize=10240
CopyBlockSizeOther=128
CopyHugeBlockSizeOther=32

Apart from this inconsistency, the information is incorrect. The minimum block size is 128KB, according to Filemon from Sysinternals. If I specify 64KB, the value stays at 64KB but in fact blocks of 128KB are read/written.

Christian?

TIA
Roman

[SanskritFritz]

AFAIK you are using FAT, right? What is the minimum blocksize in your system? Couldnt it be the reason?

[Hacker]

Yep, I am using FAT... how do I find out what the minimum blocksize is? And does this affect the minimum size of the data being read? Meaning if I want to read 10 characters the OS will read BlockSize anyways?

TIA
Roman

[SanskritFritz]

I dont know how to get the size of the cache in Win98, but, yes, the cache is always filled, this is why it is a cache. The system expects you to read further in the file, and in this case it can provide the data much faster.

[SanskritFritz]

Umm sorry, first i mixed up the file system blocksize with cache
But what i said about the cache is still true. I hope

[Clo]

2Hacker
  Hi Roman,
• In the RamBooster Help, the Author recommended a value = RAM-amount /4. I mean in the system.ini file under:

Code: Select all

[vcache]
MinFileCache=2048
MaxFileCache=80000

Unit= KB, while I've 320 MB of SD-RAM installed...
• I don't know whether it's the same problem, just an idea (maybe wrong...)
• That works under Win 95B / 98 SE, bringing a good general improvement...
  KR
Claude
Clo

[Hacker]

I don't think it's about the same thing.
The question raised by SanskritFritz is if there is a minimum amount of data (that is larger than the size of the data being requested) that has to be read from a disk when wanting to read eg 16 bytes from a file.

Roman

[Maxwish]

I think it depends on the cluster size you have formatted your drive with:

Cluster = The smallest allocation unit in the FAT, FAT32, and NTFS file systems. One cluster consists of a fixed number of disk sectors. Each file is allocated at least one cluster, thus many small files, lead to wasted HD space. Cluster size vary from 512 b to 64 k.

So even if a file is only 16 bytes, maybe the PC needs to read the complete cluster from the HD, as that is how the data is stored on it ? Just guessing here...

[Hacker]

The guess is ok, but according to Filemon, Explorer reads in 64KB blocks, TC in 128KB blocks. I wanted to set TC to 64KB, it didn't work. So I guess it's TC's "fault".

Roman

[IGL]

Please notice that that some Hard Disks use "block read" methos which is configured in BIOS setup. And it usually results in reading block of 64KB at once - even if you request just one byte. Another thing is the cluster size - but explaine previously. Then we also have system cache. But does this method of file reading uses windows cache?
Maybe Christian could help us to find out what kind of function is used by TC and how big block are being read.
Hacker, did you try to perform tests on floppy drive? It has a 512bytes sector.
Anyway, maybe the value of minimal block size may differ on various systems?
But is this actually a problem? Or you are working to make TC perfect (which is a good thing!).

[Hacker]

Well, to describe how I came to this situation - I tried to copy a large file (~600MB) from C: to D: using TC and using Explorer to see which one is faster. Explorer won by about 25% (TC - ~40s, Explorer - ~30s). So I wanted to "tweak" TC's options to acheive the speed of Explorer and I wanted to see what "blocksize" Explorer uses. Using Filemon I found out it's 64KB, and when trying to set that size in TC I still got minimally 128KB.
I don't think that this has anything to do with:
- the disk cache
- the file cache
- the windows cache
- the cluster size
because AFAI understand Filemon only detects application requests, ie how much data the application wants to read, not low-level info like how much info is really transferred from disk to OS.

I did not try to perform any tests on a floppy - I don't see any sense in that.

To me it simply seems that TC does a read(file, 128KB) even if I specify I'd like it to do read(file, 64KB).

Thanks
Roman

[IGL]

OK, I haven't been working with filemon much, so I guess you are right and testing on floppy is sensless.
I guess we need the help of Author to explain what is inside the program.

[JackFoo]

Roman,
Did you try setting compatibility mode on? Oh, right, you've got w9x, it won't work. Anyway, I think the difference stems from that option, here on (wXP) I got ~40% speedup on disk to disk copy with compatibility mode on and even more on network copy.

Hopefuly Christian will have a look at it and give some insight.

Cheers.

[Hacker]

here on (wXP) I got ~40% speedup on disk to disk copy with compatibility mode on and even more on network copy.

I know, but as I have W9x which doesn't support CopyFileEx (and thus not even Explorer can use it to copy files) the difference in speed must be caused by something else.

Thanks nevertheless
Roman

[JackFoo]

Well, yes, but what I meant is that there is something fishy going on in TC, since CopyFileEx (from what I know) shouldn't provide any boost in speed and somehow it does when using it in TC, so it follows there is some other difference beside the copy mode:

Code: Select all

if(g_bcompmode)
{
CopyFileEx(...)

[block 1]
}
else
{
CopyFile(...)

[block 2]
}

[block 1 vs 2] has to make a difference. Unless I'm mistaken about CopyFileEx (which I don't think I am), I've searched the net and found no apparent connection between copy mode and speed.

Cheers.