Topic: M3 Raw (Will this still be in a archive format)

reason i ask is, from my experience DVD readers (Especially Writers) in general don't like reading extremely small files, I.E. 4Kb Files, not to mention the strain it puts on the drive aswell,

or will they be in some kind of BIN (Image) file,

Re: M3 Raw (Will this still be in a archive format)

There was indeed a problem with DVD writes being used as reader would wear quite fast due to the heavier read/write head as opposed to the more simple read-only head around the dawn of the new millenium.
Since then, I have only been using RW ODD drives for my tasks (why even buy a read-only one when writing capability does not cost more plus writers usually tend to read better, too).
I could not observe any malfunction that could in any way be related to heavy read duties.
Dust is a much bigger thread, moreso if you smoke in the same room.
Cleaning the lenses usually takes care of that, though.

However, it is true that if files are not being read in the linear order they are being found on the disc, drives will make loud noises during seek operation and the access time gets really bad.
The idea would be to either arrange the files on the disc in such an order that they can be read mostly linearly during installation or to even shift from an ODD to, say, a USB stick.
Flash media does not mind where random access happens, (read) access times do not depend on it.
Most system can actually be booted from a USB stick, plus you wouldn't even need to verify the ODD medium for write/read errors after burning.

Anyway, even if there was some big .BIN file, if data access inside the file was still not linear, you'd still encounter the problem of lens head seeking through the sectors.
It does not matter whether it's on a file system basis or in-file, if the sectors are not arranged consequitively, the problems persists.

Re: M3 Raw (Will this still be in a archive format)

well you got me thinking on this one, as what you said contradicted my albeit old knowledge i had with the way cdrom and dvd drives access files, and the way files are written to disk,

so i decided to update my knowledge and for the last 4 hours i've been doing some benchmarks, and a lot of reading, although the information from 10 years ago hasn't changed that much even though technology has,
i think it's because the fundamental technology in media drives hasn't really changed and is still based on the same principle's it always has been, a bit like a combustion engine i suppose,

any way, tests,
i extracted all the graphics drivers, A,B,C
900MB worth of data, i then set my self 3 tests in mind
1 burn files to disc as is
2 burn files to disc using optimize files first
3 create ISO (Optimize) and burn the ISO to disc


using nero drivespeed 4 i got to work

test 1 results

[14:20:26]  Drive: TSSTcorpDVD-ROM SH-D162D SB00
[14:20:26]  Disc: DVD+RW, 4.28 GB, RICOHJPN W11
[14:21:16]  Starting transfer rate test
[14:30:27]  Speed:4-8 X CAV (6.36 X average)
[14:30:27]  Elapsed Time:  9:11
[14:30:27]  Starting access times test
[14:30:37]  Random Access: 94 ms
[14:30:48]  1/3 Access: 108 ms
[14:31:05]  Full Access: 174 ms
[14:31:05]  Elapsed Time:  0:38
[14:31:05]  Starting burst rate test
[14:31:07]  Interface burst rate: 22 MB/sec (22436 KB/sec)
[14:31:07]  Elapsed Time:  0:02


test 2 results

[15:18:47]  Drive: TSSTcorpDVD-ROM SH-D162D SB00
[15:18:47]  Disc: DVD+RW, 4.28 GB, RICOHJPN W11
[15:19:14]  Starting transfer rate test
[15:28:25]  Speed:4-8 X CAV (6.36 X average)
[15:28:25]  Elapsed Time:  9:11
[15:28:25]  Starting access times test
[15:28:34]  Random Access: 94 ms
[15:28:45]  1/3 Access: 109 ms
[15:29:03]  Full Access: 175 ms
[15:29:03]  Elapsed Time:  0:38
[15:29:03]  Starting burst rate test
[15:29:05]  Interface burst rate: 22 MB/sec (22369 KB/sec)
[15:29:05]  Elapsed Time:  0:02


test 3 results

[16:14:55]  Drive: TSSTcorpDVD-ROM SH-D162D SB00
[16:14:55]  Disc: DVD+RW, 4.28 GB, RICOHJPN W11
[16:15:00]  Drive: QVCFG   0TI7OL2NSDQ7     1.03
[16:15:00]  Disc: Data CD, 98:20.06,
[16:16:04]  Starting transfer rate test
[16:19:34]  Speed:24-32 X P-CAV (28.26 X average)
[16:19:34]  Elapsed Time:  3:30
[16:19:34]  Starting access times test
[16:19:44]  Random Access: 106 ms
[16:19:56]  1/3 Access: 116 ms
[16:20:09]  Full Access: 132 ms
[16:20:09]  Elapsed Time:  0:36
[16:20:09]  Starting burst rate test
[16:20:11]  Interface burst rate: 19 MB/sec (19566 KB/sec)
[16:20:11]  Elapsed Time:  0:02


now i have to be honest, test 3 was hard, and not sure how reliable it is,

as i had to mount the ISO with Daemon tools, then run test 3 on Daemon tools drive
however i still feel the test is fine, as deamon tools still had to get the information of from the cdrom anyway in real-time

and the windows memory and cache was cleared after each test,

now at this point i could see results that even surprised me a little,

1/3 access and random access was a little faster reading from the actual files them selves and not from a ISO,
however Full Access was a lot faster extracting the files from the ISO.

also of note test 3 transfer rate scored a whopping 28.26 as opposed to test 1 & 2 which only scored 6.36,
and on this phase of the test cut the time from 9:11 to 3:30 which is huge,


now i wanted to rerun these tests but using the outer edge off the DVD-rom,
so i designed a track and put the information at the outer edge,
however test 1 would not run properly,

the sound coming from my drive was terrible, a lot of spinning up and spinning back down, i've seen this kind of thing before, it's where the drive does not aspect to be reading at such a slow speed, and yet the drive cannot read such small files at such high speed, so the drive is fighting with it's error correction technology, one wants to speed up, but the other is saying slow down.

so unfortunately on my drive i can't run these tests again using the (faster reading) outer track.

now what this all means i'm not going to say this is the 1st time in a very long time i have benchmark something, there are some smart people here that hopefully will confirm i done things right, and even better do further tests to see if the M3 Raw idea is veasable without some kind of container for the many many thousands of files that driverpacks have and can dvd-reader and writers handle this new method in general.

the above test's are what they, basic to say the least, and of course more tests, from smarter people then i will be needed to confirm,
but personally do fear the workload and extra fatigue added to a dvd-reader could be quite high,
in fact i've even seen on many occasions dvd reader's have trouble installing the first steps of windows XP.

Re: M3 Raw (Will this still be in a archive format)

was reading up further, and found that live compression can help upto 40%,

what i mean is many files on windows xp setup cd are in fact compressed with CAB compression
I.E. explorer.exe but on CD it would be explorer.ex_
now this underscore at the end of the extension tells windows setup it needs to be de-compressed, could this be utilized, or would this invalidate what M3 is about, not sure, as of course M3 is probably been designed to fulfil more then one roll,

just an idea out loud, as compression would improve file access times as the work load would be lowered on the drive and shifted over to the CPU and HD (HD depending on buffers or cache of course)

Last edited by Registered (2008-09-26 05:17:58)

Re: M3 Raw (Will this still be in a archive format)

Your points are irrelevant.... (sorry)

1 we already have compressed file method available (that would be M1)
   You're more than welcome to use it based on your personal beliefs / preference. Enjoy !

2 Why would we be reading thousands of files off the ODD?
   (at most we would only read the INF's and then perhaps few more files for a matched driver)
    (the infs would likely only be read once and cached both by the drive and the OS)

3 SAD doesnt need to be on an ODD at all...

DP BartPE Tutorial   DP_BASE Tutorial   HWID's Tool     Read BEFORE you post    UserBars!
http://driverpacks.net/userbar/admin-1.png
The DriverPacks, the DP_Base program, and Support Forum are FREE!.

Re: M3 Raw (Will this still be in a archive format)

fair enough, just thought i'll think out loud, that's all,

as i said, wasn't that sure anyway, i'll leave the real thinking to you guys,

thanks for reading anyway.

Last edited by Registered (2008-09-26 23:41:37)

Re: M3 Raw (Will this still be in a archive format)

Registered wrote:

now what this all means i'm not going to say this is the 1st time in a very long time i have benchmark something, there are some smart people here that hopefully will confirm i done things right, and even better do further tests to see if the M3 Raw idea is veasable without some kind of container for the many many thousands of files that driverpacks have and can dvd-reader and writers handle this new method in general.

You still do not seem to have grasped my point:

There's no difference between small, single files or a large container file that houses these small files.
If the sector-based access (and that is what matters for the ODD, it does not care about the overlayed file-system) is non-linear, then that means the head will need to shift often, access times will rise, throughput will go down and the driver will make "funny" noises.
Why do you assume files in a contained would all be consecutively arranged while single files aren't?
It's still the same data inside the container, the same sectors to be read and possibly even at the same positions.

As I said before, for random data access, Flash memory is the best because it has no movable parts that would slow down the scattered access process.
Any drive, be it HDD or ODD will suffer greatly from this compared to it's burst data rate.

The only way to overcome this is to know in which order files are being read an to pre-arrange them so that they lay in line.
I am sure this can already be done at ISO level, so there's no need for a container file.

Obviously, even inside a container, there can be fragmentation.
The worse thing about it is that file-system defragmentation cannot even catch it because it's invisible to it (it only sees the big container file).

Think about that for a second.

but personally do fear the workload and extra fatigue added to a dvd-reader could be quite high,

I am sure a PC drive will be designed and tested for such cases of stress.
Compared to an ordinary stand-alone DVD player's drive (which often enough happen to be PC drives anyway), you usually do not only play one large file (the movie) in one given order (from start to end).
The common case is random sector access (same for HDDs), which is why access times play a great role in the performance of different drives and should not be neglected.

in fact i've even seen on many occasions dvd reader's have trouble installing the first steps of windows XP.

That is probably also due to the fact that an unattended medium has to be created by the user on either R or RW media (which are not perfect to read compared to a pressed medium) or the fact that Windows setup is extremely pricky about BIOS settings, RAM timings in particular.
It usually helps setting the BIOS to "Safe Mode" if you encounter file read errors during setup.
You can re-enable your ordinary ("Optimzed") settings once it's installed.