Hello all!

I have two HDDs, a new 120 GB Hitachi 7K250 with 8MB cache and a three years old 40 GB IBM 60GXP with 2 MB cache.
The 7K250 is Primary Master and the 60GXP is Primary Slave.

The rearmost partition on both (16-18GB) are FAT32, dedicated to Ghost Images.
I have the same Images on both HDDs, created to the target partition on the 60GXP and copied to the 7K250.

When I do integrity checks, the "transfer rates" are bothering me. The latest Image, which is approximately in the middle of both partitions (8-9 GB from the end of both HDDs), is checked at 142 MB/min on the 7K250 compared to 397 MB/min on the 60GXP.

I promptly did a benchmark in AIDA32 with the following results:

Quick Linear Read - 7K250 = 58.3-28.1 MB/s (46.8 avg)
QLR - 60GXP = 38.8-18.5 MB/s (31.2 avg)

Random Read - 7K250 = 57.6-27.9 MB/s (46.0 avg)
RR - 60GXP = 35.2-17.8 MB/s (30.7 avg)

Buffered Read - 7K250 = max 73.9 MB/s (73.7 avg)
BR - 60GXP = max 74.4 MB/s (74.2 avg)
(min readings omitted, low dips due to unknown interference)

Average Access - 7K250 = 11.8-13.4 ms (12.6 avg)
AA - 60GXP = 12.2-13.8 ms (13.0 avg)

The 7K250 should outperform the 60GXP and it does in the AIDA32 benchmark but why the very low performance when running the integity check in Ghost?

I would expect Ghost to create an Image quicker to a different HDD than to a different partition on the same HDD and that goes for restoring too but not for integrity checks which are read only operations.

Ideas anyone?

Thanks for Your time,
Christer

Quote:

... The 7K250 is Primary Master and the 60GXP is Primary Slave. Christer

What is assigned respectively to the Secondary Master and the Secondary Slave?  Also, what is your O.S. and are there any "fine-tuned" settings in the  BIOS re: HDDs, i.e., UDMA On or Off?

[glb]El Pescador [/glb]

I have an image stored at the slow end of an 80-gig drive that is several years old. To be honest, I don't recall who made this drive. I think it's an IBM 120-GXP, but I can't tell from the device mgr. But I bought it when 80-gig drives were the ones to get. The drive has 3 partitions: 12+34+34.

Just checked the image & Ghost reports between 500 & 600-MB per min.

So your 60GXP number seems reasonable. The only problem is the low check speed of the master. I suspect the image may have become fragmented while transferring.

I wouldn't defrag it, but check its level of fragmentation to see what you're getting. A fragmented image would slow down the read speed. I had a similar problem once. (I've had just about every problem   :'(  )

Since your benches are good, there should be nothing physicaly wrong with the drive.

I use Diskeeper for frag checks. They have a demo if you need.

http://www.executive.com/diskeeper/diskeeper.asp

Ghost reboots into DOS, so I don't think the OS matters.

I'm using a 2.2-GHz P4 CPU, which will affect the speed of the check. What CPU do you have?

It's not an SATA drive, is it?

Hello guys,
thanks for Your replies!

El Pescador,


Quote:

What is assigned respectively to the Secondary Master and the Secondary Slave?

The Secondary Master is a CD/R-RW running at PIO4 and the Secondary Slave is a DVD-ROM running at ATA33.


Quote:

Also, what is your O.S. and are there any "fine-tuned" settings in the  BIOS re: HDDs, i.e., UDMA On or Off?

The OS is WinXP pro but since Ghost runs from DOS, I agree with Radministrator that it shouldn´t matter.

BIOS settings are checked and in XP's device manager both drives run in UDMA mode 5, which is verified by the benchmark.
I doubt that it would matter because the rates are way below PIO4 which is 16.7 MB/s. The rate of the 7K250 is some 2-3 MB/s but the 60GXP stands out at 6-7 MB/s ......  :-/ ...... !

Radministrator,


Quote:

I suspect the image may have become fragmented while transferring.   I wouldn't defrag it, but check its level of fragmentation to see what you're getting. A fragmented image would slow down the read speed.

First, I actually created each Image twice, one to each HDD.
The create speed was also much lower on the 7K250 but I thought that might be due to reading from and writing to different partitions on the same HDD.
I have not yet restored from either of the HDDs.
The resulting check speed on the master was the same low rate as when checking the copied Images.

Regarding defragmentation, all Images are split in 650 MB chunks if I in the future should want to burn to CDs. When Ghost creates the Images, it leaves a small slack between each span. These small spaces are actually written to during the next creation, resulting in the second, third and so on, Images becoming fragmented. I had a fragmentation level of ~30% but if 6 out of 19 large files become fragmented, thats the percentage.

I know that Images shouldn´t be defragmented but copying the files also defragments.
I decided to reformat the 60GXP partition and copy the files, one by one, from the 7K250 to it. All copied Images passed the integrity check and not a single file is fragmented.
Next, I reformated the 7K250 partition and copied the files, one by one from the 60GXP to it with the same results from the integrity check and fragmentation level.


Quote:

I use Diskeeper for frag checks.

I used to use Norton Speed Disk but I have come to the conclusion that it fights the XP "on the move" defragmentation and relocation of files.
Speed Disk has one idea of what is the optimum and as soon as XP regains control, it starts moving things around to suit its preferences.
It actually feels like, after running Speed Disk, the computer slows down a wee bit but after a few restarts it picks up normal speed again.
My reaction to this is to quit using Speed Disk and let the native XP tool handle it.
I use the "Analysis" funtion of Speed Disk, though, for a second opinion on fragmentation levels.


Quote:

What CPU do you have?

AMD Athlon Thunderbird, 1 GHz with 266 MHz bus speed.


Quote:

It's not an SATA drive, is it?

Nope, it´s a PATA but it at least has 8 MB cache.

Christer

2 things:

1. i don't think it's a good idea to mix dma & non-dma devices on the same chanel. i think this forces ALL devices to run in pio mode. i think different DMA devices can run at diff DMA speeds, such as 1 at DMA33 & another at DMA100 on the same controller, but once you put a pio device, i think ALL devices on that channel must run at/in pio mode. i could be wrong, tho.

2. there are different ways to measure fragmentation. suppose a partition contains 10 files, and 1 of them is fragmented into 2 parts. that would be reported as 10% fragmentation. but suppose that same file is broken into 100 parts or 1000 parts, or a million. technically, the partition would STILL be reported as 10% fragmentation (only 1 file in 10). but this would be a much worse fragmentation that the previous example mentioned. so you have to delve deeper into exactly how bad the files are bfragmented.

Quote:

1. i don't think it's a good idea to mix dma & non-dma devices on the same chanel. i think this forces ALL devices to run in pio mode.

That´s a different issue regarding the performance of the opticals which share the Secondary. The HDDs share the Primary and are both ATA100.

I have experimented a bit with the setup of the hardware and mixed as follows:

Primary Master - 60GXP - ATA100
Primary Slave - CD-R/RW - PIO4 (MultiWord 2)
Secondary Master - empty front mounted rack in waiting for delivery of new HDD
Secondary Slave - DVD-ROM - ATA33

I did an AIDA32 benchmark of the 60GXP. The results were the same as when the 60GXP was alone on Primary.
(I saved and still have the results for Linear Read and Buffered Read, with and without the CD-R/RW as Primary Slave. If You or anyone else want to see them, just holler!)

In the early days of IDE, the controller set itself to the lowest transfer rate of any device connected to it.
In recent years they came up with Independent Device Timing which means that when the respective device takes its turn on the channel, it transfers at its own rate. My motherboard is three years old and obviously supports IDT.


Quote:

2. there are different ways to measure fragmentation.

Yes and that´s why I use Speed Disk for a "second opinion".

When there is fragmentation they (XP and SD) always differ in the percentage but now, for my two partitions holding Ghost Images, they agree that the fragmentation level is 0%, the number of fragments per file is 1.00 and the number of "additional file parts" (or whatever it's called in english?) are 0.

I´m 99.99% certain that the files are not fragmented.

Christer

i am tired, so maybe i'm missing something. however u say "The HDDs share the Primary and are both ATA100", but show the pio4 cd sharing the primary channel.

are u sure Independent Device Timing pertains to pio with dma, and not just different levels of dma? (i.e. 33, 66, 100, 133)

okay, i think you ruled out fragmentation, altho, if that image is not vital, i would be interested to see what happened following a defrag of that drive.

so we still don't know why the low check speed on the new 120-gigger, right?

Hi Christer.

The 7K250 should outperform the 60GXP and it does in the AIDA32 benchmark but why the very low performance when running the integity check in Ghost?

This may shed some light:

http://linux.tu-varna.acad.bg/~lig/freedos/

I don't think Ghost has a DMA controller - If not, then it will be operating in PIO mode.


Ian.  8)

Sorry Christer, bit premature in my previous post! ::)

Ghost can use DMA.

Have a look at your 'Ghost Diagnostic Error File' and see if it is using DMA.

http://service1.symantec.com/SUPPORT/ghost.nsf/pfdocs/1999021911433525


Ian.  8)

[glb]You guys are all operating way above my present level of PC knowledge !!! [/glb]
With the answers to my questions in hand, I must admit I am "stumped".

[glb]El Pescador [/glb]

Radministrator,


Quote:

i am tired, so maybe i'm missing something. however u say "The HDDs share the Primary and are both ATA100", but show the pio4 cd sharing the primary channel.

I´m sorry for the confusion. I shouldn´t have mentioned my experiments with hardware combinations since they are history. The current setup is:
Primary Master - 7K250
Primary Slave - 60GXP
Secondary Master CD-R/RW
Secondary Slave - DVD-ROM


Quote:

are u sure Independent Device Timing pertains to pio with dma, and not just different levels of dma? (i.e. 33, 66, 100, 133)

No, I´m not 100% sure but the AIDA32 benchmarks indicated that it does.


Quote:

okay, i think you ruled out fragmentation, altho, if that image is not vital, i would be interested to see what happened following a defrag of that drive.

Well, they are all vital in my strategy for sensible "roll back" points but since I have them in duplicate, I could defrag the Image partition on the 7K250. My guess is that the defragmenter will start and then finish immediately but we will not know until I´ve done it. I´m not at home now but will get back Sunday evening.

Ian,


Quote:

Have a look at your 'Ghost Diagnostic Error File' and see if it is using DMA.

I don´t think that I have one. The only place it could be is on the second ghost boot floppy which is in the drive when Ghost runs. There is no additional file(s) on it.

El Pescador,


Quote:

With the answers to my questions in hand, I must admit I am "stumped".

Welcome to the club ......  ??? ......  :-/ ...... !

Christer

I have "defragmented" the Image partition on the 7K250. No defragmentation took place and the time to do the integrity checks are the same.

I noticed that the cluster sizes differ with 32kB on the 7K250 and 16kB on the 60GXP but that shouldn´t make such a difference ......  ??? ...... or should it?

Christer

Does it make any difference what order you run the integrity checks? Like is the second one faster than the first, or is the 7K250 always slower?

all things being equal, i would expect the drive with 32kb clusters to go faster than the one with 16kb clusters.

since you have both hard drives on the same controller, the pio-dma issue is not relevant because that only pertains to drives/devices on the same controller (primary, secondary).

Quote:

Does it make any difference what order you run the integrity checks? Like is the second one faster than the first, or is the 7K250 always slower?

I have six different Images created at different points of the install procedure. Each one is 2.5-3 times slower to check on the 7K250, no matter which gets checked first.

I have created an additional Image of the system to each of them, as the system is at present time. I checked the Images and also restored using each Image and the one on the 7K250 is 2.5-3 times slower in all operations.


Quote:

all things being equal, i would expect the drive with 32kb clusters to go faster than the one with 16kb clusters.

I would expect that too but it is the opposite!

I had a thought which pertains to the setup of the drives respective firmware. I´ve heard about "normal seek mode" and "quiet seek mode" where the latter should yield lower performance.
The AIDA32 benchmarks doesn´t indicate any difference so, I buried that thought.

Christer

In the end the most important thing is the reliability of your images. Speed comes in a destant second. Altho I too wonder why the difference.

Hi Crawdaddy!

I´m with You all the way on that one but 2.5 -3 times slower is too much to swallow without trying to find out why.

I just did an Integrity Check on an Image on the 7K250 with the 60GXP powered off in the rack in order to rule out any possibility of interference. Still slow as molasses!

One observation that I have failed to mention is that the time ticks down second by second when the 60GXP is at work but when the 7K250 is at work, it can pause for several seconds (5-10) and then it catches up.

I think that all of this compounds into a very strange behaviour!

Christer

Hi Christer.

One observation that I have failed to mention is that the time ticks down second by second when the 60GXP is
at work but when the 7K250 is at work, it can pause for several seconds (5-10) and then it catches up.

That sounds like something to do with the cache on the 7K250. There is a diagnostic program from Hitachi that you
could run here:

http://www.hgst.com/hdd/support/download.htm

and the user manual is here:

http://www.hgst.com/downloads/dft32_user-guide.pdf

Their main support home page is here:

http://www.hgst.com/portal/site/hgst/?epi_menuItemID=a401d71a474b26fe25ad4e8060e4f0a0&epi_menuID=e41fff51ec9a8f8d5f5a530560e4f0a0&epi_baseMenuID=22f0deefa8f3967dafa0466460e4f0a0

Try the diagnostic and see if it comes up with anything.


Ian  8)

Hi again Christer!

Update:

The drive may not have been sut-up INTERNALLY to operate DMA, or at ATA100/133, and may actually be operating WITHOUT DMA, or at ATA66  - See below:


Feature Tool (v1.92)  
The Feature Tool allows you to control some of the features of our Deskstar and Travelstar high performance ATA hard disk drives and supports 48-bit addressing, so it will work with the new large capacity drives. This version adds support for our latest drives. The Feature Tool allows you to:

Enable or disable the read-ahead or write cache. - THIS MIGHT BE DISABLED - IAN

Change the drive Automatic Acoustic Management settings to the:
Lowest acoustic emanation setting (Quiet Seek Mode), or
Maximum performance level (Normal Seek Mode).

Change the predefined capacity of the drive. This option can be used in situations where there is a BIOS limitation and the drive is not recognized. See the  Users Guide for specific details.

Switch the Ultra DMA mode - THIS MIGHT BE INCORRECTLY SET - IAN

Change Advanced Power Mode - allows you to change between the lowest power consumption and the highest power consumption (maximum performance level).
Show Drive Temperature - shows the current drive temperature in Celsius and Farenheit.


My SeaGate drive also has a utility for changing the INTERNAL settings, but I didn't need to change any as they were already correct. - some BIOS's and older PC's cannot use ATA100/33, so when ATA100/133 drives first came out, the drives were set INTERNALLY to ATA66 by default to maintain compatibility - the user had to manually change them to ATA100 mode.

I think the 'Enable or disable the read-ahead or write cache' setting might be your problem - it should be ENABLED.

Let us know what happens!


Ian  8)

Hi Ian!

I´ve been busy this afternoon but not with anything that I´m paid for ......  :-X ...... !

When I prepared to install the new HDD, I ran IBM DFT on both the 60GXP and the 7K250. They both came out "green". Afterwards I did an "Erase Disk" on the 60GXP and finally updated the firmware on it.

Now, there was a new version of IBM DFT which I downloaded an ran with the same results.


Quote:

The drive may not have been sut-up INTERNALLY to operate DMA, or at ATA100/133, and may actually be operating WITHOUT DMA, or at ATA66

I´ve been playing with thoughts along those lines too but the AIDA32 benchmarks indicate that it is operating in "Ultra DMA Mode 5" = ATA100. If not, the Buffered Read would not go above 66 MB/s.

About "Quick Seek Mode" and "Normal Seek Mode", I think that the AIDA32 benchmarks on Average Access indicate that it is operating in "Normal".

I downloaded the Feature Tool too and will run it later just to confirm what I think I know or to find the problem.

By the way, I have created and used all flavours of Ghost Boot Disks, using MS-DOS and PC-DOS as well with the same results.

I checked the opticals and the CD-R/RW operating in "Multi-Word DMA Mode 2" = PIO4, checks an Image at 101-103 MB/s. The DVD-ROM operating in "Ultra DMA Mode 2" = ATA33, checks an Image at 106-108 MB/s.

It seems to me like Ghost misidentifies the 7K250 ......  ??? ...... In IBM DFT, the 60GXP is said to be DMA Mode 5 where as the 7K250 is said to be DMA Mode 6 (or words which I don´t remember exactly, to that meaning).

According to the WinXP Device Manager, the mentioned devices operate in the mode within "double quotes".

I´ll be back ......  >:( ...... !

Christer

I´ve had a look in the Feature Tool and both HDDs were identically configured:

SMART status = GOOD
UDMA mode = ATA100
Accoustic management = Disabled (which I understand as giving the best performance)
Power management = Disabled (which I understand as giving the best performance)
Write cache = Enabled
Read look-ahead = Enabled

If I have understood this correctly, the HDDs are properly configured and the problem isn´t with the 7K250.

My belief that it is a case of mistaken identity is strenghtened.

Christer

By the way, I´m concidering asking Symantec Support but I think that we have made me run around in circles all by our selves, haven´t we ......  ;D ...... ?

I´ve been busy this afternoon but not with anything that I´m paid for ......   ...... !

Hmm... sounds naughty!! ;)


I have a feeling that the drive is not using the read-ahead or write cache -  this would slow the drive considerably.

Have a look and see if it's enabled.


Ian.  8)

Must have been typing when you posted - didn't see the last posts!

Will have a think about it!

Ian  8)

'the 7K250 is said to be DMA Mode 6 (or words which I don´t remember exactly, to that meaning). '

UDMA Mode 6 is ATA133

UDMA Mode 5 is ATA100

try changing it to UDMA 5/ATA100

(or conversely, change it to UDMA 6/ATA 133)

If you have one setting as ATA100 and are trying to use UDMA 6 then it's possible that could be the trouble - DOS, i.e. the Ghost environment, is very unfriendly at the system level - if it doesn't like something it may not even tell you why!


BTW, I don't know what happenned to the page width on my earlier post!!


Ian  8)

Hi AGAIN Christer!

SMART status = GOOD
UDMA mode = ATA100 - This is UDMA 5 - for UDMA 6 it should be ATA133

Try changing it.


Ian  8)

Running the Drive Fitness Test, the 7K250 is said to have "ATA Compliance = ATA-6" whereas the 60GXP is said to have "ATA Compliance = ATA-5".

Running the Feature Tool, they are both said to have "Max UDMA Mode = 5" and it is possible to set them to Mode 0-5.
Both were/are set to Mode 5.

If Hitachi has problems detecting what the 7K250 is, then there is the possibility that I´m right about Ghost mistaking the identity and performance.

Christer

To Radministrator:

Is it possible to reverse the order of the previous posts? A lot of scrolling to get to the bottom when copying and pasting ......  :-/ ...... but that´s my own fault ......  ;D ......

Have a look at the web pages below, discussing transfer rates and compare to what I get from my devices:

http://www.storagereview.com/guide2000/ref/hdd/if/ide/modesUDMA.html
and
http://www.storagereview.com/guide2000/ref/hdd/if/ide/modesDMA.html

All my devices transfer at rates below Ultra DMA Mode 0 which is 16.7 MB/s.
This indicates to me that it is Ghost that is setting the standards and it got it all wrong with the 7K250.

Christer

Try putting the two HDD's on different controllers, and then see if that makes a difference - The drive set as MASTER may be hogging the bus - try this:

Primary Master - 7K250
Primary Slave - DVD-ROM
Secondary Master CD-R/RW
Secondary Slave - 60GXP


Ian.  8)

All the devices are jumpered to Cable Select but I don´t think that it would make any difference if jumpered Master and Slave respectively.

When I bought and installed the mobile rack, the only option that worked was to use CS. Any other jumping and the computer didn´t boot, it didn´t detect the PM.

Since I have the 60GXP in the mobile rack, I have tried powering it off, leaving the 7K250 alone on the Primary but no change in behaviour.

Christer

When I bought and installed the mobile rack, the only option that worked was to use CS. Any other jumping and the computer didn´t boot, it didn´t detect the PM.

This sounds suspicious!

Do you have a proper Ultra ATA-capable 40 pin, 80 conductor cable with the blue (system board), black (master) and gray (slave) connectors? - if you are using a 'normal' (an all gray) ATA cable, then it won't work in ATA100.

Cable Select is known to be unreliable, so it is best not to use it - make sure that you have the proper ATA100 cable and then try jumper-ing the drives properly. I would try getting this right with only the Hitachi drive connected first - leave the others off for now.

Back tomorrow - I'm on GMT and it's 00:35 hrs! (I think Sweden must be on GMT+1)


Ian.  8)

Yes, I have the 40-pin, 80-conductor cables. As a matter of fact, the "modern" round variant which should improve air circulation in the case but I don´t know about that. A degree maybe ......  ::) ...... but the scientists still debate whether it´s a degree Celsius or a degree Fahrenheit!
I use them because they are slightly longer. If I use the flat ones, one of them is stretched over its length and puts a mechanical stress on the connectors.

Cable Select only works with the 80-conductor cables which have one conductor grounded on the Slave connector but not on the Master connector. My devices have always been detected correctly on CS and since the computer doesn´t boot with any other jumping on the HDDs, it would be a dead end even trying.

When I was experimenting with different combinations of hardware on the controllers, to find out if Independent Device Timing was working with my motherboard, I drew the conclusion that I had used up all my luck for a while ......  8) ...... not breaking any connectors.

I´ll make one test, though, which will be to disconnect all other devices but the 7K250 and see what happens. As I mentioned earlier, I believe that it´s a problem with the software (Ghost), not the hardware.

Christer,
who will leave (almost) nothing untried

Hi Christer.

'the computer doesn´t boot with any other jumping on the HDDs'

This is NOT right! Can you try another cable, as if the machine cannot boot WITHOUT using Cable Select then somethings definitely wrong! - there may be a setting in the BIOS to disable CS.

Try using a flat cable with the drive jumpered and propped-up inside the case, so as not to strain the connections - If the PC still will not boot then it looks like you have a hardware problem (cable, drive or controller) - you must get the PC to boot using the jumpers before you can sort-out the speed problem.

Let us know what happens!

Ian  8)

I have created and checked another Image, this one of a partition on the 60GXP.

A reminder of my partitions:

7K250 - C: - D: - E:

60GXP - F: - G:

This time I created an Image of F: to E: as well as G: with the results below:

Target partition E: - create in 10min 41sec at 136 MB/min - check in 9min 59sec at 145 MB/min

Target partition G: - create in 4min 14sec at 342 MB/min - check in 3min 43sec at 390 MB/min

The different Image gave slightly different rates but it definitely rules out the read-write theory (different HDDs or different partitions on the same HDD) and points towards either some unknown (to me at least) feature of the 7K250 or some bug in Ghost.

Maybe I´m lazy and/or stupid but I wont bother disemboweling the computer as You suggested, Ian, since I´m 99.99% certain of the outcome. As I mentioned before, I have powered off the 60GXP in the rack, leaving the 7K250 alone on the Primary, with the same results.

Christer

By the way, I started a thread (http://forums.storagereview.net/index.php?showtopic=14374) over at StorageReview (http://www.storagereview.com/index.html). A Guy over there was adamant on the read-write theory and that´s why I did the test to prove either him or me wrong.

Hi Ian!

We were typing at the same time but You hit the button sooner!


Quote:

This is NOT right!

Oh YES, it is!

When doing the experimenting on Independent Device Timing, I tried all combinstions of hardware, cables and jumping. No matter which cable was used, the Primary Master was only detected if it was jumpered as Cable Select. It was not detected jumpered as Master or "Force Slave Present".
The reason for trying FSP was the empty rack connected to the Primary Slave (I had not yet taken delivery of the new HDD at the time).

Maybe I´ll sit down and think about it. The HDD that wasn´t recognized as PM was the 60GXP. Maybe the 7K250 is different?
I wouldn´t think so but OK, I´ll give it a try!

Christer

Hi Again!

No matter which cable was used, the Primary Master was only detected if it was jumpered as Cable Select. It was not detected jumpered as Master or "Force Slave Present

I still think this is NOT right!!

Any and every drive SHOULD work using the jumpers - I still think you have something wrong somewhere.

When you have the time (and feel like it!) disconnect ALL drives and then try it with just the Hitachi connected with a FLAT cable (i.e., NOT the cable you usually use) Check the BIOS to see if there is anything to do with CS and if so, DISABLE CS. Then you can start trying to find out why the drive only boots when using CS.

USING JUMPERS IS THE DEFAULT AND SO SHOULD ALWAYS WORK -  IN ADDITION, CABLE-SELECT IS KNOWN TO BE UNRELIABLE! (I'm NOT shouting here!  :))

You can start by connecting the drive to IDE2 (as long as nothing else is connected, it will still be able to boot from IDE2) and see if it is a fault with the controller or motherboard.

You can also try clearing the BIOS and letting it detect the drive again (make a note of your BIOS settings and then power-off and take out the back-up battery - wait five minutes and then re-insert the battery, power-up and re-enter your BIOS settings - this will force a clean detection of your hardware, i.e. your drive.

From your first post it seems that the drive has been under-performing from the start - this may help.


Ian.  8)

Ian,
while You were typing and posting, I was doing almost exactly as You suggest!

1)
I jumpered the 7K250 to Master and restarted the computer which booted OK.
Shut down and next, I removed the 60GXP physically from the rack and restarted the computer which booted OK.
Obviously there was something not quite right with the firmware on the 60GXP when that one didn´t boot jumpered to Master. (It only occured after connecting the empty rack to the Primary Slave connector.) The 60GXP has since received an updated version of the firmware but it will never again have an Operating System installed on it so, we will never know.

You were right that it was wrong but I was not wrong that it was right since it was a fact ......  ;D ...... !

2)
I physically disconnected all drives apart from the 7K250 and booted from the Ghost Boot Disks and ran a check ......  :'( ...... which was a slow as before, no change, not even a second quicker.

I did not dig out the old flat cable since I am 100% sure that there is nothing wrong with the ones that I use. Tried all combinations of hardware and cables when testing Independent Device Timing.

3)
Now on to the things I didn´t do:


Quote:

Check the BIOS to see if there is anything to do with CS and if so, DISABLE CS.

Doesn´t the DEVICE set it self to either Master or Slave, depending on which connector, when using Cable Select? I dont think that happens on the motherboard but I´ll shut down and restart to check.


Quote:

You can start by connecting the drive to IDE2 (as long as nothing else is connected, it will still be able to boot from IDE2) and see if it is a fault with the controller or motherboard.

Since the 60GXP worked OK on IDE1 as the single HDD (Master) on that controller and it still works OK on IDE1 as Slave to the 7K250, I think that I know the result of trying to connect it to IDE2


Quote:

You can also try clearing the BIOS and letting it detect the drive again ...

Well, that´s possibly the last stone to turn but it would mean getting down on the floor again ......  >:( ...... !
Since I don´t believe that it will work, I will probably have to sit down and reassure myself that it should be done, just to rule out the last (?) possibility.


Quote:

From your first post it seems that the drive has been under-performing from the start - this may help.

The drive performs as expected when Ghost is out of the picture. The AIDA32 benchmarks indicate that.

It is only when running Ghost that the performance gets crippled!

I can rerun the benchmarks and save the screens to post here.

Christer

If anyone is interested in the Rack-issue and Independent Device Timing, follow the links below to two threads on the Windows BBS (http://www.windowsbbs.com/)

http://www.windowsbbs.com/showthread.php?s=&threadid=25654

http://www.windowsbbs.com/showthread.php?s=&threadid=25915

Christer

Hi Again Christer.

I only mentioned changing the cable to see if it was the cause of the CS/jumper problem - obviously it now works OK!

It would appear that unless you have a fragmentation problem, then it must be as you say - a problem with Ghost itself. (with a much larger cache the Hitachi drive should be noticeably faster)

I wish I could remember where I had a Ghost Error Report, but I last got one over a year ago, (when I started using Ghost) and I can't remember how to get one! The error report would at least confirm that Ghost is using DMA.

I'll do a bit more thinking!


Ian  8)

Hi again, Ian!

I´ll have a look in the Ghost manual to see if anyting is said on this matter.

The promised Images (no, not the Ghost variant) below, there are some dips during Quick Linear Read and Buffered Read due to unknown interference. I only disconnected from Broadband and disabled Norton AntiVirus and Norton Personal Firewall. Probably should have been more thorough.

http://img33.photobucket.com/albums/v98/Engdahl/AIDA32/7K250_QLR.jpg

http://img33.photobucket.com/albums/v98/Engdahl/AIDA32/7K250_RR.jpg

http://img33.photobucket.com/albums/v98/Engdahl/AIDA32/7K250_BR.jpg

http://img33.photobucket.com/albums/v98/Engdahl/AIDA32/7K250_AA.jpg

Christer

From one of my earlier posts:


Quote:

One observation that I have failed to mention is that the time ticks down second by second when the 60GXP is at work but when the 7K250 is at work, it can pause for several seconds (5-10) and then it catches up.

That was when C: on the 7K250 had been imaged.

The latest Image I created was of F: on the 60GXP.
Now, when the Images are checked, the 60GXP stalls whereas the 7K250 runns smoothly.

I have stared at the screen and have come to the conclusion that when the checking is still on the first span (*.gho) then it ticks on by the second but it starts stalling as soon as it gets into the second span (*.ghs)

......  ??? ...... Christer ......  :-/ ......

Ian,
early in the discussion You provided a link to a Symantec webpage dealing with the GhstStat.txt which can be created to the floppy using the swith -dd. I´ve cut and pasted the relevant bit from mine:


Quote:

Drive 128 HDS722512VLAT80       VNR33EC3C9DR1K Int 13h Total Sectors     16450560 Bytes per Sector  512 MB                8032 Cylinders         1024 Heads             255 Sectors per Track 63 Extended Int 13h Total Sectors     241254720 Bytes per Sector  512 MB                117800 Cylinders         16383 Heads             16 Sectors per Track 63 IDE using PIO Total Sectors     241254720 Bytes per Sector  512 MB                117800 Cylinders         65535 Heads             1 Sectors per Track 63 IDE using UDMA (Active) Total Sectors     241254720 Bytes per Sector  512 MB                117800 Cylinders         65535 Heads             1 Sectors per Track 63 Drive 129 IC35L040AVER07-0          SX0SXL17272 Int 13h Total Sectors     16450560 Bytes per Sector  512 MB                8032 Cylinders         1024 Heads             255 Sectors per Track 63 Extended Int 13h Total Sectors     80418240 Bytes per Sector  512 MB                39266 Cylinders         16383 Heads             16 Sectors per Track 63 IDE using PIO Total Sectors     80418240 Bytes per Sector  512 MB                39266 Cylinders         16383 Heads             16 Sectors per Track 63 IDE using UDMA (Active) Total Sectors     80418240 Bytes per Sector  512 MB                39266 Cylinders         16383 Heads             16 Sectors per Track 63

Since it says "IDE using UDMA (Active) for both drives, the whole situation becomes even more confusing!

The Symantec Descriptions are needed to understand the contents: http://service1.symantec.com/SUPPORT/ghost.nsf/docid/1999090210274225?Open&src=&docid=1999021911433525&nsf=ghost.nsf&view=pfdocs&dtype=&prod=&ver=&osv=&osv_lvl= and
http://service1.symantec.com/SUPPORT/ghost.nsf/pfdocs/1999021911433525

Christer

Christer I have just noticed something from your 'GhstStat.txt' post.

Ghost is not using the 'Extended Int13h ' access method.

Try running Ghost with the 'GHOST -FFX' switch.

Let me know if it makes a difference!


Ian  8)

Premature post!!

I thought that Ghost needed to use that method as well as DMA, but they appear to be mutally exclusive!

The only thing I can now suggest is trying out the various switches that control the disk access method, and seeing if there is any difference.

Ian  ???

Ian,
I´ve tried these combinations:

-ffx

-fni -ffx

-fnx - ffi

-ffi (which is the default Ghost choice of its own)

The only thing that happens is that one Active substitutes the other. No change in performance, though.

I think it´s time for a chat with Symantec Support. That will, however, have to wait a while because I don´t want to start it now and leave for a week of holidays on friday evening.

But when I get back ......  >:( ......  :-/ ......  :-X ...... !

Christer

Hi Christer.

OK.

I'll have a think about it until you do (contact Symantec) and see if I can come up with anything.

I must admit it's rather puzzling!!

It will probably turn out to be something obvious/simple!


Ian  8)

Well Ian,


Quote:

I must admit it's rather puzzling!!

I had "a grey streak" to my hair when this started developing and I don´t think that the colour has changed in a positive way ......  :o ......!


Quote:

It will probably turn out to be something obvious/simple!

I suspect that too but it will be a real challenge to compile a "question" to Symantec Support in a way that makes them understand the problem and at the same time keeping it short.

I will provide a link to this thread, though, just to demonstrate that we have tried our best.

Christer

I'd be interested to hear what they say.

Stumpy

Like the Governor says ......  >:( ...... I´ll be back!

Christer

I did a seach for "slow" in the Symantec Support database and it came up with this (the only document with a bearing on the situation):

http://service1.symantec.com/SUPPORT/ghost.nsf/8f7dc138830563c888256c2200662ecd/8e630335d1b9274388256a480063a14e?OpenDocument&prod=Norton%20Ghost&ver=2003%20for%20Windows%202000/NT/Me/98/XP&src=sg&pcode=ghost&svy=&csm=no

Well, the -fnu switch didn´t force it to use PIO but Ext Int 13h. I have used any and all combination of switches and I have even managed to crash Ghost ......  ;D ...... !

Christer

You have a real head-scratcher there.

When performing a Ghost BackUp of my primary active partition, the rate at which it is performed turns out to be disappointingly slower using an external HDD connected via USB 2.0 as a destination contrasted to the exact same task where a logical drive in the extended partition onboard the same internal HDD is the destination.

Maybe I ought to do some comparisons between the two options shown in the image below.

[glb]El Pescador[/glb]

http://img.photobucket.com/albums/v235/El_Pescador/HotSwap6.jpg

I would try changing the preferences but I don´t know if it will work better afterwards. I´ve never used a gizmo like that!

Christer

As I suspected, Write caching and Safe Removal are policies restricted to removable HDDs.  I am not clear at all as to whether or not a HDD in a mobile rack is categorized the same as external HDDs connected via USB 2.0 or Firewire cables.


[glb]El Pescador[/glb]

It's referring to 'Write Behind'


This means that the data to be written to disk is kept in memory and not actually written when the program reports it has been written, e.g. when something is saved, or the program exitted  - the data is written when the system can spare the time - it writes BEHIND (after) the actual program says it has finished writing.


Ian 8)

Quote:

I am not clear at all as to whether or not a HDD in a mobile rack is categorized the same as external HDDs connected via USB 2.0 or Firewire cables.

My 60GXP is in a mobile rack but the rack is connected as Slave on IDE1 which means that the OS doesn´t know it is removable.

A HDD connected via USB or FW is probably per definition of the ports that are used, considered to be removable.

Christer

Just checking in to see what's happening with the mystery.

Hello all,
I´m back from my vacation in Norway and will continue with my query to Symantec Support on my problem.

I have wondered if I´m the only one using the 7K250 and Ghost?

No one has neither commented on having the same drive and the same problem nor commented on having the same drive but not the problem.

:-/ ...... Christer ......  ???

My query to Symantec Support:


Quote:

I have a problem with differing transfer rates on my hard drives when either creating an Image or checking the integrity. I gave not yet had the reason to restore using an Image. My hardware setup: Primary Master – Hitachi Deskstar 7K250 – three partitions C: NTFS – D: NTFS – E: FAT32 Primary Slave - IBM Deskstar 60GXP – two partitions F: NTFS – G: FAT32 Secondary Master – Samsung SW-408B Secondary Slave – Samsung SD-612S I run ghost.exe from Ghost Boot Disks with CD/DVD support but have also tried a Standard GBD w/o CD/DVD support but the results are the same (identical). When creating an Image of C: to E: or when checking the integrity of the Image on E:, the operation is 2.5-3 times slower than when creating an Image of C: to G: or when checking the integrity of the Image on G:. When creating an Image of F: to G: or when checking the integrity of the Image on G:, the operation is 2.5-3 times quicker than when creating an Image of F: to E: or when checking the integrity of the Image on E:. During the creation of an Image with the target partition on the 60GXP, the rates are approximately 342 MB/sec and the rates during the integrity check are approximately 390 MB/sec. During the creation of an Image with the target partition on the 7K250, the rates are approximately 136 MB/sec and the rates during the integrity check are approximately 145 MB/sec. I have tried all combinations of switches (-ffi, -ffx, -fni, -fnx and -fnu) when creating Images and checking the integrity. There is no way to force the 7K250 to use PIO instead of UDMA. I have benchmarked both hard drives using the utility in AIDA32 and there is no problem with the 7K250. It outperforms the 60GXP in that test. I tried to copy ghststat.txt but the message became too long. I would appreciate any advice on how to correct this problem concerning the low rates on the 7K250! Thanks for Your time, Christer

I/we should receive a response in 4-5 business days.

Christer

How was Norway?

I've never been.

Land of the Vikings & Norsemen.

I think they make Opera, the browser, in Norwway.

Norway is a small country bordering to Sweden, Finland and Russia. The nature is quite beautiful with ondulating landscape in the south, developing into mountains towards the north. The only drawback is that the price level is rather high, approximately 1½-2 times the level in Sweden. Some people actually work in Norway but live in Sweden, taking the benefit of higher wages and lower living expenses on the respective side of the border.

We were in Vågå which is a small community within the Jotunheimen National Park ( http://www.lonelyplanet.com/mapshells/europe/norway/norway.htm ) with the two highest mountains in Norway, Glittertind (2464m MSL) and Galdhöpiggen (2469m MSL).

We were taking off from (and landing back on) a frozen lake, Vågåvattnet, at 370m MSL.
I made a flight, releasing from the tow plane at 1.200m GND and the highest altitude I reached was 6.600-6.700m GND. If You add the 370m starting altitude, You´ll get approximately 7.000m MSL which is the limit for the quite simple oxygen equipment we use in gliders. You can fly higher but then You need to get personally adapted equipment, emergency oxygen and take tests in an under pressure chamber.

That flight earned me a diamond in my badge for a 5.000m altitude gain above the lowest point after release from the tow plane, well, 5.513m to be exact ......  ;D ......

We are utilizing waves to gain altitude. The waves are formed under certain conditions. You need to have a positive wind gradient with increasing altitude (wind speed increasing with the altitude) and an obstacle (a mountain) to get the air to start undulating like sinus waves. If a second obstacle (another mountain) is in the path the wave pattern is augmented. The positive wind gradient makes it increase its amplitude to great hights.

Christer

By the way, MSL = above Mean Sea Level and GND = above Ground.

That's a coincidence!

I was planning to do a five-day gliding course here:

http://www.kent-gliding-club.co.uk/cgi-local/public_headline.cgi

last year, but I didn't get round to doing it during the summer - in winter the days are too short, so you can't get in as many flights per day.

I was going to try again this year, but I will have to see what happens.

I last did some flying when I was 14, and there's a bit about it, (in my rather c****y web site!) here:

http://web.ukonline.co.uk/ie.dunster/


Ian  8)

Well, before someone else states the obvious ......  ::) ...... it´s a small world!

I started my gliding training in 1974 and managed to get my license in 1975. Since 1982, I´ve been Chief of Operations in our club and since 1996, I´ve "worked" as a Flight Safety Instructor for the Swedish Soaring Federation. "Worked" within double quotes since it´s not an activity that increases my wealth, rather the opposite but it is quite interesting.

Whenever You end up in the extreme south of Sweden ......  ;) ......

Christer

I quote their response to my first question(s):


Quote:

Hello Christer, Thank you for contacting Symantec Online Technical Support. From your message you are wanting help to speed up the performance of Ghost while create images in various ways.  The speed slowdown seems to be from the 7K250 hard drive alone. You have attempted about all the relevant switches that are available.  The only one that I can think of using is the -NTC- switch (Disable NTFS contiguous cluster run allocation.)  This switch is useful when the MFT is fragmented and Ghost is trying to read it while making an image. Also it could depend upon what compression you are using.  With High, it would be slower.  At None and at Fast there may be no noticeable slow down.   It could be that the hard drive is slow to be accessed when imaging to the hard drive, or when imaging from the hard drive.  If the -NTC- does not help, there really is no way to speed up the Ghost operation.   Please let me know if you have any additional questions. Best regards, Franz Lochridge Symantec Authorized Technical Support

and my follow up question(s):


Quote:

Hello Franz, thanks for Your prompt response! The -ntc- switch made no difference. I honestly didn´t expect it to, since the 60GXP performance is not affected by any possible MFT fragmentation. The number of MFT fragments on the imaged partition is two (2), which is the minimum number. The images all reside on FAT32 partitions. A few thoughts: The -fnu switch does not force PIO as it is said to do, see: http://service1.symantec.com/SUPPORT/ghost.nsf/8f7dc138830563c888256c2200662ecd/8e630335d1b9274388256a480063a14e?OpenDocument&prod=Norton%20Ghost&ver=2003%20for%20Windows%202000/NT/Me/98/XP&src=sg&pcode=ghost&svy=&csm=no It forces Extended Int 13h on both the 7K250 and the 60GXP. Is that an error in the knowledge base or an error in Ghost? The rates for the 7K250 is only slightly quicker than the performance of my CD-R/RW Samsung SW-408B. This prompts a few questions: How does Ghost determine which device it is reading from / writing to? Does Ghost do its own detection or does it go by BIOS information? How does Ghost adapt to different drives? I have copied the ghststat.txt below and I hope that the contents may reveal the cause and provide a solution: (ghststat.txt omitted) Best regards, Christer

and I, as usual, forgot something:


Quote:

Hello again, Franz! I forgot to mention that I use no compression. Best regards, Christer

Let´s wait and see if he is inclined to dig deeper into my issue.

Christer

I have now sent a message to Hitachi with the approximately same contents as the first message sent to Symantec Support.

Maybe they know what´s up and have a firmware update or something else up their sleeve.

Christer

It could be that the hard drive is slow to be accessed when imaging to the hard drive, or when imaging from the hard drive.

Yes, we know that, but why?


Ian.  8)

The second reply from Symantec Support which I think is leading into a dead end:


Quote:

Welcome Back Christer, After some research, the compression level would have been the only thing that I could have suggested.  Since you are using Even with no compression, there still is no way to speed up the Ghost operation with a switch.  It really is dependant upon the drive, it's internal speed, and the motherboard.  Those factors are the biggest factors in determining the speed of the transfers. Best regards, Franz Lochridge Symantec Authorized Technical Support

I have received the first response from Hitachi but they mistook my drive for a SATA. It is a PATA.

They said that the rates are normal for a SATA drive ......  ??? ......  :o ...... !

Christer

'Welcome Back Christer,'


I didn't know that you'd been away!!

(Just back from pub! -  00:26hrs GMT - slightly p****d!)


Ian.  8)

On second thoughts, perhaps you told them you were going to Norge!

As I said, I am a bit p****d!

Apologies Christer!!


Ian!  8)

No worries! ...... or how they say it down under?

Symantec Support are always very polite. When You get back to them a second time on the same issue, that´s always the greeting - Welcome Back!

I´ve had a few "conversations" with them but we are not on such friendly terms that I tell them where I spend my vacation ......  ;) ......

Christer

I had a few beers last night!



Ian.  :-[

Ian,
I´m glad that I didn´t have a few beers because I managed to reply to a "non-reply" address to Hitachi!

I did it right this time (I think) and sent this message:


Quote:

With reference to the below pasted response, I´d like to thank You for Your promtness! The drive is however not a SATA, it´s a PATA and I don´t know if it makes a difference. If the low rates are normal for the PATA too, is there an explanation for the low rates for the 7K250 in combination with Ghost? Our latest correspondence: Dear Mr Engdahl, thank you for your email. We checked with our technical department and the tranfer rate that you mention is the right one for SATA drives. If you need further information please don't hesitate to contact us again Best Regards Hitachi Global Storage Technologies ------------------ In Response To ------------------ Delivered Date: 03-24-2004 08:17:59+6 First Name: Christer Last Name: Engdahl Email: christer.engdahl@bredband.net Phone: Country: Sweden Family: deskstar Serial Number: C3C9DR1K Model Number: HDS722512VLAT80 BIOS: Award Modular 04/09/03 Operating System: Windows XP Professional SP1 Subject: Support feedback from: Christer Engdahl Comments: I have a problem with differing transfer rates on my hard drives when either creating a Norton Ghost Image or checking the integrity of an Image. I have not yet had the reason to restore using an Image. My hardware setup: Primary Master – Hitachi Deskstar 7K250 HDS722512VLAT80 – three partitions C: NTFS – D: NTFS – E: FAT32 Primary Slave - IBM Deskstar 60GXP IC35L040AVER07-0 – two partitions F: NTFS – G: FAT32 Secondary Master – Samsung SW-408B Secondary Slave – Samsung SD-612S I run ghost.exe from Ghost Boot Disks with CD/DVD support but have also tried a Standard GBD w/o CD/DVD support but the results are the same (identical). When creating an Image of C: to E: or when checking the integrity of the Image on E:, the operation is 2.5-3 times slower than when creating an Image of C: to G: or when checking the integrity of the Image on G:. When creating an Image of F: to G: or when checking the integrity of the Image on G:, the operation is 2.5-3 times quicker than when creating an Image of F: to E: or when checking the integrity of the Image on E:. During the creation of an Image with the target partition on the 60GXP, the rates are approximately 342 MB/sec and the rates during the integrity check are approximately 390 MB/sec. During the creation of an Image with the target partition on the 7K250, the rates are approximately 136 MB/sec and the rates during the integrity check are approximately 145 MB/sec. I would appreciate any advice on how to correct this problem concerning the low rates on the 7K250! Thanks for Your time, Christer

Christer

Sounds like the boyz at Symantec aren't being very helpful.

Well, they aren´t breaking their backs!

I don´t know the weight of an E-mail but they must get tons of them. I wonder if they have a system to assist in deciding if a problem is a one-off or if it is a true Ghost Bug?

Christer

An update:

I thought of the XP motherboard drivers which are the ones installed during XP setup and I updated to VIAs own drivers in two steps, first to 4in1_v443 which is the lates for the "older" chip sets and then to 4in1_v451 which "can" cause problems with "older" chip sets.

Well, I didn´t have any problem with any of them ......  :( ...... other than that the issue with the 7K250 persists.

Christer

In the mean time, I´ve been juggling connectors and checked my smallest Image of 1.026 MB on different hardware setups.

First, a reminder of the hardware setup that I normally use and the rates:

Primary Master - 7K250 - 143 MB/min
Primary Slave - 60GXP - 425 MB/min
Secondary Master - CD-R/RW
Secondary Slave - DVD-ROM

Next, after juggling connectors:

PM - 7K250 - 143 MB/min
PS - DVD-ROM
SM - 60GXP - 135 MB/min
SS - CD-R/RW

The reduced rate for the 60GXP indicates that in DOS environment, it makes a difference if a UDMA device is mixed with a non-UDMA device on the same channel.

PM - 7K250 - 143 MB/min
PS - none
SM - 60GXP - 425 MB/min
SS - none

The restored rate for the 60GXP supports the mixing theory.

The 7K250 alone on Primary, nothing on Secondary - 143 MB/min
The 7K250 alone on Secondary, nothing on Primary - 137 MB/min

There is a slight difference between the channels but I don´t know why. Maybe it´s performance scatter?

Christer

By the way, someone over at the StorageReview forum, told me that his 160 GB PATAs work well, imaging from the one to the other. I have asked him what he conciders to be well.

The second response from Hitachi came today and I quote:


Quote:

Dear Sir, Thankyou for your reply. I am not sure exactly what Ghost means by 342MB/s during the creation of the image, as the drives can ony ever read / write at a speed of 100MB/s Are you sure it is MB/s and not Mb/s ? ie megabits as opposed to megabytes ? The reason why you are seeing differences in 'speed' when you are creating your image is to du with the seeking involved. When you are copying to a partition on the same drive, there is a lot more seeking by the actuator as it reads and writes. ie the actuator is constantly moving between reads and writes. When you use a partition on a separate drive, the C: can happily read and read, as the actuator on the second drive is happily writing. Regards

With a blushing face I posted this reply:


Quote:

Dear Sir! With reference to the below pasted response, I´d like to thank You for Your assistance! In my first question, I made a typing (?) error and gave the wrong rates. The rates quoted should be MB/min, not MB/sec and I´m very sorry for that mistake and any confusion caused by it. I have carried out three different tasks with Ghost in a DOS environment, create images, check the integrity of images and restore images to the original source partition. The rates for the 7K250 are consistently 2.5-3 times slower than the rates for the 60GXP. If both the source partition and the target partition are on the 7K250 or if the source partition is on the 60GXP and the target partition is on the 7K250 doesn´t matter. The 7K250 is slow. If both the source partition and the target partition are on the 60GXP or if the source partition is on the 7K250 and the target partition is on the 60GXP doesn´t matter. The 60GXP is 2.5-3 times quicker. The correct rates for the below tasks are: Create an image to a target partition on the 7K250, 136 MB/min. Check an image on the 7K250, 145 MB/min. Create an image to a target partition on the 60GXP, 342 MB/min. Check an image on the 60GXP, 390 MB/min. An image integrity check is a read only operation which means that seek time is not an issue as in a read/write operation which is probably the cause for the different rates during the respective task. It is noteworthy that the difference between create and check is 14 % for the 7K250 compared to 7 % for the 60GXP. I have made several tests, which all verify the above quoted rates (six different images created to both drives which makes each image identical on both drives). The 7K250 is a HDS722512VLAT80 – firmware V33OA60A The 60GXP is an IC35L040AVER07-0 – firmware ER4OA45A Best regards, Christer Engdahl (copy of their response omitted)

They are at least doing something and I really appreciate it. I have probably stirred their curiosity.

Christer

It´s been over three weeks since my latest (last?) correspondence with Hitachi but still no response.

Maybe, they are busy investigating the issue (fat chance, heh) or my investigation into it has come to a halt.

Christer

Thanks for checking in. I've been watching this thread.

I still think there's something very funny with your drive - at least under DOS.

Ian.  8)

Well, I´m in the process of convincing a friend that he needs a HDD like mine ......  :-/ ...... he is even more computer illiterate than I am so I guess that I will have to assist him installing it ......  :D ...... after a detour via my system for tests.

If that one is performing better under DOS, then my HDD is going back to the seller. If not, I´ll have to accept its performance under DOS as an oblation on the sacrificial altar of GHOST. It is not a daily occurence ...... :-X ......

Christer

Christer

You might find this of interest...

I think the problem may be a compatibility issue between the various hard drives and the hard drive IDE controller on the motherboard's chipset, and how the chipset's controller is implemented by the motherboard's maker, rather than the hard drive itself or the Norton Ghost program.  Here's why I think that....

My setup:  I have an Abit KG7-Raid motherboard.  It has two IDE hard drive controllers--the standard VIA VT82C686B southbridge controller chip, and a built in HighPoint 370/372 Raid controller chip which can be used either as a Raid controller or just another IDE controller for additional hard drives.  Each of the controller chips has the standard primary and secondary channel, and each channel can have a master and a slave device.

I have the following hard drives:

a matched pair of Seagate 120 GB, model ST3120026A

one IBM Deskstar 40 GB, model 60GXP (same model that you have--it's actually made by Hitachi and was private labeled as an IBM)

one Hitachi Deskstar 40 GB  (A warranty replacement from Hitachi for an IBM Deskstsar 60GXP that failed last month)

So, I can create a large number of combinations of hard drive/controller match-ups.  I tested using the Image Creation speed rather than the Image Integrity Check speed, and in each case I'm reporting below, I'm using Image Creation without Compression.  So here's what I found...

If I had the Seagate 120 GB on the HighPoint primary channel as master and I tried to image to either the IBM 40 GB or the Hitachi 40 GB on the VIA secondary channel as slave, the image creation speed was 115 MB/min.

But, leaving the Seagate 120 GB on the HighPoint primary channel as master, if I switched either the IBM 40 GB or the Hitachi 40 GB to the HighPoint secondary channel as slave, and I imaged from the Seagate to either the IBM 40 GB or the Hatachi 40 GB, I now got an image creation speed of 1176 MB/min.  Quite a dramatic increase!

Now, again leaving the Seagate 120 GB on the HighPoint privary channel as master, I hooked the second Seagate up to the VIA primary channel as master, when I imaged from the Seagate 120 GB on the HighPoint controller to the Seagate 120GB on the VIA controller, I got an image creation speed of 1195 MB/min.  And when I imaged from the Seagate on the VIA controller to the Seagate on the HighPoint controller, I got an image creation speed of 1363 MB/min (which was the fastest combination I found).

I also imaged from the Seagate on the VIA primary channel as master to the Hitachi 40 GB on the HighPoint secondary channel as slave and got an image creation rate of 1274 MB/min.

However, if I put one of the Seagates on the VIA primary channel as master and the other Seagate on the VIA secondary as master, I now got an image creation rate of 128 MB/min!

I did a couple Image Integrity Checks along the way, and they all had speeds that were between one third to one half again faster than their corresponding Image Creation speeds.

So, all the hard drives showed the potential to create images at a high speed and Ghost could deliver the high speed with each of the drives, but it depended on which controller the hard drives were matched up with.   All the hard drives worked well if they were on the HighPoint controller, but only the Seagate showed a high creation speed when it was on the VIA controller's primary channel as master and imaging to and from other hard drives on the HighPoint controller, but not other drives on the VIA controller.

I'm betting it's a VIA controller issue under native DOS.  And the problem may not exist under Windows because you're then using the 4in1 VIA drivers.  You used test programs to check the speed of your drives--were those programs under Windows, or do they check things under native DOS?  I don't know the answer to this, but what 'driver' is the VIA IDE controller using under native DOS when you're not using Windows?

It's interesting that it's your IBM Deskstar that is showing the better performance while my IBM Deskstar is showing poorer performance when on the VIA controller--that's why I think it's how the motherboard maker has implemented the chipset on their particular board that's making a difference being as I believe we both have the same VIA controller, but we have different brands of motherboards.

Given all this, it looks like one might do well to 'test drive' several different brands of hard drive to see which one gives the better results before making a 'final' purchase--however, not an easy thing to do.  And I wonder if any folks with an Intel based chipsets have similar issues?  There must be some other folks with integrated Raid chips from HighPoint or Promise, or are using PCI add-on IDE controller cards, either with Raid or just for additional hard drives, either on a VIA chipset board or a Intel chipset board--any other input would be interesting to hear as to performance depending on which controller one uses with which hard drives.

Hello NightOwl
thanks for Your reaearch into this!

I am very sad right now ...... :'( ...... almost crying. I spent the best part of half an hour to compile a reply ...... >:( ...... and accidentally clicked on one of those links that takes you back to the main page ...... :o ...... and all was lost in cyberspace.

<Insert adequate number of curses and language abuse>

I´ll be back later, nice and calm,
Christer

Quote:

... and all was lost in cyberspace... Christer

The above has happened to me often enough to where I now open up a WordPad file to 'mirror-image' my posts once well underway, continually updating it as I go along - in such a mishap, a significant portion of my text is preserved for reconstruction.

[glb]El Pescador[/glb]

El Pescador

Yup--have to agree.  The rather long and involved post above would have been lost if I had composed it within the 'Post Reply' area of this forum.  When I tried to post-it, I experienced some sort of Internet slow down, and the post-it command timed out and the whole thing was lost.

But, I had composed it using 'WordPad' and had just 'copied' and 'pasted' to the reply area.  It was no problem re-copying and pasting and re-posting.

Well guys, it's not the first time and I try to remember to either do the typing in Word or back it up there. When using a lot of quotes, I tend to NOT do it the safe way but I guess I'll remember now ...... :-/ ...... for a while.

Now, to my thoughts and comments:


Quote:

I have an Abit KG7-Raid motherboard.  It has two IDE hard drive controllers--the standard VIA VT82C686B southbridge controller chip, ...

I don't remember if I mentioned my system basics but it is EPOX 8KTA3 with VIA KT133A+VT82C686B. I actually tried to update the 4in1 drivers but that was out of pure frustration, since they don't get loaded when not starting Windows. That action was, of course, in vain.


Quote:

If I had the Seagate 120 GB on the HighPoint primary channel as master and I tried to image to either the IBM 40 GB or the Hitachi 40 GB on the VIA secondary channel as slave, the image creation speed was 115 MB/min.

It seems like Your Hitachi built 60GXP differs from my IBM built. The rates are approximately the same as for my 7K250 so; does Your 60GXP have different firmware or is it possible that it has the "7K250"-electronics? There must (?) be a reason for the "no difference" between Your Hitachi/IBM.


Quote:

But, leaving the Seagate 120 GB on the HighPoint primary channel as master, if I switched either the IBM 40 GB or the Hitachi 40 GB to the HighPoint secondary channel as slave, and I imaged from the Seagate to either the IBM 40 GB or the Hatachi 40 GB, I now got an image creation speed of 1176 MB/min.  Quite a dramatic increase!

Yes, it definitely points to the VIA chipset. That rate is more than three times higher than on my computer.


Quote:

Now, again leaving the Seagate 120 GB on the HighPoint privary channel as master, I hooked the second Seagate up to the VIA primary channel as master, when I imaged from the Seagate 120 GB on the HighPoint controller to the Seagate 120GB on the VIA controller, I got an image creation speed of 1195 MB/min.  And when I imaged from the Seagate on the VIA controller to the Seagate on the HighPoint controller, I got an image creation speed of 1363 MB/min (which was the fastest combination I found).

This definitely suggests a hardware conflict, VIA - Hitachi, which is supported by ......


Quote:

I also imaged from the Seagate on the VIA primary channel as master to the Hitachi 40 GB on the HighPoint secondary channel as slave and got an image creation rate of 1274 MB/min.

...... which indicates that HighPoint - Hitachi is fine.


Quote:

However, if I put one of the Seagates on the VIA primary channel as master and the other Seagate on the VIA secondary as master, I now got an image creation rate of 128 MB/min!

This indicates that the problem is basically with the VIA chipset.

The conclusion I drew from my test results was that the problem was when the target partition was on the 7K250. That is concurrent with Your test result in my first quote under which the 7K250 was the target on the VIA controller.

If You find the time, could You do a test with the 7K250 as the target on the HighPoint controller?
If that works better, then I believe that You have nailed VIA to the wall!


Quote:

I did a couple Image Integrity Checks along the way, and they all had speeds that were between one third to one half again faster than their corresponding Image Creation speeds.

My results show smaller differences (6-12%), ~136 MB/min creating and ~145 MB/min checking with the target on the 7K250, ~342 MB/min creating and 390 MB/min checking with the target on the 60GXP.
Even my "good" figures are low compared to Your "good" figures which also points to VIA.


Quote:

So, all the hard drives showed the potential to create images at a high speed and Ghost could deliver the high speed with each of the drives, but it depended on which controller the hard drives were matched up with.

As I mentioned and asked about before, If You find the time, could You do a test with the 7K250 as the target on the HighPoint controller? That's the one test You "missed".


Quote:

You used test programs to check the speed of your drives--were those programs under Windows, or do they check things under native DOS?

It was the plug-in in AIDA32. It only performs tests under Windows.


Quote:

I don't know the answer to this, but what 'driver' is the VIA IDE controller using under native DOS when you're not using Windows?

Neither do I know but a guess would be which ever driver that is loaded by the boot disk which probably is none. That leaves us with what is in BIOS.


Quote:

It's interesting that it's your IBM Deskstar that is showing the better performance while my IBM Deskstar is showing poorer performance when on the VIA controller ...

Now, You're confusing me. I was under the impression that there was no difference between Your 7K250 and Your 60GXP. See my comments on Your test #1.


Quote:

... any other input would be interesting to hear as to performance depending on which controller one uses with which hard drives.

I agree!
If anyone out there is willing to do a couple of tests, the results would be very welcome!!

Christer

Christer

Quote:

"It seems like Your Hitachi built 60GXP differs from my IBM built. The rates are approximately the same as for my 7K250 so; does Your 60GXP have different firmware or is it possible that it has the "7K250"-electronics? There must (?) be a reason for the "no difference" between Your Hitachi/IBM. "

My IBM Deskstar 60GXP was manufactured Jun-2001, Model # IC35L040AVER07-0, and part # is 07N6654.  There is no firmware number indicated.

You can go here and put in your IBM 60GXP hard drive's serial number to see if it's the listed under Hitachi:

http://www.hitachigst.com/portal/site/hgst/?epi_menuItemID=c0b801be666736fe25ad4e8060e4f0a0&epi_menuID=e41fff51ec9a8f8d5f5a530560e4f0a0&epi_baseMenuID=22f0deefa8f3967dafa0466460e4f0a0

or here:
http://www.hitachigst.com/hddt/Dlocator.nsf/Search?OpenForm

to see if your hard drive matches mine.

Quote:

"Now, You're confusing me. I was under the impression that there was no difference between Your 7K250 and Your 60GXP. See my comments on Your test #1."

I do not have a 7K250 Hitachi.  I have a 40 GB Hitachi Deskstar that was sent as a current 'equivalent' replacement for the failed IBM Deskstar 60GXP and it has a manufacture date of March, 2004.  And I have an older IBM Deskstar 60GXP.

Both the Hitachi Deskstar and the IBM Deskstar performed the same.  If either was on the VIA controller's secondary as slave, they each got the 115 MB/min image creation speed.  If either was switched to the HighPoint controller's secondary slave position, they got 1176 MB/min image creation speed.

What I was trying to say was that your IBM Deskstar 60GXP on your system using the VIA controller was performing better than my IBM Deskstar 60GXP on my system's VIA controller.

Quote:

"If You find the time, could You do a test with the 7K250 as the target on the HighPoint controller?
If that works better, then I believe that You have nailed VIA to the wall!"

Again, I do not have a 7K250, but I did put the Hitachi Deskstar 40 GB on the HighPoint controller's secondary channel as slave and got the 1176 MB/min image creation speed.

NightOwl,


Quote:

one IBM Deskstar 40 GB, model 60GXP (same model that you have--it's actually made by Hitachi and was private labeled as an IBM) My IBM Deskstar 60GXP was manufactured Jun-2001, Model # IC35L040AVER07-0, and part # is 07N6654.  There is no firmware number indicated.

I got this one right but I've got to ask: What do You mean by "private labeled as an IBM"?

Mine was manufactured in march 2001 by IBM-Thailand and has the same Model # and Part # as Yours.
There is no firmware version mentioned but I have updated my 60GXP to the version recommended by IBM.


Quote:

You can go here and put in your IBM 60GXP hard drive's serial number to see if it's the listed under Hitachi:

Yes, I've been there but Hitachi inherited the warranty commitments from IBM which means that IBM HDD's are listed too.


Quote:

one Hitachi Deskstar 40 GB  (A warranty replacement from Hitachi for an IBM Deskstsar 60GXP that failed last month)

I misunderstood "Hitachi Deskstar 40 GB" as a 7K250. That model too is named Deskstar.


Quote:

I do not have a 7K250 Hitachi.  I have a 40 GB Hitachi Deskstar that was sent as a current 'equivalent' replacement for the failed IBM Deskstar 60GXP and it has a manufacture date of March, 2004.

That is news to me. I didn't know that the 60GXP is still manufactured but I take Your word for it.
Other replacements for failing 60GXP's that I've heard about have been either a refurbished IBM 60GXP or a new Hitachi 7K250 of the corresponding capacity.


Quote:

What I was trying to say was that your IBM Deskstar 60GXP on your system using the VIA controller was performing better than my IBM Deskstar 60GXP on my system's VIA controller.

Yes, now that I have sorted out Your hardware ...... ;) ...... do I understand what You mean. The possible difference regarding firmware version doesn't matter. I noted the same transfer rates before as I do after the update.
The rates of this drive fitted my misunderstanding that You had a 7K250. It was actually somewhat slower than my 7K250.


Quote:

... but I did put the Hitachi Deskstar 40 GB on the HighPoint controller's secondary channel as slave and got the 1176 MB/min image creation speed.

Yes but my thought was which rate was acchieved with the Hitachi on VIA as source drive and one of the Seagates as target drive on HighPoint.
That would sort out if it is a write problem only or a read problem as well.
However, since it isn't a 7K250, it isn't an important test from my perspective but it would still be interesting.

On my system, it is both. From the 60GXP to the 7K250 is slow. The other way, is quick(er). From one partition to another on the 7K250 is slow but from one partition to another on the 60GXP is quick(er). Checking an Image on the 7K250 is always slow, on the 60GXP it is quick(er).

The general agent for EPOX in Sweden is located 20 km away from my home. Maybe I should give them a call and possibly get my PC over there to let them have a look.

Christer

Christer


Quote:

I got this one right but I've got to ask: What do You mean by "private labeled as an IBM"?

IBM contracted with Hitachi to make the hard drive and put an IBM lable on it that says IBM.


Quote:

There is no firmware version mentioned but I have updated my 60GXP to the version recommended by IBM.

I did not know there was a firmware upgrade available!  How do you 'flash' a hard drive--never done that one.


Quote:

That is news to me. I didn't know that the 60GXP is still manufactured but I take Your word for it. Other replacements for failing 60GXP's that I've heard about have been either a refurbished IBM 60GXP or a new Hitachi 7K250 of the corresponding capacity

I think I'm wrong here!  I thought your 7K250 model was specific to your 120 GB drive--but, I now see that it applies to several different capacity hard drives after looking further at the Hitachi site.  The reason I got this wrong is that I no longer have the hard drive on my machine.  My daughter's hard drive failed two weeks ago and I gave her that one to take back to college, so I could not look at the label.  My replacement 40 GB Hitachi Deskstar must be a Hitachi 7k250.  But regardless of the name, the performance results are as previously posted.


Quote:

Yes, I've been there but Hitachi inherited the warranty commitments from IBM which means that IBM HDD's are listed too.

Yeh-Hitachi 'inherited' the IBM warranties because they're the ones who actually made them!


Quote:

Yes but my thought was which rate was acchieved with the Hitachi on VIA as source drive and one of the Seagates as target drive on HighPoint.

You're right, I did not do that test.  I realized afterwords that that would have been a good confirming test.  But I can not use the Hitachi hard drive for the moment because my daughter has it.  And actually, I cant try the IBM right now either, because I have returned it to Hitachi for warranty replacement as well (its platter spin sound was becoming louder than the case fans)!!!!

When I get the replacement hard drive (probably in about a week), I will run that test and report it back here.


Quote:

The general agent for EPOX in Sweden is located 20 km away from my home. Maybe I should give them a call and possibly get my PC over there to let them have a look.

If you have access to other brands of hard drives that you can borrow from friends, or can install an add-on PCI IDE controller card, you could see if you can get better imaging speeds under those conditions.

NightOwl,


Quote:

How do you 'flash' a hard drive--never done that one.

First, You have to run a utility which scans for IBM drives and then check the firmware version. It will notify if a new version is available and which it is. It runs from a boot floppy and is a DOS operation.

http://www-1.ibm.com/support/docview.wss?rs=0&uid=psg1MIGR-44195&loc=sv

If needed, a flash utility with the new version can be downloaded. It creates a boot floppy and is a DOS operation. When I did it, I physically disconnected all other devices ...... :-/ ...... one never knows what can go wrong ...... 8) ...... but nothing did.

http://www-1.ibm.com/support/docview.wss?uid=psg1MIGR-43972
and
http://www-1.ibm.com/support/docview.wss?uid=psg1MIGR-44330

Sorry about the "swedish wrapping" but what You need is in english.


Quote:

My replacement 40 GB Hitachi Deskstar must be a Hitachi 7k250.  But regardless of the name, the performance results are as previously posted.

My logic wasn't all off then. Your rates correspond to my rates for the 7K250. The question is, why the rates of Your 60GXP differs from the rates of my 60GXP?

I can't help thinking about the fact that Your IBM Deskstar was manufactured by Hitachi and has the same performance as the Hitachi Deskstar. The model # and part # speak against this but it seems like Your Hitachi manufactured IBM Deskstar has the 7K250 electronics and firmware.


Quote:

Yeh-Hitachi 'inherited' the IBM warranties because they're the ones who actually made them!

I don't think so. Most 60GXP's were IBM manufactured, I didn't even know that Hitachi was involved before the purchase. When a company buys another, it buys all assets and obligations, including warranties.


Quote:

When I get the replacement hard drive (probably in about a week), I will run that test and report it back here.

I'm looking forward to that!


Quote:

If you have access to other brands of hard drives that you can borrow from friends, or can install an add-on PCI IDE controller card, you could see if you can get better imaging speeds under those conditions.

I have thought about that and came to the conclusion to not do any tests on harddives belonging to friends. None of these drives are empty. Most of them are in single harddrive systems.
As I mentioned in a previous post, I'm going to buy a second harddrive for a friend. I had planned to get an identical 7K250 to mine and do tests on that one before installing it in my friends system. That would be safe but now, I believe that I know the outcome. The test would be to get better rates from the second harddrive and identify my 7K250 as defective but Your rates indicate that the rates are "normal" on a VIA chipset.

Christer

Christer


Quote:

I don't think so. Most 60GXP's were IBM manufactured, I didn't even know that Hitachi was involved before the purchase. When a company buys another, it buys all assets and obligations, including warranties.

Once again, I could be wrong about who manufactured the IBM labeled Deskstar hard drive back in 2001.  When I was looking for warranty info, I went to this website:

http://www.storage.ibm.com/hddredr/hddredr_w.html

Based on the info about the 'IBM FRU Number', I made the leap of faith that any drive without the IBM FRU number and now supported by Hitachi, must have been actually made by Hitachi, and that's why Hitachi took over the warranties.  

And drives with the IBM FRU number must have been made by IBM (although, I'll bet IBM contracts out to others the actual manufacturing).  And I assumed Hitachi did not want to take on those warranties because they did not make those hard drives.

So, if you have information that says IBM Deskstars were made by IBM and not Hitachi, I really cant say I know otherwise except based on what I said above.

Below a copy of an email sent to EPOX-UK:


Quote:

Dear Sir's and Ladies! My motherboard is EPOX 8KTA3 equipped with an 1 GHz Athlon Thunderbird and 512 MB SDRAM PC133. Primary Master is Hitachi 7K250, HDS722512VLAT80 Primary Slave is IBM 60GXP, IC35040AVER07-0 I use Norton Ghost (under DOS, no 4in1-drivers loaded) for backup and have experienced slow transfer rates: Image creation to the 7K250 is at ~136 MB/min. Image creation to the 60GXP is at ~342 MB/min. A friend has carried out tests and these returned the same rates when on his VIA controller (VT82C686B) but when the drives are on his HighPoint controller the rates are ~1176 MB/min. Please visit our ongoing discussion at: http://radified.com/cgi-bin/YaBB/YaBB.cgi?board=general;action=display;num=1078435342;start=81#81 I hope that the link takes You to post #81 in which the discussion on VIA starts. I would very much appreciate any comment or solution to the issue with the VIA controller (VT82C686B). Thanks for Your time, Christer Engdahl

Will be interesting to read their comments and possible solution.

Christer

NightOwl,


Quote:

So, if you have information that says IBM Deskstars were made by IBM and not Hitachi, I really cant say I know otherwise except based on what I said above.

IBM has had manufacturing in several locations around the globe, including Asia and Europe. It is said that the most troublesome Deskstars were manufactured in Hungary, a plant which was subsequently closed.

I never say 100% unless I'm 200% sure I'm right and that has never happened ...... :-X ...... so, I keep the door open for 60GXP's manufactured by Hitachi.

Christer

I'm very impressed by EPOX-UK! I had the first response with a request for more information within minutes, actually while typing the reply to NightOwl!

Christer

Yesterday, I received an update from Hitachi:


Quote:

Dear Christer, I am sorry for the delay, but at the moment have no explanation as to the Ghost timings. I have been following your threads on StorageReview and also Radified, but I still have not found an explanation for your results from Ghost. Your initial benchmarks do show that the 7K250 outperforms the 60GXP, but I am not sure about the Ghost timings, apart from my intitial response. I know since then though you have now also extended the test to involve different source partitions. I will keep investigating to see if the issue has appeared elsewhere and advise accordingly. On a separate issue, you mention in a thread at Radified about using a firmware 'update tool' that you have downloaded from IBM. This tool will not work with your drives. You have a generic distribution drive, whereas the tool you are trying is specifically for drives that Hitachi have sold to IBM for use in their systems ie the drives will most likely have a different firmware. Regards

It's interesting that he/she mentions having found his/her way here and to StorageReview.
I don't remember having mentioned neither Radified nor StorageReview to Hitachi but I did mention Radified to EPOX.
Do they browse the web in general or has Hitachi and EPOX been in contact with eachother on this issue?

He/she comments on the firmware update to the 60GXP and claims that it won't work with my drives. I don't know if he/she refers to the same update, which was explicitly to "cure" the reliability issue with the 60GXP.
The fact that I did the update, has no bearing on the speed issue. I did that update before the 7K250 was installed, after a recommendation on StorageReview in order to possibly prolong the life of the 60GXP.
The "scan and check" utility found the 60GXP and identified the firmware version as in need of an update to "cure" the reliability problem.
The flash utility updated the firmware and a succeeding "scan and check" again found the 60GXP and identified the firmware as OK.
I will send a reply to Hitachi later today but I will not quote it here.

By the way, Hitachi's comment on them building drives for IBM indicate that NightOwl was right but as I understand it, generic drives are sold to computer manufacturers, not to end users like us.

Christer

I bet it's a "He".

I've been following this thread for weeks.

Christer

It's taken me a while to get back to this because, unlike the first replacement drive which came from California, and took only 2 days to arrive, this one came from Malaysia, and took 9 days to arrive.  Hmmmm... our global economy!

But now I have the Hitachi replacement hard drive and have done some more testing.  First off...


Quote:

IBM has had manufacturing in several locations around the globe, including Asia and Europe. It is said that the most troublesome Deskstars were manufactured in Hungary, a plant which was subsequently closed.

Well, maybe that plant was not really closed!  The new replacement hard drive from Hitachi is labeled 'IBM Deskstar made in Hungary for Hitachi Global' with a manufacturing date of 'May-04' and with a sticker that says 'Serviceable Used Part.'

And I say out loud with what appears to be a forced, unnatural smile, 'Greeeat...a serviceable used part IBM Deskstar made in Hungary for Hitachi Global', and the bubble above my head shows what I'm really thinking, 'Oh, s--t, a serviceable used part IBM 'DeathStar' made in Hungary for Hitachi Global.'  :D  Thanks for that information quoted above, Christer.  Now I have more confidence in the IBM Deskstars, having replaced the first two that were made in Thailand by IBM Storage Products, Ltd.

Oh, well...so far its spin is quiet, and I can only just hear the heads clicking when there's heavy access, like when creating a Ghost image...unlike the Seagates that are totally silent!

The refurbished 40 GB hard drive from Hitachi is model # IC35L040AVER07-0 and the part # is W: 07N6654, and no firmware version indicated.  I'm going to call this replacement the 'used IBM' drive.

So here's the results:

In all cases, I'm using image creation speed, and no compression.

Christer--you wanted to know the image creation speed with the 'used IBM' 40 GB hard drive on the VIA controller (I know you preferred the Hitachi 7K250 40 GB model, but I don't have that now as previously mentioned) and sending the image to the Seagate on the HighPoint controller.  Well, I noted that I had put the previous IBM Deskstar (not the 'used IBM'), and the Hitachi Deskstar on the VIA secondary channel as slave, while the Seagate was always on the VIA primary as master, so I put the 'used IBM' on the VIA primary channel as master and sent the image to the Seagate on the HighPoint primary as master and the creation speed was 1114 MB/min.  I sent the image the other direction leaving the hard drives hooked up to the same controller positions, from the Seagate to the 'used IBM' and got a 404 MB/min creation speed!

Next, I changed the 'used IBM' to the VIA secondary channel as slave as I had things setup on the original tests that I previously reported and imaged from the 'used IBM' to the Seagate on the HighPoint primary as master and got a creation speed of 991 MB/min.  And reversing the imaging direction from the Seagate to the 'used IBM', I got 132 MB/min.  That creation speed was some better, but very similar to the previous results when I got 115 MB/min when using either the Hitachi 7k250 or the original IBM Deskstar and imaging from the Seagate on the HighPoint primary as master to either the Hitachi 7k250 or the original IBM Deskstar on the VIA secondary channel as slave.

I then put the 'used IBM' on the HighPoint secondary controller as slave and left the Seagate on the HighPoint primary as master and imaging from the Seagate to the 'used IBM' gave a creation speed of 1163 MB/min, and sending the image from the 'used IBM' to the Seagate gave a creation speed of 889 MB/min.

So, again it appears to still be the case--drives on the HighPoint worked well together, but trying to send an image from a drive on the HighPoint to a drive on the VIA controller resulted in a much reduced performance, while sending an image from a hard drive on the VIA controller to the HighPoint was much better performance.  And as previously noted, if both drives were on the VIA controller, the performance was poor.

Both Norton Ghost and the hard drives show the ability to perform together at high speed, but it depends on the their position on the controller and which controller they're on...I still think the results are pointing at the VIA controller as being the problem.

NightOwl,
thanks for posting back!

I think that this mammoth thread is a record breaker and we are probably far from the finish line!!


Quote:

Well, maybe that plant was not really closed!  The new replacement hard drive from Hitachi is labeled 'IBM Deskstar made in Hungary for Hitachi Global' with a manufacturing date of 'May-04' and with a sticker that says 'Serviceable Used Part.'

Maybe I'm totally wrong but is it possible that it was originally manufactured by IBM in Hungary and subsequently refurbished elsewhere by Hitachi?

In the latest correspondence, the "guys" at Hitachi confessed to lurking here and since they have the answers, I invite them to join our discussion.

The "guys" at EPOX came off the starting-blocks rather quickly but since then - nothing.
I hope that they too are "on the case" and it's better to get a solution in due course than a quick "evasive action".

The outcome of all this will have an influence on my next purchase decision ...... :-/ ......


Quote:

... so I put the 'used IBM' on the VIA primary channel as master and sent the image to the Seagate on the HighPoint primary as master and the creation speed was 1114 MB/min.  I sent the image the other direction leaving the hard drives hooked up to the same controller positions, from the Seagate to the 'used IBM' and got a 404 MB/min creation speed! Next, I changed the 'used IBM' to the VIA secondary channel as slave as I had things setup on the original tests that I previously reported and imaged from the 'used IBM' to the Seagate on the HighPoint primary as master and got a creation speed of 991 MB/min.  And reversing the imaging direction from the Seagate to the 'used IBM', I got 132 MB/min.

These two tests indicate that it is a write problem and not a read problem. The task is slower when the IBM is the target.

I haven't found any mention of to which controller Your optical drives are connected. I assume that they are out of the picture but an optical as VIA Secondary Master would explain the drop from 404 to 132 with the IMB as the target, if VIA Primary Slave had nothing or another HDD connected.

(As a side note; I have noticed that mixing a HDD and an optical drive doesn't affect the performance of the HDD when under Windows and 4in1-drivers but under DOS, the performance of the HDD drops to that of the optical drive.)


Quote:

I then put the 'used IBM' on the HighPoint secondary controller as slave and left the Seagate on the HighPoint primary as master and imaging from the Seagate to the 'used IBM' gave a creation speed of 1163 MB/min, and sending the image from the 'used IBM' to the Seagate gave a creation speed of 889 MB/min.

This points almost all fingers, including the thumbs, to VIA but this, from Your first tests:


Quote:

Now, again leaving the Seagate 120 GB on the HighPoint privary channel as master, I hooked the second Seagate up to the VIA primary channel as master, when I imaged from the Seagate 120 GB on the HighPoint controller to the Seagate 120GB on the VIA controller, I got an image creation speed of 1195 MB/min.  And when I imaged from the Seagate on the VIA controller to the Seagate on the HighPoint controller, I got an image creation speed of 1363 MB/min (which was the fastest combination I found).

indicates that the IBM/Hitachi incompatibility could possibly be resolved by a "simple" modification of the HDD firmware. I mean, there is no incompatibility with the Seagate firmware.

The "general" differences of the rates in my system compared to the rates in Your system can probably be explained by the "general" performance differences of our respective system.
My processor is an AMD Athlon Thunderbird 1GHz/266MHz and my guess is that Your processor is in the 2.5-3 GHz range.

Christer

Christer

I was out of town for a few days and have been busy with other things, but to respond to your last post...

'And now for the rest of the story....'  

I did several additional imaging test when I was testing the 'used IBM' and regarding your comment:


Quote:

I mean, there is no incompatibility with the Seagate firmware.

I repeated the tests using the Seagates... I wanted to confirm my findings, and low and behold, the results were different this time!!!!  Computers, ya gotta love 'em!

I put one Seagate on the VIA primary channel as master and one Seagate on the HighPoint primary as master and sending the image from the VIA Seagate to the HighPoint Seagate, I got a creation speed of 983 MB/min (slower than the 'used IBM to Seagate of 1114 MB/min!), and now when I imaged from the HighPoint Seagate to the VIA Seagate, I now got 142 MB/min creation speed!  I do not know what has changed to make the results different this time, but I tried serveral times and each test was similar in results!

If you recall, on my original post I got an image creation rate of 1195 MB/min going from the Seagate on the HighPoint to the Seagate on the VIA controller, and got 1363 MB/Min going from the Seagate on VIA to the Seagate on the HighPoint controller.


Quote:

I haven't found any mention of to which controller Your optical drives are connected. I assume that they are out of the picture but an optical as VIA Secondary Master would explain the drop from 404 to 132 with the IMB as the target, if VIA Primary Slave had nothing or another HDD connected.

I have a CD-writer on VIA's primary as master, and a DVD-Rom drive on VIA's secondary as master.  I also did tests where I specifically either left them connected or disconnected to see if the image creation speed varied.  On my system, it did not matter if the optical drives were connected or not, and it did not matter if the optical drives were connected and sharing the same channnel or on separate channels from the hard drives.  However, most of the test results were with the optical drives disconnected.


Quote:

my guess is that Your processor is in the 2.5-3 GHz range.

I have an AMD Athlon XP 2100+ @1.746 GHz

NightOwl,
thanks for those tests and comments!

The information on different configurations is almost getting difficult to keep track of. I'm going to make an Excel spread sheet when I find the time.

Still waiting for the second response from EPOX. If nothing happens within next week (been a month by then), I'll resend my latest e-mail.

Christer

NightOwl,
in an early post You asked:


Quote:

And I wonder if any folks with an Intel based chipsets have similar issues?

A friend of mine has:
- ASUS P4P800 motherboard with Intel i865PE chipset
- P4 2.8GHz/800MHz
- 2x512 MB PC3200 dual channel
- one Seagate 7200.7 160 GB SATA (ST3160023AS) as boot drive with two partitions, C: and D:
- one Seagate 7200.7 plus PATA (ST3160023A) as backup drive with two partitions, E: and F:

I created an Image of C: to D: (SATA -> SATA), with a transfer rate of 817 MB/min. The integrity check was at 2370 MB/min.

I created an Image of C: to E: (SATA -> PATA), with a transfer rate of 900 MB/min. The integrity check was at 2584 MB/min.

This is more in reference to Your Seagates and not my/our issue wth the Hitachis.

Christer

Hello all,
it’s time to bump this thread with a bit of recent research results!

I believe that I have mentioned a friend, for whom I was shopping for a new HDD. Well, I finally got around to it and guess what …… ::) ...... he went by my recommendation to get a Hitachi HDS722512VLAT80, 120 GB - 8 MB cache PATA, identical to mine including the same firmware. I borrowed it for a day or two before helping him to reinstall his system on the new drive.

I formatted it to F: - 12 GB NTFS, G: - 90 GB NTFS, H: - 18 GB FAT32. Mine is identical but with drive letters C/D/E.

From C: - NTFS to H: - FAT32 was the same low rates as before, creating at 136 MB/min and checking at 145 MB/min.
From C: - NTFS to G: - NTFS, creating was at 809 MB/min and checking was at 2480 MB/min!

I put my own backup drive (IBM 60GXP) back in the rack and it has the partitions F: - NTFS and G: - FAT32.
Previous results for C: - NTFS to G: - FAT32 was creating at 343 MB/min and checking at 390 MB/min.
Now, I tested C: - NTFS to F: - NTFS. Creating was at 802 MB/min and checking at 2229 MB/min!

This was a surprise and a test that should have been done a long time ago!

Could it be that Ghost’s new-won ability to create Images directly to NTFS partitions has hampered its ability to create Images to FAT32 partitions on some hardware configurations?

Comparing the differences for creating to the differences for checking, indicates to me that it's more of a read problem than a write problem when FAT32 is involved.

========================

Now, I went to visit another friend (or rather his computer ...... ;) ...... don’t tell him) whom I mentioned in my previous post. To recapture his setup:

- ASUS P4P800 motherboard with Intel i865PE chipset
- P4 2.8GHz/800MHz
- 2x512 MB PC3200 dual channel
- one Seagate 7200.7 160 GB SATA (ST3160023AS) as boot drive with two partitions, C: - NTFS and D: -  NTFS
- one Seagate 7200.7 plus PATA (ST3160023A) as backup drive with two partitions, E: - NTFS and F: - FAT32

From C: - NTFS to E: - NTFS, creating was at 885 MB/min and checking was at 2959 MB/min.
From C: - NTFS to F: - FAT32, creating was at 831 MB/min and checking was at 1611 MB/min.

The difference for creating is ~6%, not ~600% as in the case of the Hitachi on my system.
The difference for checking is ~84% which supports my suspicion that it's a read problem when FAT32 is involved.

========================

Now I took his PATA out from the rack and installed the 7K250. Those partitions now became E/F/G.

From C: - NTFS to F: - NTFS, creating was at 895 MB/min and checking was at 2145 MB/min.
From C: - NTFS to G: - FAT32, creating was at 859 MB/min and checking was at 1674 MB/min.

A difference of ~4% for creating which is an acceptable figure compared to the ~600% difference on my system.
The ~28% difference for checking is lower than for the Seagate but still indicates a read problem.

========================

NOTE – OFF TOPIC

As a side test, from within XP – Windows Explorer, to compare the performance of the Seagate PATA to the performance of the Hitachi PATA:

Seagate - moving the Image (4340 GB) from F: - FAT32 to E: - NTFS took 9min03sec which equals 480 MB/min.

Hitachi – moving the Image (4340 GB) from G: - FAT32 to F: - NTFS took 4min40sec which equals 930 MB/min.

This actually puts the rates during Ghost operations in a perspective.

========================

Christer

Quote:

... Could it be that Ghost’s new-won ability to create Images directly to NTFS partitions has hampered its ability to create Images to FAT32 partitions on some hardware configurations? Comparing the differences for creating to the differences for checking, indicates to me that it's more of a read problem than a write problem when FAT32 is involved... Christer

Hmm - check the thread below and consider if there is a somewhat related phenomenon vis a' vis NTFS versus FAT32:

http://radified.com/cgi-bin/YaBB/YaBB.cgi?board=general;action=display;num=1082832086;start=0#0

[glb]El Pescador[/glb]

El Pescador,
I hardly ever read topics on USB or FireWire since I don't have such devices.

However, it seems like there is a connection between my issue and Your issue and the common denominator is FAT32.

As tested according to my latest post, all FAT32 target partitions were on an extended partition as logicals.
All NTFS source partitions were primary partitions.
That combination wasn’t among Your tests.

I hope that the guys at Symantec are following this thread and the people at Hitachi and EPOX too for that matter. It seems to be both software related and hardware related but I currently lean towards Ghost being the culprit with different effects on different hardware.

In my latest post, I forgot to mention that when installing the new Hitachi in my friends system, a WD800 was relegated to backup drive.

I made the WD800 into one extended partition with one logical NTFS and one logical FAT32. The notes I took were mislaid but from memory it was much slower to the FAT32 partition than to the NTFS partition. The difference was of the same magnitude as for my IBM 60GXP.
The strange (?) thing is that the computer in question (Fujitsu Siemens) has an Intel chipset, either i845/82801BA or i850/82801BA, which sort of complicates things since I, a few weeks ago, thought that we had VIA nailed to the wall.

Christer

Edited: Updated information on the Intel chipset

Christer

Okay--now which of the three NTFS versions were you using....?  (Just kidding...kind of  ;D)

Was up past mid-night running test Ghost images  :D.

BTW, I looked at my notes and I could not determine for sure whether I was imaging to a NTFS partition or to a FAT32 partition on the various previous tests.  I suspect most of the tests were imaged to a FAT32 partition however.

Here's the results--

I re-partitioned the 'used IBM' so it had an extended partition only with a logical drive formated as a FAT32 partition  and a logical drive formated as a NTFS partition.

In each case, I'm showing the final image creation speed, and using 'no compression' to create the images.

The Seagate 120 GB hard drive was on the HighPoint Controller, primary channel as master and the 'used IBM' was on the VIA Controller, primary channel as master:

Seagate NTFS   >>> 'used IBM' NTFS               994 MB/min *
Seagate NTFS   <<< 'used IBM' NTFS             1071 MB/min

Seagate FAT32  >>> 'used IBM' NTFS              946 MB/min *
Seagate FAT32  <<< 'used IBM' NTFS             1040 MB/min

Seagate FAT32  >>> 'used IBM' FAT32             442 MB/min *
Seagate FAT32  <<< 'used IBM' FAT32             962 MB/min

Seagate NTFS   >>> 'used IBM' FAT32             434 MB/min *
Seagate NTFS   <<< 'used IBM' FAT32             846 MB/min

Imaging to the 'used IBM' on the VIA controller was over twice as fast if the partition was in the NTFS format to receive the image.

************************

I then switched the 'used IBM' from the VIA Controller to the HighPoint Controller, secondary channel as slave, and left the Seagate on the HighPoint Controller, primary channel as master:

Seagate NTFS   >>> 'used IBM' NTFS              1206 MB/min
Seagate NTFS   <<< 'used IBM' NTFS              1050 MB/min

Seagate FAT32  >>> 'used IBM' NTFS             1216 MB/min
Seagate FAT32  <<< 'used IBM' NTFS             1020 MB/min

Seagate FAT32  >>> 'used IBM' FAT32            1184 MB/min
Seagate FAT32  <<< 'used IBM' FAT32             976 MB/min

Seagate NTFS   >>> 'used IBM' FAT32            1267 MB/min
Seagate NTFS   <<< 'used IBM' FAT32            1017 MB/min

Now, with the VIA controller out of the picture, the imaging to a FAT32 partition vs the NTFS partition difference is pretty much gone.

Also, in general, it looks like the NTFS is some faster.  Whether this is due to Ghost being optimized for NTFS or if it's what Microsoft intended to improve with the introduction of the NTFS format, someone else who knows more than I would have to help out there.

NightOwl,
I was contemplating a new round of e-mails to Symantec, Hitachi and EPOX but I believe that I would fry my brain in the process!

We have two VIA chipsets (mine and Yours) giving us trouble and the Intel chipset on the other computer that I mentioned displaying slow performance on FAT32 may require some more investigation. I will find out the exact computer model and go Google on it.

Judged by Your latest results, it seems like the key words are VIA, FAT32 and TARGET PARTITION, which equals slow performance.

Christer

Christer

As you recall, my first tests with the Seagate hard drives showed very good results whether on the HighPoint controller or the VIA controller.  When I repeated the test, the results were much different.



Quote:

I repeated the tests using the Seagates... I wanted to confirm my findings, and low and behold, the results were different this time!!!! Computers, ya gotta love 'em! I put one Seagate on the VIA primary channel as master and one Seagate on the HighPoint primary as master and sending the image from the VIA Seagate to the HighPoint Seagate, I got a creation speed of 983 MB/min (slower than the 'used IBM to Seagate of 1114 MB/min!), and now when I imaged from the HighPoint Seagate to the VIA Seagate, I now got 142 MB/min creation speed! I do not know what has changed to make the results different this time, but I tried serveral times and each test was similar in results! If you recall, on my original post I got an image creation rate of 1195 MB/min going from the Seagate on the HighPoint to the Seagate on the VIA controller, and got 1363 MB/Min going from the Seagate on VIA to the Seagate on the HighPoint controller.

Well, after your test results of imaging Fat32 vs NTFS formated partitions, I decided to go back and repeat the tests using just the Seagates and varying the formatting of the partitions and here are the results:

In each case, I'm showing the final image creation speed, and using 'no compression' to create the images.

One Seagate (120 GB) hard drive was on the HighPoint Controller, primary channel as master and the other Seagate (120 GB) was on the VIA Controller, primary channel as master, and the arrows show the direction of the image creation:

On HighPoint---------------On VIA------------Speed

Seagate NTFS  >>>>> Seagate NTFS   1185 MB/min  
Seagate NTFS  <<<<< Seagate NTFS     944 MB/min

Seagate FAT32 >>>>> Seagate NTFS     786 MB/min  
Seagate FAT32 <<<<< Seagate NTFS   1243 MB/min

Seagate FAT32 >>>>> Seagate FAT32    136 MB/min  
Seagate FAT32 <<<<< Seagate FAT32  1241 MB/min

Seagate NTFS  >>>>> Seagate FAT32     140 MB/min  
Seagate NTFS  <<<<< Seagate FAT32   1265 MB/min

Apparently, just by accident, I must have chose the best combinations to image from HighPoint to VIA or from VIA to HighPoint on my first tests.  And it's clear you do not want to image to a hard drive on the VIA controller if the partition is FAT32, but a NTFS partition is quite good.


************************

I then switched the Seagate on the VIA Controller to the HighPoint Controller, secondary channel as slave, and left the other Seagate on the HighPoint Controller, primary channel as master:

On HighPoint-------------On HighPoint-------Speed

Seagate NTFS  >>>>> Seagate NTFS   1110 MB/min  
Seagate NTFS  <<<<< Seagate NTFS   1145 MB/min

Seagate FAT32 >>>>> Seagate NTFS     786 MB/min  
Seagate FAT32 <<<<< Seagate NTFS   1054 MB/min

Seagate FAT32 >>>>> Seagate FAT32    767 MB/min  
Seagate FAT32 <<<<< Seagate FAT32  1218 MB/min

Seagate NTFS  >>>>> Seagate FAT32    916 MB/min  
Seagate NTFS  <<<<< Seagate FAT32  1291 MB/min

Now with the Seagates both on the HighPoint controller, there are some differences (and I can only wonder why :-) ), but not the dramatic differences seen imaging to a VIA FAT32 partition.

************************

Now I put both Seagates on the VIA controller, one on the primary as master and the other on the secondary as master:

  On VIA-------------------On VIA----------Speed

Seagate NTFS  >>>>> Seagate NTFS   1171 MB/min  
Seagate NTFS  <<<<< Seagate NTFS   1341 MB/min

Seagate FAT32 >>>>> Seagate NTFS     829 MB/min  
Seagate FAT32 <<<<< Seagate NTFS     144 MB/min

Seagate FAT32 >>>>> Seagate FAT32    131 MB/min  
Seagate FAT32 <<<<< Seagate FAT32    144 MB/min

Seagate NTFS  >>>>> Seagate FAT32    135 MB/min  
Seagate NTFS  <<<<< Seagate FAT32  1300 MB/min

Again, imaging to a FAT32 partition on the VIA controller was not the best option.

So, it looks like if you have a VIA VT82C686B southbridge controller chip on your system, you would get much better performance if you image to a NTFS partition rather than to a FAT32 formated partition.

NightOwl,

Your latest figures confirm that the issue is with FAT32 and VIA. It puts Hitachi in the clear since Your figures are for Seagates.

This week I start my holidays and will be more or less separated from my computer for the next two weeks. I will not start a new correspondence with Symantec, EPOX and VIA as an addition, until I know that I will be available for their responses. I will also mail Hitachi to tell them about our findings.

I will check in every now and then from other computers, though.

I will keep You posted when I send the mails!

Christer

Christer

Have a good holiday!


Quote:

It puts Hitachi in the clear

Actually, looking at the results, it seems that the newer hard drives from both Hitachi and Seagate are performing less well than the older IBM's.  

I'm thinking that maybe the newer hard drives have been tweaked for NTFS, and in the process, it has somehow effected the compatibility of the VIA chipset with FAT32 and the newer hard drives firmware performance.

Quote:

Christer Have a good holiday!

Thanks, NightOwl!

I'll do my best to go into "idling mode".

Christer

Hi guys!

My vacation is over but I still have some time off and the purpose of that is doing nothing ...... ;) ...... isn't it. I have yet to find the inspiration to continue or renew my correspondence with the different parties but eventually I'll get around to it.

I'll be back!

Christer

Enjoy your vacation. I'm still watching this thread, a great mystery.

After a bit of cutting, pasting and creative editing ...... ;) ...... I sent this message to EPOX:


Quote:

Dear Sir's and Ladies! I have tried to correspond with You on this issue before but have not received any response other than being prompted for more information. I have a problem regarding transfer rates when performing Ghost operations, creating, checking and restoring Images. In the meantime, a friend and I have done some further research on our respective computers and have come to the conclusion that the VIA chipset (VIA VT82C686B) is the common denominator. ------------------------------------------------------------------------ My setup and results: Motherboard - EPOX 8KTA3 / VIA VT82C686B Two HDDs connected to IDE0 as Master and Slave respectively. The Master (Hitachi 7K250 - HDS722512VLAT80) has three partitions: C: - NTFS (system) D: - NTFS E: - FAT32 The Slave (Hitachi 7K250 - HDS722512VLAT80) has three partitions: F: - NTFS G: - NTFS H: - FAT32 Creating an Image of C: - NTFS to G: - NTFS, the transfer rate is 809 MB/min Creating an Image of C: - NTFS to H: - FAT32, the transfer rate is 136 MB/min Creating an Image to a FAT32 partition is approximately six times slower than to a NTFS partition. ------------------------------------------------------------------------ My friend's setup and results: Abit KG7-Raid motherboard. It has two IDE hard drive controllers, the standard VIA VT82C686B southbridge controller chip and a built in HighPoint 370/372 Raid controller chip which can be used either as a Raid controller or just another IDE controller for additional hard drives. A matched pair of Seagate 120 GB, model ST3120026A, with a mix of NTFS and FAT32 partitions, connected as below: On HighPoint-------------------On VIA------------Speed Seagate NTFS  >>>>> Seagate NTFS     1185 MB/min Seagate NTFS  <<<<< Seagate NTFS     944 MB/min Seagate FAT32 >>>>> Seagate NTFS     786 MB/min Seagate FAT32 <<<<< Seagate NTFS     1243 MB/min Seagate FAT32 >>>>> Seagate FAT32    136 MB/min Seagate FAT32 <<<<< Seagate FAT32    1241 MB/min Seagate NTFS  >>>>> Seagate FAT32    140 MB/min Seagate NTFS  <<<<< Seagate FAT32    1265 MB/min It's clear you do not want to image to a hard drive on the VIA controller if the partition is FAT32, but a NTFS partition is quite good. On HighPoint----------------On HighPoint--------Speed Seagate NTFS  >>>>> Seagate NTFS     1110 MB/min Seagate NTFS  <<<<< Seagate NTFS     1145 MB/min Seagate FAT32 >>>>> Seagate NTFS     786 MB/min Seagate FAT32 <<<<< Seagate NTFS     1054 MB/min Seagate FAT32 >>>>> Seagate FAT32    767 MB/min Seagate FAT32 <<<<< Seagate FAT32    1218 MB/min Seagate NTFS  >>>>> Seagate FAT32    916 MB/min Seagate NTFS  <<<<< Seagate FAT32    1291 MB/min Now with the Seagates both on the HighPoint controller, there are some differences but not the dramatic differences seen imaging to a VIA FAT32 partition.   On VIA-----------------------On VIA-------------Speed Seagate NTFS  >>>>> Seagate NTFS     1171 MB/min Seagate NTFS  <<<<< Seagate NTFS     1341 MB/min Seagate FAT32 >>>>> Seagate NTFS     829 MB/min Seagate FAT32 <<<<< Seagate NTFS     144 MB/min Seagate FAT32 >>>>> Seagate FAT32    131 MB/min Seagate FAT32 <<<<< Seagate FAT32    144 MB/min Seagate NTFS  >>>>> Seagate FAT32    135 MB/min Seagate NTFS  <<<<< Seagate FAT32    1300 MB/min Again, imaging to a FAT32 partition on the VIA controller was not the best option. ------------------------------------------------------------------------ It looks like if you have a VIA VT82C686B southbridge controller chip on your system, you would get much better performance if you image to a NTFS partition rather than to a FAT32 formated partition. Since there are conciderations indicating that storing Ghost Images on a FAT32 partition is the better option, this speed issue is a problem. We would appreciate any comments and/or directions on how to get better performance on a FAT32 target partition on VT82C686B. I realize that this is not an isolated EPOX problem but I have not found any contact details to VIA. That's the reason why I still try my luck with You and depend on Your assistance! Best regards, Christer Engdahl

I sent the message to EPOX-UK and received a reply from EPOX-NL. There was a note in the reply(ies) that they were confidential and not to be reproduced.
However, my response(s) aren't confidential and I'm sure You can "fill in the blanks":


Quote:

Dear Tom! Slow performance from NTFS to FAT32 may be concidered to be normal if the difference is up to 25 % but not if it is six (6) times slower. I have Imaged several systems based on different chipsets and only VIA displays these remarkably inferior transfer rates. The results, provided by my friend, were submitted to You in order to demonstrate that it was not HDD related but it was VIA related. If this is EPOX's final standpoint, then my next build will not include anything EPOX or VIA. I would like to discuss this issue with VIA and would appreciate if You can provide contact details to VIA support. Regards, Christer

Quote:

Dear Tom! I forgot to point out that Norton Ghost performs its operations under DOS. There are no Windows drivers loaded. The operation mode is PIO and there may be differences in performance between different systems due to CPU speed but the results obtained by me and my friend are quite consistent. Regards, Christer

Quote:

Dear Tom! Even if Ghost is launched from the Windows interface, it reboots the computer to DOS when the operation is carried out and restarts Windows when complete. I have also come to the conlusion, which I pointed out in my mail, that it is not an isolated EPOX issue but pertains to all motherboards with that chipset (VT82C686B). I would discuss this issue with VIA, if I had contact details to VIA support. The processor is a factor since the operation is in PIO mode. Mine is an Athlon T-bird 1 GHz / 266 MHz FSB, my friend's is an Athlon XP 2100+ @ 1.746 GHz. The specific HDD is also a factor and since they differ too we can only take the transfer rates as indications but in both cases they are approximately six times slower to FAT32 than to NTFS. The objective of submitting my friend's results is not to compare the respective performance but to rule out the possibility of a HDD incompatibility or a Ghost incompatibility. Thanks for Your time, Christer

In the meantime, I have also sent a similar e-mail to VIA Technologies GmbH in Germany. On the web, there was no specific e-mail addy to any technical support but I found a general e-mail addy which I used. My expectations are not high ...... :-X ...... !

Christer

Well, lucky me ...... :-X ...... that I didn't hold my breath ...... ;D ...... !

I have made one final attempt to get a productive answer from Symantec Support and this is what I sent:


Quote:

Dear Sir's and Ladies! I have a problem regarding transfer rates when performing Ghost operations, creating, checking and restoring Images. Ghost operations are carried out using Ghost Boot Disks. The transfer mode is PIO and all attempts to force (U)DMA using switches have been unsuccessful. A friend and I have done some research on our respective computers and have come to the conclusion that the VIA chipset (VIA VT82C686B) is the common denominator. My friend's results are to rule out any HDD incompatibility in my specific case. --------------------------------------------------------------------- My setup and results: Motherboard - EPOX 8KTA3 / VIA VT82C686B Two HDDs connected to IDE0 as Master and Slave respectively. The Master (Hitachi 7K250 - HDS722512VLAT80) has three partitions: C: - NTFS (system) D: - NTFS E: - FAT32 The Slave (Hitachi 7K250 - HDS722512VLAT80) has three partitions: F: - NTFS G: - NTFS H: - FAT32 Creating an Image of C: - NTFS to G: - NTFS, the transfer rate is 809 MB/min Creating an Image of C: - NTFS to H: - FAT32, the transfer rate is 136 MB/min Creating an Image to a FAT32 partition is approximately six times slower than to a NTFS partition. --------------------------------------------------------------------- My friend's setup and results: Abit KG7-Raid motherboard. It has two IDE hard drive controllers, the standard VIA VT82C686B southbridge controller chip and a built in HighPoint 370/372 Raid controller chip which can be used either as a Raid controller or just another IDE controller for additional hard drives. A matched pair of Seagate 120 GB, model ST3120026A, with a mix of NTFS and FAT32 partitions, connected as below: On HighPoint -------------- On VIA -------------- Speed Seagate NTFS  >>>>> Seagate NTFS     1185 MB/min Seagate NTFS  <<<<< Seagate NTFS     944 MB/min Seagate FAT32 >>>>> Seagate NTFS     786 MB/min Seagate FAT32 <<<<< Seagate NTFS     1243 MB/min Seagate FAT32 >>>>> Seagate FAT32    136 MB/min Seagate FAT32 <<<<< Seagate FAT32    1241 MB/min Seagate NTFS  >>>>> Seagate FAT32    140 MB/min Seagate NTFS  <<<<< Seagate FAT32    1265 MB/min It's clear you do not want to image to a hard drive on the VIA controller if the partition is FAT32, but a NTFS partition is quite good. On HighPoint -------------- On HighPoint ---- Speed Seagate NTFS  >>>>> Seagate NTFS     1110 MB/min Seagate NTFS  <<<<< Seagate NTFS     1145 MB/min Seagate FAT32 >>>>> Seagate NTFS     786 MB/min Seagate FAT32 <<<<< Seagate NTFS     1054 MB/min Seagate FAT32 >>>>> Seagate FAT32    767 MB/min Seagate FAT32 <<<<< Seagate FAT32    1218 MB/min Seagate NTFS  >>>>> Seagate FAT32    916 MB/min Seagate NTFS  <<<<< Seagate FAT32    1291 MB/min Now with the Seagates both on the HighPoint controller, there are some differences but not the dramatic differences seen imaging to a VIA FAT32 partition. On VIA ------------------------ On VIA --------------- Speed Seagate NTFS  >>>>> Seagate NTFS     1171 MB/min Seagate NTFS  <<<<< Seagate NTFS     1341 MB/min Seagate FAT32 >>>>> Seagate NTFS     829 MB/min Seagate FAT32 <<<<< Seagate NTFS     144 MB/min Seagate FAT32 >>>>> Seagate FAT32    131 MB/min Seagate FAT32 <<<<< Seagate FAT32    144 MB/min Seagate NTFS  >>>>> Seagate FAT32    135 MB/min Seagate NTFS  <<<<< Seagate FAT32    1300 MB/min Again, imaging to a FAT32 partition on the VIA controller was not the best option. --------------------------------------------------------------------- It looks like if you have a VIA VT82C686B southbridge controller chip on your system, you would get much better performance if you image to a NTFS partition rather than to a FAT32 formated partition. Since there are conciderations indicating that storing Ghost Images on a FAT32 partition is the better option, this speed issue is a problem. We would appreciate any comments and/or directions on how to get better performance on a FAT32 target partition on VT82C686B. Best regards, Christer Engdahl

SS usually provides a response and even if the response not always contains an answer ...... :-/ ...... my expectations are a bit higher.

Christer

The reply from Symantec Support:


Quote:

Christer, the differences in speed you are experiencing can be caused by the way Ghost is accessing the drives, by the performance of the drives themselves, and\or by the controller the drives are running on. Ghost does not support RAID in any form, so you may want to test with a controller that does not have RAID capability. Symantec does not test with any specific controllers, so I am unable to make any detailed comments on what you are experiencing with this particular hardware. You can also try some of the drive access switches outlined in the following document. Here's that link: Title: 'Switches: Drive Geometry' Document ID: 1998082609375125 Web URL: http://service1.symantec.com/SUPPORT/ghost.nsf/docid/1998082609375125&src=w Please let us know if you have additional questions on Ghost. Best regards, Stephen May Symantec Online Technical Support

Stephen's comment on Ghost not supporting RAID and that I should try a controller that does not support RAID is a bit odd ...... ??? ...... I didn't say that RAID was configured and on that controller the speed to FAT32 was "normal".

I have already tried the switches that he suggests but will try them once more and I will also repeat my attempts using PC-DOS.

I do, however, believe that this is the end of the line and that my issue remains unresolved.

Christer

After having confirmed my previous findings regarding the use of switches, I decided to send another message informing that they don't work properly (and to admit to a mistake):


Quote:

Hello Stephen! First of all, I made a serious mistake, I quote from my first message: "The transfer mode is PIO and all attempts to force (U)DMA using switches have been unsuccessful." That is not the case but the other way around. The transfer mode is UDMA and I have tried to use the -fnu switch to force PIO mode. I have created Ghost Boot Disks with these switches: -ffi -split=650 -auto -ffx -split=650 -auto They appear in autoexec.bat on the floppy but only Spanning and AutoName appear as active switches in ghosterr.txt. If I, booted from the GBDs, go to Options > Harddisk Access and mark the option there and save, then a new file is written to the floppy, Ghost.ini, and then the corresponding switch appears as active in ghosterr.txt but there is no difference in performance. I have also created GBDs with these switches: -fnu -split=650 -auto They appear in autoexec.bat on the floppy but only Spanning and AutoName appear as active switches in ghosterr.txt. There is no option to force PIO (-fnu) in Options > Harddisk Access and as a concequence, I have not been able to make that switch active. Any suggestions? Thanks, Christer

A little more reading ...... ;) ...... !

From Stephen to me:


Quote:

Try this test: On the floppy that contains the autoexec.bat, add the -DD, -FNU, and -FNI switches. The -DD outputs information to a file named ghststat.txt that will be written in the Ghost folder on the floppy. Once this file has been written, open it and you will see that the -FNU and -FNI switches have been included in how Ghost is being run.

From me to Stephen:


Quote:

Stephen, "On the floppy that contains the autoexec.bat, add the -DD, -FNU, and -FNI switches. The -DD outputs information to a file named ghststat.txt that will be written in the Ghost folder on the floppy. Once this file has been written, open it and you will see that the -FNU and -FNI switches have been included in how Ghost is being run." There are two autoexec.bat, one on each of the two floppies and I edited both according to Your suggestion. The below is cut and pasted from ghststat.exe: ********************************* Date   : Fri Sep  3 13:03:12 2004 Error Number: (0) Message: Stats Dump Version: 2003.793 (Dec 17 2003, Build=793) Command line arguments: -dd -fnu -fni -split=650 -auto Active Switches :       Spanning       AutoName => => Drive 128 Int 13h Total Sectors     16450560 Bytes per Sector  512 MB                8032 Cylinders         1024 Heads             255 Sectors per Track 63 Extended Int 13h (Active) Total Sectors     241254720 Bytes per Sector  512 MB                117800 Cylinders         16383 Heads             16 Sectors per Track 63 ********************************* The switches seem to be active but they are not registered as such at the top of the textfile. -fni removed UDMA but -fnu didn't force PIO but Extended Int 13h. No difference in performance Next, I added the -fna switch and the below is cut and pasted from ghststat.exe: ********************************* Date   : Fri Sep  3 13:22:54 2004 Error Number: (0) Message: Stats Dump Version: 2003.793 (Dec 17 2003, Build=793) Command line arguments: -dd -fna -fnu -fni -split=650 -auto Active Switches :       Spanning       AutoName => => Drive 128 Int 13h Total Sectors     16450560 Bytes per Sector  512 MB                8032 Cylinders         1024 Heads             255 Sectors per Track 63 Extended Int 13h (Active) Total Sectors     241254720 Bytes per Sector  512 MB                117800 Cylinders         16383 Heads             16 Sectors per Track 63 ********************************* The same result as in the previous test and no difference in performance. Finally, I removed the -fna switch and added the -fnx switch as a last attempt to force PIO but it failed with a ghosterr.txt. The reason being that the only alternative left was Int 13h. I actually expected this. Could it be that the -fnu switch (force PIO) only works with the corporate edition and that it doesn't work with the consumer version? I actually don't think PIO would produce improved performance but I believe that there is an incompatibility issue between the VIA chipset and Ghost. Regards, Christer

Noone can say that I don't exhaust all options ...... :-X ...... !

Christer

Posting the error messages revealed my version of Norton Ghost ......


Quote:

Christer, unfortunately, we will be unable to continue this thread, as you are running the consumer version of Ghost, but posting questions in the Ghost Enterprise Discussion Forums. Please resubmit your issue to the following link, where a Ghost 2003 Technician will be happy to assist you. Here's that link: http://www.symantec.com/techsupp/ghost/ghost_2003_info_solve_error.html

I posted the question, including all information submitted to the "enterprize guy" and the answer was short and probably the most accurate so far ......


Quote:

Hello Christer, Welcome to Symantec Online Technical Support. In your message you wrote: It looks like if you have a VIA VT82C686B southbridge controller chip on your system, you would get much better performance if you image to a NTFS partition rather than to a FAT32 formated partition. Since there are considerations indicating that storing Ghost Images on a FAT32 partition is the better option, this speed issue is a problem. Christer, thanks for the detailed information and co-operation. Symantec is aware of this issue, and there is no solution at this time. We will continue to track this issue, and the knowledge base documents will be updated if new information becomes available or a solution is found. We apologize for any inconvenience this may have caused you. If I can be of further assistance, please let me know. Regards, Anand Symantec Authorized Technical Support

Quote:

Symantec is aware of this issue, and there is no solution at this time.

Are they referring to a performance problem with the Via southbridge?

It's the first person to acknowledge that there is a problem with that chipset and that they knew about it ...... :-X ...... or maybe NightOwl and me presented enough evidence.

BTW, did You get my PM's?

Christer

Well, that's progress. Getting them to admit a problem. I don't know why companies are so adamant against it.

I always forget to check PMs, sorry. I'll go there now.

I've had the opportunity to do some tests on a system based on ABIT VA-10 with VIA VT8378 (KM400) / VT8235 (southbridge), AMD Sempron 2600+, 512 MB PC2700, two Maxtor Plus8 - 40 GB.

C: (NTFS) on HDD-0 to E: (NTFS) on HDD-1
Create - 860 MB/min
Check - 3533 MB/min

C: (NTFS) on HDD-0 to F: (FAT32) on HDD-1
Create - 248 MB/min
Check - 315 MB/min

If we compare that to the transfer rates from 7K250 to 60GXP:

C: (NTFS) on 7K250 to F: (NTFS) on 60GXP
Create - 802 MB/min
Check - 2229 MB/min

C: (NTFS) on 7K250 to G: (FAT32) on 60GXP
Create - 342 MB/min
Check - 390 MB/min

The Plus8 and 60GXP are 2 MB cache drives and are both performing better, when the target partition is FAT32, than the 7K250 and Seagate 7200.7 which are 8 MB cache drives.

Anyway, the tests on the ABIT VA-10 based hardware have convinced me that my next motherboard will not include anything VIA.

Christer

http://img.photobucket.com/albums/v235/El_Pescador/Porgy.jpg
Christer -

Serendipity strikes again - while winding up my successful attempts to restore the temporarily-lost capability of my "purpose-built" Iomega 80GB HDD USB 2.0 External Drive to function in Norton Ghost 2003 with the stock Norton/Iomega drivers extracted from Guest.exe, I blundered into a phenomenon not unlike this thread of long standing considering the performance disparity between the NTFS and FAT32 file system formats under particular hardware configurations.

To recap, after using PowerQuest Partition Magic 8 to partition the preformatted FAT32 Iomega External Drive I ruefully discovered that I was unable to restore its former capability and had become reliant on NightOwl's Panasonic Universal USB Driver routine in order to conduct Ghost 2003 operations.  Suffering from a degree of neurotic obsessiveness, I was bound and determined 'to put Humpty-Dumpty back together again' - and I succeeded. The trick (CLICK HERE) is to zero-fill the Iomega disk using the Ghost 2003 DOS-based utility GDisk with the /diskwipe switch and then with no preparation whatsoever immediately submit the disk to the Seagate DiscWizard in Windows; once there, configure a single primary FAT32 partition not-to-exeed 32GB and close out followed by a reboot into SAFE MODE.  Restarting DiscWizard: (1) click on the Maintenance button; (2) select Partitioning and Formatting Options; and (3) select Grow a Partition whereupon the process completes itself. Theoretically Windows XP FAT32 volumes larger than 32 GB have to emanate from other operating systems, but this DiscWizard is a "loophole" utility running inside XP that let the 16kb cluster size remain static right up until the capacity limit of the HDD was attained (luckily the Iomega HDD was Seagate-compliant, but not all HDDs are).

Once all this had transpired, I began to consider if such an extraordinary reconfiguration of other FAT32 primary partitions and logical drives would reinvigorate them so as to be more on par with their NTFS counterparts.  On my Dell Dimension 8100, I now have a 60GB IBM/Hitachi DeskStar IDE HDD (IC35L060AVV207-0) set up as a SLAVE inside my PC to serve primarily as a first-line repository for the Norton Ghost 2003 Backup images spun off my MASTER 120GB Maxtor SATA HDD (6Y120MO); likewise, I have an 80GB Western Digital IDE SLAVE HDD (WDC WD800JB-00JJA0) installed in my Dell Dimension 8300.  With my external HDDs mounted in enclosure kits, I typically set them up as a single extended partition - no primary, no active - and split them into two logical drives of equal volume with the leading drive formatted NTFS and the trailing drive formatted FAT32; with external HDDs, I suffer no performance penalty but with internal SLAVE IDE HDDs set up exactly the same way on both my Dell Dimension 8100 and on my Dimension 8300 as well, I have been consistently experiencing poor performance with FAT32 ... UNTIL I EMPLOYED THAT CONFIGURATION DESCRIBED ABOVE, THAT IS !!!

Without any tables or graphs at this stage, let me say that a routine Ghost 2003 "partition-to-image" Backup to the FAT32 logical drive on the 8100 SLAVE HDD that heretofore took 22-to-23 minutes now takes 10-to-11 minutes; albeit the same task to the SLAVE NTFS logical drive now takes 4-to-5 minutes but unfortunately there are no available logs on the pre-transition period.  The situation on the Dimension 8300 is even more noteworthy: whereas heretofore a Ghost 2003 "disk-to-image" Backup to the NTFS logical drive was consuming 35-to-36 minutes, it is now taking 16-to-17 minutes in NTFS - but only 17-to-17¹/₂ minutes in FAT32 (again, no available logs on the pre-transition period).

Therefore, the question I pose to you is to what degree - if any - could a reconfiguration such as I describe above enhance or afflict the performance of HDDs tested in the FAT32 file system format back upstream in this thread. Also, a bit of an aside - the 60GB SLAVE Hitachi IDE HDD has a 2MB cache versus an 8MB cache for the 80GB SLAVE Western Digital IDE HDD.  

[glb]El Pescador[/glb]

El_Pescador

Interesting stuff!!!


Quote:

UNTIL I EMPLOYED THAT CONFIGURATION DESCRIBED ABOVE, THAT IS !!!

Are you using Gdisk to wipe the HDD, and then setting up a single FAT32 Primary--less than 32 GB, 16 kb cluster size, and then Growiing it?

Do you think it's the cluster size that is responsible for the better performance?

NightOwl wrote on Aug 11^th, 2005 at 1:47am:

"... Are you using Gdisk to wipe the HDD, and then setting up a single FAT32 Primary--less than 32 GB, 16 kb cluster size, and then Growiing it? Do you think it's the cluster size that is responsible for the better performance?..."

GDisk n /diskwipe only - then straight to Windows XP and let Seagate DiscWizard find the target HDD "hands-off".  I have done several repetitions, and my latest twist is to let DiscWizard lay out a NTFS partition by default for a bit over half of the disk (anything over 35GB) - then lay out about 25GB which is FAT32 w/16kb cluster by default so as to leave the remainder unencumbered until the second pass in SAFE MODE using the GROW command.

Then - and only then - do I go into Partition Magic 8.0 where I delete the primary 34GB+ NTFS partition (its weird, but once the primary emerged from DiscWizard unformatted!) and use PM8 to recreate it as a NTFS logical drive expanded to the maximum capacity of the HDD while sharing the single extended partition with the GROWN-UP FAT32 logical drive containing 16kb clusters.  Bottom line - neither primary partition nor active partition are present - and as to cluster size, quien sabe^' ? ::)

[glb]El Pescador[/glb]

Hi El_Pescador,
thanks for remembering this issue!

I have only skimmed through Your post and will have to get back later. I have a feeling that questions may arise!

Christer

Christer wrote on Aug 11^th, 2005 at 10:08am:

"... I have a feeling that questions may arise!..."

El_Pescador wrote on May 15^th, 2005 at 12:02am:

Well, I have turned up another USB 2.0 device controller that requires NightOwl's Universal Panasonic USB Driver to be able to function in Norton Ghost 2003. The PPA Metal Gear Box Model 2179780SAU2 combo USB 2.0/SATA external HDD enclosure kit has 'USB\Vid_067b&Pid_2507...' as Hardware Id in Device Manager.  Be advised that only IDE/ATA HDDs will work in this unique device - SATA HDDs will not fit. In the USB 2.0 mode, Ghost 2003 was totally dysfunctional in PC-DOS using the Norton/Iomega USB drivers.  With the Panasonic drivers, the Western Digital IDE drive was functional only in the FAT32 file system format - and just barely so with the Intel onboard USB host controllers (see table below). Switching to SATA mode was a totally different story for the combo enclosure kit.  As evident in the table, the IDE-to-SATA conversion was just a couple of minutes slower than a native SATA NCQ HDD mounted in a conventional SATA enclosure for comparison purposes when both were tested in sequence while connected to the same SATA port on the systemboard.   http://img.photobucket.com/albums/v235/El_Pescador/eekMG.jpg [glb]El Pescador[/glb]

Many questions can arise around just one individual device, i.e., the 80GB Western Digital IDE SLAVE HDD (Model No. WDC WD800JB-00JJA0 - Serial No. WD-WCAM93132923) and the various ways it can be linked to the host Dell Dimension 8300 desktop: (1) as an internal SLAVE HDD linked to an IDE port on the MoBo via ribbon cable; (2) as an EXTERNAL HDD linked to a USB 2.0 port on the MoBo via USB cable; (3) as an EXTERNAL HDD linked to a USB 2.0 port on a PCI-to-USB2 host adapter card via USB cable; (4) as an EXTERNAL HDD linked to a FireWire port on a PCI-to-FireWire host adapter card via FireWire cable; and (5) most strangely of all, as an EXTERNAL HDD linked to a SATA port on the MoBo via SATA cable routed through an IDE-to-SATA conversion bridge chipset within the enclosure referred to in the graphic above (not included is the v2.20 release of usbaspi.sys for the Panasonic Universal USB Driver routine).  These different modes of connection will demonstrate varying levels of performance disparity between the NTFS and the FAT32 file system format partitions ranging from NULL performance for either of the formats to NEAR-IDENTICAL performance with both formats.  Toss in the concept of having a manipulated outsized FAT32 partition - on a disk with neither a primary nor an active partition - and the permutations become positively unwieldy.

[glb]El Pescador[/glb]

El_Pescador wrote on Aug 11^th, 2005 at 3:18am:

"START QUOTE...

"... GDisk n /diskwipe only - then straight to Windows XP and let Seagate DiscWizard find the target HDD "hands-off".  I have done several repetitions, and my latest twist is to let DiscWizard lay out a NTFS partition by default for a bit over half of the disk (anything over 35GB) - then lay out about 25GB which is FAT32 w/16kb cluster by default so as to leave the remainder unencumbered until the second pass in SAFE MODE using the GROW command.

Then - and only then - do I go into Partition Magic 8.0 where I delete the primary 34GB+ NTFS partition (its weird, but once the primary emerged from DiscWizard unformatted!) and use PM8 to recreate it as a NTFS logical drive expanded to the maximum capacity of the HDD while sharing the single extended partition with the GROWN-UP FAT32 logical drive containing 16kb clusters.  Bottom line - neither primary partition nor active partition are present - and as to cluster size, quien sabe^' ?..."


Quote:

...STOP QUOTE"

Substitute the quote below for the statement in RED above:

"... Then - and only then - do I go into Partition Magic 8.0 where I CONVERT the primary 34GB+ NTFS partition to a logical drive to share the single extended partition with the GROWN-UP FAT32 logical drive containing 16kb clusters..."

[glb]El Pescador[/glb]

Hi El_Pescador!

I appreciate You efforts to share Your findings and make colourful and sometimes animated posts. I don't know if it's only me and my eyesight (I have new glasses since a few months ago) but I can't read some of the text, especially the text in red colour. It gets all "flourescent" ...... :'( ...... kind of ...... :-[ ...... and illegible. It seems like red on a grey background is the problem for me.

In a friendly spirit,
Christer

[glb]HOWZZATTT ? :o[/glb]

[glb]El Pescador[/glb]

Much better ...... :) ...... !

Thanks,
Christer

Christer wrote on Aug 11^th, 2005 at 10:08am:

"... thanks for remembering this issue!.. I have a feeling that questions may arise!.."

Christer and NightOwl -

I have uncovered and pinned down the extremely fascinating material that allows my Seagate, Western Digital, and Hitachi HDDs to function at equivalent speeds in either NTFS or FAT32 file system format during Norton Ghost 2003 Backup and Integrity Check procedures - but not with Maxtor HDDs.  Are you willing once again to pick up the gauntlet thrown down? ... LOL !!!

[glb]El Pescador[/glb]  

Hi El_Pescador!

I understand it as You'd like me/us to make the same "experiment" with one of our HDDs to find out if it works. At the time being and into the nearest future, I will have very little time at my disposal to do that but I would like to find out.

I don't want to mess with my current two 7K250's because they are in use and working flawlessly but I have my disused 60GXP that I can do some tests on. The 60GXP was/is not as bad with FAT32 as the 7K250 but the tests would be interesting no matter what.

I will build a new computer for a friends daughter ...... ::) ...... and will have two 7K250 SATAs to play with for a day or two. Maybe that will be my best opportunity.

I will have to reread Your recent posts to recapitulate Your methods and results. I do not own or have access to any partitioning program for resizing and that may be a problem.

As soon as I have the time ...... :-/ ...... !

Christer

Christer wrote on Aug 22^nd, 2005 at 4:38am:

"... but I have my disused 60GXP that I can do some tests on. The 60GXP was/is not as bad with FAT32 as the 7K250 but the tests would be interesting no matter what... will have two 7K250 SATAs to play with... do not have access to any partitioning program for resizing and that may be a problem..."

My favorite "low-level formatting" tool, i.e. zero-fill routine, is included with every copy of Ghost 2003 and is a DOS-based utitlity called GDisk.  The routine I use is the switch 'GDISK ^{drive no.} /DISKWIPE'.

I will be glad to mail you one of my numerous copies of the Seagate installation CDs included with each retail HDD kit, but you may prefer to download the latest counterpart material from their WebSite:

http://www.seagate.com/support/kb/disc/howto/use_dwse.html

http://www.seagate.com/support/kb/disc/howto/use_dwse_maint.html

The BIOS-tricking software is called Dynamic Drive Overlay (DDO), and despite warnings about no support will be extended to non-Seagate users, it has worked for me with Western Digital, Hitachi and whatever brand is encased in my Iomega External 80GB HDD - but it rejects my Maxtor HDDs.  In fact, I was thoroughly disgusted with my three identical 80GB Western Digital IDE disks (WDC WD800JB-OOJJA0) as internal SLAVE HDDs in regard to disparity between the NTFS and FAT32 file system formats - but not when mounted in external enclosures.  However, since installing the Seagate Dynamic Drive Overlay, the WDC WD800JB-OOJJA0s now outperform every other brand of HDD I have tested in the SLAVE role when performing Ghost 2003 procedures with a FAT32 logical drive on the Destination HDD.  Do keep in mind that all the remarks above relate to IDE HDDs - so one caveat is that the technique may not work on every model in the Hitachi line, particularly native SATA HDDs.  

[glb]El Pescador[/glb]

El_Pescador

The devil is in the *details*--I have lost track of exactly what you are doing--

In your reply #123 above--you created what appears to be a single FAT32 primary partition.

In your reply #125 above--you create what appears to be two primary partition:

1.  a NTFS partition of > 35 GB

2.  a FAT32 partition of approx. 25 GB

You then manipulate those partitions using PartitionMagic to delete and reconfigure them as Logical partitions in an extended partition--but the step-by-step sequence is missing--and the final size of each partition is not mentioned.

And then, in your reply # 128, you modify your procedure so as to not *delete* the NTFS partition, but simply manipulate it and the FAT32 partition so as to end up with an Extended partition with the NTFS and FAT32 partition inside...but, again the step-by-step details of the sequence of steps is missing--as well as the final size of the partitions.

So, of the three different configurations and steps outlined above--which one (or ones) did you want tested--and what are the missing steps and final sizes of the partitions in your outline?

FOUR STEPS (using 160GB Seagate IDE HDD as example as it mirrors my MASTER SATA NCQ HDD):

(1)  Use DOS-based GDisk ^{disk no.} /diskwipe to zero-fill the target HDD, but no subsequent GDisk operations at all;

(2)  Go straight to Windows XP and tacitly allow Seagate DiscWizard for Windows^(R) find the target HDD "hands-off" - do not do any searching, but merely confirm its choice if correct;

(3)  Use DiscWizard to lay out the first NTFS primary active partition as 52GB (by default anything over 35GB transforms to NTFS, so anything over that size is arbitrary - as are the number of NTFS partitions for that matter); then lay out another NTFS partition of 57GB (by default, this second partition becomes the basis of an extended partition); and finally, lay out about 25GB for the last partition which by default will be FAT32 w/16kb cluster so as to leave the remaining freespace unencumbered until subjected to the GROW command during a follow-up pass in SAFE MODE; and

(4)  Then - and only then - do I go into Partition Magic 8.0 where I CONVERT the leading NTFS primary active partition to a logical drive to share the single extended partition with the 57GB NTFS logical drive and the now GROWN-UP FAT32 logical drive whose volume has expanded from 25GB to 39GB albeit it does retain 16kb clusters.

I avoid primary active partitions on all internal SLAVE HDDs and external HDDs as well - particularly those devices with SATA or SATA/USB combo capability where the dread message 'NTLDR is Missing - Press any key to restart' can jump up and bite you if your MASTER HDD has been reassigned from IDE to SATA.

[glb]El Pescador[/glb]

El_Pescador

I have the IBM 40 GB...or an IBM 60 GB that I can test--how would you like those partitioned and formated?


Quote:

... I go into Partition Magic 8.0 where I CONVERT the leading NTFS primary active partition to a logical drive to share the single extended partition with the 57GB NTFS logical drive and the now GROWN-UP FAT32 logical drive whose volume has expanded from 25GB to 39GB albeit it does retain 16kb clusters.

I've never used PartitionMagic's *Convert* function--so I do not know what happens here.

Do you end up with two 57 GB NTFS partitions inside the Extended partition plus the 25 GB FAT32 partition--and the remaining *free space* at the end of the HDD outside the Extended partition?

Do you have to *resize* the Extended partition to use the remaining free space?  You don't explain how you have *GROWN-UP* the FAT32 partition.

Do you resize the FAT32 partition to take up the remaining free space after *growing* the Extended partition?

Now, I'm probably going to prove that I'm thick but:

gdisk "diskno" /diskwipe is done to get all space "used", filled with zeros, right?

The resizing and merging of partitions is to maintain 16 kB clusters on a FAT32 partition larger than 32 MB, right?

If the above is correctly understood, why not use a Win98 or WinME start disk to format and use the commands /U (unconditional, said to wipe and zero fill) and /Z:32 (will yield a cluster size of 32 x 512 bytes = 16 kB). If the drive letter is H: it would be "FORMAT H: /U /Z:32".

Christer

NightOwl wrote on Aug 22^nd, 2005 at 8:00pm:

START QUOTE

"... or an IBM 60 GB that I can test--how would you like those partitioned and formated?... I've never used PartitionMagic's *Convert* function--so I do not know what happens here... end up with two 57 GB NTFS partitions inside the Extended partition plus the 25 GB FAT32 partition--and the remaining *free space* at the end of the HDD outside the Extended partition?... have to *resize* the Extended partition to use the remaining free space... resize the FAT32 partition to take up the remaining free space after *growing* the Extended partition?"
Quote:

STOP QUOTE

BE ADVISED: DiscWizard assigns file system format by the volume of the partition selected, plus the second partition and all subsequent are going to be in an extended partition as a set of logical drives no matter what you do or don't do - forego fighting any of this early on:

(1)  The 60GB IBM IDE HDD would be best, but with only two partitions - initially go for a leading primary active NTFS partition trailed by default with an extended partition containing a single FAT32 logical drive;
(2)  After the so-called "low-level format" with GDisk, use DiscWizard to assign the target HDD as 'Additional Storage' and when underway proceed to slide the scale LEFT-to-RIGHT until the leading partition changes from GREEN-to-PURPLE (FAT32-to-NTFS) at about 36GB and stick with the NTFS default file cluster size as you mark SET; then

(3)  For the trailing partition, keep an eye on the window below the pie-chart graphic for the shift in FAT32 default cluster size from 8kb-to-16kb as you slide the scale LEFT-to-RIGHT and STOP RIGHT THERE to mark SET and then select the NEXT> radio button (you will find the remainder of this phase to be straightforwardly automated);

(4)  Upon exiting from DiscWizard, reboot your PC into SAFE MODE and reenter DiscWizard to select the Maintenance radio button to go to 'Maintenance Options', select 'Partitioning and Formatting Options' where you in turn select 'Grow a Partition' (this feature actually pumps up the logical drive to force the extended partition to occupy the remaining freespace albeit while retaining the 16kb cluster size - you will find the remainder of this phase to be likewise straightforwardly automated as DiscWizard will reboot without intervention on your part);

(5)  After the system reboots, you merely hit the Finish radio button, then in turn the Exit radio button and on to PM8; and

(6)  Once in Partition Magic 8.0, target the NTFS partition in the lead and perform a 'Convert partition' from Primary-to-Logical - et voila^' - you are done.

The trick now is to see if there are any marked performance differences between NTFS and FAT32.  I am reasonably confident that the IBM HDD will be amenable to the Seagate DiscWizard, but I cannot assure you of this.

[glb]El Pescador[/glb]

El_Pescador

I was reading your reply # 134 to Christer.  You talk about installing Seagate's DDO (dynamic disk overlay).  But your instructions above make no mention of doing that!

Also, your reply #134 refers to *DiscWizard Starter Edition*, but in the outline above you refer to *Seagate DiscWizard for Windows*, which appears to be a different program!?

Two questions:

1.  DDO is for systems that can not recognize the full capacity of larger HDD's because of BIOS limitations--why would you be recommending that on a system whose BIOS recognizes the HDD capacity natively?

2.  Does the Seagate Disk Wizard program *automatically* install the DDO on the HDD when you use it to partition the zeroed out HDD by GDISK?

*********************************************

Separate question:

In another thread here:  

TYPE FLAGS: A component of USB misbehavior ?

you said you were getting an *Error # 91* in DOS PartitionMagic, which stated that it was detecting *Disk Manager*.

*DDO* is also known as *Disk Manager* and this may be the source of that error message!

Have you attempted to install DDO on all your HDD's?

Christer wrote on Aug 22^nd, 2005 at 8:21pm:

"... gdisk "diskno" /diskwipe is done to get all space "used", filled with zeros, right?... resizing and merging of partitions is to maintain 16 kB clusters on a FAT32 partition larger than 32 MB, right?... why not use a Win98 or WinME start disk to format and use the commands /U (unconditional, said to wipe and zero fill) and /Z:32 (will yield a cluster size of 32 x 512 bytes = 16 kB). If the drive letter is H: it would be "FORMAT H: /U /Z:32"..."

Christer -

All of that is most likely correct - and exceedingly elegant, I might add - but at the end of the day will your troublesome HDD so configured have its FAT32 partition perform almost as well as its NTFS partition, for that is the real question.

All I do know is that my Western Digital SLAVE HDDs configured in time-honored fashion experience Ghost 2003 Backups with NTFS partitions at ¹/₄-to-¹/₃ the elapsed time achieved with the FAT32 partitions. After being reconfigured as described above, the FAT32 partitions will almost achieve parity with the NTFS partitions - go figure !!!

Regrettably, I cannot explain why it happens - I can only say that I can make it happen in my modest environment.  However, if you and NightOwl do in fact independently succeed in replicating my findings then this becomes a whole new ball game, doesn't it?

[glb]El Pescador[/glb]

NightOwl wrote on Aug 22^nd, 2005 at 11:58pm:

"... I was reading your reply # 134 to Christer.  You talk about installing Seagate's DDO (dynamic disk overlay).  But your instructions above make no mention of doing that!..."

That has been done by default with DiscWizard all along, but I only recently became aware of it.  In fact, I have spent several hours today with a Seagate utility that is supposed to remove DDO - and although the option is visible, it is "greyed-out" so that I cannot invoke it.  Since the utility is DOS-based, I am unable to make a screenshot to post.


NightOwl wrote on Aug 22^nd, 2005 at 11:58pm:

"... your reply #134 refers to *DiscWizard Starter Edition*, but in the outline above you refer to *Seagate DiscWizard for Windows*, which appears to be a different program!?..."

DiscWizard Starter Edition is the DOS-based version that overlaps DiscWizard for Windows to a great extent, but Seagate recommends the Windows version to make a final wrap - particularly where either the HDD exceeds 137GB or the client is running XP w/SP2 - or both.


NightOwl wrote on Aug 22^nd, 2005 at 11:58pm:

"... DDO is for systems that can not recognize the full capacity of larger HDD's because of BIOS limitations--why would you be recommending that on a system whose BIOS recognizes the HDD capacity natively?

This is not a recommendation one way or the other - it is nothing more than serendiptity that spun off of my resolution of grief with the Iomega External 80GB HDD.  I am simply stating that by so configuring I have placed the FAT32 partition of my internal SLAVE HDDs on a performance par with the NTFS partition.  It is up to you and Christer to ascertain whether or not it can be replicated with the IBM/Hitachi HDDs.


NightOwl wrote on Aug 22^nd, 2005 at 11:58pm:

"... Does the Seagate Disk Wizard program *automatically* install the DDO on the HDD when you use it to partition the zeroed out HDD by GDISK?..."

Absolutely and unequivocally - and I can neither stop it nor can I remove it - and I have tried mightily of late to do both.


NightOwl wrote on Aug 22^nd, 2005 at 11:58pm:

"... an *Error # 91* in DOS PartitionMagic, which stated that it was detecting *Disk Manager*.... *DDO* is also known as *Disk Manager* and this may be the source of that error message!..."

Honestly, I cannot recall either way whether the Iomega was subjected to DiscWizard prior to the attempts with the DOS-based PM8 emergency disks - but damned if doesn't sound likely.


NightOwl wrote on Aug 22^nd, 2005 at 11:58pm:

"... Have you attempted to install DDO on all your HDD's?..."

I have never installed DDO on any HDD with knowledge aforethought until yesterday afternoon when I was shaking down the process I was outlining for you in Reply #136 on a 160GB Seagate Barracuda IDE HDD mounted in a Metal Gear Box USB 2.0/SATA combo enclosure kit.  All of the MASTER HDDs in my three Dell Dimension desktop PCs were classically configured, for I only began using DiscWizard for Windows during the Iomega epiosode.  Admittedly, I now have SLAVE HDDs and external HDDs with DDO installed - but I did so unwittingly because I do things heuristically, i.e., I really screw things up, then I go check the manual ... LOL !!!

[glb]El Pescador[/glb]

El_Pescador

I looked at the on-line information here:

DiscWizard Suite is your installation software kit for installing Seagate disc drives.

Clicking on the *Learn More* link just above the *Select Language* radio buttons--according to the *posted* information--only *DiscWizard Starter Edition* mentions the DDO.

It implies that it will only install DDO if the program determines that your BIOS does not support the HDD capacity, and it seems to imply that it will alert you that it is installing DDO(or at least has) :


Quote:

How to use DiscWizard Starter Edition 8. If a Dynamic Drive Overlay (DDO) is required, DiscWizard Starter Edition will give very important instructions for booting to the computer. You will be given an option and instructions for creating an Ontrack Boot Diskette (requires a floppy with the OS on it). You will then be prompted to remove the diskette from Drive A: and press RESET or CTRL-ALT-DEL to reboot.

Quote:

That has been done by default with DiscWizard all along, but I only recently became aware of it.

1.  DiscWizard Starter Edition or DiscWizard for Windows--or both?

2.  I'm curious--if the option to remove DDO is *greyed out*--how have you determined that DDO is actually being installed and is present on your HDD's?

NightOwl wrote on Aug 23^rd, 2005 at 11:35am:

"... according to the *posted* information--only *DiscWizard Starter Edition* mentions the DDO..."

In retrospect, I now recall that after completing a very recent GDisk procedure using my Dell Dimension L400c - which lacked the DiscWizard for Windows installation at that time - I rebooted with the Seagate bootable installation CD.  I surmise that DiscWizard Starter Edition must be on the "front-end" of the CD, and that must be where I very first encountered the phrase Dynamic Drive Overlay (DDO).


NightOwl wrote on Aug 23^rd, 2005 at 11:35am:

"... It implies that it will only install DDO if the program determines that your BIOS does not support the HDD capacity, and it seems to imply that it will alert you that it is installing DDO(or at least has)... DiscWizard Starter Edition or DiscWizard for Windows--or both?..."

I did not catch that implication at all, but I cannot argue against it for it sounds quite sensible.  When booting from the CD, it advises against prepping the HDD outside of Windows but leads you to believe a DDO will be installed if you so choose.  I cannot recall the details in the least, but it seems that a good while back Rad cautioned against drive overlays under certain circumstances.


NightOwl wrote on Aug 23^rd, 2005 at 11:35am:

"... if the option to remove DDO is *greyed out*--how have you determined that DDO is actually being installed and is present on your HDD's?..."

The more I follow your assessment, the more I am inclined to believe that the DDO installation is an automated elective procedure - hmm, is that a contradiction within a phrase or not.  Let's just say the DDO installation is triggered by a shortcoming of some kind, and if the host BIOS and the candidate HDD are otherwise fully "up-to-specification" and compatible then such will not occur.  If I knew how to ascertain the presence of a DDO, I would seek them out in every little nook and cranny of my tangled cybernetic environment.

[glb]El Pescador[/glb]

P.S.  Step (2) in Reply #139 has been edited for clarity.

I had time to carry out a few tests, creating and checking images of the source (system) partition, C: on a 120 GB 7K250 with the target partition, F: on a 40 GB 60GXP. Both HDDs are PATAs. The 7K250 also has an extended partition with two logicals. I use No Compression when creating the images. I formated the single partition (all 40 GB) on the 60GXP in different ways and found:

WinME start disk, created extended/logical partition, formated using switch "/u" but let it decide the cluster size (cluster size 32 kB) => create image = 403 MB/min, integrity check = 400 MB/min

WinME start disk, created extended/logical partition, formated using switch "/u" and "/z:32" (cluster size 16 kB) => create image = 403 MB/min, integrity check = 392 MB/min

WinME start disk, created primary partition, formated using switch "/u" but let it decide the cluster size (cluster size 32 kB) => create image = 404 MB/min, integrity check = 399 MB/min

WinME start disk, created primary partition, formated using switch "/u" and "/z:32" (cluster size 16 kB) => create image = 403 MB/min, integrity check = 392 MB/min

From within WinXP Disk Manager, created extended/logical partition, formated NTFS with standard cluster size (4 kB) => create image = 854 MB/min, integrity check = 2101 MB/min

From within WinXP Disk Manager, created primary partition, formated NTFS with standard cluster size (4 kB) => create image = 854 MB/min, integrity check = 2125 MB/min

In no case did extended/logical or primary make a difference.

In no case did 32 kB or 16 kB cluster size make a difference (for cases formated FAT32).

Under all circumstances was NTFS 2.1 times faster creating and 5.3 times faster checking integrity compared to FAT32.

It seems like El_Pescador has discovered something that is quite puzzling. Creating a specific type of partition with a specific (non-standard) cluster size using a specific (quite intricate) method. I used a different method to acchieve similar partitioning but the performance was totally different. I can't predict if I would benefit from the same performance as E_P, if I would adhere to the E_P-procedure on my 60GXP. I don't have access to Partition Magic and have no other incentive to buy it which makes it a no-go for me.

Another peculiarity on FAT32 is that Ghost leaves "slack space" between the spans. My images were five spans with four "slack spaces". Any subsequent image gets written in the "slack spaces" of the previous image which makes span #1 fragmented. This doesn't happen on NTFS. Well ...... :-X ...... on my system but I don't know about others!

Christer
(who from now on, officially believes in ...... :o ...... GREMLINS)

Christer wrote on Aug 28^th, 2005 at 8:43pm:

"... Christer (who from now on, officially believes in ...... :o ...... GREMLINS)

The datestamp for the above post has a macabre twist for me, as I was fleeing northward before an approaching Hurricane Katrina at that very moment.  I never had opportunity to revisit this thread until today.

EP :'(

You must have been digging deep in the forum to find the old thread. I re-read my last post and don't even remember having done those tests ... :-[ ... !

Christer

Christer wrote on Mar 18^th, 2006 at 2:12am:

"... You must have been digging deep in the forum to find the old thread..."

Yes, indeed.  I was refreshing my thoughts relating to the thread below:

http://radified.com/cgi-bin/YaBB/YaBB.cgi?board=general;action=display;num=1142516913

EP :'(