new ssd anticlimactic

put another one, ssd in

dos native transfers - no gain, if not pain, between ssdssd

but it is a semi-intensive compression thingy I'm working with on
sector-to-sector binary transfers

ssd's are great, don't get me wrong, but at a certain point of
efficiency, they're redundant. Once the OS and supportive
applications layers are in NAND - it's only going so much farther.

may as well call it hybrid scenario then, as storage to cost
considerations mean a lot more when a $89 plattered 3T drive trumps
(for most) a $500 1T SSD.

Fortunately, I've got enough accumulated storage/data to where I can
say getting around in that quagmire is a lot easier on a SSD than
platters. (175G of storage still does take some time for eating up
CPU cycles while churning over indices and whatnot. Transfers, figure
I'm cutting time down somewhere between 1/2 and third of a
conventional drive trxs.)

As for my core OS, binary backups, one SSD pretty well covers about as
much speed as the OS is going to give up;- as mentioned, DOS binary
backups, well, it's in the header.

They're a lot of fun, though. Real pain in the butt to get this one -
had to fight it tooth and nail over getting the MBR settled,
(Partition Magic fixed it - 1st fat/primary for valid fdisk/format to
sys a: c: take, and last a boot arbitrator and that's pretty damn
nervey for probably a 10yr old prg!), some trouble with Win XP puking
over virtual memory (swapfile) assignments/cludge to get thru. Got
that thru another "settings" angle, luckily.

Haven't looked it over for what Win7 will think of my "new&improved
sys" yet.

This isn't a Samsung SSD unit, btw, like my other two. Samsungs are
pretty much effortless in my experience. Still this new brand, it's
working as expected with nothing major wrong - has a good reputation
for a somewhat smaller adherence, 3yr warrantee &etc., so enough said
about $20-25 average on 60G chunks of NAND.

That trim crap - can't believe after all these years they don't break
down and address some code directly to the controller. Was reading
some crap that for the controller otherwise to kick in its "garbage
routine" (independently of the non-TRIM OS) -- Log Out and let the
computer sit for 10 hours.

How about kiss my big hairy butt while I wait expressely for somebody
to address code directly to the controller;- besides, it may be NTFS
dependent for an OS TRIM request: screw TRIM for *nix and FAT
altogether, sounds like. And, little surprise, I can't stand NTFS
(except for what I'm stuck with using for - in case dealing in larger
than FAT32 allowances of 4G filesizes). That stuff about writing 1's
or 0's to clear the logic NAND gates, nahhh, don't like that either.
Only thing I got going for me, is once settled in, I don't need to
churn data, especially, and can just let it run 24/7, the way I like.
Got a big'un in between the SDD units, besides, big plattered drive if
I need to churn up some redundant read/write muck.

Seems like you were writing about an Intel SSD, but you never said.

Since you brought it up, does anyone know how well "trim" (automatic)
works on the Crucial MX100 drives (512 GB, $219)?

Bill


Flasherly wrote:
put another one, ssd in

dos native transfers - no gain, if not pain, between ssdssd

but it is a semi-intensive compression thingy I'm working with on
sector-to-sector binary transfers

ssd's are great, don't get me wrong, but at a certain point of
efficiency, they're redundant. Once the OS and supportive
applications layers are in NAND - it's only going so much farther.

may as well call it hybrid scenario then, as storage to cost
considerations mean a lot more when a $89 plattered 3T drive trumps
(for most) a $500 1T SSD.

Fortunately, I've got enough accumulated storage/data to where I can
say getting around in that quagmire is a lot easier on a SSD than
platters. (175G of storage still does take some time for eating up
CPU cycles while churning over indices and whatnot. Transfers, figure
I'm cutting time down somewhere between 1/2 and third of a
conventional drive trxs.)

As for my core OS, binary backups, one SSD pretty well covers about as
much speed as the OS is going to give up;- as mentioned, DOS binary
backups, well, it's in the header.

They're a lot of fun, though. Real pain in the butt to get this one -
had to fight it tooth and nail over getting the MBR settled,
(Partition Magic fixed it - 1st fat/primary for valid fdisk/format to
sys a: c: take, and last a boot arbitrator and that's pretty damn
nervey for probably a 10yr old prg!), some trouble with Win XP puking
over virtual memory (swapfile) assignments/cludge to get thru. Got
that thru another "settings" angle, luckily.

Haven't looked it over for what Win7 will think of my "new&improved
sys" yet.

This isn't a Samsung SSD unit, btw, like my other two. Samsungs are
pretty much effortless in my experience. Still this new brand, it's
working as expected with nothing major wrong - has a good reputation
for a somewhat smaller adherence, 3yr warrantee &etc., so enough said
about $20-25 average on 60G chunks of NAND.

That trim crap - can't believe after all these years they don't break
down and address some code directly to the controller. Was reading
some crap that for the controller otherwise to kick in its "garbage
routine" (independently of the non-TRIM OS) -- Log Out and let the
computer sit for 10 hours.

How about kiss my big hairy butt while I wait expressely for somebody
to address code directly to the controller;- besides, it may be NTFS
dependent for an OS TRIM request: screw TRIM for *nix and FAT
altogether, sounds like. And, little surprise, I can't stand NTFS
(except for what I'm stuck with using for - in case dealing in larger
than FAT32 allowances of 4G filesizes). That stuff about writing 1's
or 0's to clear the logic NAND gates, nahhh, don't like that either.
Only thing I got going for me, is once settled in, I don't need to
churn data, especially, and can just let it run 24/7, the way I like.
Got a big'un in between the SDD units, besides, big plattered drive if
I need to churn up some redundant read/write muck.

On Sat, 23 Aug 2014 12:12:55 -0400, Bill
wrote:

Seems like you were writing about an Intel SSD, but you never said.

Since you brought it up, does anyone know how well "trim" (automatic)
works on the Crucial MX100 drives (512 GB, $219)?

So weird - not intel - in fact an $80 Crucial MX 256. Accepted
convention for the automated Garbage Collection routine is just to
leave it alone to do its thing. A few "magic" utilities intended to
force the automated portion of GC are far and between, and generally
only reinforce that aspect (of a, hm, not stupidity - but "faith" in
technological intent for GC).

On Sat, 23 Aug 2014 12:25:57 -0400, Flasherly
wrote:

&btw - I filled mine twice - reformated and copied data to fill it
twice to its capacity of 256G. During a course of mistakes (didn't
catch a 64K segment format that should have been 4K segments) and
establishing a primary partition both for validly to boot and take a
boot arbitrator on the MBR (BIOS very first time up locked and
rejected it, scary, and except for an old Partition Manager Pro 8.5,
semi-scary, locked at a DMPI recognition every time for every all
other MBR/format-sys/fdisk I used).

Why I'd recommend a Samsung over that experience to anyone without
tools and a persistance for hammering (on something not necessarily
all about "Winderz").

Bill wrote:

Seems like you were writing about an Intel SSD, but you never said.

Since you brought it up, does anyone know how well "trim" (automatic)
works on the Crucial MX100 drives (512 GB, $219)?

Bill


This shows how they test for it.

http://www.anandtech.com/show/4202/t...-510-review/13

"As expected, Intel's SSD 510 fully supports the ATA TRIM instruction.

To gauge it's implementation I filled the 510 with data then ran a
4KB random write test (QD=32, 100% LBA space) for 20 minutes and
measured performance using ATTO.

I then TRIMed the entire drive by formatting it in Windows 7
and re-ran the ATTO test."

The review of the MX100, on the other hand, doesn't even have
the word TRIM in the article. The MX100 in the graph here,
is a little slow on write, compared to some others.

http://www.anandtech.com/show/8066/c...512gb-review/7

If you compare the Performance Consistency page in this article,
to the MX100, you'll see they specifically test TRIM here, and
the TRIM doesn't recover performance. It implies the MX100 doesn't
have TRIM (as they didn't do a TRIM test). On the other hand, while
the MX100 has "flat line graphs", I can't tell from the text description
whether it recovered from the 4K write test or not. Certainly the IOP rate
of the MX100 can drop to 20% of original value, as seen in one graph. But
I don't understand exactly how those graphs relate to how the
test for Performance Consistency works.

http://www.anandtech.com/show/8294/intel-ssd-pro-2500/2

The review here claims the MX100 supports TRIM. Or rather,
the reporting utility sees TRIM commands as being accepted.
With TRIM, there's no way to know what the drive does with
the information, which could just be ignored as it is
considered a "hint" and not a "command". There is no useful
information in this review, to comment on whether the
TRIM is used or not. The lack of TRIM analysis on the
Anandtech review, implies it isn't used for some reaslon.

http://www.thessdreview.com/our-revi...ew-256-512-gb/

Considering the MX100 price, I think you're supposed
to just buy it and use it :-) And not look too closely
under the covers.

I tried a search on the controller chip in the MX100,
"88ss9189 and trim", and in another review, the command
latency didn't bounce back when the pressure was off the
drive. Unlike some competing drives. Try tracking down
the 88ss9189 and see if there is more info on it. While
radically different firmwares could be developed for it,
most companies likely don't have designers with the skill
set to do it (write a new firmware from scratch, not just
turn some tuning knobs).

Paul

Paul wrote:
snip


Thanks for your post. I read some of those articles about the MX100
earlier, but I didn't mind looking again!

Bill

On Sat, 23 Aug 2014 13:39:34 -0400, Paul wrote:

I tried a search on the controller chip in the MX100,
"88ss9189 and trim", and in another review, the command
latency didn't bounce back when the pressure was off the
drive. Unlike some competing drives. Try tracking down
the 88ss9189 and see if there is more info on it. While
radically different firmwares could be developed for it,
most companies likely don't have designers with the skill
set to do it (write a new firmware from scratch, not just
turn some tuning knobs).

Here it is*, all else being equal to identical controllers (" "-BLD2)
and some suggesting ADATA is just a rebadged Crucial. (For whatever
else write performances might have to do with memory type
implementation and subsequent rating considerations.)

In any event - can't see a reason offhand for ADATA's TRIM
implementation software not to work with the Marvel. Pretty slick
looking actually (potentially for me, since I got nada else with this
drive so far). Interesting, too, if it did actually help/improve with
that latency delay;- not so sure it would, though, as the controller
has been around long enough in various developmental forms for
something of a stable regard, if not a "black box" implementation
perhaps never quite properly translated from obscurer Far Eastern
regions and dialects.

*
http://www.hardcoreware.net/adata-pr...pro-sp920-ssd/