[mythtv-users] warning for anyone with western digital green drives

Warpme warpme at o2.pl
Wed Jan 11 21:29:54 UTC 2012


Hi,

At beginning I want to underline, Ron's OP make this mailing-list really 
nice source of knowledge.
Thx for this.
Inspired by OP, last days I was experimenting little with SDD in my 
MythTV system (BE server).
Result were surprising enough that I decide to post them here.

My BE is 880G based mobo with AMD235E CPU, 4G RAM, and base storage via 
2x2TB WD green.
First HDD is OS+DB and hosts HD movies.
Second HDD is /myth.
OS is Arch derivative.

All FE are based on ATOM1 and are disk-less PXE booted.
OS is minimyth derivative.

MythTV is v0.25pre-4055-gf9f8b71-dirty-20120111

In my test I replaced OS+DB drive to SSD (Samsung 830 series, 64G model).
SSD was with Ext4, discard, noatime, barriers=off. CHS aligned to 32/32.

Some notes:
 From 4G RAM, kernel allocated 2,7G to buffers.
I can expect this level in storage hierarchy (buffers) will be slower 
that RAM but faster than any next in hierarchy level (physical mass 
storage).
Also I configured 32M query cache to mysql in hope that DB reads fill be 
mainly from cache. Other parameters were set to mysqltuner.pl suggestions.
I configure /tmp as tempfs in hope that all temp SQL tables will be 
written-read from RAM based mass storage.

Moving from HDD to SSD.

Results:
Qualitative:
-On FE I practically didn't notice any subjective speed-up.
-Only area where speed-up is seen is mythweb (was instant, with SSD is 
flashy)
-I can definitely say: it is NOT a case where SSD-based system was slow 
like HDD-based one. It is a case where HDD-based system is the same fast 
like SSD (for justification of such statement pls go to end of this post).

Quantitative:
Here are OS boot & scheduling comparisons:

HDD boot:
Jan 11 14:36:54 Startup finished in 3s 54ms 736us (kernel) + 56s 995ms 
395us (userspace) = 1min 50ms 131us.

HDD scheduling:
2012-01-11 14:53:42.959000 I Scheduled 381 items in 5.7 = 3.44 match + 
2.22 place
2012-01-11 15:46:22.516929 I Scheduled 379 items in 5.8 = 3.50 match + 
2.27 place
2012-01-11 15:51:17.644414 I Scheduled 379 items in 5.9 = 3.55 match + 
2.36 place
2012-01-11 15:56:16.214845 I Scheduled 379 items in 5.9 = 3.55 match + 
2.37 place
2012-01-11 15:57:53.363886 I Scheduled 379 items in 2.4 = 0.00 match + 
2.35 place
2012-01-11 15:59:50.008540 I Scheduled 379 items in 2.4 = 0.00 match + 
2.36 place
2012-01-11 16:07:13.492971 I Scheduled 378 items in 6.0 = 3.74 match + 
2.26 place
2012-01-11 16:11:16.104133 I Scheduled 378 items in 5.9 = 3.73 match + 
2.21 place
2012-01-11 16:16:16.588279 I Scheduled 378 items in 5.7 = 3.55 match + 
2.20 place

SSD boot:
Jan 11 11:57:26 Startup finished in 4s 541ms 296us (kernel) + 52s 835ms 
494us (userspace) = 57s 376ms 790us.

SSD schedulling:
2012-01-11 12:07:04.334242 I Scheduled 383 items in 6.0 = 3.56 match + 
2.39 place
2012-01-11 12:10:03.098568 I Scheduled 382 items in 2.4 = 0.00 match + 
2.36 place
2012-01-11 12:11:15.145393 I Scheduled 382 items in 5.8 = 3.47 match + 
2.36 place
2012-01-11 12:16:16.925119 I Scheduled 382 items in 5.9 = 3.53 match + 
2.35 place
2012-01-11 12:21:16.627705 I Scheduled 382 items in 5.8 = 3.47 match + 
2.33 place
2012-01-11 12:26:14.412831 I Scheduled 382 items in 5.9 = 3.51 match + 
2.35 place
2012-01-11 12:31:16.768138 I Scheduled 382 items in 5.9 = 3.50 match + 
2.39 place
2012-01-11 12:35:31.710289 I Scheduled 382 items in 6.0 = 3.55 match + 
2.44 place

My conclusions:
1.In case of my system build-in-kernel disk buffering is so effective 
that even significant speedup of next level storage hierarchy (HDD->SSD) 
is totally masked by kernel buffering.
2.Big enough MySQL caches quite effectively masks speedups in mass-storage.
3.Recordings rescheduling speed is directly correlated to CPU (going 
from Celeron 3,46G to AMD 235E changed reschedule time from 60s to 18s).
4.For rescheduling speed-up, next, after CPU upgrade & mysql caches, is 
moving /tmp to tempfs (noticeable speedup 18s->6s).
5.Current MythTV system based on quite slow HDD like WD Green is working 
really nice even with ATOM CPU. (86 progs EPG loads in aprox 0.4sec. 
390+ recordings list is instant (in sense that there is no time to show 
loading progress dialog).

Summarizing:
Speaking in economy: HDD->SSD marginal utility increase is in my case 
was ABSOLUTELY not worth of SSD investment.
Before SSD spending decision I'm strongly recommending:
-buy more RAM for having huge as possible kernel disk buffers
-move /tmp to tempfs
-allocate 32MB or more for MySQL query cache (and other parameters 
accordingly to http://mysqltuner.pl/)
With above it is highly probable that You will get MythTV system where 
HDD->SSD upgrade will absolutely not worth the money (and allows You 
spent those money elsewhere - with much higher utility).

br

BTW: Sorry not sending this mail with proper thread-id. I had some 
problems with mailer software and old posts were lost, so I can't get 
reference ID.

BTW2: I replaced my desktop HDD (Caviar Black 1TB) with this SSD. Here 
SSD plainly SCREAMS.
I.e launching program or restoring it's window are practically 
indistinguishable.




More information about the mythtv-users mailing list