Very slow SATA and eSata peformance

[Paul]

Smarty wrote:
Smarty wrote:


Even advice to shove you head up a dead bear's arse ?

Pathetic...........

Yes, rodless did the only thing he knows: insult via profanity.


Since these drives including the fastest one I own, a WD
Velociraptor, can sustain read/write transfers at several times the
rate I am experiencing when configured with the right RAID
controller, I am reasonably certain that the drive is inherently
capable of much faster performance than I am experiencing with my
present SATA controllers.

The "simple" explanation would be that (some) SATA controllers
underperform the SATA specs by a considerable degree, and the 5
different controller chipsets I happen to be using all suffer from
this shortfall. Kinda' hard to believe......

I just ventured into eSATA. I found out the [relatively] hard way
via
an allegedly bad cable and an RMA. However, the fine techies at
IcyDock set me straight!

It turns out that if a SATA controller (e.g., the ICH9R) does not
have
hot-swap capability, the eSATA device must be seen and enumerated by
the BIOS at boot-up. Otherwise you run into those speed problems you
noticed, if the device is recognized at all...

Try this. Set up and power up all eSATA devices on all your
computers.
Reboot them all. Check the BIOS screens as they falsh by (if
possible)
to see if all the eSATA devices are enumerated. Retest the transfer
rates. You might be pleasantly surprised.


I did indeed have the very problem arise which you refer to, and
one of my machines (a Dell XPS420) mis-manages the one and only
external eSATA port it has just as you describe. I added my own
SATA controller cards rather than suffer with the (yet unfixed)
Dell issue, and have not seen this type of slowdown since.

The drives which are internal to the computers are present at boot
time, are correctly enumerated by the BIOS when the machine boots,
and still have this same speed problem. My external eSATA ports,
provided by add-in cards, are actually capable of hot-swap, and do
not to seem to care whether the drive was there or not at boot time
since they (usually) mount and dismount external eSATA drives
whenever I chose to. The "Safely Remove" feature seems to work
properly.

Most important is the fact that the transfer speeds stay at this 25
MByte/sec rate regardless of whether the drive was there at boot
time, added later on, dismounted and then remounted, etc.

It is most frustrating to me since my USB2 drives perform at about
the same transfer rates..........25 Mbytes/sec give or take. This
is NOT what I was expecting SATA or eSATA to provide, and hence my
post to this newsgroup.


Have you tested any drives with HDTune from hdtune.com ?

Paul



Yes Paul, and HD Tune shows the average transfer rates to the drives
being in the range of 40 to 70 MBytes/sec maximum transfer rates can
get up to 85 or 90 Mbytes/sec, the minimum transfer rates as low as
10-15 Mbytes/sec.)

I'm quite convinced that the drives and controllers, if used only one
at a time, are working correctly. The problem is using a pair of
drives to do useful work, moving a large file from one drive to another.

When you test disk to disk transfer, are large files involved ? Or a
lot of small files ? For benchmarking purposes, you'd want to avoid a
lot of random head movement.

Maybe as a test case, you could try running HDTach and HDTune at the
same time, focused on different hard drives. That might take Windows
out of the picture, as the access there is raw, rather than through a
file system.

In the spirit of general debugging, maybe you could download Process
Explorer from sysinternals.com, and keep an eye on system operation,
while one of your disk to disk transfers is running. When performance
drops to 25MB/sec from one disk to the other, see if any other stats
change at that point in time.

Paul

My file transfer issue has come up with the only files I frequently
transfer, approximately 6 GB size. The same relative lack of speed shows
up for smaller transfers as well, but it only bothers me when I have to
wait an appreciable amount of time, and thus the smaller transfers which
are typically done in much less than a minute do not concern me if
though they also show about the same transfer rates.

I really like the suggestion of using Process Explorer to see what may
be happening behind the scenes here. I will try that is see what I can
find. I have been pruning the background 'crap' using the Task Manager
and other tools so I have a relatively short list of services and
processes running, but I have not really studied what the actual
run-time contention for the cores may be.

I will report back with any significant findings, and thank you Paul for
the helpful suggestion.

Normally, I run a pair of PATA drives on my current computer.

But I do have a pair of SATA drives, identical 250GB drives, which
I keep as spares. They do 95MB/sec at the start of the disk, and 60MB/sec
near the end.

I fired up HDTune, and benchmarked one of the drives, and got the expected
read benchmark curve.

Next, I tried a test, where I ran HDTach against the second drive. HDTach
is a bit different, in that during the testing phase, no graph is shown.
HDTach does some other tests first, before it does sustained transfer
testing.

http://www.simplisoftware.com/Public/index.php?request=HdTach

I waited until HDTach hit the last stage of testing, before clicking
the start button for HDTune (so both drives would be entering sequential
testing at the same moment). Instead of hitting 95MB/sec at the
beginning of the disk, HDTune dropped to 89MB/sec. Gradually, as the
test progressed, the rate rose a little bit, so the graph has
a mild "hump" in the middle of the transfer curve.

HDTach transfer curve hit about 95MB/sec. The two programs do not
agree on transfer rate, and they always differ in their results.

The effect of one test on the other was minor. a 6MB/sec drop
from the normal 95MB/sec rate.

During the test, processor utilization is relatively low. About
6% perhaps.

At the instant that HDTach finishes its sustained test, and presents
the graph, HDTach seems to go into a loop, and the CPU hits 50%
utilization (as a dual core). That had no effect on the graph
the other program was drawing. If I click the "Done" button on
HDTach, its processor usage drops back to zero.

The chipset involved, is a VIA chipset. Not one you'd expect to
have flawless behavior. The Southbridge used for this test,
is VT8237S, which is the only Southbridge VIA makes that has
the ability to run the disk at SATA II (300MB/sec) rates. The
burst transfer benches at about 154MB/sec, so not that good as
far as bursts go. Some other chipsets manage 200MB/sec burst
rating, out of the theoretical 250MB/sec promised by the
raw data rate on the cable. Since packets are being sent
across the cable, there should be some amount of overhead.

I cannot do any file system related tests right now, because
of the two disks in question, one is a Linux only drive (has
Debian on it), while the other has Windows file systems. I'm
pretty sure, I'd see nowhere near that transfer rate of 95MB/sec,
if I transferred actual files.

While the operating system may support overlapping file I/O,
I'm not sure the code that does file copying does that. So
that could cut the I/O in half right there (serializing the
read and write phases). That still would not account for all
of the slowdown you're seeing.

Paul

 

[Paul]

While the operating system may support overlapping file I/O,
I'm not sure the code that does file copying does that. So
that could cut the I/O in half right there (serializing the
read and write phases). That still would not account for all
of the slowdown you're seeing.

Paul

OK, I moved the partitions around on my two PATA disks,
so I could do some testing. I have to apologize to the
Microsoft people, because indeed the file I/O is overlapped
when a disk copy is between different disks.

I created a couple 5GB partitions. I used 2GB and 4GB test files,
since the 2GB one is larger than my available memory, and prevents
the system file cache from affecting the results.

HDTune reports about 73MB/sec and 74MB/sec or so, at the beginning
of the two disks. The two test partitions fall into that area,
so I know what the physical capabilities are.

If I copy with either the DOS copy, or the Windows drag and
drop copy, or via the robocopy program, the performance is
74MB/sec during the transfer (timed with a watch with second
hand display). So one disk reads at 74MB/sec and the other
disk writes at 74MB/sec.

I also tried with 4GB files.

I tried FAT32 partitions. I tried NTFS partitions. I got the
same results. No slowdown.

I tried one other test case, which is copying the 2GB file to
the same partition, and the results were 27.9MB/sec. There
was audible seek noise as well.

So if you were copying files from partitions on the same
disk, then expect a slowdown. If on different disks, I
can't see anything here as evidence of a slowdown. So the file
I/O overlaps and works good.

To create the test files, I used fsutil.

fsutil file createnew testnum1.bin 2147483648

When you do that on FAT32, it takes about 30 seconds to create
the file. Which means it is really writing the file. If you
do it on NTFS, the program cheats and creates a sparse file.
To "un-sparse" it, you have to copy it to the other disk, and
then back again. Not that it made any difference. I even
timed the first copy, while the source file was still sparse,
and it still took the same time to copy disk to disk, because
the destination disk is still a limit.

I think you should go back to HDTune, and run the benchmark
on any disk you're seeing a slowdown on. If you see a lot of
downward "glitches" in the transfer curve, those are spared out
sectors. On one of my test disks, I have some spared sectors in
the test area. So during the test, there is a slight dip for a
few seconds, as the heads pass over the affected area. I use
the Performance window in Administrative Tools, and add a couple
Physical_Disk counters. The write bytes/sec and read bytes/sec
counters. I set the graph Y axis to 10000 full scale, which
equals 100MB/sec. Using that, I can actually monitor the
transfer, and see the tiny dip due to bad sectors that have
been replaced by spare sectors.

So something else must be interfering with your work. Do you
have any AV or malware tools ? Any chance they're busy ?

Paul

 

[Smarty]

Not really.


Sure, but with appropriate RAID on that system, you still dont
need to furiously copy large files around. You just play them
from there without moving them around before you play them.

Rod - I have video content sitting on 3 different computers in various
locations on 3 floors of my house, and want to consolidate them onto a
single computer where my home theater is located. I see no point in trying
to defend my choice or justify to you why I prefer to have them
consolidated. I furthermore see no profit in debating the relative merits of
this with you.

Yeah, I prefer it myself.


Yeah, like I said, the OS isnt really optimised for fast file copying,
essentially because it makes no sense to furiously copy large files
around. Thats best left to the apps like backup that does much of that.




Essentially because its not optimised for that sort of thing.

Paul's experiments and results seem to directly contradict your opinion /
comments. I will be doing more testing after today to see what I need to do
to achieve similar faster speeds, but it now appears that Vista is not
neccesarily the culprit at all either......

 

[Smarty]

OK, I moved the partitions around on my two PATA disks,
so I could do some testing. I have to apologize to the
Microsoft people, because indeed the file I/O is overlapped
when a disk copy is between different disks.

I created a couple 5GB partitions. I used 2GB and 4GB test files,
since the 2GB one is larger than my available memory, and prevents
the system file cache from affecting the results.

HDTune reports about 73MB/sec and 74MB/sec or so, at the beginning
of the two disks. The two test partitions fall into that area,
so I know what the physical capabilities are.

If I copy with either the DOS copy, or the Windows drag and
drop copy, or via the robocopy program, the performance is
74MB/sec during the transfer (timed with a watch with second
hand display). So one disk reads at 74MB/sec and the other
disk writes at 74MB/sec.

I also tried with 4GB files.

I tried FAT32 partitions. I tried NTFS partitions. I got the
same results. No slowdown.

I tried one other test case, which is copying the 2GB file to
the same partition, and the results were 27.9MB/sec. There
was audible seek noise as well.

So if you were copying files from partitions on the same
disk, then expect a slowdown. If on different disks, I
can't see anything here as evidence of a slowdown. So the file
I/O overlaps and works good.

To create the test files, I used fsutil.

fsutil file createnew testnum1.bin 2147483648

When you do that on FAT32, it takes about 30 seconds to create
the file. Which means it is really writing the file. If you
do it on NTFS, the program cheats and creates a sparse file.
To "un-sparse" it, you have to copy it to the other disk, and
then back again. Not that it made any difference. I even
timed the first copy, while the source file was still sparse,
and it still took the same time to copy disk to disk, because
the destination disk is still a limit.

I think you should go back to HDTune, and run the benchmark
on any disk you're seeing a slowdown on. If you see a lot of
downward "glitches" in the transfer curve, those are spared out
sectors. On one of my test disks, I have some spared sectors in
the test area. So during the test, there is a slight dip for a
few seconds, as the heads pass over the affected area. I use
the Performance window in Administrative Tools, and add a couple
Physical_Disk counters. The write bytes/sec and read bytes/sec
counters. I set the graph Y axis to 10000 full scale, which
equals 100MB/sec. Using that, I can actually monitor the
transfer, and see the tiny dip due to bad sectors that have
been replaced by spare sectors.

So something else must be interfering with your work. Do you
have any AV or malware tools ? Any chance they're busy ?

Paul

These results and your prior post really have me intrigued, and I will be
spending some serious time researching this after I fulfill my family
obligations today (Sunday). I am possibly suffering some penalty for
background processing which I have been unaware of, and will take a look
with msconfig to disable all but the most essential processes to see if this
helps. My drives can and do achieve speeds in the HD Tune tests as high as
75 MBytes/sec read/write as average speed for some drives, and I will trying
pruning the list of processes and services carefully and report back late
today or possibly early tomorrow on my results.

Thanks again Paul for taking the time to conduct your tests and report your
results. These seem to be guiding me in the right direction.

 

[Mike Ruskai]

It's mostly an issue of cosmetics and future maintenance Rod. I strongly
prefer to have a single cabinet with 4 drives, each with a terabyte, rather
than spreading the files around on a lot of drives. It allows for much
easier backups, power management, etc.

I have just such a setup here, which I use for disc-based backups. It's an
Addonics mini drive tower with four 1.5TB Seagate 7200.11 units. That tower
has several connector options, and I went with four individual eSATA ports.
They are connected to my backup server via a 8x PCIe "RAID" card with four
external ports. The server runs linux, and the drives are striped together in
software (no redundancy, since the original data is the backup for the
backup).

The array has a sustained transfer rate of about 450MB/sec. Copying to and
from itself, the rate falls to around 70MB/sec. I have scripts that assemble
the array and mount the drive on demand, so if no backup is active, I can yank
the tower without any delay. SATA hotswap actually works in linux, too
(doesn't even matter if it's eSATA or not).

So that's 5.457TB of storage in a neat package with excellent transfer speed.
If you want redundancy, you could use four 2TB drives in a software RAID 5
configuration (which also works perfectly fine in linux). Write performance
would drop to about that of a single drive (that's the nature of RAID 5), and
read performance would go down by 25%, but it'd still be considerably faster
than what you're experiencing now.

 

[Mike Tomlinson]

Yes Paul, and HD Tune shows the average transfer rates to the drives being
in the range of 40 to 70 MBytes/sec maximum transfer rates can get up to 85
or 90 Mbytes/sec, the minimum transfer rates as low as 10-15 Mbytes/sec.)

Those look ok to me, not wonderful but believable. Are you using the
drives in AHCI or IDE emulation mode?

If you use a PCI plug in card you will never see transfer speeds in
excess of about 100MB/s since you are limited by the PCI bus.

The problem is using a pair of drives to do
useful work, moving a large file from one drive to another.

Rather suggests to me that the bottleneck (or fault) is elsewhere.

 

[Mike Tomlinson]

In this specific case, I would be reading one drive
at 66 Mbytes per second and writing the other at the same speed. I

Not simultaneously, you won't. It's read chunk from disc A -> memory ->
write to B and repeat until finished.

 

[Mike Tomlinson]

but this very same system running Vista is somehow
reading the C drive and writing the 61 GB output file at a rate of 3 GB per
minute, roughly 3 times the speed which Vista takes to do a simple file
copy.

File copy in Vista is broken. Just google the subject for more info
that you ever wanted to know.

 

[Rod Speed]

Smarty wrote

Rod - I have video content sitting on 3 different computers in various
locations on 3 floors of my house, and want to consolidate them onto a single computer where my home theater is
located.

Yes, but once you have them on the single computer, you dont
copy them around anymore. Or are you saying that you plan to
continue to have them on 3 different computers and a single
computer in the future ? Whats the point of using that approach
when you end up with the file copying speed problem ?

I see no point in trying to defend my choice or justify to you why I prefer to have them consolidated. I furthermore
see no profit in debating the relative merits of this with you.

If you dont copy files around in the future, it doesnt
matter how long it takes to consolidate the files
onto one computer. Once its done, its academic.

Paul's experiments and results seem to directly contradict your opinion / comments.

And your own dont. Yours are more useful because its the total time to
copy the file using a stopwatch etc that matters, not what HDTunes shows.

I will be doing more testing after today to see what I need to do to achieve similar faster speeds, but it now appears
that Vista is not neccesarily the culprit at all either......

Doesnt explain why True Image does it a lot faster than Vista does
when you measure the only thing that matters, time to do the job.

 

[Paul]

And your own dont. Yours are more useful because its the total time to
copy the file using a stopwatch etc that matters, not what HDTunes shows.

If you read my test results, they were done with a stopwatch. The results
of real file transfers were compared to HDTune results, and the results
are equal. My test also proved I was wrong, and WinXP actually does
do overlapping file I/O when copying files. (I'm sure I've seen other
Windows OSes, where file I/O is not overlapped.)

I tested from the DOS prompt, and also tried Explorer copy and paste,
as well as giving Robocopy a try, and they all achieved the same
stopwatch time. Consistent with the transfer rate possible in the
small area of the disk I defined for the test.

Paul

 

[Rod Speed]

Paul wrote

Rod Speed wrote

If you read my test results, they were done with a stopwatch. The results of real file transfers were compared to
HDTune results, and the results are equal.

Pity about the widespread reports of problems with
Vista file copying and his results when comparing
what True Image and Vista achieve on his hardware.

ALL you have shown is that the Vista file copy
problem isnt seen on your hardware with XP.

My test also proved I was wrong, and WinXP actually does do overlapping file I/O when copying files.

He isnt even using WinXP himself.

(I'm sure I've seen other Windows OSes, where file I/O is not overlapped.)

Thats unlikely to be the problem given that its a
tad unlikely that XP is overlapped and Vista isnt.

I tested from the DOS prompt, and also tried Explorer copy and paste, as well as giving Robocopy a try, and they all
achieved the same stopwatch time. Consistent with the transfer rate possible in the small area of the disk I defined
for the test.

Sure, but it aint the OS he is using.

 

[Smarty]

Upping your pagefile, possibly putting it on a differet drive
(if you have more than one), and making the pagefile a
fixed size might help.

After several hours of experimentation, benchmarking, tweaking of processes
and services, and comparing performances of several pieces of file copy
software (some of which actually replaces the Vista copy file code), I have
come to learn that I can sustain much faster file transfers at the nominal
average speed of my drives and controllers by changing the pagefile
settings, as Ato-Zee had initially recommended.

I am now seeing about 70 MB/sec speeds versus my prior 23MB/sec, essentially
a 3 to 1 improvement. This translates into many many hours of time saved for
the roughly 4 TBytes I am about to move onto the video server disks in
roughly 6 GByte chunks.

The key modification was to move the pagefile from either of the source or
destination disks. Apparently Windows wants to use a lot of virtual memory
during the file copy, and paging to either the source or destination drive
forces much more latency and thrashing. I am saying "apparently" since this
is my conclusion from seeing the speed improvement, but I do not know enough
about the internals of Vista to know this for a fact.

Thanks very much to all for your help in solving this problem.

 

[JR Weiss]

I just ventured into eSATA. I found out the [relatively] hard way
via an allegedly bad cable and an RMA. However, the fine techies at
IcyDock set me straight!

It turns out that if a SATA controller (e.g., the ICH9R) does not
have hot-swap capability, the eSATA device must be seen and
enumerated by the BIOS at boot-up. Otherwise you run into those
speed problems you noticed, if the device is recognized at all...

Try this. Set up and power up all eSATA devices on all your
computers. Reboot them all. Check the BIOS screens as they falsh
by (if possible) to see if all the eSATA devices are enumerated.
Retest the transfer rates. You might be pleasantly surprised.

I did indeed have the very problem arise which you refer to, and one
of my machines (a Dell XPS420) mis-manages the one and only external
eSATA port it has just as you describe. I added my own SATA
controller cards rather than suffer with the (yet unfixed) Dell
issue, and have not seen this type of slowdown since.

The drives which are internal to the computers are present at boot
time, are correctly enumerated by the BIOS when the machine boots,
and still have this same speed problem. My external eSATA ports,
provided by add-in cards, are actually capable of hot-swap, and do
not to seem to care whether the drive was there or not at boot time
since they (usually) mount and dismount external eSATA drives
whenever I chose to. The "Safely Remove" feature seems to work
properly.

Most important is the fact that the transfer speeds stay at this 25
MByte/sec rate regardless of whether the drive was there at boot
time, added later on, dismounted and then remounted, etc.

It is most frustrating to me since my USB2 drives perform at about
the same transfer rates..........25 Mbytes/sec give or take. This is
NOT what I was expecting SATA or eSATA to provide, and hence my post
to this newsgroup.

Is it possible the controller cards or PCIe bus is saturated? Do the
eSATA controllers have on-board processing, or do they use the CPU?

 

[Paul]

After several hours of experimentation, benchmarking, tweaking of
processes and services, and comparing performances of several pieces of
file copy software (some of which actually replaces the Vista copy file
code), I have come to learn that I can sustain much faster file
transfers at the nominal average speed of my drives and controllers by
changing the pagefile settings, as Ato-Zee had initially recommended.

I am now seeing about 70 MB/sec speeds versus my prior 23MB/sec,
essentially a 3 to 1 improvement. This translates into many many hours
of time saved for the roughly 4 TBytes I am about to move onto the video
server disks in roughly 6 GByte chunks.

The key modification was to move the pagefile from either of the source
or destination disks. Apparently Windows wants to use a lot of virtual
memory during the file copy, and paging to either the source or
destination drive forces much more latency and thrashing. I am saying
"apparently" since this is my conclusion from seeing the speed
improvement, but I do not know enough about the internals of Vista to
know this for a fact.

Thanks very much to all for your help in solving this problem.

Info on how Vista copies files, pre and post SP1.

http://blogs.technet.com/markrussinovich/archive/2008/02/04/2826167.aspx

What doesn't make sense to me, in your description of a fix, is why
a file cache should cause pressure to the extent that paging/swapping is involved.
I mean, I've seen this happen in Linux (watched it on Knoppix for example),
and it should be easy to fix, by not allowing the file cache to consume all
available real memory. So why would Vista be allowing a file cache to do this.

Maybe there is a Vista system setting, that defines how large the file cache can
get ?

When I first saw file caching (on SunOS or Solaris, I cannot remember which),
it was harmless fun. Memory was freed up so quickly under pressure, that
there was no problem with any cached file operations causing grief for any
other part of system operation. File caching on that system was virtually
free, and I never detected a scenario where it was costing me anything.
What is a puzzle to me, is how modern OSes have allowed the file cache
to bugger things up.

I did a test in Knoppix, using

sudo echo 1 > /proc/sys/vm/drop_caches

to manually cause the system to recover memory from the file cache. What I
discovered is, the usage of memory for a file cache was not a performance
problem. If I issued that command every five seconds, leaving the system
with more than half the memory available at all times, it made no difference
to how long it took a file intensive command to complete. The only problem
file caching causes on Knoppix, is when the thing freeing up memory cannot
do it fast enough, and the system is forced to swap to disk. Since Knoppix
by default, has no swap partition set up, it crashes! The cure, if you're a
Knoppix user, is to install a tiny swap partition on one of your hard drives.
That instantly fixed my problems. And the answer is not something I discovered
in ten minutes work either. It took me quite a while to discover what was
going on. Like, finding that "drop_caches" option, took forever, because I
didn't have a clue as to what terminology to use to find it.

Paul

 

[Peter]

I have 3 PCs which each have a variety of internal SATA drives, and all of
which have external eSATA ports. The external eSATA ports were either
factory-provided (Dell) or added by me with controller cards from Addonics
and Rosewill with PCI-Express or PCI interfaces.

Regardless of which computer and which internal or external drive I use (and
there are 14 drives in total I have tried), the nominal transfer rates I am
getting are roughly 25 to 30 Mbytes/sec. I will occasionally see a brief
transfer rate of 70-90 Mbytes/second, but this rate only lasts for a very
short time, I assume until some buffer in RAM has either emptied or filled.

The machines are all 32 bit Windows, both Vista and XP, in all cases with
latest patches and service packs.

I assume that SATA speeds closer to the theoretical limit should be
achievable, but have never seen even remotely close to this type of
performance. In fact, this type of performance I experience is much more
similar to USB2 and Firewire 400.

Is there anything I can do to speed things up? Files I read and write are
nominally long sequential transfers of roughly 6 GByte size, in all cases to
and from NTFS volumes / partitions.

Thanks in advance for any advice.

Have you checked the transfer mode for the ports in Device Manager. Had
I guy who's SATA drive was only set to PIO mode and was getting just
30MB/s transfer rates max. May even have been less than this. Just
removed the controller and allowed XP to re-install and everything was
fixed.

Just go to device manager->click on the + by IDE ATA/ATAPI controller-

then right click on each controller and select properties, then click

on advanced settings and ensure that Current Transfer Mode is Ultra DMA

 

[Yousuf Khan]

I don't know what causes some systems to be faster than others, but it
happens. I have a friend who was getting concerned about his transfer
speeds between Esata hard drives, which we measured to be over 40 MB/s.
I showed him that my transfer rates were only 30 MB/s or less.

I don't think it's got anything to do with the size of the cache onboard
the hard drive, as we both were using essentially similar sized hard
drives with similar sized caches.

Yousuf Khan

 

[Man-wai Chang to The Door (+MS=32B)]

Regardless of which computer and which internal or external drive I use

(and there are 14 drives in total I have tried), the nominal transfer
rates I am getting are roughly 25 to 30 Mbytes/sec. I will occasionally
see a brief transfer rate of 70-90 Mbytes/second, but this rate only
lasts for a very short time, I assume until some buffer in RAM has
either emptied or filled.
The machines are all 32 bit Windows, both Vista and XP, in all cases
with latest patches and service packs.

If it's the eSATA, I would try re-connecting the plugs.

--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Ubuntu 9.04) Linux 2.6.30.5
^ ^ 18:12:02 up 23:17 0 users load average: 1.22 1.24 1.19
ä¸å€Ÿè²¸! ä¸è©é¨™! ä¸æ´äº¤! ä¸æ‰“交! ä¸æ‰“劫! ä¸è‡ªæ®º! è«‹è€ƒæ…®ç¶œæ´ (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

 

[Yousuf Khan]

Try increasing the pagefile, make it a fixed size, and if possible put
it on a different drive.

Had already been done.

Yousuf Khan