The only thing I really have against Speed Disk at this time, is that it apparently interferes with the boot and application optimization prefetch that XP performs every three days. Norton works on a different theory than XP does, and the both of them tend to scramble eachothers work, kind of fighting eachother.
AlecStaar and I are still working on a patch to fix this, but still have some things to work out yet. Hopefully we can release it soon.
Other than that, other than philosophical differences in how many defraggers work, I have nothing against Norton.
The criticisms of the previous post are very valid.
Speed Disk not only is poor at defragmenting in general (Run the regular defrag and see how many fragments are left after Speed Disk), but it runs a program in the background, npodb.exe, I think.
After running Norton for a month, and then the native defragmenter for a month, I am convinced that MS has not been stupid with regard to defragmentation. The built-in one works the best.
It is a good idea generally to consider Microsoft better than retarded people, and to realize that maybe they have really solved problems with previous systems.
I have been using Vopt for awhile now in both 98 and ME. The best dam defragger I have ever used. It's currently not compatible with XP but they will have it out shortly. This defragger isn't well know but I'll put it up against anyones. It can be purchased at www.goldenbow.com
Originally posted by Mike89 I have been using Vopt for awhile now in both 98 and ME. The best dam defragger I have ever used. It's currently not compatible with XP but they will have it out shortly. This defragger isn't well know but I'll put it up against anyones. It can be purchased at www.goldenbow.com
I'll have to admit, Vopt was a kick@ss product back when I was using '98. But but I'n not counting the chickens waiting for them to release a W2k/XP compatible product. They've been saying this since W2K was released...
(And, all of the most recent versions of defraggers have adopted this, even Executive Software's Diskeeper 7.0 which is radical because they stated it would not make a diff. only theoretically... well, they have seen the light & had to alter their code for that as well, there is no denying that XP's own native BootOptimization/OptimalLayout features work... speeding up the boottime at the VERY least!)
With great fear of hijacking another thread , I need to ask where you found this out, and any linkage if you have any. I wasnt aware that DK7 had changed its algorithim one iota from previous versions, with the exception of any MS API changes, and giving consideration to layout.ini, and MS requested. Other than that, DK7 still is an unoptimized defragmenter, with its sole job of defragmenting files and clearing freespace as best as it can. I wont debate the pros and cons between DK and SD, since its out of the scope of my question.
.S.=> Speed4Ever's mentioned something I have slowly been working on that improves Speedisk working WITH XP's native BootOptimization/OptimalLayout feature... & it is working! I can run them BOTH concurrently/simultaneously without them getting into "Tug-of-War" conflicts on files XP is working on! Simple program, tells Speedisk to ignore the files XP works on for BootOptimization/OptimalLayout & is working out well, only waiting for some feedback from Symantec on it really at this point... & some minor issues about MFT$ placement, which personally, from writing to Speed4Ever, I think Norton has a BETTER idea to place it to the outermost faster disk tracks... why? Well, MS puts it into the middle of the disk... which is FINE because BTree seeks start there... so you will find the file fast! BUT, on the outer tracks it will read it faster... what's more important? Finding it fast (which B-Tree seeks would find it in two seeks rather than one on outer tracks) OR, reading its contents in & out faster as Speedisk yields? I will take speedisk's philosophy on that... apk
I would contend that *either* method works fine. They both have pros and cons which cancel eachother out by your definition. Seek fast or read fast? IMO (and thats all it is ) with the small indexes that make up the MFT, faster seeking would be the better method. I mean, how long does it take to read a series of small files like that, as long as they are defragmented and concurrent?
In the past, when most HDs were somewhere around the speed of 3600 RPM or slower, I could where it would be paramount to having optimal disk placement. But in todays speeds of 7200 RPM and faster, I would contend that that file placement isnt as important today. But again, thats just just my opinion.
The primary reason for our patch, was to provide full compatibility between XP and SD. IMO, that includes the MFT, as XP apparently handles it just fine on its own. Having SD and XP fight over that one is a big concern to me. When SD moves the MFT, its also moves space for the MFT reserved space. Problem is, XP doesnt seem to read that freespace, and will put newly written files there. Lets say, for example, that XP has the MFT and Reserved space in the middle of the disk. After SD placement is complete, it has the MFT at the top of the map, along with what *it* considers the reserved space.
Now, analyze that with DK7, and the MFT is at the top of the map also, but the space that XP considers MFT reserved space is still where it was, at the middle of the map, and theres a bunch of space at the top that XP considers free game for new files to be written. I contend that this is far from optimal, and ruins any chance for optimal disk placement. I believe this is why SD will always have to redo most of its optimization process soon after it completed a run. SD just does not communicate with XP very well, and its important that we find a way to get full compatibility between XP and SD. A half-assed patch wont do any good at all.
Unfortunately, I dont think I'm going to get a good response to our questions from Symantec. Its been about three weeks since I wrote to their tech support dept., and no answer. I'm also still awaiting their answer in the support forum, but still nothing
Well my dumb ass understood very little in last couple of posts. Heh heh. I got some of it though. This is definitely good reading.
Does disabling Indexing (or disabling any other service for that matter) affect anything that was said about XP always working on the drives for optimization? I did disable it after reading it was a resource hog.
I did email Vopt and they claim a defragger for XP will be out shortly.
I have only defragged in XP once. It was slow. This was shortly after I had installed XP (Home) and had messed with it a bit (did upgrade from 98). I will have to do it again when I return to work to see it run a second time. I did like XP's defragger better than 98 though. I absolutely hated 98's. I like to see the whole process on one screen, not that scrolling crap.
Sorry if there was a misunderstanding there. I may have worded it in the wrong way.
What I meant to say was that DK7 still does the "push everything where it will fit" method, just doing straight defragging, no optimization, with the exception of offline MFT, Directory, and Pagefile optimization. It adheres to ignoring XP optimizations.
Looking through the rest of your post, you made some pretty good points. And I'll admit, they make some sense.
Now, technical points are one thing. Real world results are another.
Heres my feelings on Speed Disk on XP so far. I've been running SD exclusively since around the beginning of the month. I figured if I'm going to be testing this out for you, I might as well not let another defragger get in the way of things.
I have 2 40 gig partitions, each having about 30-35% freespace on the average.
I have yet to see a SD defrag run take less than an hour. This is with daily runs, because an SD analysis usually shows over 600 fragmented files daily, so I choose to do daily runs to keep my system tuned. It has been given plenty of time to get acustomed to my drive, and organize things so that future runs would be quicker, like you said it would. I have yet to see this happen.
There are usually a few files left fragmented, including the MFT, but I've never really thought that was a big deal, with the exception of the MFT fragmentation.
When I ran DK 7, it would typically take around 5 minutes to do a run, and would complete with no fragmented files left over. It would leave maybe 2-3 spaces in the freespace, assumably because it was trying to give way to unmovable files, which I assume were metadata, or some other unmovable.
I dont notice any appreciable speed difference between now, and when I ran DK 7. I might be me, but I just dont notice the difference SD makes over DK 7. Neither is slower or faster, except in defrag runs, which DK 7 whoops all over SD in that area. If my files are being accessed faster in miniscule benchmark scores, great. But I'm not noticing a difference at all. My computer ran fast under DK 7, it runs fast under SD. I think the differences, if any, are nominal at best.
Now, I'm still frustrated by the fact that SD moves the MFT, then XP moves it back, plus the fact that XP ignores the space that SD reserves for MFT. If you can come up with a way to fix that, cool. I'd love to see it, and try it.
I do like the fact that SD has been proven to run well in extreme situations, like having a full defrag run in >10% freespace situations.
The point I see here is, as we've gone over and over in the past, is that SD is not compatible with XP, and doesnt seem to want to obey commands when told to ignore given unmovable files. I'm *hoping* that its ignoring the layout.ini files as we're telling it to. But to be honest, I cant confirm whether it is or not, due to its lousy disk map. All I know is, everytime I run a pass, it feels jsut like the first time I ran it. Its moving practically everything all over again. I understand that it goes by the count of how often you run an app, but this just isnt right. It takes *way* too long to do a run. One to two hours daily is just too long for any defragger to run.
That, plus it doesnt work as advertised. It doesnt move the Pagefile in Xp. It doesnt ignore the MFT if you tell it to. As I said, I have no idea if its ignoring the files we told it to, I'm going on faith here. It doesnt move all the metadata, as it says it does. The fact that Symantec has ignored my emails pertaining to how it works with XP pretty much shows we arent going to get any help from them. Hopefully Im proven wrong on this, and they respond. But I'm not holding my breath.
Theres other things I could mention, but I dont see the point...
I'm hoping once your patch is completed, it will run better. I still havent given up on this patch, but thats because I'm a persistant bastard, and hope that SD will work for other people someday. Because IMO, Symantecs ripping them off right now.
Regardless, in its present form, I cannot recommend Speed Disk on XP right now.
Originally posted by AlecStaar Glad you see those points above, about logicals & filesystems addressing only NOT being a good way to look at this stuff only...
See, unlike software in RAM that is FULLY addresseable thru ALL POINTS IN RAM equally fast using X86 or better CPU's, technically at the same speed... pure logical, disks are NOT that way. They deal in the physical, & pure theory alone, BREAKS DOWN when dealing with that.
I understand what your saying, I have for awhile. But, unless you can point me to a link proving otherwise, these disk placements mean *nominal* speed boosts in file access. Its the file defragment that makes the difference. With the exception of concepts like directory compacting, MFT defragmentation, moving files to a paticular place on the disk means little. Now, if this could be done in a short amount of time, I'd be all for it. *But*, it takes me over an *hour* to get decent file placement. How is that saving me time? How is that making my computer all that much faster? Is this 1-2 hours being given back to me in increased computing efficiency?
I understand your philosophy. I agree with your philosophy. I dont agree on its implementation. Its like giving a dollar to save a dime...
Like you said: Real world results! Mine are not like yours, we both tested that before, my second FULL DISK DEFRAGS take me roughly 10 minutes!
What size and complements are your disks? What is your usage patterns? What is your disk complement?
I, along with many other people on the web, have yet to see these 10 minute defrag runs with SD. Go to the Symantec Tech forum and see what the response is to people who complain about it being slow, like mine. Know what the response is?
">I too have the same problem with Speed Disk (an oxymoron) taking
>forever to run. I have tried it with System Restore both enabled and
>disabled but no help. Also, I changed the global settings to tell the
>system to devote more system resources to running Speed Disk
>optimization but again no increase in speed.
Windows XP is a very different operating system than Windows 98 and
Windows ME. Windows XP exerts greater control over the computer than
the Windows 95/98/ME family ever did. As a result of the increased
control by Windows XP, the Symantec software will run slower."
This question, and this answer, are littered all over the Symantec Forum. So I'm not the only one facing this problem. Go to the MS NGs, you'll see more of the same...
On disks, you have the physical to address: Disk head swings! Just like NTFS was said by MS initially to be "frag proof/frag resistant" & that proved to be TOTALLY untrue. NOT PHYSICALLY POSSIBLE, especially when files are created/destroyed alot on a disk.
Faster read/writes (the goal of ANY file, not just its seektime) is where Norton's placement of MFT$ & Pagefiles on outer tracks, WHALES on Ms' philosophy of middle of disk placement: YOU GET FASTER READ/WRITES ON THOSE FILES!
I myself, and you know this, we tested it... get EXTREMELY FAST DEFRAGS WITH NORTON! You know that, we tested it at NTCompatible.com, I had to see if mine was like yours, & it's not after a good first run I did days before!
Yes, I know that. But I'm still curious as to how you did this? How big a disk? How full is it?
Whats your secret? Many people would want to know...
You told me that mine was slow because it was a 40 gig HD with about 35% or so freespace. Thats cool...except that DK 7 can do it in 5-10 minutes. no sweat. And my files get accessed just as fast as when defragged by SD.
BUT, the first run was VERY slow for me... it had finally had enough access counts to files & particular ones I use, to pull of a "Bands of most used vs. least used" placements. Even Microsoft had to concede this, & built in their Bootoptimization/OptimalLayouts into their OS... tossing out MoveAPI file constraints EVEN IN THE DEFRAGGER! That also limits its defragging ability to 4096 sized sectors/clusters.
I'm still waiting for it *not* to be slow for me. Its been 2-3 weeks, SD has been used on a regular basis...how much time is enough for it not to go though 75% of my disk and rearrange my files for the umpteeth time?
I also dont percieve prefetching and layout ot be like Nortons placement, although there are similarities in the theories. The point is, SDs placement interferes with XPs placement. Again, I hope we can get this fixed soon.
Norton... knows NO SUCH LIMITATION & can move files like Pagefile/directories/MFT$ during runtime... even Diskeeper has adopted this, & why? SUPERIOR UPTIME! No need for reboots!
I apologize for that one. I was thinking of DISK DOCTOR when I mentioned that. Think of it as I need to lay off the crack pipe . I know, that was a dumb mistake...LOL. I've been looking through the Sysmantec forum way too much, things are bound to get mixed up once in awhile
It cant move all the metadata (not that thats a big deal), and it often cant leave the MFT in a defragmented state. It often leaves it in 5-7 pieces on my computer.
And Diskeeper hasnt adapted to this, *XP* has. Right now, with DK 7 and XP, they can do the same thing as. XP handles the MFT and pagefile just fine. The only advantage SD gives is directory consolidation (which I'm still trying to figure out why DK doesnt do that. One mark against DK there).
* Imitation IS the sincerest form of flattery... seems both MS & Executive Software (both companies I admire alot) had to imitate Symantec/Norton this round... no denying this!
I find little imitation here, especially from Executive Software. As far as MS is concerned, you need to read up on prefetching, predicting, layout, and see how they work together as a whole. It doesnt work anything like SDs placement for the most part.
P.S.=> On our patching it? Listen... be patient! I don't like operating without ALL the facts... I think we need to waitout Symantec's reply is all... I rarely fail on a programming task, this will NOT be one of them, but many times I too, had to be patient. Wait out answers... recently, I had to with my APK Registry Cleaner 7.0++ with Lonman, & I overcame that too. This will be NO different.
Right now? I think we have a good 90% of it done... no doubt in my mind! BUT, the MFT$ & PageFile.sys placements... man, from what I told you above, can you say it is inferior to that of MS? apk
I'm not in any hurry on the patch. I want it to be done right before its released. We need to find more information on how SD works internally. I'm working as hard as I can to find this information, but sources are very lacking so far. I'll keep at it.
As far as MFT placement is concerned, yes I do question SD method. Leaving it fragmented like that cant do it any good, no matter where you place it. The problem is, that XP still wants to put it where it wants it. I tried shutting down the XP optimizations using your methods, and XP still moves it around. I'm curious as to whether a different XP function controls this. Either way, we are still trying to attain SD compatibility with XP (at least this is what I had in mind at first. Is this still the plan?)
Now on ignoring those files? I have an email from you here in front of me now, that says you saw the UNMOVEABLE black patch grow bigger in Speedisk after we populated it & you ran Speedisk... you have seen that, or so you told me in email!
I said I assumed (i.e.- hoped), that the unmovables was working. Something along that line.
But to be certain, we cant be absolutly positive that its working. That big black line is the Windows system files. Thats the one I was looking at. Now I can only hope that that has the files from layout.ini. I see a couple of other little blocks marked black. Hopefully one or several of these are it. But because of the lunatic who designed SDs Map and Analysis list, I am at a loss to completely confirm it.
So I *think* we're on the right track. With all this hassle we've gone through, it better...
Ep, glad to see you come back and tidy up...did want to ask a one day favor, I want to enhance my resume , was hoping you could make me administrator for a day, if so, take me right off since I won't be here to do anything, and don't know the slightest about the board, but it would be nice putting "served administrator osnn", if can do, THANKS