If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#61
|
|||
|
|||
This isn't a thread, it's a duvet, of low tog :-)
The Hawthorne effect is a most useful one, and real, but not here. Implicit in higher-rpm drives are other material changes to "user experience": o Faster rpm drives often have higher data-density - good for big transfers ---- less of an impact for multiple small-data transfers (MS-IE cookies, site graphics) o Faster rpm drives often have lower seek & access times - good for "interactivity" ---- for multiple small data-transfers, seek time can be a major component Hence whilst a P-M laptop may be a desktop replacement on CPU, the laptop HD even if 7200rpm still has slow seek & access times. Hence, desktops often feel much quicker for the same CPU speed as their corresponding laptop "equivalent". Case in point, I moved from a P2-366 laptop to a Cel-2.2, benchmarks say 10x faster CPU, but all I noticed was the HD really did feel 0.3% slower. The laptop felt slower. So yes, very often the HD is the most neglected point. Increasingly people use external firewire/USB high-speed drives for their laptop replacements when stationary - to get the I/O speed back up. This becomes particularly true when you do an application benchmark such as a textual search in the Message-Body of a 540MB MS-OE dbase. On a laptop, you lose 1) all interactivity, 2) it takes ages on a laptop HD, and 3) when it's done the I/O cleanup takes longer than a mechanic. Do the same on a desktop drive of say 10,000rpm and it is much quicker. Re networks - 100Mbps per seat is only ~8-9MB/sec. o In theory, that is a small pipe compared to the outer-track SDTR of HD (40MB/sec+) ---- yet that is only true if the HD is for that person & doing peak SDTR-reads o In reality, the pipe isn't so small vs typical HD electromechanical seeks & access latency ---- MS-IE cookies, huge quantities of temp graphics, involve mainly seek v SDTR reads It is wrong to conclude the HD doesn't matter :-) o The HD in multiple small-files is doing lots of seeks ---- this gets chronic with a server serving user-profiles or multiple MS-IE temp files o The HD is just still the electromechanical problem ---- it just got moved to the other end of a pipe, the problem remains o Again, higher-rpm HD tend to have lower seek & access-times ---- so there remains a material benefit above that of rpm & rpm-based-SDTR figs Some people may not notice a central HD app/file store so much. o Often networked machines are relatively low spec o So disk I/O is less noticeable as a slow-up compared to general PC operation o We have made CPUs move 4GB/sec+ - but HDs typically avg 0.01GB/sec o Whilst rpm boosts SDTR, an equally important boost is in access time/latency Applications which use a PC/laptop like a book do not necessitate high I/O. Using a laptop to hammer out anything with lots of I/O is an exercise in frustration. Case in point: o I benchmarked the fastest laptop I could find to do some app benchmarks ---- not synthetic, but some typical scripts running apps representing my workload ---- particularly, a workload which was typical of sudden unpredictable deadlines o I repeated the same on a same spec desktop, but noisier 10,000rpm drive o I repeated the same using a bottom-of-range laptop as thin-client to 7200rpm desktop ---- vis., 2 PCs instead of 1 very expensive laptop or desktop Whilst the 2nd solution was quickest in task absolute terms, the 3rd was best for me. It completely removed the I/O based "machine crawl" re usability from the laptop, and stuck it on a separate machine at the end of a pipe. For usability, it's a step beyond the usual "choose dual processor for smoother experience of interactivity". If you have to have a single machine, higher-rpm drives make a larger difference. This still remains for lots of multiple small-file thrashing (MS-IE, multiple-apps, lots of MS-IE windows & constantly changing sites, outlook running, *.pdfs accessed). To view higher-rpm drives as just offering higher SDTR misses their other attributes. Sure, doing a Word doc & printing it doesn't need much more than a 5400rpm drive. However, people are increasingly reading a *.pdf, doing a MS-OE search, MS-OE is downloading half a truck load of SPAM, anti-virus s/w is being a dog opening Excel, they are bringing up a contact book & searching for an address, all at the same time :-) If you throw MS-IEs prolific micro-file characteristics, things can slow substantially. Higher drive rpm, higher densities *might* also mean the heads move less since the data density is so much higher (120GB drive v 20GB) that even fragmentation is less. Moving a hard-drive head around is monumentally slower than multi-GB/sec CPUs can eat data. The faster CPUs get, the faster HDs will need to get - but a lot of that speed up has been lost due to micro-file-growth, O/S bloat & graphicalisation of everything with XP bringing up previews of 500 file folders whilst you just want a filename or such. IT has a delightful ability at degrading 90% of every speed improvement, or focusing on the speed improvements least beneficial to the actual task at hand. In some ways rpm may seem to be this - since head movement time is often dominant, but that is theory versus the reality where higher-rpm drives typical have benefits far beyond basic rpm / SDTR. Doing an I/O baseline of typical user segments is interesting, you'll find that the HD is an often overlooked area for many of them - particularly when deadlines hit or for the key tasks where a user, or customer, is waiting for an answer and your I/O is crawling. I don't think customer service centres have enough multi-TB RAM Opterons :-) Sure, it's not available yet, but it would beat listening to muzak whilst I/O crawls along... .... the problem isn't the pipe, it is still that lump of electromechanical latency at its end. (That's a HD for anyone wondering if I mean the droids reading off a screen - badly). -- Dorothy Bradbury www.stores.ebay.co.uk/panaflofan for quiet Panaflo fans & other items http://homepage.ntlworld.com/dorothy...ry/panaflo.htm (Free Delivery) |
#62
|
|||
|
|||
|
#63
|
|||
|
|||
On Fri, 20 Aug 2004 06:45:45 GMT, Andy wrote:
On 18 Aug 2004 11:42:10 -0700, (Darren Harris) wrote: Can anyone tell me if hard drive spindle speed is an important factor to consider when purchasing a hard drive? Or should I just concentrate on average latency, average access, and max. full seek time? Latency is the time it takes for the disk to spin half a revolution, so the latency of 7200 rpm drives is the same. I meant average latency. I ask because two hard drives with a data rate of 80mps can differ in these other respects. Thanks a lot. Darren Harris Staten Island, New York. |
#64
|
|||
|
|||
On Wed, 18 Aug 2004 19:21:58 GMT, CJT put
finger to keyboard and composed: Darren Harris wrote: Can anyone tell me if hard drive spindle speed is an important factor to consider when purchasing a hard drive? Or should I just concentrate on average latency, average access, and max. full seek time? I ask because two hard drives with a data rate of 80mps can differ in these other respects. Thanks a lot. Darren Harris Staten Island, New York. For most people, desktop hard drives are hardly ever accessed anyway, so speed is pretty irrelevant. Unless you're setting up a server that will be accessed by many, go for the cheapest drive per byte stored. That's my view as well, at least for my Internet PC. However, I believe my multimedia PC *may* benefit from a faster HD, depending on how I use it. Performance issues aside, I expect that a slower HD will have reliability benefits, all things being equal, due to less heat and reduced bearing wear. Does anyone have any data to confirm or refute this? On the question of performance, I took a 147KB pure text file (ie no HTML formatting) and opened it with both my browser (Opera 7.54) and Wordpad. Wordpad opened the file within the blink of an eye, while my browser required some three seconds before it was able to "render" it. There was no noticeable difference whether the same file was opened from an old 1.2GB Maxtor, or from my 13GB Seagate. Clearly the bottleneck in this case is my browser, not my HD. BTW, my Internet PC is a lowly socket 7 Cyrix MII-333 with 128MB SDRAM. Perhaps someone can perform a more substantial test using a P4 or Athlon. Alternatively, if someone can point me to a webpage with "a thousand little files" (as claimed elsewhere), I would be happy to see how my two HDs handle it. In the meantime I have done some R/W timing tests in a Win98se DOS box on both my HDs. In these tests I compare the times taken to copy a 1MB file and sixteen 64K files on drives C: (Seagate 13GB) and D: (Maxtor 1.2GB). Write-behind caching is disabled. The results below show no significant difference for the 1MB file (0.55s vs 0.44s), but the 16 smaller file transfers require 2.25 vs 1.53 secs. Of course these execution times are for both reading *and* writing, so we should probably halve the figures for read access alone. Doing this gives us a difference of only 0.36 sec, which is barely noticeable. I suppose a more accurate test would involve copying from HD to RAM disk, but I'm not sure how to create a RAMdrive in a Win DOS box. ================================================== ================ C:\WIN98SE\TEMP\testdir Directory of C:\WIN98SE\TEMP\test 64K TXT 65,536 08-20-04 5:16p 64K.txt 1MB TXT 1,048,576 08-20-04 5:13p 1MB.txt TEST BAT 364 08-20-04 5:29p test.bat ================================================== ================ C:\WIN98SE\TEMP\testtype test.bat @echo off echo Start 1MB copy echo.|time copy 1MB.txt 1MB.bak nul echo End 1MB copy echo.|time echo. echo Start 16 x 64K copies echo.|time for %%v in (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16) do copy 64K.txt %%v.bak nul echo End 16 x 64K copies echo.|time del 1MB.bak nul for %%v in (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16) do del %%v.bak nul ================================================== ================ C:\WIN98SE\TEMP\testtest Start 1MB copy Current time is 5:38:15.95p Enter new time: End 1MB copy Current time is 5:38:16.39p elapsed time = 0.44s Enter new time: Start 16 x 64K copies Current time is 5:38:16.45p Enter new time: End 16 x 64K copies Current time is 5:38:17.98p elapsed time = 1.53s Enter new time: ================================================== ================ D:\WINDOWS\TEMP\testtest Start 1MB copy Current time is 5:45:30.80p Enter new time: End 1MB copy Current time is 5:45:31.35p elapsed time = 0.55s Enter new time: Start 16 x 64K copies Current time is 5:45:31.40p Enter new time: End 16 x 64K copies Current time is 5:45:33.65p elapsed time = 2.25s Enter new time: ================================================== ================ - Franc Zabkar -- Please remove one 's' from my address when replying by email. |
#65
|
|||
|
|||
kony wrote:
On Wed, 18 Aug 2004, CJT wrote: For most people, desktop hard drives are hardly ever accessed anyway, so speed is pretty irrelevant. Unless you're setting up a server that will be accessed by many, go for the cheapest drive per byte stored. Nonsense, everything the system is running is loaded from HDD, and the speed is directly effected by speed of that hard drive. A Celeron 800 with a WD Raptor HDD will feel faster for everday use than a P4 3.2GHz with a budget-grade 40GB HDD. I think you're right. In my experience, upgrading an older machine with a modern HD makes a much more noticeable improvement in system response than a CPU upgrade does. |
#66
|
|||
|
|||
CJT wrote:
I guess we'll just have to disagree. I've stated my position. If it makes you feel good to have a faster disk, and you've convinced yourself you can detect the difference, that's ok with me. There are people who claim they can detect the difference when they change power cords on their stereos, too. Hardly analogous, moron. |
#67
|
|||
|
|||
Andy wrote:
On Fri, 20 Aug 2004 06:45:45 GMT, Andy wrote: On 18 Aug 2004 11:42:10 -0700, (Darren Harris) wrote: Can anyone tell me if hard drive spindle speed is an important factor to consider when purchasing a hard drive? Or should I just concentrate on average latency, average access, and max. full seek time? Latency is the time it takes for the disk to spin half a revolution, so the latency of 7200 rpm drives is the same. I meant average latency. If you want to be pedentic, _average_ latency is the time it takes for the disk to spin the data half the distance between heads, which on currently available drives which have a single head per platter means "half a revolution", while "latency" is the time it takes for the disk to spin the data from wherever it is when the head stabilizes to where the head is located. Average latency depends on the number of heads per platter and the RPM and nothing else. I ask because two hard drives with a data rate of 80mps can differ in these other respects. Thanks a lot. Darren Harris Staten Island, New York. -- --John Reply to jclarke at ae tee tee global dot net (was jclarke at eye bee em dot net) |
#68
|
|||
|
|||
I think you're right. In my experience, upgrading an older machine
with a modern HD makes a much more noticeable improvement in system response than a CPU upgrade does. you are absolutely out on 'cloud 9' "chrisv" wrote in message ... kony wrote: On Wed, 18 Aug 2004, CJT wrote: For most people, desktop hard drives are hardly ever accessed anyway, so speed is pretty irrelevant. Unless you're setting up a server that will be accessed by many, go for the cheapest drive per byte stored. Nonsense, everything the system is running is loaded from HDD, and the speed is directly effected by speed of that hard drive. A Celeron 800 with a WD Raptor HDD will feel faster for everday use than a P4 3.2GHz with a budget-grade 40GB HDD. |
#69
|
|||
|
|||
"David Maynard" wrote in message
Folkert Rienstra wrote: "David Maynard" wrote in message CJT wrote: David Maynard wrote: CJT wrote: kony wrote: On Wed, 18 Aug 2004 21:29:03 GMT, CJT wrote: Alright, I'll concede there, but a 7200 will still provide a very noticable performance increase over a 5400. Not just in drive benchmarks, but in day to day computer usage. I think the devil will be in the details. If you mostly just browse the Web, I doubt your disk will be exercised much. If you do a lot of video editing, you probably want something pretty fast -- most likely RAID. There's a whole range in between (and perhaps beyond). Clueless. Browser caches everything to disk, and reloads it all from this cache until pages are refreshed unless brower is changed from defaults. Och, the times that drives were slower than an internet connection, those were the times. You've mixed replying to someone else inside of a reply you indicate at the top, by the order of posters listed, is to me. And that (a comment, not a reply) confuses the hell out of you. Sounds like purpose fulfilled, when the controversy in the statement fully eludes you. BTW, what makes you think that comments made to your post is for your consumption only? The only time HDD speed doesn't matter much is when system has A) Excess system memory to cache files B) Limited multitasking so files are never flushed from this cache. [snip] And that's before we even get to doing a couple of things simultaneously and/or burning CD/DVDs, playing videos/MP3s, etc. I have yet to see a user who didn't notice the difference between a 15 gig 5400 RPM drive and a 120 gig 7200 RPM drive. The later is simply faster. And I have yet to see a user who won't notice the difference between a 15 gig 7200 RPM drive and a 120 gig 5400 RPM drive. The latter is simply faster. However, the 15GB/7200rpm drive may still load an internetpage (from cache), existing of a thousand puny files, a bit faster than it's much newer 120GB/5400rpm competitor. Well, you've mixed apples and oranges in not only the messages you're replying to, The apples and oranges are obviously all yours when you compare a 4-year old dimpled 5400rpm apple with a current fresh 7200rpm orange. mixing someone else's in with mine, but in the supposed 'argument'. Whatever floats your brain, err, boat. When I said, "it's simply faster" I meant the 'faster' drive *is* faster by every measurable standard.. And I said that your dimpled apple may still beat your fresh orange in some respect. But I can't tell what you mean by it as you say 'faster' in one case and then say precisely the opposite in the other, as if one is a 'fake' I was only overly generalizing the statement in the same way that you overge- neralized yours, there obviously was a reason for why I picked the same wording. If you have a problem with that then you have a problem with your own statement. "faster" with the other a real but 'irrelevant' "faster." Yeah, never mind the example that I gave. Your 'faster' is purely based on sequential reading, i.e. STR. 'Faster' is also having low access time, when reading random small files. The difference in latency time for a 5400 and 7200rpm drive is 1.4 ms. With 1000 files (of lets say 5kB each) the new 5400 rpm drive is 1.4 sec 'slower' than your old 7200rpm at same data rate and seektime. At about 0.1 s to 0.2 s actual data transfer time in about 14 seconds (1000*14ms) of total load time no speedup of STR will ever make good on that 1.4 second difference. Let me be clear about it. My comment was that a (significantly) faster drive, regardless of how it achieves the speed (RPM, linear density [which I explained previously], etc), is noticed by the user in program load times, at the least, whether the system 'needs' it to 'keep up' with some notion of 'average load' or not. I believe I just proved you wrong. When the excess latency time exceeds the actual transfer time then there is no way of making good with STR. There is no such thing as negative time. |
#70
|
|||
|
|||
On Fri, 20 Aug 2004 18:39:31 +1000, Franc Zabkar
put finger to keyboard and composed: In the meantime I have done some R/W timing tests in a Win98se DOS box on both my HDs. In these tests I compare the times taken to copy a 1MB file and sixteen 64K files on drives C: (Seagate 13GB) and D: (Maxtor 1.2GB). Write-behind caching is disabled. Oops, I forgot to take read caching into account. The results below show no significant difference for the 1MB file (0.55s vs 0.44s), but the 16 smaller file transfers require 2.25 vs 1.53 secs. Of course these execution times are for both reading *and* writing, so we should probably halve the figures for read access alone. Doing this gives us a difference of only 0.36 sec, which is barely noticeable. I suppose a more accurate test would involve copying from HD to RAM disk, but I'm not sure how to create a RAMdrive in a Win DOS box. I also forgot to defrag my drives. Here are my latest results which compare the read and write performance of my two *defragged* drives. A ramdrive (G is used for both tests. It was created by adding the following lines to my config.sys: DEVICE=C:\WIN98se\HIMEM.SYS DEVICE=C:\WIN98se\RAMDRIVE.SYS 2048 /E The system was rebooted before each test to ensure that all caches were flushed. I measured no reduction in performance when DMA was disabled for each HD in Device Manager, yet this DMA parameter does affect benchmark S/W such as Wintune. I also observed that the older 1.2GB Maxtor reads faster than the newer 13GB Seagate. shrug I believe the results show that HD performance is not an issue when transferring files to and from your browser's cache, except in the case of severely fragmented file systems. ================================================== ================ Results of read test after defragmentation ------------------------------------------ C:\WIN98SE\TEMP\testfileread Start 1MB copy Current time is 7:20:34.04a Enter new time: Current time is 7:20:34.54a (elapsed time = 0.50s) Enter new time: End 1MB copy Start 16 x 64K copies Current time is 7:20:34.59a Enter new time: Current time is 7:20:35.20a (elapsed time = 0.61s) Enter new time: End 16 x 64K copies D:\WINDOWS\TEMP\testfileread Start 1MB copy Current time is 7:28:17.28a Enter new time: Current time is 7:28:17.72a (elapsed time = 0.44s) Enter new time: End 1MB copy Start 16 x 64K copies Current time is 7:28:17.78a Enter new time: Current time is 7:28:18.27a (elapsed time = 0.49s) Enter new time: End 16 x 64K copies ================================================== ================ Results of write test before defragmentation -------------------------------------------- C:\WIN98SE\TEMP\testfilewrit Start 1MB copy Current time is 10:03:43.47p Enter new time: Current time is 10:03:44.78p (elapsed time = 1.31s) Enter new time: End 1MB copy Start 16 x 64K copies Current time is 10:03:45.61p Enter new time: Current time is 10:03:47.53p (elapsed time = 1.92s) Enter new time: End 16 x 64K copies D:\WINDOWS\TEMP\testfilewrit Start 1MB copy Current time is 10:05:05.91p Enter new time: Current time is 10:05:06.51p (elapsed time = 0.60s) Enter new time: End 1MB copy Start 16 x 64K copies Current time is 10:05:07.06p Enter new time: Current time is 10:05:08.82p (elapsed time = 1.76s) Enter new time: End 16 x 64K copies ================================================== ================ Results of write test after defragmentation ------------------------------------------- C:\WIN98SE\TEMP\testfilewrit Start 1MB copy Current time is 6:53:56.70a Enter new time: Current time is 6:53:57.08a (elapsed time = 0.38s) Enter new time: End 1MB copy Start 16 x 64K copies Current time is 6:53:57.85a Enter new time: Current time is 6:53:59.23a (elapsed time = 1.38s) Enter new time: End 16 x 64K copies D:\WINDOWS\TEMP\testfilewrit Start 1MB copy Current time is 6:55:39.19a Enter new time: Current time is 6:55:39.68a (elapsed time = 0.49s) Enter new time: End 1MB copy Start 16 x 64K copies Current time is 6:55:40.78a Enter new time: Current time is 6:55:42.54a (elapsed time = 1.76s) Enter new time: End 16 x 64K copies ================================================== ================ Directory of C:\WIN98SE\TEMP\test .. DIR 08-20-04 5:14p . ... DIR 08-20-04 5:14p .. 64K TXT 65,536 08-20-04 5:16p 64K.txt 1MB TXT 1,048,576 08-20-04 5:13p 1MB.txt FILEWRIT BAT 593 08-20-04 9:53p FILEWRIT.BAT FILEREAD BAT 374 08-20-04 8:27p fileread.bat 64K1 BAK 65,536 08-20-04 5:16p 64k1.bak 64K2 BAK 65,536 08-20-04 5:16p 64k2.bak 64K3 BAK 65,536 08-20-04 5:16p 64k3.bak . . . . . . 64K16 BAK 65,536 08-20-04 5:16p 64k16.bak ================================================== ================ C:\WIN98SE\TEMP\testtype fileread.bat @echo off echo. echo Start 1MB copy echo.|time copy 1MB.txt g:\1MB.bak nul echo.|time echo End 1MB copy del g:\1MB.bak nul echo. echo Start 16 x 64K copies echo.|time for %%v in (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16) do copy 64K%%v.bak g: nul echo.|time echo End 16 x 64K copies for %%v in (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16) do del g:\64k%%v.bak nul echo. ================================================== ================ C:\WIN98SE\TEMP\testtype filewrit.bat @echo off echo. echo Start 1MB copy copy 1MB.txt g: nul echo.|time copy g:\1MB.txt 1MB.tmp nul echo.|time echo End 1MB copy del 1MB.tmp nul del g:\1MB.txt nul echo. echo Start 16 x 64K copies for %%v in (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16) do copy 64K%%v.bak g:\ nul echo.|time for %%v in (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16) do copy g:\64K%%v.bak 64K%%v.tmp nul echo.|time echo End 16 x 64K copies for %%v in (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16) do del 64k%%v.tmp nul for %%v in (1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16) do del g:\64K%%v.bak nul echo. ================================================== ================ - Franc Zabkar -- Please remove one 's' from my address when replying by email. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
ATA100 hard drive not recognized when PS/2 mouse is not attached | S. Lipson | Homebuilt PC's | 2 | July 27th 04 09:55 PM |
Large Hard Drive & BIOS upgrade problems | Lago Jardin | Homebuilt PC's | 1 | June 12th 04 02:08 PM |
Hard drive heating up | Kipper | Homebuilt PC's | 4 | May 22nd 04 10:37 PM |
Help needed: problem installing XP on new system | GJ | General | 26 | March 1st 04 11:04 PM |
Multi-boot Windows XP without special software | Timothy Daniels | General | 11 | December 12th 03 06:38 AM |