Could 1 Bit really Make a Difference. Memory Expert Wanted Please.

My friend and I have been experiencing the same corrupted archive issues using TI9.1 build 3854 on his machine as a lot of other people on this forum. After reading several threads, I went ahead with memory testing using Memtest86+ v1.70. After three tests, we had 1 error in test No. 3 (See attached pic). This surprised me as his system has RDRAM which is usually error free, so I thought it may have been the memory controller.

We ran another test and this time it ran for over 7 hours and finished 26 loops, all of them perfect (See attached pic).

Question is, could this 1 bit error have been a fluke and if it was not a fluke, what is the likelihood that this could the source of our corrupted archive problem?

His System.

Mobo: Gigabyte GA-8IHXP-Rev.3
RAM: Samsung MR16R0828AN1-CK8 RDRAM (4 sticks 128 MB each 512 MB total)
HD No.1 Maxtor DiamondMax IDE ATA133 80 GBs running on regular IDE 100 MHZ, not the native Promise ATA133 controller (this was done intentionally for booting purposes). This HD has two partitions with the operating system Win XP in the C partition and data in the D partition.
HD No.2 Maxtor DiamondMax21 SATA 320 GBs. This HD has two partitions and holds just data in both.
HD No.3 Maxtor DiamondMax21 SATA 320 GBs. This HD has two partitions and holds just data in both.

All his HDs are NTFS formatted with 4k clusters.

His SATA drives are not running in RAID, they just hold data. He does not have native SATA support on his mobo. His addon PCI SATA controller card is an INIC-1622TA2 manufactured by Initio; it supports both 1.5 Gb/s and 3.0 GB/s modes.

Our goal was to successfully backup the OS ("C" partition approx. 12.5 GB on the IDE hard drive) to one of the other 5 partitions.

Whenever we ran a "partition backup/archive validate" whether as one task or as two separate tasks (backup first then validate), with the target image location the D partition on the same IDE drive, everything is always successful. We never actually attempted a restore as my friend is nervous.

Whenever we run a "partition backup/archive validate" whether as one task or as two separate tasks, with the target image location on any of the 4 partitions on the two SATA drives the backup process is always successful, but the validation process always fails. This has been the case whether we have the SATA drives set to 1.5Gb/s or 3.0 Gb/s.

If I try and copy the successfully completed archive from the "D" partition non the IDE drive to any of the four partitions on the SATA drives, the MD5 checksum using eXpress Checksum Calculator always fails.

I can't test using the CD as his SATA is not native and the SATA drives are therefore unseen using the CD.

This made me think of the RAM issue so I ran the tests. I'm no expert in that department so I'm not sure if that single bad result could be the cause of our problems. Seeing as how one single result from 29 full tests was bad, does that mean the RAM is good or bad? This is why I need the help of a memory expert

If I had money to bet on it, I would say that the SATA controller card is the problem or the SATA cable as I read in one of the threads. If someone could tell me what further tests to run to try and isolate the offending hardware I would appreciate it as I doubt it's a TI issue.

Any help is highly appreciated

 

Most here would recommend you let the test run at least overnight. Since you may have a problem, I would suggest you let the test run at least 12 hours and perhaps as long as 24 hours. If errors continue to show up then something is either wrong with the memory or motherboard.

 

There are a number of things which can make faults look like flukes. In your case it could be the address of the memory which was being exercised, it could have been variations in the speed that the data was being transferred, it could have been a slight difference in the ambient temperature.

Yes this could cause your TI fault, and as MudCrab suggests you need to get a more accurate sample by increasing the test time. However I would run it for a full 24 hours at least.

On another tack, I suggest you double check you are using the correct SATA drivers, it is possible that Windows is using generic ones which are not 100% compatible. Also, I suggest you try your known faulty backup configuration, but instead use the boot CD to do the backup and validate - you might find the results differ.

Other things to try are to swap the SATA cables and see if that helps (although I read somewhere, perhaps on this forum) that the plugs are only designed for 50 insertions, so lets hope you don't need to do too much of this.

Good luck

F.

 

I will let it run for 24 hours and post the results.

 

First make sure you are running with standard memory timings and no overclocking of the system.

TI can get a corrupt archive message if anything causes the checksum calculation to screw up, this includes reading the disk, RAM, the motherboard. Yes, it only takes 1 bad bit in the archive.

The MD5 checksum calculation failing with the SATA transfer only does make the SATA system suspect but remember that the MD5 checksum calculation also relies on RAM and the motherboard working properly. It is the same type of calculation that TI does to validate an archive. In other words, bad RAM could cause the MD5 checksum calculation to fail as well.

Memtest may show up an occassional error but remember that it is running in somewhat of a nicer environment than when you are running Windows with all the buss traffic from the disks, heating from the disks and graphics card (since it is doing fancier stuff) and heavier load on power supply. Check your power supply voltages to make sure they are within spec. They probably are but bad power can cause all sorts of problems. Electronics people will tell you to always check the power supply first but naturally, it is usually the last thing to be checked.

Since the error showed up in test 3 only you could set Memtest to just run test 3 to really flog the RAM with that test.

 

System is not overclocked.

What I meant by one bad bit is, does that mean that my RAM is bad if I only received that one error from that one bit or could that "problem" have been anything other than a RAM issue.

If it is a RAM issue, how come there are no errors when creating a backup of the C partition onto the D partition located on the same IDE drive?

Is there any software that does this?

I was considering this.

 

It could be caused by any of the hardware involved in the RAM testing which is a lot of the motherboard and the CPU itself. If you have a RAM error though odds are in favor of the stick itself being faulty. You should get 0 RAM errors. Your PC has no way of knowing if it is being given data from a faulty location until something goes wrong.

Good question and it maybe points to something else being a problem; it also isn't totally out of the question you have a very marginal RAM stick combined with the say a disk or disk controller card problem.

Some modern machines will display the voltages in BIOS. The ASUS machines come (still?) with a utility on the motherboard CD called AsusProbe which measured the voltages as well as the fan speeds. Other manufacturer's likely have them as well

A good utility was Motherboard monitor which you probably can still find via Google but the author stopped supporting it a year or two ago. If your machine is not the latest it may well work for you.

 

I am using Initio's drivers 5.6.5.1223 dated 12/23/05 which are not even digitally signed for XP. These were on the CD that came with the card, but it does not mean anything since the card came in a box for an ATA IDE controller card; we are in Egypt However, it's very strange that the version that was on the CD was somehow newer than the one I saw on Initio's website so I kept it. I just loaded up the one from Initio's website, version 5.6.5.1123 dated 11/23/05 which is also not digitally signed for XP, but it's still a no go.

Can't use the boot CD because the SATA drives are not seen by the bios.

 

If it's a marginal RAM stick I can only assume that it will sometimes fail when running a back up on the IDE drive and will cause that archive to fail validation if only once.

Just downloaded it from MajorGeeks. Will install and let you know if it works.

Great forum, thanks for all the help

 

The power supply is an LS-B300ATX made in china and pretty crappy as far as I can tell, but if it does the job, then there you go.

I looked it up and it's 300 Watts which is pretty weak. I took out all his cards and drives. We are currently powering up the IDE HD, one SATA HD, video card and SATA controller card. I took the following snap of Motherboard Monitor. If anyone can read it or tell me what to look for, I would really appreciate it.

 

Don't know why I didn't think of this before, but I just did a backup/validate to my iPod and it worked!

I also did an across network backup/validate and that worked too!

So there has to be something wrong with the system, but can we assume, not 99.99% but 100% that the fault does not lie with the RAM? Would hate to take away his system for a full 24 hours on a pointless RAM test.

Also, if we can definitely 100% rule out the RAM, can we definitely blame the SATA controller card or is it still too early for that?

 

You are asking for guesses. The only way to find where the problem lies is to track it down and isolate it. You did have a RAM error. How frequent it is is anybody's guess. If you do run the 24 hour test and get an error (or more than one) then that's more than enough to cause problems with TI (and Windows, for that matter). If it runs for 24 hours without errors, then maybe you'll get away with using it since the error will be very infrequent. Just don't forget that you did get an error.

I'm guessing that it's probably more a problem with the controller card as the tests seem to work when it's not included.

Do you have another SATA card you can try?

Do you have different RAM you can try? If you do, then you could install it and then try TI again and see if it works.

As for booting to the CD, it sounds like you're saying that the Full mode of TI (the Linux mode) isn't recognizing the SATA drives at all. Is that correct?

Have you duplicated your MD5 tests by doing copies between the iPOD and the IDE drive, between the network share and the IDE drive, etc.? Do those all check out okay?

If all the other tests come out okay, then I'd try a different SATA controller card. And if you plan on using it with TI, you may want to get one with good Linux support.

 

I did get an error, but so far in all of the tests, not a single archive failed when it was between the IDE, USB or Network. So while I am sure that the error is still a risk out there, I can only say that it is extremely small as 100% of the about 20 archives we did have been validated; restored is another question.

Unfortunately neither one of us has one and they are extremely hard to come by here in this country.

No and they are no longer sold in this country.

Yes, because it is not recognizing the SATA controller card. Only thing I could do was to copy over archives I created on the SATA drives over to the IDE drive and try to validate them with the CD which of course did not work.

Yes, I did checksum with two archives, the one I did on the iPod (Archive 1) and the other I did on the Network Computer (Archive 2).

I copied Archive 1 from the iPod to the IDE drive and that was OK. I then copied Archive 1 from the IDE to the Network Computer and that was OK.

I copied Archive 2 from the Network Computer to the IDE drive and that was OK. Only problem I had is when I tried to copy Archive 2 from the IDE to the iPod, it gave me an I/O device error.

I'm not to concerned about that because but this has happened to me a few times on other systems; my iPod has been dropped a few times I went ahead and copied Archive 2 to the SATA drive and it copied fine, but did not even attempt a checksum for obvious reasons I then copied Archive 2 to the Network Computer and the checksum was also fine. Again, I am by no means a RAM expert, so I may be absolutely wrong here, but if RAM was the issue, it would not have copied over Archive 2 to the SATA drive then Network Computer when it failed to copy to the iPod. I think the system is unstable somehow, but don't really think it is the RAM. I will run memory test No. 3 and see what happens

This is our final option.

Again I very much appreciate everyone's input

 

I suggest you raise a support request asap with Acronis and get them to look into this. Operability from the CD should not be seen as optional unless you have proven alternative such as BartPE ready to go.

If you want to restore your system partition using TI you need the linux environment to be work. If it isn't and you don't have a Bart/Win PE then you may be stuffed.

F.

 

To be honest with you, I don't think there is anything wrong with the software and after reading through the forums, it doesn't seem that they will be coming up with better solutions than the members of this forum.

I am much more interested now in knowing whether the RAM is good or bad as everyone has pointed out in many threads in this forum that bad RAM means high system unreliability. I've been running test No. 3 for over 10 hours now, 642 loops and not a single error. What does that mean in context of that one error I got earlier in Test No. 3. Could his RAM be good, with that one error being a fluke attributed to something else other than RAM (voltage drop, electrical issue)?

I can't seem to access http://www.nu2.nu/pebuilder/ to get a copy of BartPE.

 

Acronis can ADD the Linux drivers necessary for TI to detect and use your SATA card. Users can't do that.

That link is down right now. You can download it from the link off my page here.

 

The main shortcoming between the two implementations is that the Linux version's drivers usually lag the Windows version's drivers, for obvious commercial reasons, often by by 6 months or so.

If you make Acronis aware of this they can often provide you with an ISO image for you to burn to disk which is a Linux boot disk with your drivers on.

F.

 

Just to reiterate what was said before, if you can't access your SATA card with the CD, you can't restore your active partition if the archive is on a SATA drive unless you create a BartPE CD with the plugin.

 

I got you guys loud and clear on that issue. Now I finally know what BartPE does

My question now is that after 27 hours of running the No. 3 RAM test which showed 1 error previously and coming up clean, can we say that the RAM is 100% and that 1 error was do to the little green men in the machine?

With regard to the SATA, we're off on the hunt for a new card. Called the largest retailer in South Africa as a buddy of mine will be down there for one night tonight and they told me that they are hard to come buy. What the hell is this.........Africa?

 

Best to make a note of it and if anything funny starts happening run the RAM test first.

FWIW, my experience with memory diagnostics dealing with an intermittent problem points to faults showing up more readily in a "random data" test rather than a specific pattern test. Since yours showed up in test 3 one would think it would reappear in that test. If I had that machine I'd try running the random data tests for a while too.

 

I no longer need a Memory Expert, I need to borrow a gun to shoot the idiot that sold us the Initio SATA card in the Syba IDE ATA controller box with later version drivers than on the manufacturer's own site!

I got another card from him, a Syba SD-SATA150R with a SIL3112ACT144 chip (from Silicone Image) on it which is SATA 1.0 compliant; only 1.5Gb/s and no Native Command Queuing. Backup/Validation is working absolutely fine now. It was either a lousy card (China) or bad drivers.

Given my current experience with this issue I would guess that most of the guys getting an validation error and blaming it on TI are giving the software a bad wrap.

Thanks for all the help guys

I will run one more random test overnight and post the results. Want to know for sure about the RAM.

 

Memtest86+ has been running for 17 hours now and has successfully concluded 61 loops. Is there a need for the test to continue running for that seemingly magic 24 hour period or can we say that there is nothing wrong with the RAM. All this of course in light of that single error received previously in Test No. 3 after three standard test loops and the fact that test No. 3 ran solo for 27 hours straight without any errors.

Thanks

 

No point in going further but nothing is going to erase the fact that you did get one error and as I said previously, you should make a note of this in case of future difficulties.

 

I was kind of hoping I could chalk it up to some sort of glitch in the system, electricity, etc. but looks like he'll just have to live with it as is. At least we got the TI issue all worked out.

Thanks to everyone for their help. GREAT FORUM