How to: exact amount of bytes of 1 read/write full cycle?

[crysis]

Hi all,
yes, how can I find what is the exact amount of bytes sent by my HD controller to external bus, after 1 full read and/or write head cycle?

If I well understood, always 1 head per time reads or writes on 1 platter, at the speed of the Zone frequency.
But hard drives always read/write a group of bytes/sectors/tracks per cycle, not just 512 bytes.
So, if I know the amount of bytes read/write in 1 full cycle, I can instruct a software to read/write only this exact number of bytes per time, optimizing at best the HD performances, right?

I guess "fzabkar" posted something about that:

AFAIK, the TPI (Tracks Per Inch) is a constant value for any particular head.

and from http://www.pcguide.com/ref/hdd/geom/tracksInterleaving-c.html :

A common operation when working with a hard disk is reading or writing a number of sectors of information in sequence

thanks

[Vulcan]

But hard drives always read/write a group of bytes/sectors/tracks per cycle, not just 512 bytes.

What do you mean by "cycle"? Do you mean a revolution of the disk, or something else?

So, if I know the amount of bytes read/write in 1 full cycle, I can instruct a software to read/write only this exact number of bytes per time, optimizing at best the HD performances, right?

Are you planning to write an application, or a new filesystem, or a new OS?

Why do you believe that the answer to your question is one number?

[crysis]

Hi all,
well, Im a programmer and I would like like to optimize my codes, also I want to see if I can optimize some programs, e.g. FastCopy, and also Im curious

As "cycle" I mean 1 complete read or write cycle, e.g. one complete call to INT13 (or 25 or 26) + RAM buffer filling.

I believe this amount of bytes is one number, because it must depend first of all on the read/write head capacity, because the head reads/writes always the same quantity of bytes, right?
Also I read that HD optimizes operations reading a group of sectors on the way, and filling the internal buffer, the pool from which come the data to the external software.

So if I instruct to read/write the exact number of bytes in the buffer/head-capacity, I dont waste cycles in reading/writing redundant data, right?

In the case this number is not an exact number, what is the minimum? any approximate range?

Where can I find this information for my HD? any smart diagnostic utility?

Thanks

[Vulcan]

I believe this amount of bytes is one number, because it must depend first of all on the read/write head capacity, because the head reads/writes always the same quantity of bytes, right?

The short answer is - no.

[crysis]

mmh.. I know that the read head is different from the write one, I know that on tracks far from the center the angle inclination of heads is not constant, and I know that data read/write is not only the simple user bytes.. but I cant see how the head reads/writes different quantity of data in 1 "frequency cycle".. the capacity of the heads is so dramatically different? depending on what? can you suggest me a range? any chance for the long answer? thanks

[Vulcan]

any chance for the long answer?

I dislike this type of hypothetical questioning, especially where the questions are poorly defined. So if you want more information after this reply from me, you'll need to wait for other forum members to decide whether or not someone else will continue answering your questions. There are many details which could be described, but IMHO your questions are too ambiguous / confused and assuming too many incorrect details. I don't feel it is worth my time in replying further, as there is no clear end to this set of questions from you...

I cant see how the head reads/writes different quantity of data in 1 "frequency cycle".

And in your previous post, you have created a new meaning to the word "cycle" as being an Int 13h/25h/26h command to BIOS/DOS. Therefore I will try to make this short reply as clear as I can do: Due to the (adaptive) read & write caching performed by the disk drive firmware, you cannot control exactly what reading/writing is done by the disk drive heads, in response to normal commands sent via the interface, as you described.

Even when such caching is programatically disabled (e.g. via a Set Features command), I have experience where at least one well-known manufacturer did not actually stop all caching.

That's all from me on this topic

[guru]

lookup ATA8 Streaming command. That's me out of this topic also...

[crysis]

hey dear Vulcan, I dont know who you are, but in the case you dont know the answer just dont need to answer, I believe I explained enough well what are exactly my purposes: optimize I/O software.
In the other case someone in this forum dont like dummies, just the admin please state it clearly at the Register page.
Thanks for the attention.

[Vulcan]

Perhaps I can help you to understand why you are not successful with your questions, if I give one more reply... Even if you choose to ignore what I say below, it might help other readers to have more realistic expectations.

I believe I explained enough well what are exactly my purposes: optimize I/O software.

Yes, you explained (eventually - but not in your first thread) why you were asking questions. However your questions assume too much e.g. you include read & write in the same question, even though they have different answers; you include a mention of TPI from your previous thread, when that has no direct link to the answers for your new questions etc. Too much background info would need to be explained to you, before your questions are sensible to answer. Otherwise I have to write a book to explain how many variables which you haven't yet mentioned, could change any answer! IMHO it isn't reasonable for you to expect that amount of assistance for free.

Look at the top right of your screen - this forum is for: "Data recovery and HDD repair discussions". Optimising I/O software is neither "data recovery" nor "HDD repair". As well as being off-topic for this forum, performance optimisation is a huge subject (I have many years experience in this area, and I still know only a small amount) and it is not a subject that can be fully explained via a free forum IMHO - especially when the questions are hypothetical (i.e. no test case).

In the other case someone in this forum dont like dummies, just the admin please state it clearly at the Register page.

Now you can see why it is better for you to spend some time looking at a forum first, before asking questions - to see if you are asking a suitable forum for your questions.

You might also find this link to be helpful, about how to ask "good quality" questions:
http://linuxsilo.net/docs/smart-questions_en.html
Notice especially the parts about choosing the right web forum (not going off-topic), and the reactions from people to "open-ended time sinks".

I hope you find a suitable forum to help you.

[Vulcan]

P.S. I know this isn't answering your specific question (for the reasons I've already explained), but perhaps this will help you a little: You can answer your own question of "which I/O size gives highest performance", by using a benchmark program which offers a variety of I/O sizes, on your own system - try test different I/O sizes and look for highest throughput. Of course you need to simulate your application behaviour, target OS configuration & system hardware etc. as closely as possible when using the benchmark.

Note that the results will vary according to disk make / family / interface (due to different firmware behaviour & cache size), I/O pattern (sequential or more random), number of threads doing I/O etc. etc.. That is why there is not just one number, to give you the answer you wanted - but at least you can answer your own question of what I/O size to use for your program, with this technique.

[guru]

As an example :O)

HD Tune Pro: WDC WD5001AALS-00L3B File Benchmark

Drive E:

File Size: 64 MB

Block size Read speed
0.5 KB 2830 KB/s
1 KB 5540 KB/s
2 KB 10456 KB/s
4 KB 17874 KB/s
8 KB 35154 KB/s
16 KB 53983 KB/s
32 KB 69579 KB/s
64 KB 81769 KB/s
128 KB 89444 KB/s
256 KB 89529 KB/s
512 KB 95159 KB/s
1024 KB 92953 KB/s
2048 KB 89519 KB/s
4096 KB 89284 KB/s
8192 KB 90795 KB/s

[Vulcan]

Exactly - nice one guru

Of course that doesn't necessarily mean that the OP's own testing will show 512kB I/Os as optimal, in his specific test case, but we'd expect a "similar looking" variation with I/O size, if he's doing sequential, single-threaded reads, as in those figures you got.

Thanks again for the example!

[guru]

I was thinking.

He could carve MINLBA>MAXLBA into "n" number of chunks that span the disk drive from MINLBA > MAXLBA and test the read speed using a varied block size and a large data file for optimum KB/s. Then he could adjust block size for each carved zone depending on his results.