yup, I'll list a detailed post tomorrow. It'll be relatively long but I will.

0

LOL, need to do some research, huh? Good maybe you'll learn something and realize that a defrag every couple of months is fine for the average user.

0

Ok, I'm gonna start out by apologizing to Mike. I was in a bad mood and did not reply appropriately to his post. I should have explained the reasoning behind my statements. I'll try and do that now by going through a hard drive read operation. A write is pretty much the same. A program will issue a read from a file, possibly with an offset into the file and a number of bytes to read. The CPU will pass that command to the hard drive controller. At that point the CPU has done his job and is free to be interrupted to take care of other tasks. These could be refreshing the monitor screen, updating the clock, checking the keyboard for input, doing some work for another program, etc. The hard drive seeks to the location of the file, starts reading the data and passing it on to the controller. The controller passes the data directly to the memory using DMA (Direct Memory Access). The CPU is not bothered. If the file is fragmented, the drive has to stop reading and seek to the other location. It does this without bothering the CPU. It then continues reading and passing the data to the controller and memory. When all the data has been sent to memory, the controller initiates an interrupt. Eventually the CPU will aknowledge that interrupt and return to the program that requested the read and continue on. So you can see that although the file read was delayed a few milliseconds, the effect on the overall system operation was not as great as might be expected.

0

I believe defragging should be done in relationship to the amount and type of usage. Someone doing video editing would need it more often then someone whom just checks their email. Every twenty hours or so of usage would enjoy a defrag. One user might find value in every 50 hours instead of twenty. Another, maybe, every 100 hours depending on the tasks performed by the individual users. I wonder if there is such a utility (hour meter) that would appear on the desktop and keep track of total Uptime even between reboots that could be reset upon defragging? (I did not find any on a Google search.) Bryan

0

This came up, in that I work in CAD. Had a few files created that were about 25-45 Meg. They took about 15 minutes each to load and see. Upon doing the DEFRAG, it took about 5-8 minutes. Quite a time saving. As this was only program running, I had sufficient time to boil water for coffee etc. However, without even pulling up the files, I manually bleeped data files here and there. Got rid of items in Recycle bin, etc. and defrag compacted a bit ahrder then. Thus my question as to what additional files could be bleeped, or things to check on first before running. Wm.

0

no, no research. it was 1130PM EST when i posted.

0

ham30, does this answer your question? From the early stages in hard drive development certain key parts have formed the base elements, yet within themselves have been the biggest hurdle to its ongoing evolution. For example, data is stored on a rotating platter, and recovered using a moving head. This principle has been used forever. The evolution has not moved away from this approach for the last 200 years even though the media size has changed from IBM's 24 inch RAMAC to 1 inch platters and the rotational speed has gone from 45rpm to 15,000 rpm. The overall performance of any system is limited to the speed of the slowest component on the critical path of data flow. Currently this is the hard disk drive in any computer system, by several orders of magnitude. The current disparity between the cycle time of a CPU (nano-seconds) and that of a hard drive (milli-seconds) means that any request for data from the hard drive by the CPU wastes a large number of CPU cycles. CPU usage is divided into four types, System, User, Wait I/O and Idle. The System CPU usage is that required by the operating system. User CPU usage is that required by applications. Wait I/O CPU usage is the time that the CPU spends held waiting for data which it requires to continue processes, unable to do other work. Idle CPU is the time that no activity is taking place. The problem with this distribution of resource, especially in commercial database operation, is that the Wait I/O component will be very high, with a 30% baseline and peaks of 80% or more not being unusual. As a result the CPU usage cost is 50-250% more than the purchase cost. Tactics developed over the years since CPUs and hard drives were first invented have included, among other things, the development of the concept of paging and the use of faster intermediate or staging memory. This has included on-chip cache, onboard cache and page and swap data-sets Another approach in the attempt to gain greater speed and throughput is to use solid state devices, these however, are relatively expensive, since they are effectively built from the same chips as RAM. These tactics all operate on the principle of removing hard drive access from the critical path of any computer process. This is done on the basis of physical and temporal proximity, in other words, if you are processing data, the next piece of data you will process may be one that is near to the current data, or near to data that has recently been processed. This works well for a number of types of processing, sequential file access, database scans. It does not work well, however, for random access processes, such activities as customer relationship interactions or ATM use. Development of the existing hard drive design has continued to focus on improving elements within the overall assembly; for example platter inertia, data compression, seek and latency times which are all affected by fragmentation btw. As the intricacy of the overall assembly evolved, areas of specialization have sprung up seeking to push the technology boundaries in one component or sub-assembly. Individual sub-assemblies or components are now areas of expertise within their own right. Industries, companies and individuals have focused, exclusively at times, on development within one area. Although there have been significant developments in the areas of specialization each new development has at times been off-set by the inherent limitations of the overall design. The additive beneficial effect of the developments within specialist areas has not delivered the sum of the parts. For example, rotational speed versus inertia, or areal density and the need for increased read/write head sensitivity. As happens occasionally within a key technology it becomes more fragmented due to significant development needs within areas of specialization. The rethinking of the whole can be so disruptive as to make it both unwelcome and damaging. The new drive combines a mix of current technologies in a fundamental design paradigm shift, aimed at sidestepping a number of key technical barriers in existing hard drive performance development. Latency and seek times will be reduced to more closely match CPU cycle times, (10 to 50 ns vs. 2 to 5 ms) but, until then, you get what you have now. The design will provide data transfer rates greater than current, high performance disk drives, with further architectural potential for massively parallel data transfer rates and fundamental database access re-designs. Ongoing increases in areal density will implicitly facilitate increases in drive performance, bandwidth and data transfer rates.

0

LOL mike, very nice discourse that you copied, but it doesn't say anything about defraging. I guess some people didn't read or understood my explanation of a read operation. Oh well, I tried. Naturally certain poorly written hard drive intensive programs (CAD?) that do not enable interrupts during hard drive operations are going to be affected quite a bit. Notice that I said the 'average user'. There are going to be exceptions.

0

Oh *goodie* - we're doing essays(!) Defragging is not the holy grail so many seem to believe. It made much more of a difference on the (now antique) MFM drives running on the primitive machines of that era. I have machines (running 9x) that have not been defragged for years and seem to function well despite this act of heresy. Life is hard; it's harder if you're stupid. -John Wayne

0

LOL, thanks for the support Jboy. :-) Correction to post #14. It should have been "poorly written 'or' hard drive intensive programs.

0

Adding to it... I was using a WinXP Pro machine yesterday that had not been defragged in over a year. When I clicked the Analyze button it said it didn't need to be defragged. I'll still defrag anyway. Moving data refreshes the cluster and avoids crosslinking of files. Bryan

0

Without question, defrag is beneficial, and will improve performance to varying degrees, depending greatly on the use of the machine. WinXP/NTFS - different kettle of fish (or so I've read) Life is hard; it's harder if you're stupid. -John Wayne

0

I thought NTFS was a different fish, defrag resistant...until I read this Fragmentation and Defragmentation i_XpUser

0

Sure, (and I'm inclined to believe PCGuide), but as a '98user', my only opinion of NTFS is that it can be a pain to deal with if troubleshooting is required ; ) But, yeah, I'd read that (and this as well as this) Life is hard; it's harder if you're stupid. -John Wayne

0

you said cpu cycles werent wasted on a fragmented drive, and I said they were, that was the reason I posted that. If you will notice in my original post, I never said that defragging had to be done every few days or anything like that, I just said that it should be done on a scheduled basis and even that based on how much the PC is used. I seems as though you took that to mean that I meant you needed to defrag it every three days, that was not what I said or implied.

0

In response to the OP's question. Those load times are way too long. 25 to 45 MB files should take seconds, not minutes. While this would usually mean you need more ram, I see that you already have 256MB which is certainly enough for win98. You might need to look at background processes. A lot of programs and hardware install there utilities to run in the background whether you need them or not. These can be disabled using msconfig. Also, if you are not already using Spybot S&D and AdAware, I strongly suggest you get them to clean out the freeloaders. Insufficient HDD space can also cause these delays while windows has to swap around it paging files. CCleaner might help get rid of some of the rubbish that gathers in the corners of your hard drive. Another cause of these delays can be the CPU. If it has to process the data as it comes off the drive, obviously a faster one would help. Defrag is more helpful on slower drives and processors. With current hardware the effect of running defrag is becomming negligible. The time taken to defrag a large hard drive may never be recovered by the microseconds it may or may not save.

0

Back to OP: The defrag could not have made that much difference, possibly the CAD program did some pre-compile of the rendering on the first load. Best

0

OK mike. I think it's about time to drop this. If a person feels more comfortable defragging once a week, what the heck.

0

.. after all of that pasting?? So then, I gather that on a drive with 0% fragmentation, there would be few (if any) idle cpu cycles during a seek? (.. not really though) It just doesn't seem to be as important as many make out, is all. It used to be, sure. As far as refreshing data , yes indeed, I recall running the venerable PCTools to do that very thing... on my MFM drive - those drives shipped with a defect map indicating straight-from-the-factory disk errors. The technology has improved (a tad) since then Life is hard; it's harder if you're stupid. -John Wayne

0

agreed - see you around the forum.

0