Speed4Ever

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters] "EnablePrefetcher" 1 = Boot time prefetch 2 = App Prefetch 3 = Both 3 is the default Hope this helps

Quote: Do me a favor... send me a copy of your layout.ini file here, zip it and fly it to me via email! I want to take a look at the contents of yours, it may lead me to a theory I have on my yours is taking some time to run that Speedisk defragmentation! Sorry, but I dont even give that out to my wife over the web <g>. Handing that out over the internet poses a significant security risk, especially on broadband. Think about it...thats practically the contents of your computer inventoried, not everything, but a damned good chunk of it. And if I edited it. that would probably defeat the purpose of your theory, whatever it might be. Its not that I dont trust you, its just that I dont trust you THAT much . Hope no offense is taken, but I just cant do that. Can you tell me what your looking for, maybe I can help. BTW, this drive is hardly 90% clear. More like 30% (40 gigger)

Brian, Sorry, you got lost in the middle of the brain-fart between AlecStaar and me If you mean write-back caching, go to control panel>system>hardware tab> device manager>disk drives, double click your HD, go to policies, enable "optimize for performance". That *SHOULD* do the trick, unless your message means something else. Post back if it doesnt get fixed. Sorry for hijacking your thread like that 8)

Well, to quote a real old song from the 70's... "You may be right....I may be crazy..." (Kudos to whoever names the artist ) No, I dont have diskeeper service running. I enabled it long enough to run an analysis, then disabled it again. With all the trouble we're going through trying to get SD and XP to work good together, I'm not about to throw DK into the mix 8) Anyways, no, I had DK disabled, and it never had a chance to run. On XP and DK interfering with eachother, thats highly doubtful. The XP FS optimization routine only runs during idle times, and that only takes about a minute or two (you basically ran it when you used the rundll32.exe advapi32.dll, ProcessIdleTasks command. The chances of DK interfering with it (assuming there is no safeguards built in to check that) is slim at best. Personally, I worry more about the fact that SD keeps kicking my MFT up to the top of the map, where supposedly the bootfiles are placed. XP will have it down somewhere else in the disk, and SD throws it back up there. Are you sure we've disabled SD from moving the MFT? Because something funky is going on there. I never saw this happen when DK was running. I typically saw XP move the MFT into the freespace towards the bottom of the map as disk space filled up. Is this happening to you? I tell you what. We've both put up some good arguments about the pros and cons of both SD and DK. So heres what I say... Lets find a way to stop SD from f***ing with the MFT, and I'll love the product. Whether I prefer SD or DK, DK is boring cause it aint broken, so lets fix SD and go on to the next broken POS (Piece Of Software ) Does that sound ok? Cause I got a feeling we're acting like SD and XP: We're both right, but from differing points of view. Whatcha say?

Point 1 Response: I never said that I ran DK on this install. You know that I recently reinstalled XP. I reinstalled my apps, and ran SD for the first time tonight. It took 1 1/2 hours. Then I used DK for analysis, but I never defragmented with it. As with the rest of your explanation, I agree, good point. Point 2 Response: When you talk about the native defragmenter, are you meaning DK lite thats installed on XP, or XPs boot and app optimization algorithms. IIRC, the two are separate functions not really related to eachother, although XPs layout may use some DK technology. I need clarification on which one you mean. I'll assume for the moment that you mean DK lite. DK and DK lite both work on the same principal, except that DK lite cant defragment the MFT or consolidate directories (MFT defragmentation is mute at this point, 'cause XP takes care of that). I need your clarification before I can respond to the rest of this portion. Point 3 Response: But your assuming that XPs opt. algorithms are based on IBMS technology. It may be in some ways, but we dont know enough to assume that at this point, unless you can point me to a link that says this. But thats also a mute point. Both theories of operation become faster as time goes by, and you defragment more. I guess what I want to know is, based on todays HD speeds and technologies, is either one really noticeable in anything except benchmarks? Both SD and DK let me operate at the same speeds. The only factor here is, XP optimizes Boot and App files, so both are run faster. Neither SD nor PD nor DK even need this functionality, as XP takes care of it. All XP needs is the bulk of the partition defragmented. So we come to my two theories of operation--optimized, and non-optimized. One defragments faster than the other. Both run at basically the same speeds in everyday OS use. All you really need is defragmented files and defragmented clear space. Both SD, PD, and DK do this. IMO, with the except of the files that XP's layout.ini handles, the defragmenter SHOULD NOT HAVE to optimize the rest of the layout, as XP takes care of this. So then, it comes down to speed of defragmentation. I run my defragmenter roughly every 2 days when I'm not working. In my experience, a light to medium-fragmented partition takes 5-10 minutes to defrag with DK, because its not working as hard. Meanwhile, SD and PD have to rearrange more files because their layout changes all the time, depending on usage. To me, even if they make the OS a little faster, the time they are taking to do this negates the time savings. And thats one of the primary purposes of a defragmenter--to allow you to do things faster and save time. SD and PD in my experience have never taken less then 15-20 minutes on a lightly-fragmented partition, because of all the rearranging. Now, if SD were run on a weekly basis, the time savings could probably be more noticable. But some people like to run it every night to have their file system as defragmented as possible much of the time. This is where DK excels IMO. Point 4 Response: Again, I ran SD for the first time on this install, not DK. But, your reasoning is sound in the capacity you site. But that wasnt the case here. BTW, my second defrag with SD took about one hour. This was immediately after the first defrag run. So this helps prove that the rearranging Theory of Operation has its drawbacks. Again, if run on a weekly basis, SD would realize more time-savings. But on a daily defrag run, DK would be the way to go. Quote: (Drink that all in, digest it... think about it!) Already had a few, thanks

Quote: " I want you to think about this: If you ran Diskeeper or PerfectDisk (or even the native defrag with its file placements technology if it uses it while it defrags in XP, which it very well may be that altered now, who knows? Not just ignoring XP bootopt/layoutopt stuff like we plan to do there, because after I just did this run I just did to test for us? The native defragger, built originally of diskeeper code, showed SAME 10 FILES FRAGGED AS SPEEDISK DID... more on diskeeper next, but BEAR THAT IN MIND!!!) first & set the disk to be placement optimized already? See my comparison I sent you via email. Quote: Diskeeper might run faster due to less work, but if it sees a pattern of defrag done by Speedisk my guess is it FLIPS IT OUT, & says disk is a mess! On the reverse flipside now, if you ran Diskeeper alot there, or just before Speedisk?? It might take Speedisk longer in a scenario like that to work. I am guessing you ran both & saw this very thing... maybe diskeeper patterned defrag more at your place in fact! AGAIN: If you used Diskeeper more there at home or before Speedisk? Speedisk would be like looking at it as a 'first run' redoing the pattern to ITS algorithm based on IBM defragmentation technologies based on accesses & splitting files into parts most accessed even! Speedisk in that case, took longer because of that quite possibly! I just ran speed disk for the first time on this computer with a new installation. Took almost 1 1/2 hours. I havent run DK on this install yet, except to take the analysis I sent you. DK service was disabled until then, so it hasnt had the opportunity to run yet. I can say this, DK has NEVER taken 1 1/2 hours to defrag anything. At the most, 15-20 minutes on a severely fragged HD, 5 minutes on a lite-medium fragged HD. Now, I havent run SD for too long on XP, so I need more time to see if it does speed up defrag runs after several times run. So far, on the last install, SD always spent time moving stuff out of the way to put in most frequent file accessed (which keeps changing all the time). This is why it always took so long on each run. I'm going to start another run right now, just to see how long it takes. It said after the last run that only the MFT was fragmented by 3 files (sorry, I forgot that part in the last email--my bad), so things shouldnt have changed that much since then. I know, we've been going around and around on this one, but its just too damned interesting Heres some more food for thought... To me, theres 2 modes of defrag theory of operation... 1) Defrag it quick, dont worry about optimizations... 2) Defrag it optimally, put everything in its special place, takes longer. Now, my thought on this (and I could be wrong), is that, with very few exceptions, it doesnt matter where the hell the files are, as long as they are defragmented. Or taken another way, does the fact that SD and PD take longer actually SAVE you time? I honestly dont notice a speed difference between DK and SD as far as disk accesses go. But I do notice that SD/PD take longer than DK. So, which way is more optimal with the speeds of todays HDs (I'm talking 7200 RPM, ATA 66 or higher, on a meduim to high end processor)? Do you see what I'm talking about? P.S.--AlecStaar, did I ever tell you that you sound like Steve Gibson? Just kidding...<ducks and covers>

Quote: Odd too, using Diskeeper based code in that native defragger also... diskeeper does not practice bands of use patterns when it defrags! Quote: MS must have altered it for this, or told it to ignore those layout.ini files for it to account with it working in harmony with XP BootOptimize/Optimallayout features. Diskeeper (native and executive) IIRC, has always just "defragged the files where they may lay". Is this what you meant? DK doesnt use an optimization routine like PD and SD do. THis is why it sometimes defrags much faster than PD and SD, as it doesnt have to move things around as much. Theres pros and cons with this, but I'll get into that later...gotta eat Later...

It's both fortunate, and strange, that I havent seen these Infinite loop errors yet. Is there a connection with the detonators and a certain type(s) of configuration(s)? I used to run the 22.83's, am now running 23.11. Not a problem yet. I'd love to know more about this...

Quote: * If you could tell the native one to ignore files? IF it does not work in harmonious operation already with XP BootOpt/Optimallayout features? I could port this 160 lines of code to that too, with ease! The native defragger already does this. Brian, Is it possible that XP is choking on a service start or something? Check your event logs for anything. If the disk is going bad, that should also tell you there.

The best way you can tell if an installer is 16-bit, is to run as theme Luna, and watch the dialog box. If it looks like Luna, it is more than likely 32-bit. But if it looks like the standard pre-Luna dialog box (like Win98, Win2000, etc.), then that shows that the installer is 16-bit. MS hasnt found a way to show 16-bit programs in the Luna theme yet.

That would be my first bet. They've improved somewhat. What version are you using now?

I think hes talking about the W2K version of XPs Control Panel > Users. W2Ks I think was different, but I cant be sure, as I never really used it.

Quote: P.S.=> Take your time, you have a really good handle on things in the OS & I am glad we made acquaintance, because something really nice may come out of it, FOR EVERY SPEEDISK USER on alot of levels! apk Ditto I'll be on in the evening or so. Have a good one...

Quote: P.S.=> IN REGARD TO YOUR LOGIC ON STOPPING THE MFT$ MOVES BY SPEEDISK? Makes sense... if I send this to Norton? It may, as an ancillary benefit? CURE that for them also... "WoW" ² !!! Only question I have is... does XP for SURE defrag MFT$ on each disk? I can find disks easily enough, & force this for all disks the program can find too that are NTFS I think! apk From my experience, yes, XP does defragment all partitions, including non-system ones (does for me anyways). Once it gets going, there may be some days where the MFT is flying all over the place, but diskeeper claims its not fragmented (it might be 3 fragments at times, but doesnt stay that way for long). 2 fragments is normal IIRC, because the MFT freespace is included as a fragment. Thus MFT+MFT Slackspace=2 fragments. 3 fragments isnt anything to worry about, but beyond that, if it stays that way, could mean slowdowns.

Quote: On your MFT$ EDIT: That I cannot stop... BUT, doesn't speedisk move it to the front of the disk if you MAKE it do that? The fastest part of the disk?? Actually, yes it does affect other defraggers DURING OFFLINE DEFRAG. They place it in a different spot though. Diskeeper puts it somewhere sround the first 1/4 of the disk. Now, Perfectdisk, I've noticed that it will pretty much leave it where XP tells the MFT freespace to go, but it will defrag the MFT files and leave the Freespace where it is. I dont know how it does this though, or why the two are different. But, during online defrags, they will pretty much leave the MFT alone. Maybe we can add that to the Exclusion list. Hell, a decent MFT shouldnt fragment at all unless its a database or something. How would you add the MFT to SD's exclusion list separately? Im not sure what file to tell it... EDIT: The reason I worry about this, is because XP, by design, puts the Bootfiles at the beginning of the disk for faster boot, right where SD puts the MFT!!! This is part of what we want to avoid! Plus, I too dont like the way SD defrags the MFT for exactly the reasons you stated. I myself have always been trying to find a way to make SD avoid it. If you know the proper name for the MFT file, I dont see why that cant be excluded according to user choice. IOW, find the filename for the MFT (I cant believe I dont know this one!), make the directions known to whoever wants to know it, and let them add it to their exclusion list. That way, it saves us both a lot of trouble. Let me know what you think....