i want my drivers install quicly on slow pc so which method is right 1 or 2

You seem to have confirmed that larger files transfer faster...
   Even when they are not copied from an ODD.

Yep, according to the benchmarks that I did on both the Hard Drive and the installation media (the usb drive)  there are two things that can slow down the driverpack installation:

1.)  the compression ratio of the driverpacks archives
2.)  the write speed of the Hard Drive

The compression ratio was the first thing that was slowing down the installation process. whenever I tried extracting one of the driverpacks, the CPU usage in task manager would hit 99-100%, so I tried getting rid of the compression and it ended up speeding things up a bit.  However, when I did that, the Hard Drive became the new bottle neck of the installation.  I knew that it wasn't the read speed of the usb drive since the USB could read at decent data rates no matter how small the size of the individual files were.  When I looked at the write speed of the hard drive for files that were 4 KB in size, it was clear that the hard drive's write speed for small files was the bottle neck (the USB read at 4.892 MB/s but the hard drive only wrote at 0.839 MB/s).  Hard drives are much better at writing big files than tiny files, which explains why the .7z archive with the cab compressed drivers transferred faster than the .7z archive that had all of the drivers extracted.  At this point, the only way to make the installation go faster would be installing windows on a hard drive (or flash drive) with a faster write speed.

I don't think you have to combine all of the driverpacks into one huge pack to save space.  I believe that it was the cab compressed drivers and the fact that the .7z archive had no compression that speed up the installation.  So if you wanted to keep all of the driverpacks in their own archives, you should be able to, you just may have to create each driverpack using the Stand Alone Driver option with method 1 for each driverpack, making sure not to add the cabbed driverpacks to the same directory.  Then just compress each directory that the driverpacks are in using 7zip with storage compression, and name the archive anything with "DP" in the beginning of the name.  Just make sure that whatever you name it is no longer than 8 characters long (8.3 file name limit in DOS).  I'll have to try it though.  When I do complete the test, I'll edit my previous post to add the test.

I don't think it is a good idea to start combining all of our packs into one single huge pack
But. It is nice to know that if we do then we can shave about 25% off our extraction time.

Our users may combine them if they wish to do so

- has anyone else tried this ????

PS the delay is windows Delayed Write (Disc caching) as you suspected

OS tested:  Windows XP SP2

Computer: Dell inspiron 2200

specs:
    Intel Celeron M 360J, 1400MHz (L1 cache: 32 KB  L2 cache:  1 MB)
    Memory: 503MB PC2700 DDR SDRAM (2.5-3-3-7 @ 166 MHz) (effective clock:  333 MHz) (bandwidth:  2667 MB/s)
    BIOS:  Phoenix
    Disk Drive:  Hitachi HTS424030M9AT00  (30 GB, 4200 RPM, Ultra-ATA/100)  (DMA mode 5)
    NTFS Tested Partition:  22842MB ( I didnt format the entire drive since I had another OS on another partition)

Installation Media:

4 GB USB flash drive formatted with NTFS file system.

Hard drive & flash drive benchmark:  Used CrystalDiskMark 2.2

Hard Drive:

-----------Read-------------
Sequential speed:  25.95 MB/s
512KB read:          16.59 MB/s
4KB read:            0.336 MB/s

-----------Write------------
Sequential write:   23.62 MB/s
512KB write:       13.72 MB/s
4KB write:           0.839 MB/s

USB Drive:

----------Read--------------
Sequential read:   26.30 MB/s
512KB read:       26.29 MB/s
4KB read:           4.892 MB/s

----------Write-------------
Sequential write:  5.678 MB/s
512KB write:       2.463 MB/s
4KB write:           0.026 MB/s

I used WinSetupFromUSB to make the USB windows installation.  The Windows XP Source was trimmed down to 354 MB by doing the following:

    Deleted the "DOCS", "VALUEADD", and "SUPPORT" folders
    Deleted "WIN9XMIG", "WIN9XUPG", and "WINNTUPG" folders in I386
    Deleted "LANG" and "cmpnents.
   
    Used nlite for the following:
   
    In the components section, removed all except "western europe and United States" under languages.
    Performed UxTheme and SFC patch under patches.
    removed error report, remote registry, messenger, security, system restore, and windows update services
   
   

Times:

All times are in minutes:seconds format.  system restore was disabled for all tests to speed up installation.

The Tests with driverpacks include ALL 25 driverpacks (both official and 3rd party driverpacks).

All tests with driverpacks have SFC (windows file protection) disabled, since it speeds up the installation.

All driverpacks were integrated using method 2.

All times start when setup is formatting the drive and ends when all desktop Icons appear.  On a fresh XP install on my computer, the screen flashes twice, so after the second flash, the desktop is considered to be usable and the installation is considered to be complete.

test1:  without driverpacks - SFC (windows file protection) enabled  :  16:23
test2:  without driverpacks - SFC (windows file protection) disabled  :  13:48
test3:  with driverpacks  :  38:40
test4:  *with driverpacks and modded presetup.cmd  :  39:57
Test5:  **driverpacks with 7zip storage compression in one archive (cab compressed)  :  31:05
test6:  ***Driverpacks using jaws1975's un7zip.exe  :  36:22

NOTE:  At this point in the test, the archives were getting too big, to the point that I wasnt able to fit both the xp installation and every single driverpack on my USB drive (all 25 driverpacks uncompressed in one archive took of the 3.76 GB of space on my USB drive), so I have excluded the 3rd party webcam driverpack for the following tests.  The tests may not be accurate because my USB drive was very full durring the tests (not sure whether that would affect reading speed or not).

test7:  driverpacks with 7zip storage compression  :  34:15
test8:  ****driverpacks with 7zip storage compression in one archive (not cab compressed)  :  36:47

*The modded presetup.cmd file copies the driverpacks archives to the hard drive before extraction.  You can get it from post #14 in this topic.

**driverpacks were created with Stand Alone Drivers option with method 1 which cabs the files to save a little space.  Driverpacks were combined into one 7zip archive with storage compression.  Archive was 1.42 GB (exactly 1,531,810,967 bytes) large and was named DPGA906.7z (I could have probably named it anything as long as the name contained DP at the beginning and was no longer than 8 characters long). The driverpack was then placed in the OEM folder of the installation media.  I also slipstreamed driverpacks CPU, mass storage, and chipset using method 2 just to make sure the installation went through correctly.

*** Same as test5, except here I replaced un7zip.exe and its .dll file with jaws1975's version.

**** Same as test5, except here drivers are completely uncompressed. 

Results:

Test 5 was the fastest method to install Windows XP SP2 with driverpacks.

NOTE :  whenever you slipstream a large amount of driverpacks, windows installation seems to hang a bit after un7zip extracts all of the driverpacks, this doesnt happen when you slipstream a few driverpacks (like chipset, cpu, and mass storage).  The hard drive light was lit up durring this time, so I belive that windows was using the page file on the hard drive to move some data around. Just a guess...

NOTE 2  :  For some reason, laptops boot up faster than Desktops, if anyone knows why, please let me know.

I will jsut use the code i already wrote since it does not seem to be flawed

the short answer is: We don't install the drivers with method 2... windows setup.exe does it for us.

We simply put them where windows setup can find them just before Windows runs setup.exe on the machine as part of the normal installation process.

Basicaly we pause setup, expand the driver library by two gig and resume setup.

now that windows has a complete library to use during the install it wins (almost) every time.

Some drivers absolutely will not install without their personal setup.exe running...
We use the finisher to address that.
Most drivers therefore will not have a finisher entry (and therefore will not have an INI entry...
If a driver folder does have an entry in the packs INI then that driver/folder is a problem child ...

i hope i understood you correctly...

As far as reducing the size... i already wrote the code for that in the testing team forum...
you were/are there
It is resonable & feasable and likely that hwidstool code will appear as a sub option for each platform...

IE the Alpha of installbyhwidstool is already written
making it a new "Include" or Function is like adding a plugin...

Except for the GUI part... That part is always a mess to deal with...
It is some of the oldest parts that Wim wrote when he was 14,
and this was the first program that he ever wrote... God love him.

if you take a peak at the TO-DO list i updated yesterday you can get a fell for what i think is a priority ATM...
http://forum.driverpacks.net/viewtopic.php?id=71

What about providing a db of sorts. I can port my code of scanning INF files.

It's really easy to write into autoit (in fact I am thinking of writing it myself) and I think it'd be a fairly quick process. So basically an m2 process without extraction of every driver to the disk? A very focused and fast install.

Oh and v3.2h of FindHWIDS is out

1. You do not have to use M1, so why bother?
There may be someone else who finds it useful so why remove something that has been working since?
Plus, SysPrep may rely on that, dunno (never used that myself so I wouldn't know)

2. The size increase by using the less memory-dependent lower compression seems to be negligible, unless you were down to single digit MBs already...
If you also include Windows updates, then you will hit the limit eventually, as these grow a bit each month.

Also, WPI could easily been "exiled" on a second DVD or a network drive, if needed.
True, breaks the completely unattended installation but you could use a second drive if you had etc.

3. Better by what?
Faster?
Yes.
Fragmenting the drive less?
No.

Also, that is exactly what the Finisher does, cleaning up the archives afterwards...

4. The new auto-updater for the DriverPacks included in BASE kinda makes this a no-brainer.
There is virtually no difference for the user if they have got all packs at least once.
If it auto-DLs one pack or a handful, doesn't matter.

At the end of the day as the saying goes "you cant please everybody".

To point 3 tho m8 yes it would be faster as for the other things it works and works well so why fix something if it aint broke kinda thing? However making improvements is always a good thing... ok im not making much sense here but I hope you know what I mean.