|
|
|
|
| Author |
Message |
Pauldoo Guest
|
Posted: Tue May 15, 2007 1:39 pm Post subject: Concurrent disk accesses slow in Windows XP |
|
|
Hi,
I have noticed very slow I/O performance in Windows XP while
performing certain tasks, and I have been able to write a small test
which reliably demonstrates the problem. I'd like to explain this
problem and ask if anyone knows a workaround or set of tweaks to
improve the situation.
I create two large files (each too large to fit in memory, so they are
not entirely cached), and attempt to read them back. When I read the
files from beginning to end, one after the other, I get certain
performance (around 35 MiB/s). When I change to reading each file in
the same way, but read both files concurrently using threads, the
performance drops to something miserable (around 1-2 MiB/s).
While running the latter test I can hear my hard disk thrash heavily,
it is clearly seeking backwards and forwards reading very little after
each seek. The same test under Linux (same hardware) results in the
parallel reads running only slightly slower than the sequential
(around 32 MiB/s total throughput), and the disk is clearly seeking
much less frequently. The same test on Mac OS X (different hardware)
has the same characteristic as Linux.
I have noticed this being a problem for real tasks. If I run any I/O
intensive operation in the background while attempting any moderate I/
O in the foreground the performance is unbearable. This typically
happens while compiling a large codebase.
My setup is Windows XP SP2 with a bog standard SATA disk and 2GiB of
RAM..
Does anyone know of any settings or tweaks I can apply to mitigate
this problem? |
|
| Back to top |
|
 |
Fix your Windows Problems - FAST.
FREE Safe Scan Registry Check. Locate & Fix Errors in Minutes!
|
|
Arno Wagner Guest
|
Posted: Tue May 15, 2007 1:39 pm Post subject: Re: Concurrent disk accesses slow in Windows XP |
|
|
In comp.sys.ibm.pc.hardware.storage Pauldoo <paul.richards@gmail.com> wrote:
| Quote: | Hi,
I have noticed very slow I/O performance in Windows XP while
performing certain tasks, and I have been able to write a small test
which reliably demonstrates the problem. I'd like to explain this
problem and ask if anyone knows a workaround or set of tweaks to
improve the situation.
I create two large files (each too large to fit in memory, so they are
not entirely cached), and attempt to read them back. When I read the
files from beginning to end, one after the other, I get certain
performance (around 35 MiB/s). When I change to reading each file in
the same way, but read both files concurrently using threads, the
performance drops to something miserable (around 1-2 MiB/s).
While running the latter test I can hear my hard disk thrash heavily,
it is clearly seeking backwards and forwards reading very little after
each seek. The same test under Linux (same hardware) results in the
parallel reads running only slightly slower than the sequential
(around 32 MiB/s total throughput), and the disk is clearly seeking
much less frequently. The same test on Mac OS X (different hardware)
has the same characteristic as Linux.
I have noticed this being a problem for real tasks. If I run any I/O
intensive operation in the background while attempting any moderate I/
O in the foreground the performance is unbearable. This typically
happens while compiling a large codebase.
My setup is Windows XP SP2 with a bog standard SATA disk and 2GiB of
RAM..
Does anyone know of any settings or tweaks I can apply to mitigate
this problem?
|
The issue here is that UNIXes and UNIX-like OSes (such as Linux)
have long been optimized for multiple users running processes in
paralell. As an effect, reads are optimized and extensiv prefetching
is done. After all, reading a bit more cost not much more time, but the
seek is slow.
Microsoft is (again) lagging behind by decades with its technology.
They still expect you to run one thing only on your box.
The only reasonable solution I see is to put up separate disks
for separate tasks, so that only one process is reading per disk.
Or, alternatively, do your work on Linux ;-)
Arno |
|
| Back to top |
|
 |
|
|
| |