I am writing a (series of) program(s) in C that will have one computer send data through a router to another computer, have that computer write it to the hard drive (that doesn’t have a filesystem), read it and send it back again. My purpose behind this is to test the efficiency of Linux and Windows for a research paper. What I am trying to figure out now is how to write data to unformatted partitions. I am going to transmit everything in the form of packets which in C will translate into char*'s.
Thanks in advance
You could use “dd” to transfer the data from a ramdisk to the hard drive partition. Read the “dd” man page.
camper365 wrote:
> I am writing a (series of) program(s) in C that will have one computer
> send data through a router to another computer, have that computer write
> it to the hard drive (that doesn’t have a filesystem), read it and send
> it back again. My purpose behind this is to test the efficiency of
> Linux and Windows for a research paper. What I am trying to figure out
> now is how to write data to unformatted partitions. I am going to
> transmit everything in the form of packets which in C will translate
> into char*'s.
As everything is a file, so is the partitions’s device file. Write to
that. ( Good luck on that “research”. )
Wouldn’t a simple redirection work in that case as well?
/dev/foo > /dev/hdX
Or would that create a problem?
There’s no command on that line, you have to do something like
cat /dev/ramdisk > /dev/sdaX
You can’t avoid running a command of some sort, dd or cat or whatever.
I like the idea of writing to the device’s file directly. However, is there an equivalent to that in Windows?
Windows uses the bios call to the hdd which specifies the read and write in terms of track and sectors.
camper365 wrote:
> I like the idea of writing to the device’s file directly. However, is
> there an equivalent to that in Windows?
i guess you are trying to remove all possible variables (like the
speed advantages of one file system over another) but wonder:
can Windows write to a disk with no file system (as your root question
suggests)??
and,
however you answer that question, will not your research paper
simply measure (not the efficiency of Linux vs Windows) but instead
the efficiency of Linux’s dd (or writing direct to the device) vs
whatever can be used in Windows to avoid the paper from mostly
measuring the efficiency of NTFS vs Ext4??
hmmmm…wait! what is it your intention? to “test the efficiency” of
Linux vs Windows to
- push bit through a router/network
- read/write to a no file system hard disk
- process/run your C programs
how are you writing the programs/code? wait! my question is: how do
you make sure your code does not give one system an advantage over the
other which is great enough to completely mask the ‘efficiency’ of
pushing bit or reading/writing, etc??
careful how you frame your ‘research’…
–
DenverD (Linux Counter 282315)
CAVEAT: http://is.gd/bpoMD
posted via NNTP w/TBird 2.0.0.23 | KDE 3.5.7 | openSUSE 10.3
2.6.22.19-0.4-default SMP i686
AMD Athlon 1 GB RAM | GeForce FX 5500 | ASRock K8Upgrade-760GX |
CMedia 9761 AC’97 Audio
Traditional Windows apps use the apl which in turn calls bios routines to actually do the read or write. Circumventing this would be something like writing a routine to directly read/write from a network direct to disk but run under Windows.
Moving to Linux, the dd command does the same, or you could have a routine to also directly read/write to disk.
As far as what it would tell you is virtually useless and here’s why. Part of the harddisk controller contained on the hdd itself is the geometry calc for the drive. This will be a fixed ratio regardless of what system initiates the cycles. What you will really be measuring the difference between the code you use to R/W under Windows vs Linux. Given the same architecture ie: Intel i686_x64 and running the code specific to each OS there should be absolutely 0 variance.
So the question becomes how tight can you write the disk code, how tight can you write the network code, and how much preprocessing is needed between the two?
From what everyone is saying, I assume that I would be better off using the default filesystem for each system instead of using a blank filesystem. Am I correct in assuming this is what everyone is saying?
That’s my opinion. Disk i/o consists of 16 controller addresses each one takes or provides a value based upon the current operation. In modern OS’s the filesystem consists of a structure planned out for handling the layout of the drive. To blindly read and write to the drive without a filesystem needs some checks and balances to be reliable. And guess what! as you make these checks and balances, you are just creating a new filesystem. So you start out to not have a filesystem and will at some point end up with the very filesystem you wanted to avoid.
camper365 wrote:
> Am I correct in assuming this is what everyone is saying?
well, what kind of efficiency are you actually trying to test of Linux
vs Windows??
–
DenverD (Linux Counter 282315)
CAVEAT: http://is.gd/bpoMD
posted via NNTP w/TBird 2.0.0.23 | KDE 3.5.7 | openSUSE 10.3
2.6.22.19-0.4-default SMP i686
AMD Athlon 1 GB RAM | GeForce FX 5500 | ASRock K8Upgrade-760GX |
CMedia 9761 AC’97 Audio
camper365 said “I am writing a (series of) program(s) in C…”
Do we know that the Linux C compiler will produce executable code that is as compact or “efficient” as the Windows C compiler? I would want to compare the number of processor cycles used for each version. Or am I missing the whole point?
Well IMHO C/C++ in either OS is highly in efficient for low level i/o to devices where speed and compactness is a factor. even the lowest levels of the kernel use assembly language for direct i/o.
While you can simulate register direct and port direct i/o in C there is nothing faster than native assembly.
Try it!
mov si:dx,[xbx]
mov di:cx,[bp+4]
int 25h
the above taken from standard bios call to transfer sectors specified in the quad word pointed to by [xbx] to the memory specified 4 bytes into the stack relative to the base. The simple int 25 does the whole transfer. Thusly, 8 bytes of code can copy up to 4GB directly in a single call. The same thing in ‘C’ would take about 23 bytes of code to maneuver values from variable storage to the registers after first saving the register state. You must also keep in mind that ‘C/C++’ may optimize for the extended registers available but low level routines for hardware in the bios seldom uses the extended set
since it doesn’t know what OS is going to be calling it.
On 2010-05-31 07:01 GMT DenverD wrote:
> camper365 wrote:
> > I like the idea of writing to the device’s file directly. However,
> > is there an equivalent to that in Windows?
>
> i guess you are trying to remove all possible variables (like the
> speed advantages of one file system over another) but wonder:
>
> can Windows write to a disk with no file system (as your root question
> suggests)??
Of course 
You can request the operation from the bios, or use some higher level
function from the api. Or from dos. Int 20 or 21, I think.
http://en.wikipedia.org/wiki/Int_21
http://en.wikipedia.org/wiki/Ralf_Brown's_Interrupt_List
My list of windows functions is from 3.11, so my info is obsolete; but
I’m sure there are functions to do such a thing in current windows
- although the kernel should not allow a user space program from writing
directly to a device, somebody has to write drivers… so it is
possible. Somehow.
And in Linux, of course. Dd does it, so you only have to look at the
source code to learn how to do it. The term “raw” devices comes to my
fuzzy memory. But I’m not a linux programmer,
As for the test the OP wants to do… speed will depend on which layer
you ask to do the operation, I guess. How many checks does the
operating system does on the call. How big is the cache. Etc.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Elessar))
On 2010-07-05 23:14 GMT Carlos E. R. wrote:
> On 2010-05-31 07:01 GMT DenverD wrote:
> > can Windows write to a disk with no file system (as your root
> > question suggests)??
>
> Of course
Oops! Sorry, I missed the old date in the post. Ignore this. O:-)
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Elessar))