Jump to content

wht36

Member
  • Posts

    5
  • Joined

  • Last visited

  • Donations

    0.00 USD 
  • Country

    South Africa

Posts posted by wht36

  1. I'm not an expert, but I was also interested in this.

    As far as I can tell, there is no established speed benchmark proving that cluster size >4kb matters. Although a cluster size of 512 bytes is said to hurt performance when you have a large disk.

    Windows uses the following defaults

    * 512 bytes: 0 MB to 512 MB

    * 1KB: 513 MB to 1 GB

    * 2KB: 1 GB to 2 GB

    * 4KB: 2 GB+

    NTFS compression only works for 4kb and below (and that is the reason for the 4kb default). Note that decompressing on the fly may be faster than reading from the hard disk if you have a fast CPU.

    I've read somewhere that Microsoft only recommends a large cluster size for servers and claims that the difference is negligible in home use.

    What is recommended by all is to switch off indexing service (and it is switched off by default in the newer editions of XP).

    If you do not have legacy programs that use the 8.3 filename storage method, you can also tell windows not to create a separate 8.3 filename entry (fsutil behavior set disable8dot3 1). Legacy programs includes all 16bit / DOS programs as well as programs that use the old uninstallers (apparently there are quite a few). Switching off last access may also help (fsutil behavior set disablelastaccess 1), but interferes with backups and restores.

    Finally Microsoft recommends that users do not disable prefetch. It is claimed that prefetch allows windows to load executables and their required dlls in optimal sequence, thus speeding up load time.

  2. I used to to this procedure several years ago, actually 8years, on windows 2000/xp.

    However, if you have a farely new computer there is a much faster way to increase overrall system/io performance.

    Use a good partition manager to set cluster size to 64KB, disable pagefile first tho and hibernation if u have it,enable large memory pages on 64bit 2gbram+, increase critical workerthreads to 16(both). Then defragement harddrive. C:\ should be somewhere between 40GB to 60GB, suitable to keep many to insane many programs. Games should be kept at a completely different harddrive, because then games dont have to read/write to same place as windows/os has to.

    Also prefetch should be disabled as it slows down system boot, unless you are going to manually optimize the layout.ini, just forget prefetch.

    Also good practise is to use portable software, making the y:\program files here mentioned in #1 bloat, as you will NOT need it, since all programs should preferrably be portable and on different harddrive for optimized performance.

    For even further i/o speed consider ramdisk software by superspeed software, or getting some expensive SSD sata drivers, which you place directly on sata-port on mainboard, making it a truly fast 0.1ms system access speed.

    ...

    I am interested in boot speed as well, do you have any stats to verify the above settings? Because according to Microsoft removing the Prefetch does the complete opposite and prolongs the boot time. Also a large cluster size prevents using compression, and in a PC with a fast CPU decompressing on the fly may be faster than reading uncompressed data from the disk.

    Now I didn't do formal timings; I just count how many times that ticker in the default Windows boot logo goes round when Windows boot. The closest I've gotten is half a round, although after accidentally deleting some files from windows the ticker now almost completes a full round before booting.

    As far as I can tell, the most obvious speed increase is from defragmenting the hard disk and disabling the network adapter (each will reduce the booting time by half a round of that windows boot screen ticker).

    Disabling indexing and creation of 8.3 filenames may help with file writing as well.

  3. Preamble:

    I tried to search for topics similar like this, and there are SO many posts related to hard drive XP installs that I gave up to see if there is an identical idea to this. So if an exact same thing has been done before, I apologise for wasting your valuable time.

    Acknowledgements

    wimb - http://www.msfn.org/board/index.php?showtopic=121446

    many others: msfn, Microsoft, Horst, wiki, msdn, flatassembler, google...

    So for whom this may be suitable?

    - If you have XP installed and you want to test how an nLited xp distribution would work and you are sick of burning the distribution to CD everytime you decided to test a new nLite distribution.

    So why use this method:

    - Original XP source on harddrive is not altered in anyway, i.e. you can use nLite unlimited number of times without having to copy the original XP source from CD everytime

    - nLited XP distribution is not deleted by XP setup afterwards

    - Duplication is done using NTFS hardlinks, so files are not actually copied, so this method is extremely fast (<1min on my PC).

    - The actual scripts are batch files, so they are very easy to edit and change to your liking

    - Has its own commandline program (setfile.exe) so it is not dependent on other commandline programs (it should work even if you don't have fsutil)

    - Accepts commandline parameters. Will also work without commandline parameters as long as xp source files are copied onto the "xp_cd" subfolder

    Basic requirements:

    - NTFS formatted primary drive

    - Original XP CD source

    - Rescue CD/USB/floppy ready in case things go bad

    - Administrator privilege

    - Files MUST be installed on the primary boot drive (because NTFS hardlinks cannot work across drives)

    Warning:

    - I have only used XP, so I can't give advice on doing this under vista or other OS

    - As far as I can tell, McAfee and NOD32 finds everything to be clean, but one can never tell. Scan everything with your virus scanner. If you are not happy, don't use it.

    - md5 sums:

    aa412cfe01876c0f5dfd30e73d19ea86 *BOOTSECT.DAT

    e384a447b57fec04f57fdec11049fa47 *nLitePrep.cmd

    20b875bff6feac7f87ee1566bb17b911 *PrepXP.cmd

    264ae29105d512aa3c58f88dc7d41a9a *setfile.exe

    Usage:

    - Extract boot.7z to C:. I have placed the files in C:\BOOT, so by default after extraction the files will be in a folder "boot", which should have the following files:

    PrepXP.cmd

    nLitePrep.cmd

    setfile.exe

    BOOTSECT.DAT

    - Copy XP source from setup CD to a folder on C: (I use C:\BOOT\XP_CD)

    - Run nLitePrep.cmd to duplicate "xp_cd" to a folder ("disk"). This folder ("disk") can then be altered by nLite without altering the original "xp_cd" folder. Note that if the destination folder ("disk") already exists before you run nLitePrep, nLitePrep will fail (if will NOT overwrite it, I think it is too risky); you MUST delete/move/rename that folder yourself if it already exists.

    - Use PrepXP.cmd to duplicate nlited "disk" folder to XP setup folders (C:\$WIN_NT$.~LS, C:\$WIN_NT$.~BT)

    - Reboot and select "Windows XP Setup" to run setup

    Commandline options

    nLitePrep

    Usage: nLitePrep [XP_source] [nLite_source]
    Example: nLitePrep xp_cd disk
    Purpose: nLitePrep duplicates the XP setup CD files in XP_source to nLite_source
    so that users can use nLite to alter nLite_source without altering XP_source

    XP_source must exist and nLite_source must not exist for nLitePrep to work
    XP_source and nLite_source must be on the same drive
    Default XP_source is "xp_cd"
    Default nLite_source is "disk"

    PreXP

    Purpose: PrepXP sets up XP for installation from NTFS Hard disk
    Usage: PrepXP nLite_source
    nLite_source is the path where nLited XP setup CD is copied on to
    nLite_source needs to be in a folder on C:
    so that PrepXP can hardlink the install files
    (to prevent XP setup from deleting the actual install files)
    Default XP_source is "disk"

    You can use nlite to customise the installation files and

    there is no need to create iso or burn to CD afterwards

    I usually create a folder, e.g. "boot" and place PrepXP inside it

    Then I put the setup files in a subfolder, e.g. "disk"

    SetFile.exe

    SetFile.exe provides support for editing of .SIF files and boot.ini, as well as making hardlinks, decompressing NTFS files, and setting file attributes, all of which are needed for setting up XP to install from HD.

    SetFile.exe i IniFilePath [section] key="string"
    key= remove key
    key== clear key
    = delete section

    SetFile.exe l ExistingFile NewFileLink
    New file must be in the same drive

    SetFile.exe a [+/-attributes] File [NewJunctionFolder]
    Attributes (+ or - to set or unset):
    a (archive), c (compressed), d (directory), e (encrypted), h (hidden), i (indexed)
    j (junction), n (normal), o (offline), r (readonly), s (system), t (temporary), v (volume)

    If things go badly...

    Okay, things shouldn't go badly. I think the batch file will not delete or overwrite stuff. The only files it may overwrite is the temporary windows xp setup folders on the harddrive, which can be deleted unless you have specific uses for them. It will also put an entry into c:\boot.ini so that you can run XP setup from hard disk. This entry will be removed by XP setup if XP setup is successful.

    Probably the worst thing that could happen is that XP setup will not run. Well... if it doesn't work, then I apologise for wasting your time. Although, if it doesn't run, I suspect it will not run if your burn it on to the CD either, then in that case it is a good thing that you find out that it won't run. Just remember to delete C:\$WIN_NT$.~LS and C:\$WIN_NT$.~BT aftewards.

    boot.7z

  4. Hello,

    I'm from South Africa. I have been browsing msfn for a while now before I joined and I must thank all the posters for their selfless work. Thanks again. Without you guys, XP installation would just be a boring and frustating chore.

    Okay... installing XP is still quite a chore for me... but at least it is INTERESTING now...

    Thanks again!

×
×
  • Create New...