Ghost timing

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.
29 answers Last reply
More about ghost timing
  1. 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.
  2. 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:DdudncNcJ7rIUu_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.
    >
    >
  3. 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:DdudncNcJ7rIUu_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.
    > >
    > >
    >
    >
  4. Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

    Captain Norm <thecaptain102@hotmail.com> wrote in
    message news:DdudncNcJ7rIUu_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.
  5. 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:DdudncNcJ7rIUu_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.
    >
    >
  6. Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

    Peter <peterfoxghost@yahoo.ca> wrote in message
    news:PRDcc.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:DdudncNcJ7rIUu_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.
  7. 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:PRDcc.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:DdudncNcJ7rIUu_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.
  8. 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:PRDcc.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:DdudncNcJ7rIUu_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.
    >
    >
  9. 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:PRDcc.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:DdudncNcJ7rIUu_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.
    > >
    > >
    >
    >
  10. 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:PRDcc.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:DdudncNcJ7rIUu_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.
  11. 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:PRDcc.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:DdudncNcJ7rIUu_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.
    >
    >
  12. 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:PRDcc.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:DdudncNcJ7rIUu_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.
    > >
    > >
    >
    >
  13. 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:PRDcc.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:DdudncNcJ7rIUu_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.
    > >
    > >
    >
    >
  14. 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)
    >
  15. 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
  16. Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

    dg <dan_gus@hotmail.com> wrote in message
    news:pqWcc.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
    >
    >
  17. 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:pqWcc.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
    > >
    > >
    >
    >
  18. 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.
  19. 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:pqWcc.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
    > > >
    > > >
    > >
    > >
    >
    >
  20. 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.
  21. 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.
  22. 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.
  23. 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.
  24. 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.
    >
    >
    >
  25. 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.
    > >
    > >
    > >
    >
    >
  26. 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.
    > > >
    > > >
    > > >
    > >
    > >
    >
    >
  27. 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.
    >
    >
    >
  28. 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.
    > > > >
    > > > >
    > > > >
    > > >
    > > >
    > >
    > >
    >
    >
  29. 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.
    > > > > >
    > > > > >
    > > > > >
    > > > >
    > > > >
    > > >
    > > >
    > >
    > >
    >
    >
Ask a new question

Read More

Storage