Ghost timing

[Rod Speed]

Obviously the 271 is a CPU bound case and is the speed of compression.
Unlikely.

Is full write-behind caching onboard the "internal ide (secondary-slave)"
enabled? Often it's not enabled. Check the OS for such a setting.

Ghost 2004 does it on dos.

 

[Ron Reaugh]

Ghost 2004 does it on dos.

Try SMARTDRV /N and then find a DOS utility to make sure that write-behind
caching is enabled onboard the HD.

 

[Rod Speed]

Try SMARTDRV /N and then find a DOS utility to make
sure that write-behind caching is enabled onboard the HD.

Unlikely to be worth bothering given that he has
seen much higher thruput with disk to disk cloning.

 

[Ron Reaugh]

Unlikely to be worth bothering given that he has
seen much higher thruput with disk to disk cloning.

What "much larger thruput" the 431 vs ~290? That kind of difference is
about the size that write-behind caching would provide.

Try SMARTDRV /N and then find a utility that can check/set the write-behind
caching on an ATA HD.
situation.

 

[Rod Speed]

What "much larger thruput" the 431 vs ~290?

Nope, his other comment that he 'Actually saw 2123 mB/min in 1 test,
to an internal IDE (udma-133), all 7200 rpm drives, different controllers'

That kind of difference is about the size
that write-behind caching would provide.

But was actually seen with compression/no compression.

Try SMARTDRV /N and then find a utility that can
check/set the write-behind caching on an ATA HD.

Unlikely to be worth bothering given that he has
seen much higher thruput with disk to disk cloning.

 

[Captain Norm]

Tried smartdrv /n, made no difference. Couldn't find write-behind caching
for dos in google.

Norm Perron

 

[Peter]

Could you please clarify your previous statement about disk-to-disk transfer
speed?
Was that done with present disk/controller configuration? I thought you have
mentioned different controllers. If that is the case, we can disregard that
number, and still have a chipset/DOS performance issue. Can you do a
disk-to-disk test with present hardware?
I think I saw somewhere similar posts with poor second IDE channel (VT8233A)
performance in DOS.

 

[Peter]

I have found this: OS2_2318.exe
Install viaide.sys in your config.sys
DEVICE=A:\VIAIDE.SYS /SET_DMAM=Y,Y,Y,Y

 

[Ron Reaugh]

I have found this: OS2_2318.exe
Install viaide.sys in your config.sys
DEVICE=A:\VIAIDE.SYS /SET_DMAM=Y,Y,Y,Y

Right, DOS is likely natively using PIO4 which limits all transfers to 16.6
MB/sec. (~1000 MB/min.) divided by 2 (~500 MB/min.). The newer Firewire
setup may be using UDMA mode (twice that fast or more). Thus 471MB/sec.
limited only by the PIO4 reads with lost revolutions. When you start doing
streaming HD I/O at slower than its native speed then one gets into lost
revolutions and that vastly complicates speed calculation.

 

[Rod Speed]

Peter <[email protected]> wrote

DOS is likely natively using PIO4 which limits all transfers to
16.6 MB/sec. (~1000 MB/min.) divided by 2 (~500 MB/min.).

Fraid not, he gets MUCH higher rates than that disk to disk, still on DOS.

The newer Firewire setup may be using UDMA mode (twice that fast or more).

Still doesnt explain why most dont get a higher rate to a
firewire target drive than an internal IDE with ghost either.

The problem is that he does. THATS what we are trying to explain.

Thus 471MB/sec. limited only by the PIO4 reads with lost revolutions.

Fraid not.

When you start doing streaming HD I/O at slower than its native speed then
one gets into lost revolutions and that vastly complicates speed calculation.

Still doesnt explain why most dont get a higher rate to a
firewire target drive than an internal IDE with ghost either.