Weird result with code

[raesoo80]

Hello, I'm totally new to programming.
I have a issue with hard disk performance i/o with my windows 2003 servers
one of my vendor sent me the code below, they said it's testing write speed of hard disk but when I run this code on few of my windows 2003 servers, the actual file size are different.
about 60% of them, it creates file size with 55MB but on rest 40% of servers I have, it creates file size of 5 MB. weird thing is that one that generates 5MB text file, it takes me about 2 minutes in order to finish generating file. but when it generates 55MB file, it takes less than 10 seconds.

all of servers are running windows 2003 standard version on a RAID 1 confuguration. I checked if any of windows updates, windows services, or drivers are causing this issue but I can't find any so that I'm hoping if anyone can give me some advice for what's causing different result.

Here's the code

for (int i = 0; i < 100000 ; i++) { FILE *pFile = fopen( "text.txt" , "at"); 
fprintf( pFile, "1234567890feoiv jeoifjonfrjobejrgojbomerjgobogorgmborjbo\n" ); 
fclose(pFile); } 

FILE *pFile = fopen( "text.txt" , "at"); 
fprintf( pFile, "VERSION:1:TIME:%d\n" , timeGetTime() - dwPre ); 
fclose( pFile );

Thank you

[CommonTater]

First, who taught you to write code on 1 line like that?

for (int i = 0; i < 100000 ; i++) 
   { 
      FILE *pFile = fopen( "text.txt" , "at"); 
      fprintf( pFile, "1234567890feoiv jeoifjonfrjobejrgojbomerjgobogorgmborjbo\n" ); 
      fclose(pFile); 
   } 

   FILE *pFile = fopen( "text.txt" , "at"); 
   fprintf( pFile, "VERSION:1:TIME:%d\n" , timeGetTime() - dwPre ); 
   fclose( pFile );

First of all I'm surprised it compiles. My C documentation does not show an "at" mode for file io at all. That's not to say it doesn't exixt, but it's not part of standard C.

Secondly it's not much of a benchmark... there is no intial time marker, only one at the end. Then there's the matter that it's going to be entirely dependent on a huge number of variables such as disk buffering, file fragmentation, other processes running at the time and of course the always present variability in Windows time sharing.

Why does the time for this vary so much? Quite probably because the server showing you the painfully slow results is also the busiest of the bunch...

[raesoo80]

Hello there,
First of all I'm not the creator of this code and I have totally new to programming.
this code is given by one of my vendor and they told me to use this code for checking disk write speed because my server is designed to generate a log file and write any events on the log file.

problem is I have no idea if there's anything wrong with this code.
I only assume that this code will create text.txt file and writes text "1234567890feoiv jeoifjonfrjobejrgojbomerjgobogorgmborjbo" 100000 times, writes time it took and then close file. Am I right?

the purpose of testing is to check writing text speed of the server and as far as I understand this code is taking that action.

if you anyone can provide appropriate code for checking disk write speed or
fix any unnessasory code or add need code would be very much appreciated.

Thank you

[Salem]

The "t" is a microsoft extension.
fopen, _wfopen (CRT)

> about 60% of them, it creates file size with 55MB but on rest 40% of servers I have, it creates file size of 5 MB
The test file is never deleted, it just grows each time you run the test.
For sure, it will grow by about 5MB each time you run the test.

From a disk exercise point of view, all those open/close are a complete waste of time on things which have nothing to do with disk access.

Not all hard disks are equal.
Hard disks | Reviews | PC Pro

[Mario F.]

I only assume that this code will create text.txt file and writes text "1234567890feoiv jeoifjonfrjobejrgojbomerjgobogorgmborjbo" 100000 times, writes time it took and then close file. Am I right?

Nope. Both open and close stream operations are inside the loop. These will also be repeated one hundred thousand times.

the purpose of testing is to check writing text speed of the server and as far as I understand this code is taking that action.

Nope. It's also including opening and closing operations and it's not recording the moment the test has started.

if you anyone can provide appropriate code for checking disk write speed or fix any unnessasory code or add need code would be very much appreciated

See DISKSPEED - hard disk speed test. Not as simple as you would expect, is it?

[CommonTater]

Nope. Both open and close stream operations are inside the loop. These will also be repeated one hundred thousand times.

AKA... "How I thrashed my hard disk to death"... since the r/w head has to traverse to the directory then back to the file's lead sector each time.

[User Name:]

The "t" is a microsoft extension.
fopen, _wfopen (CRT)

No, it's not.

With the mode specifiers above the file is open as a text file. In order to open a file as a binary file, a "b" character has to be included in the mode string. This additional "b" character can either be appended at the end of the string (thus making the following compound modes: "rb", "wb", "ab", "r+b", "w+b", "a+b") or be inserted between the letter and the "+" sign for the mixed modes ("rb+", "wb+", "ab+").
Additional characters may follow the sequence, although they should have no effect. For example, "t" is sometimes appended to make explicit the file is a text file.
In the case of text files, depending on the environment where the application runs, some special character conversion may occur in input/output operations to adapt them to a system-specific text file format. In many environments, such as most UNIX-based systems, it makes no difference to open a file as a text file or a binary file; Both are treated exactly the same way, but differentiation is recommended for a better portability.
For the modes where both read and writing (or appending) are allowed (those which include a "+" sign), the stream should be flushed (fflush) or repositioned (fseek, fsetpos, rewind) between either a reading operation followed by a writing operation or a writing operation followed by a reading operation.

[Mario F.]

No, it's not.

Yes, it is. Read the text you quoted more carefully.

[Salem]

The cplusplus reference material is buggy to say the least.
Just look up scanf and see how much is missing.

http://www.open-std.org/jtc1/sc22/wg...69/n869.pdf.gz
Quote the actual standard.
Page 285 - there is no "t" mode.

Description
2 The fopen function opens the file whose name is the string pointed to by filename,
and associates a stream with it.
3 The argument mode points to a string. If the string is one of the following, the file is
open in the indicated mode. Otherwise, the behavior is undefined.214)
r
open text file for reading
w
truncate to zero length or create text file for writing
a
append; open or create text file for writing at end-of-file
rb
open binary file for reading
wb
truncate to zero length or create binary file for writing
ab
append; open or create binary file for writing at end-of-file
r+
open text file for update (reading and writing)
w+
truncate to zero length or create text file for update
a+
append; open or create text file for update, writing at end-of-file
r+b or rb+ open binary file for update (reading and writing)
w+b or wb+ truncate to zero length or create binary file for update
a+b or ab+ append; open or create binary file for update, writing at end-of-file