Ghost timing

[Captain Norm]

I can't believe it, ran timing twice, got pretty much same results. Running
Ghost 2004, DOS that came w/Win98SE, everything FAT32, source: 80 GB IBM
drive udma100, 2 mb cache, 7200 rpm, primary-master. Three different
destinations:

udma, cache-rpm; mB/minute at end
133, 2-5400; 235 external usb2.0
100, 8-7200; 271 external firewire
133, 8-7200; 225 internal ide (secondary-slave)

I would expect internal IDE (ASUS A7V333 MB, supports udma133, AMD 2100+
cpu, nothing on RAID) to be faster than external firewire. I expect udma to
not be a factor, limited by source udma100.

Would anyone else expect internal ide to be slowest?

Btw, my email address is not 102, it's 101.

 

[kalabp]

I can't believe it, ran timing twice, got pretty much same results. Running
Ghost 2004, DOS that came w/Win98SE, everything FAT32, source: 80 GB IBM
drive udma100, 2 mb cache, 7200 rpm, primary-master. Three different
destinations:

udma, cache-rpm; mB/minute at end
133, 2-5400; 235 external usb2.0
100, 8-7200; 271 external firewire
133, 8-7200; 225 internal ide (secondary-slave)

I would expect internal IDE (ASUS A7V333 MB, supports udma133, AMD 2100+
cpu, nothing on RAID) to be faster than external firewire. I expect udma to
not be a factor, limited by source udma100.

Would anyone else expect internal ide to be slowest?

Btw, my email address is not 102, it's 101.

I had a problem with my Maxtor DiamondMax+9's writing at less than 6
MB/sec due to the "CPU HALT command detection" setting being enabled in
BIOS (MSI KT3-Ultra2 with AMD 2000+). Disabling it boosted drive writing
and reading speed considerably.

I also discovered that running a software cooler in Win98 ("Cooler XP"
that came with my MSI board) had the same effect on disk performance. I
use Drive Image, not Ghost, but I would definitely expect more than 225
MB/minute.

 

[dg]

Interesting. Isn't the firewire drive just an IDE drive in an adapter
enclosure?

Thanks,
--Dan

 

[Captain Norm]

Sure is, standard IDE 3.5" drive.

Norm

Interesting. Isn't the firewire drive just an IDE drive in an adapter
enclosure?

Thanks,
--Dan

 

[Rod Speed]

I can't believe it, ran timing twice, got pretty much same
results. Running Ghost 2004, DOS that came w/Win98SE,
everything FAT32, source: 80 GB IBM drive udma100, 2 mb
cache, 7200 rpm, primary-master. Three different destinations:

udma, cache-rpm; mB/minute at end
133, 2-5400; 235 external usb2.0
100, 8-7200; 271 external firewire
133, 8-7200; 225 internal ide (secondary-slave)

I would expect internal IDE (ASUS A7V333 MB, supports udma133,
AMD 2100+ cpu, nothing on RAID) to be faster than external firewire.
I expect udma to not be a factor, limited by source udma100.

Would anyone else expect internal ide to be slowest?

Shouldnt be. There's something about the motherboard
chipset for the IDE controller that ghost doesnt like.

Demand some answers from Symantec if its a legal copy.

 

[Peter]

Don't waste your time on Symantec tech support.
How did you run Ghost? Disk to Image or Disk to Disk? Try Disk to Image.
Ghost does some caching internally, but slows down on large number of
smaller files.
There might be some quirks when you do Disk to Disk. Try other Gost
versions.
(BTW. There is no Ghost 2004, Ghost 2003 is the last one)
I would not use Ghost as a disk benchmark tool.

 

[Rod Speed]

Don't waste your time on Symantec tech support.

How did you run Ghost? Disk to Image or Disk to Disk?
Try Disk to Image. Ghost does some caching internally,
but slows down on large number of smaller files.

There might be some quirks when you do Disk to Disk.

Still shouldnt produce the slowest result with an internal IDE target.

Try other Gost versions.
(BTW. There is no Ghost 2004, Ghost 2003 is the last one)
I would not use Ghost as a disk benchmark tool.

He aint using it as a benchmarking tool, he was asking
why the internal IDE target gets the slowest result.

 

[Captain Norm]

Don't waste your time on Symantec tech support.

On one other occasion I asked Symantec, they don't support thruput

How did you run Ghost? Disk to Image or Disk to Disk?

Was disk to image, in all 3 tests, same everything, but destination. If I
have time to do it again, will try to defrag destination drives, could make
a difference.

Still shouldnt produce the slowest result with an internal IDE target.

That was my feeling, why asked the question. I figured my ASUS MB would be
more efficient that an external case, then add the overhead of firewire or
USB.

Try other Gost versions.
(BTW. There is no Ghost 2004, Ghost 2003 is the last one)

Norton Systems Works Pro 2003 failed, on an other machine that had SATA,
just hung. Norton Syetems Works Pro 2004 had a version of ghost.exe with
different size & date. 2004 version works fine w/SATA.

I would not use Ghost as a disk benchmark tool.

As was pointed out, was not actually using it as a benchmark tool. Ghost
gives MB/minute numbers, just presented them.

Shouldnt be. There's something about the motherboard
chipset for the IDE controller that ghost doesnt like.

It's using the same IDE chipset when going from internal IDE to internal IDE
(always reading from internal IDE, sometimes writing to internal IDE)

Norm Perron

 

[Rod Speed]

On one other occasion I asked Symantec, they don't support thruput

Good reason to avoid them if it wasnt for the fact that
Ghost can be so cheap as part of SystemWorks Pro 2003.

Was disk to image, in all 3 tests, same everything,
but destination. If I have time to do it again, will try
to defrag destination drives, could make a difference.

Nope, it wont, you watch. It never does with writing
very large files, essentially because the extra head
movements with any reasonable fragmentation is
a fart in the bath timing wise with thruputs that poor.

That was my feeling, why asked the question. I figured
my ASUS MB would be more efficient that an external
case, then add the overhead of firewire or USB.

Yes, and that is in fact the result usually seen, that and internal
IDE target produces the best thruput. And yours isnt even on
the same ribbon cable as the drive being imaged.

I'd try HDTach on both internal drives. Its possible that the
internal target IDE drive isnt coexisting with whatever else is
on that ribbon cable too well and thats why the lousy result.

Norton Systems Works Pro 2003 failed, on an other machine that had
SATA, just hung. Norton Syetems Works Pro 2004 had a version of
ghost.exe with different size & date. 2004 version works fine w/SATA.

The other thing worth trying is for live updates for the one that came
with 2004, it may have been some wart later fixed or something.

As was pointed out, was not actually using it as a benchmark tool.
Ghost gives MB/minute numbers, just presented them.

It's using the same IDE chipset when going from internal IDE to internal IDE
(always reading from internal IDE, sometimes writing to internal IDE)

Sure, but that doesnt necessarily mean that it doesnt affect the thruput.

I have seen a similar effect with Drive Image with an Asus TUSL2-C.
Drive Image just doesnt like the IDE chipset used, and Intel, and the
thruput has always been quite poor between internal IDE drives and
the /IDE=ON switch that Drive Image has doesnt help.

Not as poor as yours tho, but not a hell of a lot better.

And I get the same relatively poor thruput with Ghost 2003
too on that system. MUCH better with both on a different
Asus P4XP-X motherboard with a different IDE chipset.

Both do quite well with HDTach with the motherboard
IDE drivers, but neither Ghost 2003 or Drive Image
2002 use those drivers when imaging at the dos level.

 

[Peter]

Actually all results were quite low. That would indeed proove that your
Ghost was not cooperating well with ASUS A7V333 VT8233A chipset in DOS. You
may try to flash A7V333 bios to newest version.
I assume you have used Ghost in "no compression" mode while performing
tests. With your disks throughput should be approaching 1GB/min or even
higher.

 

[Captain Norm]

Well, I defragged all drives, here are my new results:
udma, cache-rpm; mB/minute at end (original mB/min)
133, 2-5400; 226 external usb2.0 (235)
100, 8-7200; 272 external firewire (271)
133, 8-7200; 228 internal ide (secondary-slave) (225)

Internal IDE got a bit better than usb 2.0, but external firewire still best
thruput.

may try to flash A7V333 bios to newest version.

I haven't looked for updated bios lately, worth a try.

I assume you have used Ghost in "no compression" mode while performing

tests.

In hindsight, should have, but did not. That would have given me higher
numbers, but should still be relatively the same. I used what I think they
call "high" compression.

For what it's worth, when I Ghost disk to disk I get much higher numbers.
Actually saw 2123 mB/min in 1 test, to an internal IDE (udma-133), all 7200
rpm drives, different controllers. My tests above were to a file, not disk
to disk.

 

[Peter]

I would suggest to use "no compression" in your tests. From high disk to
disk numbers, it looks ther is no problem with chipset. But it still does
not answer the difference observed. It must be one of those Ghost things...

 

[Captain Norm]

The following table shows mB/minute, NO compression. Internal IDE still
slowest, firewire quite faster.

udma, cache-rpm; mB/minute at end (original mB/min)
133, 2-5400; 295 external usb2.0 (235)
100, 8-7200; 431 external firewire (271)
133, 8-7200; 287 internal ide (secondary-slave) (225)

 

[Captain Norm]

Table below shows results of test with NO compression. Firewire still a big
winner.

udma, cache-rpm; mB/minute at end (original mB/min)
133, 2-5400; 295 external usb2.0 (235)
100, 8-7200; 431 external firewire (271)
133, 8-7200; 287 internal ide (secondary-slave) (225)

Norm Perron

 

[Eric Gisin]

Are the destination drives all FAT32?

Firewire faster than IDE is interesting. I assume FW uses ASPI and IDE uses
Int13, but that doesn't explain it.

 

[dg]

I know this is just one example of one persons experience, but I have new
respect for those external firewire enclosures. I may pick one up someday.
Who would have thought that adding an interface in between the drive and
motherboard would actually improve performance. What kind of firewire card
do you use? Onboard or PCI? Brand?

Thanks,
--Dan

 

[Rod Speed]

I know this is just one example of one persons experience, but I have new
respect for those external firewire enclosures. I may pick one up someday.

You dont get that effect with the usual benchmarks tho.

There must be something weird about Ghost
and that particular system with an internal drive.

And for the others, I agree that it doesnt appear to be a
chipset problem if you can get very high thruput numbers
with a disk to disk clone to an internal drive on that system.

Oddly enough the speed to the internal drive doesnt change all
that much with compression turned off either with image creation.
Which makes it look rather like ghost is getting seriously confused
with the internal drive for some reason, just with image creation.

I would have a closer look at whats on the same ribbon cable as
the internal drive tho, trying it with that internal drive alone on the
ribbon cable. Its possible that the decent speeds seen with the
disk to disk clone were actually seen with a different config of
drives on the internal secondary ribbon cable or something.

I'd also see what HDTach sees as the thruput to that target drive.

Who would have thought that adding an interface in between
the drive and motherboard would actually improve performance.

It doesnt with normal benchmarks. Firewire
is a bit below internal IDE, as expected.

Unfortunately the best review that showed
that clearly is no longer on the web site.

 

[Captain Norm]

I would have a closer look at whats on the same ribbon cable as

the internal drive tho, trying it with that internal drive alone on the
ribbon cable. Its possible that the decent speeds seen with the
disk to disk clone were actually seen with a different config of
drives on the internal secondary ribbon cable or something.

The master drive is a 250 GB WD drive. I don't have time to pull cable off
master and re-config jumpers. I wouldn't think that master would intefer
with that slave any more than the slave on the other cable (DVD player).

I'd also see what HDTach sees as the thruput to that target drive.

You guys are keeping me busy <g>. The image,
http://www.catalina42.org/images/0-hdtachx4.jpg has 4 screen dumps. 82gb
drive is source, 203gb drive is internal ide, 1.22gb is USB2.0, 200gb is the
firewire. I'm not at all familiar w/hdtach, but see internal ide drives
about 2 times faster (read burst speed) than firewire & usb quite a bit
slower.

Its possible that the decent speeds seen with the
disk to disk clone were actually seen with a different config of
drives on the internal secondary ribbon cable or something.

Actually haven't moved any cables/config in months, performed w/same config
as these tests.

What kind of firewire card do you use? Onboard or PCI? Brand?

This ASUS board has onboard FW, which has stopped working. I added a cheapo
PCI card about 6 months ago.

Are the destination drives all FAT32?
Yes

Firewire faster than IDE is interesting. I assume FW uses ASPI and IDE uses
Int13, but that doesn't explain it.

Yes

Norm Perron

 

[Rod Speed]

The master drive is a 250 GB WD drive. I don't have time to pull cable off
master and re-config jumpers. I wouldn't think that master would intefer
with that slave any more than the slave on the other cable (DVD player).

I actually meant the target drive, not that master.

Since that master does deliver a decent rate to the firewire
external, the problem if any is likely to be the IDE the image
file is written to, not the drive being imaged.

You guys are keeping me busy <g>.

Getting PCs running properly aint ever pain free |-)

The image, http://www.catalina42.org/images/0-hdtachx4.jpg
has 4 screen dumps. 82gb drive is source, 203gb drive is internal
ide, 1.22gb is USB2.0, 200gb is the firewire. I'm not at all familiar
w/hdtach, but see internal ide drives about 2 times faster (read
burst speed) than firewire & usb quite a bit slower.

Yeah, thats what it should show. The main question is why
the internal IDE particularly doesnt produce that with ghost too.

Clearly HDTach isnt showing anything bad with the 203GB drive.

Actually haven't moved any cables/config in months,
performed w/same config as these tests.

Odder and odder.

You could just cut to the chase and beat the system to a pulp
with a baseball bat and then it wouldnt matter why its so slow
writing the image file to the IDE drive on the secondary channel.

This ASUS board has onboard FW, which has stopped working.

Thats interesting. Maybe the weird numbers with
the internal IDE as the destination for the image
file is another effect of that fault or something.

I added a cheapo PCI card about 6 months ago.

Yes

I'd reach for that baseball bat now |-)

 

[Ron Reaugh]

Table below shows results of test with NO compression. Firewire still a big
winner.

udma, cache-rpm; mB/minute at end (original mB/min)
133, 2-5400; 295 external usb2.0 (235)
100, 8-7200; 431 external firewire (271)

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

133, 8-7200; 287 internal ide (secondary-slave) (225)

Is full write-behind caching onboard the "internal ide (secondary-slave)"
enabled? Often it's not enabled. Check the OS for such a setting.
Firewire drives are frequently configured for video streaming and it is
likely configured for write-behind caching. Write-behind caching onboard
the drive being enabled is a 'must' in most any streaming I/O situation.