Marc de Vries <marcdevries@geen.spam.zonnet.nl> wrote:

You mean Rod^Hn was right for once? Is the world coming to an end?

"Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message
news:T7jJc.95077$OB3.11984@bgtnsc05-news.ops.worldnet.att.net...
100 MB, Yes.

The program has 1 seek instruction.

Officialy it's called 'User Space'. But let's just call it 'Program Space'.
Memory allocated by the program.
It does a seek into the file at a random location.

Because it seeks more.

Loop:

Seek somewhere in file.

Write 4 KB

Write 4 KB

Write 4 KB

etc up to 1 MB / 4 KB.

go back to loop.

So after it has written 1 MB to the file... (in pieces of 4KB)... it goes
back to loop and does a seek again.

That's why it does more seeks than the read test.... at least for big files


I thought 1 MB cache was enough to reach maximum harddisk speed... or 'good
enough' speed...

But 1 MByte/Sec is not really satisfactory for a 100 Megabit Network.

So I would prefer higher write speeds of say 4 MByte/Sec to 8 MByte/Sec

A bigger cache and less seeking might be required to achieve that... I am
not sure about though

Bye,
Skybuck.

"Nicholas Sherlock" <n_sherlock@hotmail.com> wrote in message
news:cd4eav$6qs$1@lust.ihug.co.nz...
So what's your point ?

During testing I have no other applications open to minimize any other disk
activity.

On Thu, 15 Jul 2004 08:02:56 -0500, chrisv <chrisv@nospam.invalid>
wrote:

When I wrote this I realized that myself too. But I decide not to
point it out, so that the people here wouldn't start worrying.

You have ruined all that....

Now you will be the cause of a huge thread that will go on for weeks
about the end of the world :-)

"Skybuck Flying" <nospam@hotmail.com> wrote in message
news:cd625r$cqb$1@news2.tilbu1.nb.home.nl...

www.storagereview.com

"Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message
news:i%iJc.95050$OB3.40182@bgtnsc05-news.ops.worldnet.att.net...
I don't understand yet how to calculate the data transfer rate

I will read some documents about that and try to understand... then I will
get back on this

Sounds reasonable.

In concept 3 yes, they should be, but might not be because of file
fragmentation.

1 File.

Well I might come back on that

Anyway here are two new concepts... actually the real concept behind concept
3.

Concept 4:

Seek

Skip 4 KByte block
Skip 4 KByte block
Write 4 KByte block
Skip 4 KByte block
Write 4 KByte block
Skip 4 KByte block
Skip 4 KByte block
Write 4 KByte block
etc

That's what I would like to do with a file...

I only want to update some parts of a file... not the complete file... etc.

The number of seeks I can use is limited so I have to try and do as many
writes as possible per seek.

Get it now ?

Concept 5:

Skip 4 KByte block
Skip 4 KByte block
Read 4 KByte block
Skip 4 KByte block
Read 4 KByte block
Skip 4 KByte block
Skip 4 KByte block
Read 4 KByte block
etc

I don't think harddisks have a 'skip x number of bytes' command.

Here is what needs to be done as efficiently as possible:

Transferring a file of 100 MByte from Computer A to Computer B.

The file is split into packets which are send across a network.

The packets are 512 bytes.

Sometimes some packets might go lost.

This creates gaps in the file.

These gaps have to be filled in later

Seeking to all these gaps could be very slow.

So I see some possible solutions.

Problem:

Packet 1, 5, 9, 13 are re-transmitted and have to be stored to file.

Possibly slow solution 1:

Seek Packet 1, Write Packet 1
Seek Packet 5, Write Packet 5
Seek Packet 9, Write Packet 9
Seek Packet 13, Write Packet 13.

Possibly faster solution 2:

Seek Packet 1,
Read Packet 1,2,3,4,5,6,7,8,9,10,11,12,13 into memory.

( Packet 1,5,9,13 are empty )

Overwrite packet 1,5,9,13 with new data into memory.

Seek Packet 1
Write Packet 1,2,3,4,5,6,7,8,9,10,11,12,13 from memory to harddisk.

Possibly bad solution 3:

( because of harddisk design, switching from read to write to read to write
is slow )

Seek Packet 1
Write Packet 1
Skip or Read Packet 2
Skip or Read Packet 3,
Skip or Read Packet 4,
Write Packet 5
Skip or Read Packet 6,
Skip or Read Packet 7,
Skip or Read Packet 8,
Write Packet 9
Skip or Read Packet 10,
Skip or Read Packet 11,
Skip or Read Packet 12,
Write Packet 13.

If the harddisk and software had a skip command this solution might be very
fast.

But because it doesn't have a skip command... I tried a read command
instead.

But funny enough that gives very bad performance.

So currently I think solution 2 is best at the moment.

At this point I am out of ideas

Bye,
Skybuck.

Try a CD-R



"Skybuck Flying" <nospam@hotmail.com> wrote in message
news:cd6876$pbb$1@news3.tilbu1.nb.home.nl...
| Here is what needs to be done as efficiently as possible:
|
| Transferring a file of 100 MByte from Computer A to
Computer B.
|
| The file is split into packets which are send across a
network.
|
| The packets are 512 bytes.
|
| Sometimes some packets might go lost.
|
| This creates gaps in the file.
|
| These gaps have to be filled in later
|
| Seeking to all these gaps could be very slow.
|
| So I see some possible solutions.
|
| Problem:
|
| Packet 1, 5, 9, 13 are re-transmitted and have to be
stored to file.
|
| Possibly slow solution 1:
|
| Seek Packet 1, Write Packet 1
| Seek Packet 5, Write Packet 5
| Seek Packet 9, Write Packet 9
| Seek Packet 13, Write Packet 13.
|
| Possibly faster solution 2:
|
| Seek Packet 1,
| Read Packet 1,2,3,4,5,6,7,8,9,10,11,12,13 into memory.
|
| ( Packet 1,5,9,13 are empty )
|
| Overwrite packet 1,5,9,13 with new data into memory.
|
| Seek Packet 1
| Write Packet 1,2,3,4,5,6,7,8,9,10,11,12,13 from memory to
harddisk.
|
| Possibly bad solution 3:
|
| ( because of harddisk design, switching from read to write
to read to write
| is slow )
|
| Seek Packet 1
| Write Packet 1
| Skip or Read Packet 2
| Skip or Read Packet 3,
| Skip or Read Packet 4,
| Write Packet 5
| Skip or Read Packet 6,
| Skip or Read Packet 7,
| Skip or Read Packet 8,
| Write Packet 9
| Skip or Read Packet 10,
| Skip or Read Packet 11,
| Skip or Read Packet 12,
| Write Packet 13.
|
| If the harddisk and software had a skip command this
solution might be very
| fast.
|
| But because it doesn't have a skip command... I tried a
read command
| instead.
|
| But funny enough that gives very bad performance.
|
| So currently I think solution 2 is best at the moment.
|
| At this point I am out of ideas
|
| Bye,
| Skybuck.
|
|

Anyway...

With my 'Possibly faster solution 2' mention somewhere else in this thread.

The big question is:

How many reads/writes per seek ?

A secondary question would be how big the buffer size (block size to
transfer in one read or write ).

The answer to this secondary question might be simply 512 bytes... or 4 KB
which should give best results because of cpu page size, ram page size and
possible harddisk page size etc. So that answer is fixed.

The remaining question would be:

How many reads of 4 KB per seek ?

How many seeks per second are ok ? (possible only 1 )

The desired speed is 4 MByte/Sec

The desired speed could be 8 Mbyte/Sec.

4 MByte/Sec divided by 4 KB buffer = 1000 reads.

That's a lot !

The second desired speed is 2000 reads that s twice as much

Seeing these specification talk about 1 to 2 milliseconds for a command,
read, switch whatever... it doesn't take a lot of imagination to see how
exceeing 1 second is easily achieved and ofcourse not desired.

Suppose each read command take 1 millisecond. 2000x1= 2 seconds... <- oops.

Or 2 Seeks = 30 Milliseconds + 1000 reads <- 1030 milliseconds <- oops.

Etc...



So the big question is

1. How to achieve MByte/Sec writing... since that seems most difficult.

Timing is the key here...

The bad news is that every harddisk has different timing.

One could assume worst case timing for all factors etc.

Only thing left to do is to come up with a formula to find out how many
reads, how many seeks and how big the transfer buffer should be...

the transfer buffer might be fixed to 4 KB so that might not be variable
since 4 KB achieves best performance... so it can't do better than that...

So that leaves... seeks vs reads....

StorageReview doesn't seem to help with the formula's... (or least I didn't
see any page about it ) so I ll dive back into my IBM/Hitachi Deskstar 14
GXP document and try to make sense of it

Skybuck.

On the other hand...

There are only 3 variables which I can control with my
software/windows/delphi/TFileStream

1. TFileStream.Seek <- seek command

2. TFileStream.Read,
TFileStream.Write <- read command or write command

3. The Read/Write Buffer Size

But then there are ofcourse more factors involved:

4. Offset of seek is also a factor.
5. Switching between read and write is a factor.

6. Switching between seek, read and write might be a factor.
7. Even pausing for a while might be a factor.

And then there are ofcourse external factors... OS, Other Hardware etc.

So at least 5 factors amount into 6 requirements

1. The program should do sequential seeks or random seeks. Randomize Offset,
Or increment Offset. <- Sequential seeks is pretty much bullshit. But not
quite... since you could seek ahead only.
2. The program should do, read only, write only, or mixed, possibly with a
read:write ratio or randomizer.
3. The program should do seeks per second.
4. The program should do writes per second. Writes per seek should therefore
be calculated.
5. The program should do reads per second. Reads per seek should therefore
be calculated.
6. The program should do buffer size variable.

5 Causes 2 to be partially done... except for the mixed and randomizer.
Read/Write Randomizer is less interesting. Mixed could be interesting but is
also automatically handled.
Ratio is also handled by 2.

So all this stuff would give a single result

Speed Per Second

( Data Transfer Speed From/To Harddisk in Bytes/Sec )

So instead of trying to understand a document about how a single harddisk
works, it's charactistics, it's timing factors and terms and how it is
related to performance and unapplyable formula's for application software
because of missing information like current cylinder number and track and
sector number, a test program could be made to find the sweet spot in
practice

To top things off some artificial intelligence mechanisme should try out all
kinds of settings and find the sweet spot hehehehe.

Bye,
Skybuck.

Thanks for proving my point that logically and physically there are two heads,
not one. That the heads can read and write at the same time and read after write
would be possible *IF* there were to be seperate Read and Write channels,
(which there aren't).
Ron Rough made the impression that is was impossible because there is only
one head. That point is false. It's because there is only one R/W channel.

"Marc de Vries" <marcdevries@geen.spam.zonnet.nl> wrote in message news:djbcf05l9pi8mn5jco4rhngrpoegjjeh19@4ax.com
Did you consider that that may have confused *you* into thinking that
I am confused? Of course not!

And obviously it is not the "head" that reads and writes but the read
and write elements.
And if you want to be picky (which obviously you are) then call it a
'slider', not a "head".

Yes, that part is indeed sloppy and can confuse what follows later.

Which are later referred to as read and write 'heads'. Thank you.

Just as logical as a (one) slider has read and write heads.

That is what normal people will understand a read and a write element to be.
Logically they are 2 seperate heads rolled into one head element, the 'slider'.

No it doesn't. It started earlier.

Because that is what normal people would call a read element.

Right. Because it started off wrong there.
Which is understandable when most people will call a slider a 'head'.

The confusion starts when the technical terms and layman terms are used
intertwixed and sliders and elements both get simplified into "heads".

No, there is only one 'slider' with the read and write 'head' on it.

Or used "head" when he should have used 'slider'.

The slider does not read or write, the head(element)s do.

One slider with 2 head(element)s.

Wow, you can read? But can you understand?
So yes, why in the first place do you you think I pointed to that page?
To embarresh myself? Get a clue.

"Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message news:hjhJc.94738$OB3.83285@bgtnsc05-news.ops.worldnet.att.net
Yes, really. How much depends per cylinder. Not that it matters.

You need to ask? Not that it matters.

Nope. Not that it matters.

Indeed, as it's automatically done by the Servo system.

"Skybuck Flying" <nospam@hotmail.com> wrote in message news:cd625r$cqb$1@news2.tilbu1.nb.home.nl
But it's not.
In order to write to the correct sector the drive has to know
if it is the right sector, therefor needs to read the header.
If it can't, writes would go one sector per rev.
Obviously not.

And this is how it used to be when Sector-IDs were still in use
and obviously things improve with time, not worsen, so if it could
do it then it certainly can do it now.

[snip]

"Skybuck Flying" <nospam@hotmail.com> wrote in message
news:cd5uig$d9f$1@news2.tilbu1.nb.home.nl...
That's an electronic headswitch or an adjacent cylinder seek.

You need to describe in more detail your program and settings. Why do you
assume that your program statements have any first order relation to what's
happening at the physical disk I/O level?

"Skybuck Flying" <nospam@hotmail.com> wrote in message
news:cd61gd$7vq$1@news3.tilbu1.nb.home.nl...

"Skybuck Flying" <nospam@hotmail.com> wrote in message
news:cd61in$5j9$1@news2.tilbu1.nb.home.nl...
There's all sorts of possible blocking and other issues related to OS
scheduling that could be at work even in an idle system.

"Skybuck Flying" <nospam@hotmail.com> wrote in message
news:cd625r$cqb$1@news2.tilbu1.nb.home.nl...
Let's assume that your programatic 4K block has a direct relation to the
actual disk I/O size(it probably does NOT.) Now assume that the disk spins
at 7200 RPM or 120 revs per second. So the throughput of one 4K block per
rev is 120 x 4,000 = bytes per second = 480,000. That's the max speed as
any seeking will slow things down more.

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message
news:2lnsisFet5f6U2@uni-berlin.de...
That's false the magnetics and physical proximity precludes both being
active simultaneously.

Go back under the bridge where you belong.

"Folkert Rienstra" <see_reply-to@myweb.nl> wrote in message
news:2lnsitFet5f6U3@uni-berlin.de...

On Thu, 15 Jul 2004 18:58:24 +0200, "Folkert Rienstra"
<see_reply-to@myweb.nl> wrote:
<snip>
You embarrass yourself here every day.

You can attempt to disguise the fact that you were wrong (and that
that page proofed it), by calling the head a slider and the elements
heads but as you can see in the replies here, nobody is fooled by
that.

But please go on embarrassing yourself. It's quite funny.

Marc