Sign in with
Sign up | Sign in
Your question

Ghost timing

Tags:
Last response: in Storage
Share
Anonymous
a b G Storage
April 6, 2004 12:40:01 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

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.

More about : ghost timing

Anonymous
a b G Storage
April 6, 2004 4:50:41 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Captain Norm wrote:
> 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.
Anonymous
a b G Storage
April 6, 2004 8:54:53 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

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

Thanks,
--Dan

"Captain Norm" <thecaptain102@hotmail.com> wrote in message
news:D dudncNcJ7rIUu_dRVn-uQ@adelphia.com...
> 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.
>
>
Related resources
Anonymous
a b G Storage
April 6, 2004 8:54:54 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Sure is, standard IDE 3.5" drive.

Norm

"dg" <dan_gus@hotmail.com> wrote in message
news:xhBcc.33518$Xv4.4289@newssvr29.news.prodigy.com...
> Interesting. Isn't the firewire drive just an IDE drive in an adapter
> enclosure?
>
> Thanks,
> --Dan
>
> "Captain Norm" <thecaptain102@hotmail.com> wrote in message
> news:D dudncNcJ7rIUu_dRVn-uQ@adelphia.com...
> > 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.
> >
> >
>
>
Anonymous
a b G Storage
April 7, 2004 9:14:43 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Captain Norm <thecaptain102@hotmail.com> wrote in
message news:D dudncNcJ7rIUu_dRVn-uQ@adelphia.com...

> 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.
April 7, 2004 9:14:44 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

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" <rod_speed@yahoo.com> wrote in message
news:c4uvj0$2n1l70$1@ID-69072.news.uni-berlin.de...
>
> Captain Norm <thecaptain102@hotmail.com> wrote in
> message news:D dudncNcJ7rIUu_dRVn-uQ@adelphia.com...
>
> > 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.
>
>
Anonymous
a b G Storage
April 7, 2004 10:54:18 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Peter <peterfoxghost@yahoo.ca> wrote in message
news:p RDcc.21615$wq4.1061657@news20.bellglobal.com...

> 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.


> "Rod Speed" <rod_speed@yahoo.com> wrote in message
> news:c4uvj0$2n1l70$1@ID-69072.news.uni-berlin.de...
> >
> > Captain Norm <thecaptain102@hotmail.com> wrote in
> > message news:D dudncNcJ7rIUu_dRVn-uQ@adelphia.com...
> >
> > > 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.
Anonymous
a b G Storage
April 7, 2004 10:54:19 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

> 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" <rod_speed@yahoo.com> wrote in message
news:c4v5dk$2no5lh$1@ID-69072.news.uni-berlin.de...
>
> Peter <peterfoxghost@yahoo.ca> wrote in message
> news:p RDcc.21615$wq4.1061657@news20.bellglobal.com...
>
> > 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.
>
>
> > "Rod Speed" <rod_speed@yahoo.com> wrote in message
> > news:c4uvj0$2n1l70$1@ID-69072.news.uni-berlin.de...
> > >
> > > Captain Norm <thecaptain102@hotmail.com> wrote in
> > > message news:D dudncNcJ7rIUu_dRVn-uQ@adelphia.com...
> > >
> > > > 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.
Anonymous
a b G Storage
April 7, 2004 1:27:20 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Captain Norm <thecaptain102@hotmail.com> wrote in
message news:u_SdnVwodqLtrO7dRVn-uw@adelphia.com...

>> Don't waste your time on Symantec tech support.

> 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.

>> 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.

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.

>> 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.

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.

>> 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.

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.

>> 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)

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.


> "Rod Speed" <rod_speed@yahoo.com> wrote in message
> news:c4v5dk$2no5lh$1@ID-69072.news.uni-berlin.de...
> >
> > Peter <peterfoxghost@yahoo.ca> wrote in message
> > news:p RDcc.21615$wq4.1061657@news20.bellglobal.com...
> >
> > > 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.
> >
> >
> > > "Rod Speed" <rod_speed@yahoo.com> wrote in message
> > > news:c4uvj0$2n1l70$1@ID-69072.news.uni-berlin.de...
> > > >
> > > > Captain Norm <thecaptain102@hotmail.com> wrote in
> > > > message news:D dudncNcJ7rIUu_dRVn-uQ@adelphia.com...
> > > >
> > > > > 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.
>
>
April 7, 2004 1:27:21 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

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.

"Rod Speed" <rod_speed@yahoo.com> wrote in message
news:c4vect$2o6rih$1@ID-69072.news.uni-berlin.de...
>
> Captain Norm <thecaptain102@hotmail.com> wrote in
> message news:u_SdnVwodqLtrO7dRVn-uw@adelphia.com...
>
> >> Don't waste your time on Symantec tech support.
>
> > 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.
>
> >> 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.
>
> 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.
>
> >> 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.
>
> 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.
>
> >> 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.
>
> 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.
>
> >> 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)
>
> 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.
>
>
> > "Rod Speed" <rod_speed@yahoo.com> wrote in message
> > news:c4v5dk$2no5lh$1@ID-69072.news.uni-berlin.de...
> > >
> > > Peter <peterfoxghost@yahoo.ca> wrote in message
> > > news:p RDcc.21615$wq4.1061657@news20.bellglobal.com...
> > >
> > > > 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.
> > >
> > >
> > > > "Rod Speed" <rod_speed@yahoo.com> wrote in message
> > > > news:c4uvj0$2n1l70$1@ID-69072.news.uni-berlin.de...
> > > > >
> > > > > Captain Norm <thecaptain102@hotmail.com> wrote in
> > > > > message news:D dudncNcJ7rIUu_dRVn-uQ@adelphia.com...
> > > > >
> > > > > > 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.
> >
> >
>
>
Anonymous
a b G Storage
April 7, 2004 1:27:22 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

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" <peterfoxghost@yahoo.ca> wrote in message
news:uWKcc.24742$wq4.1278614@news20.bellglobal.com...
> 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.
>
> "Rod Speed" <rod_speed@yahoo.com> wrote in message
> news:c4vect$2o6rih$1@ID-69072.news.uni-berlin.de...
> >
> > Captain Norm <thecaptain102@hotmail.com> wrote in
> > message news:u_SdnVwodqLtrO7dRVn-uw@adelphia.com...
> >
> > >> Don't waste your time on Symantec tech support.
> >
> > > 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.
> >
> > >> 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.
> >
> > 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.
> >
> > >> 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.
> >
> > 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.
> >
> > >> 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.
> >
> > 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.
> >
> > >> 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)
> >
> > 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.
> >
> >
> > > "Rod Speed" <rod_speed@yahoo.com> wrote in message
> > > news:c4v5dk$2no5lh$1@ID-69072.news.uni-berlin.de...
> > > >
> > > > Peter <peterfoxghost@yahoo.ca> wrote in message
> > > > news:p RDcc.21615$wq4.1061657@news20.bellglobal.com...
> > > >
> > > > > 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.
> > > >
> > > >
> > > > > "Rod Speed" <rod_speed@yahoo.com> wrote in message
> > > > > news:c4uvj0$2n1l70$1@ID-69072.news.uni-berlin.de...
> > > > > >
> > > > > > Captain Norm <thecaptain102@hotmail.com> wrote in
> > > > > > message news:D dudncNcJ7rIUu_dRVn-uQ@adelphia.com...
> > > > > >
> > > > > > > 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.
April 7, 2004 1:27:23 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

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" <thecaptain102@hotmail.com> wrote in message
news:k-idnRQa7o66D-7d4p2dnA@adelphia.com...
> 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" <peterfoxghost@yahoo.ca> wrote in message
> news:uWKcc.24742$wq4.1278614@news20.bellglobal.com...
> > 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.
> >
> > "Rod Speed" <rod_speed@yahoo.com> wrote in message
> > news:c4vect$2o6rih$1@ID-69072.news.uni-berlin.de...
> > >
> > > Captain Norm <thecaptain102@hotmail.com> wrote in
> > > message news:u_SdnVwodqLtrO7dRVn-uw@adelphia.com...
> > >
> > > >> Don't waste your time on Symantec tech support.
> > >
> > > > 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.
> > >
> > > >> 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.
> > >
> > > 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.
> > >
> > > >> 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.
> > >
> > > 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.
> > >
> > > >> 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.
> > >
> > > 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.
> > >
> > > >> 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)
> > >
> > > 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.
> > >
> > >
> > > > "Rod Speed" <rod_speed@yahoo.com> wrote in message
> > > > news:c4v5dk$2no5lh$1@ID-69072.news.uni-berlin.de...
> > > > >
> > > > > Peter <peterfoxghost@yahoo.ca> wrote in message
> > > > > news:p RDcc.21615$wq4.1061657@news20.bellglobal.com...
> > > > >
> > > > > > 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.
> > > > >
> > > > >
> > > > > > "Rod Speed" <rod_speed@yahoo.com> wrote in message
> > > > > > news:c4uvj0$2n1l70$1@ID-69072.news.uni-berlin.de...
> > > > > > >
> > > > > > > Captain Norm <thecaptain102@hotmail.com> wrote in
> > > > > > > message news:D dudncNcJ7rIUu_dRVn-uQ@adelphia.com...
> > > > > > >
> > > > > > > > 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.
>
>
Anonymous
a b G Storage
April 7, 2004 1:27:24 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

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)

"Peter" <peterfoxghost@yahoo.ca> wrote in message
news:vZQcc.5504$BF2.722394@news20.bellglobal.com...
> 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" <thecaptain102@hotmail.com> wrote in message
> news:k-idnRQa7o66D-7d4p2dnA@adelphia.com...
> > 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" <peterfoxghost@yahoo.ca> wrote in message
> > news:uWKcc.24742$wq4.1278614@news20.bellglobal.com...
> > > 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.
> > >
> > > "Rod Speed" <rod_speed@yahoo.com> wrote in message
> > > news:c4vect$2o6rih$1@ID-69072.news.uni-berlin.de...
> > > >
> > > > Captain Norm <thecaptain102@hotmail.com> wrote in
> > > > message news:u_SdnVwodqLtrO7dRVn-uw@adelphia.com...
> > > >
> > > > >> Don't waste your time on Symantec tech support.
> > > >
> > > > > 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.
> > > >
> > > > >> 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.
> > > >
> > > > 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.
> > > >
> > > > >> 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.
> > > >
> > > > 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.
> > > >
> > > > >> 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.
> > > >
> > > > 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.
> > > >
> > > > >> 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)
> > > >
> > > > 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.
> > > >
> > > >
> > > > > "Rod Speed" <rod_speed@yahoo.com> wrote in message
> > > > > news:c4v5dk$2no5lh$1@ID-69072.news.uni-berlin.de...
> > > > > >
> > > > > > Peter <peterfoxghost@yahoo.ca> wrote in message
> > > > > > news:p RDcc.21615$wq4.1061657@news20.bellglobal.com...
> > > > > >
> > > > > > > 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.
> > > > > >
> > > > > >
> > > > > > > "Rod Speed" <rod_speed@yahoo.com> wrote in message
> > > > > > > news:c4uvj0$2n1l70$1@ID-69072.news.uni-berlin.de...
> > > > > > > >
> > > > > > > > Captain Norm <thecaptain102@hotmail.com> wrote in
> > > > > > > > message news:D dudncNcJ7rIUu_dRVn-uQ@adelphia.com...
> > > > > > > >
> > > > > > > > > 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.
> >
> >
>
>
Anonymous
a b G Storage
April 7, 2004 1:45:01 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

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

"Peter" <peterfoxghost@yahoo.ca> wrote in message
news:vZQcc.5504$BF2.722394@news20.bellglobal.com...
> 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" <thecaptain102@hotmail.com> wrote in message
> news:k-idnRQa7o66D-7d4p2dnA@adelphia.com...
> > 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" <peterfoxghost@yahoo.ca> wrote in message
> > news:uWKcc.24742$wq4.1278614@news20.bellglobal.com...
> > > 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.
> > >
> > > "Rod Speed" <rod_speed@yahoo.com> wrote in message
> > > news:c4vect$2o6rih$1@ID-69072.news.uni-berlin.de...
> > > >
> > > > Captain Norm <thecaptain102@hotmail.com> wrote in
> > > > message news:u_SdnVwodqLtrO7dRVn-uw@adelphia.com...
> > > >
> > > > >> Don't waste your time on Symantec tech support.
> > > >
> > > > > 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.
> > > >
> > > > >> 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.
> > > >
> > > > 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.
> > > >
> > > > >> 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.
> > > >
> > > > 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.
> > > >
> > > > >> 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.
> > > >
> > > > 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.
> > > >
> > > > >> 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)
> > > >
> > > > 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.
> > > >
> > > >
> > > > > "Rod Speed" <rod_speed@yahoo.com> wrote in message
> > > > > news:c4v5dk$2no5lh$1@ID-69072.news.uni-berlin.de...
> > > > > >
> > > > > > Peter <peterfoxghost@yahoo.ca> wrote in message
> > > > > > news:p RDcc.21615$wq4.1061657@news20.bellglobal.com...
> > > > > >
> > > > > > > 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.
> > > > > >
> > > > > >
> > > > > > > "Rod Speed" <rod_speed@yahoo.com> wrote in message
> > > > > > > news:c4uvj0$2n1l70$1@ID-69072.news.uni-berlin.de...
> > > > > > > >
> > > > > > > > Captain Norm <thecaptain102@hotmail.com> wrote in
> > > > > > > > message news:D dudncNcJ7rIUu_dRVn-uQ@adelphia.com...
> > > > > > > >
> > > > > > > > > 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.
> >
> >
>
>
Anonymous
a b G Storage
April 7, 2004 1:50:34 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

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.

"Captain Norm" <thecaptain102@hotmail.com> wrote in message
news:bv2dnfsid8Z_tOnd4p2dnA@adelphia.com...
> 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)
>
Anonymous
a b G Storage
April 7, 2004 8:57:57 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

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

"Captain Norm" <thecaptain102@hotmail.com> wrote in message
news:nYudnVVtMviOrendRVn-uQ@adelphia.com...
> 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
Anonymous
a b G Storage
April 8, 2004 8:35:19 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

dg <dan_gus@hotmail.com> wrote in message
news:p qWcc.33762$3L6.9970@newssvr29.news.prodigy.com...

> 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.

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


> "Captain Norm" <thecaptain102@hotmail.com> wrote in message
> news:nYudnVVtMviOrendRVn-uQ@adelphia.com...
> > 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
>
>
Anonymous
a b G Storage
April 8, 2004 8:35:20 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

> 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" <rod_speed@yahoo.com> wrote in message
news:c51hl6$2oe1mi$1@ID-69072.news.uni-berlin.de...
>
> dg <dan_gus@hotmail.com> wrote in message
> news:p qWcc.33762$3L6.9970@newssvr29.news.prodigy.com...
>
> > 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.
>
> > What kind of firewire card do you use? Onboard or PCI? Brand?
>
>
> > "Captain Norm" <thecaptain102@hotmail.com> wrote in message
> > news:nYudnVVtMviOrendRVn-uQ@adelphia.com...
> > > 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
> >
> >
>
>
Anonymous
a b G Storage
April 8, 2004 10:08:47 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Captain Norm" <thecaptain102@hotmail.com> wrote in message
news:nYudnVVtMviOrendRVn-uQ@adelphia.com...
> 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.
Anonymous
a b G Storage
April 8, 2004 11:48:01 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Captain Norm <thecaptain102@hotmail.com> wrote in
message news:5KGdncfQtN_N_-ndRVn-vw@adelphia.com...

>> 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 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.

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

> 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.

>> 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.

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.

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

> 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.

>> 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

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



> "Rod Speed" <rod_speed@yahoo.com> wrote in message
> news:c51hl6$2oe1mi$1@ID-69072.news.uni-berlin.de...
> >
> > dg <dan_gus@hotmail.com> wrote in message
> > news:p qWcc.33762$3L6.9970@newssvr29.news.prodigy.com...
> >
> > > 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.
> >
> > > What kind of firewire card do you use? Onboard or PCI? Brand?
> >
> >
> > > "Captain Norm" <thecaptain102@hotmail.com> wrote in message
> > > news:nYudnVVtMviOrendRVn-uQ@adelphia.com...
> > > > 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
> > >
> > >
> >
> >
>
>
Anonymous
a b G Storage
April 8, 2004 10:12:07 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Ron Reaugh <ron-reaugh@worldnet.att.net> wrote in message
news:p %5dc.33361$vo5.1058766@bgtnsc05-news.ops.worldnet.att.net...
> Captain Norm <thecaptain102@hotmail.com> wrote

>> 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.

Unlikely.

>> 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.

Ghost 2004 does it on dos.

> 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.
Anonymous
a b G Storage
April 8, 2004 11:10:54 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Rod Speed" <rod_speed@yahoo.com> wrote in message
news:c531gp$2msrne$1@ID-69072.news.uni-berlin.de...
>
> Ron Reaugh <ron-reaugh@worldnet.att.net> wrote in message
> news:p %5dc.33361$vo5.1058766@bgtnsc05-news.ops.worldnet.att.net...
> > Captain Norm <thecaptain102@hotmail.com> wrote
>
> >> 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.
>
> Unlikely.
>
> >> 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.
>
> 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.

> > 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.
Anonymous
a b G Storage
April 9, 2004 9:38:28 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Ron Reaugh <ron-reaugh@worldnet.att.net> wrote in message
news:2thdc.60858$He5.1164154@bgtnsc04-news.ops.worldnet.att.net...
> Rod Speed <rod_speed@yahoo.com> wrote
>> Ron Reaugh <ron-reaugh@worldnet.att.net> wrote
>>> Captain Norm <thecaptain102@hotmail.com> wrote

>>>> 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.

>> Unlikely.

>>>> 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.

>> 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.

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

>>> 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.
Anonymous
a b G Storage
April 9, 2004 9:38:29 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Rod Speed" <rod_speed@yahoo.com> wrote in message
news:c549nm$1voek0$1@ID-69072.news.uni-berlin.de...
>
> Ron Reaugh <ron-reaugh@worldnet.att.net> wrote in message
> news:2thdc.60858$He5.1164154@bgtnsc04-news.ops.worldnet.att.net...
> > Rod Speed <rod_speed@yahoo.com> wrote
> >> Ron Reaugh <ron-reaugh@worldnet.att.net> wrote
> >>> Captain Norm <thecaptain102@hotmail.com> wrote
>
> >>>> 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.
>
> >> Unlikely.
>
> >>>> 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.
>
> >> 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.
>
> 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.

> >>> 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.
Anonymous
a b G Storage
April 9, 2004 9:38:30 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

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

Norm Perron

"Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message
news:uvidc.61229$He5.1168926@bgtnsc04-news.ops.worldnet.att.net...
>
> "Rod Speed" <rod_speed@yahoo.com> wrote in message
> news:c549nm$1voek0$1@ID-69072.news.uni-berlin.de...
> >
> > Ron Reaugh <ron-reaugh@worldnet.att.net> wrote in message
> > news:2thdc.60858$He5.1164154@bgtnsc04-news.ops.worldnet.att.net...
> > > Rod Speed <rod_speed@yahoo.com> wrote
> > >> Ron Reaugh <ron-reaugh@worldnet.att.net> wrote
> > >>> Captain Norm <thecaptain102@hotmail.com> wrote
> >
> > >>>> 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.
> >
> > >> Unlikely.
> >
> > >>>> 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.
> >
> > >> 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.
> >
> > 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.
>
> > >>> 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.
>
>
>
April 9, 2004 9:38:31 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

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.

"Captain Norm" <thecaptain102@hotmail.com> wrote in message
news:B6OdnWkMRqRfROjd4p2dnA@adelphia.com...
> Tried smartdrv /n, made no difference. Couldn't find write-behind caching
> for dos in google.
>
> Norm Perron
>
> "Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message
> news:uvidc.61229$He5.1168926@bgtnsc04-news.ops.worldnet.att.net...
> >
> > "Rod Speed" <rod_speed@yahoo.com> wrote in message
> > news:c549nm$1voek0$1@ID-69072.news.uni-berlin.de...
> > >
> > > Ron Reaugh <ron-reaugh@worldnet.att.net> wrote in message
> > > news:2thdc.60858$He5.1164154@bgtnsc04-news.ops.worldnet.att.net...
> > > > Rod Speed <rod_speed@yahoo.com> wrote
> > > >> Ron Reaugh <ron-reaugh@worldnet.att.net> wrote
> > > >>> Captain Norm <thecaptain102@hotmail.com> wrote
> > >
> > > >>>> 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.
> > >
> > > >> Unlikely.
> > >
> > > >>>> 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.
> > >
> > > >> 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.
> > >
> > > 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.
> >
> > > >>> 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.
> >
> >
> >
>
>
April 9, 2004 9:38:32 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

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

"Peter" <peterfoxghost@yahoo.ca> wrote in message
news:3%odc.11281$BF2.1097789@news20.bellglobal.com...
> 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.
>
> "Captain Norm" <thecaptain102@hotmail.com> wrote in message
> news:B6OdnWkMRqRfROjd4p2dnA@adelphia.com...
> > Tried smartdrv /n, made no difference. Couldn't find write-behind
caching
> > for dos in google.
> >
> > Norm Perron
> >
> > "Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message
> > news:uvidc.61229$He5.1168926@bgtnsc04-news.ops.worldnet.att.net...
> > >
> > > "Rod Speed" <rod_speed@yahoo.com> wrote in message
> > > news:c549nm$1voek0$1@ID-69072.news.uni-berlin.de...
> > > >
> > > > Ron Reaugh <ron-reaugh@worldnet.att.net> wrote in message
> > > > news:2thdc.60858$He5.1164154@bgtnsc04-news.ops.worldnet.att.net...
> > > > > Rod Speed <rod_speed@yahoo.com> wrote
> > > > >> Ron Reaugh <ron-reaugh@worldnet.att.net> wrote
> > > > >>> Captain Norm <thecaptain102@hotmail.com> wrote
> > > >
> > > > >>>> 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.
> > > >
> > > > >> Unlikely.
> > > >
> > > > >>>> 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.
> > > >
> > > > >> 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.
> > > >
> > > > 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.
> > >
> > > > >>> 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.
> > >
> > >
> > >
> >
> >
>
>
Anonymous
a b G Storage
April 9, 2004 11:54:46 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message news:uvidc.61229$He5.1168926@bgtnsc04-news.ops.worldnet.att.net...
>
> "Rod Speed" <rod_speed@yahoo.com> wrote in message
> news:c549nm$1voek0$1@ID-69072.news.uni-berlin.de...
> >
> > Ron Reaugh <ron-reaugh@worldnet.att.net> wrote in message
> > news:2thdc.60858$He5.1164154@bgtnsc04-news.ops.worldnet.att.net...
> > > Rod Speed <rod_speed@yahoo.com> wrote
> > >> Ron Reaugh <ron-reaugh@worldnet.att.net> wrote
> > >>> Captain Norm <thecaptain102@hotmail.com> wrote
> >
> > >>>> 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.
> >
> > >> Unlikely.
> >
> > >>>> 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.
> >
> > >> 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.
> >
> > 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?

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.

> > >>> 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.
>
>
>
Anonymous
a b G Storage
April 10, 2004 5:59:57 AM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Peter" <peterfoxghost@yahoo.ca> wrote in message
news:ZHpdc.11369$BF2.1109271@news20.bellglobal.com...
> 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.

> "Peter" <peterfoxghost@yahoo.ca> wrote in message
> news:3%odc.11281$BF2.1097789@news20.bellglobal.com...
> > 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.
> >
> > "Captain Norm" <thecaptain102@hotmail.com> wrote in message
> > news:B6OdnWkMRqRfROjd4p2dnA@adelphia.com...
> > > Tried smartdrv /n, made no difference. Couldn't find write-behind
> caching
> > > for dos in google.
> > >
> > > Norm Perron
> > >
> > > "Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message
> > > news:uvidc.61229$He5.1168926@bgtnsc04-news.ops.worldnet.att.net...
> > > >
> > > > "Rod Speed" <rod_speed@yahoo.com> wrote in message
> > > > news:c549nm$1voek0$1@ID-69072.news.uni-berlin.de...
> > > > >
> > > > > Ron Reaugh <ron-reaugh@worldnet.att.net> wrote in message
> > > > > news:2thdc.60858$He5.1164154@bgtnsc04-news.ops.worldnet.att.net...
> > > > > > Rod Speed <rod_speed@yahoo.com> wrote
> > > > > >> Ron Reaugh <ron-reaugh@worldnet.att.net> wrote
> > > > > >>> Captain Norm <thecaptain102@hotmail.com> wrote
> > > > >
> > > > > >>>> 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.
> > > > >
> > > > > >> Unlikely.
> > > > >
> > > > > >>>> 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.
> > > > >
> > > > > >> 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.
> > > > >
> > > > > 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.
> > > >
> > > > > >>> 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.
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Anonymous
a b G Storage
April 10, 2004 4:09:24 PM

Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Ron Reaugh <ron-reaugh@worldnet.att.net> wrote in message
news:xyIdc.2701$K_.74883@bgtnsc05-news.ops.worldnet.att.net...
> Peter <peterfoxghost@yahoo.ca> 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.


> > "Peter" <peterfoxghost@yahoo.ca> wrote in message
> > news:3%odc.11281$BF2.1097789@news20.bellglobal.com...
> > > 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.
> > >
> > > "Captain Norm" <thecaptain102@hotmail.com> wrote in message
> > > news:B6OdnWkMRqRfROjd4p2dnA@adelphia.com...
> > > > Tried smartdrv /n, made no difference. Couldn't find write-behind
> > caching
> > > > for dos in google.
> > > >
> > > > Norm Perron
> > > >
> > > > "Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message
> > > > news:uvidc.61229$He5.1168926@bgtnsc04-news.ops.worldnet.att.net...
> > > > >
> > > > > "Rod Speed" <rod_speed@yahoo.com> wrote in message
> > > > > news:c549nm$1voek0$1@ID-69072.news.uni-berlin.de...
> > > > > >
> > > > > > Ron Reaugh <ron-reaugh@worldnet.att.net> wrote in message
> > > > > > news:2thdc.60858$He5.1164154@bgtnsc04-news.ops.worldnet.att.net...
> > > > > > > Rod Speed <rod_speed@yahoo.com> wrote
> > > > > > >> Ron Reaugh <ron-reaugh@worldnet.att.net> wrote
> > > > > > >>> Captain Norm <thecaptain102@hotmail.com> wrote
> > > > > >
> > > > > > >>>> 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.
> > > > > >
> > > > > > >> Unlikely.
> > > > > >
> > > > > > >>>> 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.
> > > > > >
> > > > > > >> 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.
> > > > > >
> > > > > > 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.
> > > > >
> > > > > > >>> 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.
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
!