Intel Communities: Message List

Re: "Disable write caching" option in SSD drive property page

webadmin@intel.com — Thu, 09 Sep 2010 03:32:00 GMT

Hi,

Your supposition's correct, Intel does not recommend disable write caching, quite on contrary, it's only an "exercise".

You can see that in: http://www.intel.com/support/ssdc/hpssd/x25m/sb/CS-031542.htm

Re: HDD Erase 3.3 HORROR STORY - Anyone else???

webadmin@intel.com — Tue, 09 Feb 2010 19:25:14 GMT

Hi Curious,

From what i know:

- you have the right drive - the retail, covered by full Intel warranty.

- the retail box come in a box with Intel label and logo, instruction CD, 3.5 to 2.5" adaptor and manual

- the part nº .......80G2GC is the SSD itself, which is the same for the retail and OEM drive.

A full discussion about the terrible way Intel identifies the drives, you can se in the following threads:

- http://communities.intel.com/thread/8492 ( a complete and funny thread with video!!)

- http://communities.intel.com/message/69677#69677 (an authoritative information: afrosty is an Intel representative)

- http://communities.intel.com/thread/6721?tstart=420 (there is some details of Intel numbering)

By the way, sometimes the customer service is not aware of all numbering details...

regards

Re: HDD Erase 3.3 HORROR STORY - Anyone else???

webadmin@intel.com — Mon, 08 Feb 2010 20:50:03 GMT

Hi Curious,

Thanks for your kind words but i'm not in any ways an expert, only a "curious" and a little stubborn consumer, but in this Forum do exist people that are truly experts in computer things...

Well, first of all you're doing the correct way, so keep doing this way.

In my post, regarding G2 drives, the old motherboard's bios did not allow hdderase to bypass the bios security freeze lock, and i had to do an alternative way to execute it. And i was informed by Guz that a new mobo bios corrects this behaviour. Nowadays i have updated the bios, but have not hdderased any G2 drive with this bios.

When hdderase is not allowed to bypass the bios lock (not your case) they say there are 3 ways to overcome this:

- to change the drive position, for instance from sata channel 1 to sata channel 4 on the sata mobo plugs (i'm presuming the drive is sata).

- to use another computer to do the secure erase, since the freeze lock depends on bios' behaviour and another computer's bios may not have this issue.

- when none of the precedents ways work, there is a workaround that is a little dangerous to the drive (the hdderase instructions are very clear about the risks involved, but i have never had any problem):

With the mobo's bios set to boot from the drive on which hdderase is, boot with the drive's sata power plug disconnected (and the signal plug connected); after you are on the hdderase DOS program, reconnect the power plug and run the program.

This fools the bios in not detecting the drive and not having a freeze lock command, and hdderase should run normally.

I have done this workaround (for G2 drives) a few times without any glitches, but i'd be more comfortable if i had not to resort to it.

Anyway your're doing the right way, and if you're in AHCI mode with Microsoft W7 drivers, TRIM will keep your drive in very good conditions, without having to hdderase it.

regards

valdir

Re: Intel RST drivers v9.5.6.1001 WHQL with Trim support?

webadmin@intel.com — Mon, 08 Feb 2010 07:58:05 GMT

Hi Bobins and UglyPercy,

I checked DCP latency in my system and the max value, in only 2 or 3 spikes, was ~4000 us, or 4 ms, under the following conditions:

- running a antivirus scan, and

- streaming a video

- a period of aprox.50 min.

- disregarding the 2 or 3 spikes the normal latency was ~100us

So, in my case the latency is not an issue, and i think the problem is a little more complex, since it depends of what is the load (applications running, if the antivirus is load intensive, etc) on the computer, and of course what is the computer's hardware resources.

For video and audio streaming, there is, at least, another parameter to be considered: the latency between the server from which we are dowloading the stream and the computer, which typically is of 50 - 300ms or 50,000us - 3000,000us, and that can cause audio/ video stutterings .

Also i think the "diagnostic" given by DPC Latency Checker is too simplified, misleading, and alarmist, in my case: "Some device drivers on this machine behave bad and will probably cause drop-outs in real-time audio and/or video streams. To isolate the misbehaving driver use ..."

From what i understood this "diagnostic" is not considering that: the spikes only happened 2 or 3 times in a period of almost one hour, the buffer of several seconds that almost all "real time" applications have, and that even good harddrives have an access time of 9,000- 18,000 us, so comparable to the spikes.

And of course, many things besides "drivers behaving badly" may cause an increased latency on a computer.

As an objective result, i have never observed in my system any stuttering effects in audio/video streams.

Sorry for invading this thread that is supposed to be about Trim support; maybe the latency subject deserves an exclusive thread...

My two cents...

regards

system: 2x 80GB G2 Intel SSD in raid conf.

Intel ICH10R sata raid controller/ driver version 9.5.6.1001

W7 64 bit

Re: HDD Erase 3.3 HORROR STORY - Anyone else???

webadmin@intel.com — Sat, 06 Feb 2010 20:06:23 GMT

Yes, the drive has endured bravely and patiently many tests and mistakes i did.

Regarding the Host Writes parameter, somewhere in this forum, there were people claiming that in some cases it was not showing the correct numbers, since their new drive, with only one Windows installation, had over 3 TB of usage!!!!

I don't know if the 1.2 toolbox version has corrected this issue, if it really was an issue...

Regards,

valdir

Re: HDD Erase 3.3 HORROR STORY - Anyone else???

webadmin@intel.com — Sat, 06 Feb 2010 06:07:57 GMT

Hi Curious,

You can see the information about bad sectors in the Toolbox, under Check SMART Attributes, ID 5, Re-allocated Sector Count.

The number of bad sectors are displayed in a different mode for G1 and G2 drives, accordingly the "Intel SSD Toolbox User Guide" and for instance my G1 test drive has between 28 and 31 bad sectors, created by enhanced hdderases, BSOD's, many installations of OS's and general harsh drive treatment...

Eventhough, the drive works perfectly well and the Media Wearout Indicator shows that it has spent less than 2% of its "working life" (less because the User Guide says that afer the value reaches 1, there yet is significant "life" for the drive... and i hope so...

Another interesting parameter is Power-On Hours Count that aprox. indicates how many hours the drive was active; mine was on the road for 431 hours at that time.

Hope this helps.

Re: HDD Erase 3.3 HORROR STORY - Anyone else???

webadmin@intel.com — Fri, 05 Feb 2010 22:52:33 GMT

Yes Guz, the bios locks i had was with an earlier bios; i have not hdderased any drive with 1704 bios, good to know that, because i updated the mobo with this bios a few days ago.

I also have always had good results with hdderase, the drives returning to its fresh state.

But a word of caution: on a G1 test drive the "enhanced secure erase" increased the number of "bad sectors" of the drive, and i stubborn as i am, tried several times this, and a not "scientifc" result, but i could say that 5 enhanced erases give origin to 3 more bad sectors on the drive, so....not to use enhanced but only secure erase.

Regards.

Re: HDD Erase 3.3 HORROR STORY - Anyone else???

webadmin@intel.com — Fri, 05 Feb 2010 21:16:23 GMT

Hi curiosconsumer,

I have ran hdderase several times on G1 and G2 drives; on G1 drives the program always asked to to a hard reboot and after doing so, everything was fine.

With G2 drives and my mobo, the hard reboot was'nt sufficient to bypass the bios security freeze lock, and i had to go on a workaround method: cut the power of SSD (by unplugging its power cable) and after rebooting with the DOS boot disk, everything was ok.

The Read Me section of http://cmrr.ucsd.edu/people/Hughes/SecureErase.shtml very well explains this and other possible issues with hdderase.

I also suppose that the particular behaviour of hdderase depends of the particular mobo and its bios; mine is ASUS Rampage 2 extreme.

Regards.

Re: Do Intel's new RST AHCI/RAID drivers support TRIM?

webadmin@intel.com — Thu, 24 Dec 2009 01:48:41 GMT

i upgraded from Intel that comes with W7 to 9.5.4.1001 a few days ago and so far so good.

In HD Tune the improvement was very good:

- before

- after

i'm running an ASUS R2E with ICH10R and still checking the driver, i believe it's possible a better performance.

Re: 80 GB (G2) not updating to 2CV102HD

webadmin@intel.com — Fri, 04 Dec 2009 00:53:21 GMT

Hi Iasp, Yes, it is the first case i see this updater behavior. I suggest you burn another CD-R with the update iso file (downloading it again, instead of using the one you possibly have already downloaded) and mark the option of the burner verify the copy after it made the copy. I have used the W7 built-in burner with good results. regards