Dette indlæg er alene udtryk for skribentens egen holdning.

Intense PC med Ubuntu 12.10 64-bit - lille, lækker og potent

27. februar 2013 kl. 21:4536
Artiklen er ældre end 30 dage

Jeg har som I allerede har kunnet læse her og her købt high-end modellen af den nye Intense PC - efterfølgeren til Fit PC-serien, som jeg tidligere har skrevet en del om.

Jeg er vildt begejstret. Jeg har startet med at installere en 64 bit Ubuntu 12.10 på maskinen via en USB-memory stick. Det var meget enkelt, og der var efter opstart kun en lille detalje, jeg skulle ændre. Under lydindstillinger skulle jeg ændre, at jeg ville have lyd ud via HDMI fremfor audio-porten, fordi min skærm har højttalere integreret. Jeg kører display i 1920x1080 via HDMI og det kører perfekt. Jeg har endvidere prøvet at have min normale fladskærm koblet på via HDMI og derefter en anden skærm på via display-port-stikket (en anden HDMI-skærm via en display-port til HDMI adaptor). Der var lidt diskussion i mit forrige blog-indlæg om dette. Det var et hit - Ubuntu ser den ekstra skærm og laver screen-extend per automatik, så vupti 2x1920x1080 - skønt. Jeg smed en 1080p film på mens jeg havde to skærme på.
Det kørte fint. Loaden på de fire processorer (to cores hver med hyper-threading) kommer aldrig op og ringe som det ses:

Jeg har startet et projekt med at rippe mine egne DVD'er med Handbrake via et LiteOn DVD-drev (koblet til via USB). Det kører et par gange hurtigere end på min gamle Pentium IV-spand :)
En normal DVD på 87 minutter rippes med H.264 i en MKV container på ca. 21 minutter og effektforbruget under fuld load er 30-33 Watt incl strøm til DVD-drevet - mod normalt 16 Watt i normal desktop drift.
Og den bliver ikke mere end håndlun. Det termiske design af Intense PC er lavet markant bedre end for Fit PC2.

Efter nogle minutters fuld CPU-kraft med DVD-rip måler jeg CPU-temperatur til ca 62 grader stabilt.
Først kørte jeg "sudo sensors-detect" og derefter:

  1. $ sudo sensors
  2. acpitz-virtual-0
  3. Adapter: Virtual device
  4. temp1: +62.0°C (crit = +106.0°C)
  5. temp2: +62.0°C (crit = +106.0°C)
  6.  
  7. coretemp-isa-0000
  8. Adapter: ISA adapter
  9. Physical id 0: +61.0°C (high = +87.0°C, crit = +105.0°C)
  10. Core 0: +61.0°C (high = +87.0°C, crit = +105.0°C)
  11. Core 1: +59.0°C (high = +87.0°C, crit = +105.0°C)

Jeg har sparket en SSD-disk i maskinen og det har vist sig at være en glimrende investering. Suspend tager ca et sekund og resume ligeledes ca et sekund. Den er rap:

  1. $ sudo hdparm -t /dev/sda
  2. /dev/sda:
  3. Timing buffered disk reads: 1188 MB in 3.00 seconds = 395.92 MB/sec
  4.  
  5. $ sudo hdparm -T /dev/sda
  6. /dev/sda:
  7. Timing cached reads: 15920 MB in 2.00 seconds = 7966.25 MB/sec

Til sammenligning ligger min trofaste Fit PC2 med en normal 2.5" harddisk på et fint - men meget lavere - niveau

  1. $ sudo hdparm -t /dev/sda
  2. /dev/sda:
  3. Timing buffered disk reads: 202 MB in 3.02 seconds = 66.99 MB/sec
  4.  
  5. $ sudo hdparm -T /dev/sda
  6. /dev/sda:
  7. Timing cached reads: 968 MB in 2.00 seconds = 484.30 MB/sec

Jeg har også prøver at smide et par Steam spil ind - sjoooovt :-)

Artiklen fortsætter efter annoncen

Alt i alt er der super tilfreds med mit køb og der passer mig fint at kunne pensionere min sidste store grå PC-kasse til fordel for min nye lille og rå Intense PC.
Jeg mangler at finde ud af om jeg også vil lave server på Intense PC maskinen og pensionere min Fit PC2.
Kræfterne er der til overflod, og selvom jeg ripper en DVD via alle fire CPU-enheder skriver dette samtidig med at se nedenstående film, så er der ingen antydning af mangel på kræfter - FED maskine. Se i øvrigt filmen

Remote video URL

Jeg har i øvrigt et spørgsmål til jer. Når jeg har en SSD-disk i en Linux-server, bør jeg prøve at minimere antal af skrivninger til disken - især tænker jeg på /var/. Eller er der reelt ligegyldigt?
Holder disken 3-5 år er jeg fint tilfreds - men under et år til hjemmebrug vil jeg være ked af. Spark gerne svar ind på dette.

/pto

36 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
29
20. marts 2013 kl. 10:37

et cronjob der dagligt kører med 'fstrim /' - afhængigt af mountpoints selvf, disable noatime (hvis man ikke bruger ting der er afhængig af dette), og så er man normalvis glad.

Hvis man er virkeligt bekymret, så kan man 'security erase' sin SSD-non-disk, så alle celler preppes til skrivning, og så partitionere så der er f.eks. 5 eller 10 GB ledig plads i enden, som aldrig røres af OS. Det giver en meget større ledig plads til diskens interne GC og wearleveling mekanismer, så man kan gange op ifht. producentes angivne levetid.

Men - en Samsung SSD830 kan holde til mange skrivninger - her er der et eksempel på at en sådan melder sig 'worn out' ved 828 TeraByte skrivning, men stadig fungerer efter over 5 Petabyte skrivninger:

http://www.anandtech.com/show/6459/samsung-ssd-840-testing-the-endurance-of-tlc-nand

In short - med lidt omtanke, så kan en 3. generations SSD holde så meget, at ovenstående spekulering i 1. og 2. generationsproblemstillinger nok er tidsspilde.

30
20. marts 2013 kl. 11:32

Quote fra linked artikel - og det jeg personligt bruger som argument for at købe Samsung SSD's (en af de største OEM SSD leverandører til bl.a. Apple og Dell):

"Furthermore, it should be kept in mind that all SMART values that predict lifespan are conservative; it's highly unlikely that your drive will drop dead once the WLC or MWI hits zero. There is a great example at XtremeSystems where a 256GB Samsung SSD 830 is currently at nearly 5,000TiB of writes. Its WLC hit zero at 828TiB of writes, which means its endurance is over five times higher than what the SMART values predicted. That doesn't mean all drives are as durable but especially SSDs from NAND manufacturers (e.g. Intel, Crucial/Micron, Samsung etc.) seem to be more durable than what the SMART values and datasheets indicate, which isn't a surprise given that they can cherry-pick the highest quality NAND chips."

25
19. marts 2013 kl. 09:39

Er også lige kommet til at købe en (efter at have læst Peters indlæg). Fin maskine. Jeg synes dog jeg har problemer med at få lyd ud fra den. Pt. har jeg smidt ubuntu 12.10 64-bit på den, har vga skærm forbidnet via HDMI->VGA konverter og tester lydudgagen via et par hovedtelefoner (skal lige have fundet nogle korrekte kabler for at kunne forbinde med mit analoge 5.1 højtalersæt).

Pt. får jeg slet ingen lyd ud. Nogen der har forslag til hvad jeg kan prøve?

26
19. marts 2013 kl. 13:28

Det er vist bare mig som er antik. Diverse konvertere bestilt.

31
20. marts 2013 kl. 19:38

Så spiller det. Kan kun være enig. Herre nice maskine.

22
2. marts 2013 kl. 16:34

Under (http://ef.gy/statistics:ssd-write-endurance) kan der ses en (teoretisk) opgørelse af SSD endurance. I forhold til andre sider viser forfatteren sin metode og antagelser (nogen er da lagt ud på ekstrem siden f.eks. kontinueret skrivning i "maximum link speed for SATA 3.0")

19
28. februar 2013 kl. 17:20

Jeg ved godt, at der hverken er diske eller blæsere. Men i et helt stille lokale - er der så støj fra den? Summen eller klikken eller deslige elektronikstøj?

18
28. februar 2013 kl. 13:56

Jeg har valgt at køre med noatime i fstab for at forhindre at der skrives timestamps hver gang en fil bliver læst fra disken og så har jeg slået swapfilen fra, jeg har 4 GB RAM i min laptop og den bruger sjældent mere end 500 - 1000 MB, så jeg syntes det er udnødigt at linux skriver til swapfilen.

Har ikke slået noget TRIM control til selvom jeg tror det vil være en fordel så har det fungeret fint og maskinen er lynhurtig selvom den nu snart er 5 - 7 år gammel Core2 Duo....bruger den mest til systemadministration, lidt python scripting og websurf.

16
28. februar 2013 kl. 11:40

Jeg mener også, at SSD endurance-problemer er helt overblæst.

Jeg har en 600GB SSD, som jeg ikke kan huske hvornår er købt. Men den har da 11.500 timers drift i Power On Hours (smart attribute 9).

I den tid er der skrevet 200.597 blokke a 32-megabytes (2^25 bytes) til den (smart attribute 225), og den har stadig 100% tilbage i media-wear-out (smart 233).

Den bruges som systemdisk UDEN trim (da jeg kører LUKS på den), mit homedir ligger på den, /var ligger på den.

Toshiba har et papir online, hvor de siger at en 64GB MLC SSD kan typisk holde til ca. 22 GB skrivninger om dagen (overlever den mere end 5 år), men at normal users skriver ca. 2 og power-users ca. 5gb pr dag (ca. dobbelt op, hvis man bruger suspend to disk etc... )

Så umiddelbart vil jeg sove roligt.. :)

13
28. februar 2013 kl. 10:15

prøv at google lidt på:

"SSD write endurance myth", så finder du en del materiale hvor folk har målt lidt på hvor lang tid du kan køre med en SSD, selvom du går amok med skrivninger.

Fedt projekt, den Intense maskine er kanon

23
2. marts 2013 kl. 16:41

Jeg undrer mig også over den myte holdes i live endnu :-) Hvis vi tager en 128gb disk, og antager den kan overskrives 1000 gange, så kan vi skrive 128000gb data før den gir op. Med 8gb om dagen, og det bruger de færreste, vil den holde 16000 dage, eller 43,8år. Jeg tror den dør af helt andre årsager længe inden da :-)

24
15. marts 2013 kl. 14:13

Hvis vi tager en 128gb disk, og antager den kan overskrives 1000 gange, så kan vi skrive 128000gb data før den gir op. Med 8gb om dagen, og det bruger de færreste, vil den holde 16000 dage, eller 43,8år.

Så nemt er det ikke. Hvis vi antager at en ganske stor del af en 128GB disk er afsat til diverse komponenter (Operativsystem, spil, programmer, pornofilm, fotografier af ungerne, manualer og kildetekster), vil der måske restere 10 - 50% af diskens kapacitet til skrivninger. Hvis skrivningerne endvidere foregår i prædefinerede kontainere (typisk i prædefinerede database filer af et eller andet format) accelereres problemet yderligere

28
20. marts 2013 kl. 08:40

Nils, du har self' ret, laver jeg så regnestykket om bliver det: Min arbejds PC har 40gb fri plads på min 128gb SSD, det er 40000gb skrivninger, 8gb om dagen gir 5000 dage, eller 13,70år. Det er stadigvæk et ok resultat :) Hvis vi som du siger antager der er 10% ledig af en 128gb disk, så snakker vi stadigvæk 4,51år før disken gir op, ved 8gb om dagen. 8gb om dagen er altså en hel del på en almindelig PC!

32
20. marts 2013 kl. 20:44

Har i glemt at disken laver wear leveling? Hvis der er områder af disken der bruges mere end andre, så bytter den området således at alle dele af disken slides lige meget.

34
21. marts 2013 kl. 05:47

@Baldur

Nej jeg har ikke glemt det. Jeg tror (lidt ligesom ved ikke rigtigt men lyder mest sandsynligt) dog ikke at SSD wera levering flytter om på filer/blokke som er allokeret til et formål. Dette ville betyde at alle filers placering er dynamiske.

35
21. marts 2013 kl. 08:28

Hmm.

Jeg tror ergo tager jeg fejl!

Tilsyneladende bruger SSD'er en teknik kaldet "Static Wear Levelling" som rent faktisk flytter om på blokke for at sikre bedre udnyttelse af SSD mht antallet af mulige skrivninger.

Så konklusionen er at hvis SSD'en understøtter denne teknik kan SSD'en levetid rent faktisk beregnes som en funktion af antallet af skrivninger og størrelsen af SSD'en uanset hvor stor del af SSD'en der er belagt med prædefinerede filer.

en.wikipedia.org/wiki/Wear_leveling

http://thessdguy.com/how-controllers-maximize-ssd-life-better-wear-leveling/

33
21. marts 2013 kl. 05:47

@Baldur

Nej jeg har ikke glemt det. Jeg tror (lidt ligesom ved ikke rigtigt men lyder mest sandsynligt) dog ikke at SSD wera levering flytter om på filer/blokke som er allokeret til et formål. Dette ville betyde at alle filers placering er dynamiske.

11
28. februar 2013 kl. 09:24

Det var jo et fint billede af strømmåleren. Den samme som jeg har lånt.

Min Mini/3210M viser 30.5W under fuld load (Handbrake session) samt film i VLC (for at belaste grafikdelen) WLAN/HDMI/Bluetooth aktive.

Så forskellen er at du også har et USB drive monteret.

Så gad vide hvordan forskellen på intels 35W/17W så fremkommer?

21
1. marts 2013 kl. 22:33

Naaa - cluet er at jeg ikke har respekt for "backup", men kæmpe respekt for "restore". Desværre er det alt for få personer, som faktisk tester at de kan "restore" data efter "backup"

4
27. februar 2013 kl. 22:22

Jeg har i øvrigt et spørgsmål til jer. Når jeg har en SSD-disk i en Linux-server, bør jeg prøve at minimere antal af skrivninger til disken - især tænker jeg på /var/. Eller er der reelt ligegyldigt? Holder disken 3-5 år er jeg fint tilfreds - men under et år til hjemmebrug vil jeg være ked af. Spark gerne svar ind på dette.

Sørg form at TRIM er aktiveret. Det sker ikke automatisk på Linux. Du skal bruge mount option discard og et filsystem der understøtter TRIM (ext4 gør).

Din SSD kan formentlig klare et par tusinde fulde overskrivninger, og medmindre du hamrer løs på disken med store datamængder, er 3-5 år ikke noget problem. Dine /var skrivninger vil ikke væsentligt forkorte levetiden.

Med smartctl kan du løbende holde øje med hvor meget der er skrevet til disken.

Jeg har en 80GB Intel X25-M siddende som system disk i min home server, og /var har en Mysql database på 900 MB, logfiler som hyppigt opdateres (cron jobs som kører hvert tredje minut), og hver nat laves et dump af mysql databasen også til SSD'en. Smartctl rapporterer at der skrives mellem 4 og 5 GB data til disken hver dag.

Swap partition ligger også på SSD'en (du kan også bruge discard på en swap partition), men fordi der er 4 GB RAM i serveren, bruges swap meget lidt. Jeg har dog tilføjet disse linjer til /etc/sysctl.conf, så swap bruges så lidt som muligt (ikke at det gør nogen forskel)

  1. # Limit swap usage on SSD
  2. vm.swappiness=1
  3. vm.vfs_cache_pressure=50

/tmp er mountet som tmpfs, men primært for hastighed (der skrives relativt lidt til /tmp så det betyder næsten intet for SSD levetiden).

Disse forslag er taget herfra hvor der er andre Linux SSD rådhttps://wiki.archlinux.org/index.php/Solid_State_Drives

Jeg har nogle andre maskiner hvor jeg bruger CF kort (SLC CF kort fra Samsung og Transscend), og her har jeg tilføjet

  1. # Limit writes to CF card (default: 500)
  2. vm.dirty_writeback_centisecs = 1500
til /etc/sysctl.conf for at begrænse skrivningerne til /var.

Men til almindelig privat brug med en nyere SSD (desktop eller home server), vil jeg i dag bare smide disken i, aktivere TRIM, og ellers nyde hastigheden. Hvis disken dør, er det formentlig på grund af en firmware bug, og ikke fordi flash chippene er slidt op.

10
28. februar 2013 kl. 08:50

Sørg form at TRIM er aktiveret. Det sker ikke automatisk på Linux. Du skal bruge mount option discard og et filsystem der understøtter TRIM (ext4 gør).

Denne blogpost forklarer at TRIM/discard nogle gange kan gøre ondt når man sletter mange små filer:https://patrick-nagel.net/blog/archives/337

I stedet kan man bruge fstrim fra util-linux-pakken til at trimme sin SSD med jævne mellemrum når man alligevel ikke skal bruge disken.

9
28. februar 2013 kl. 08:45

Om trim:

I stedet for at mounte med discard så kan du køre fstrim jævnligt i et cron job. Et filsystem der er mounted med discard kan være meget langsomt i nogle situationer. f.eks sletning af mange små filer.

6
27. februar 2013 kl. 22:26

TRIM

Wauv - fed kommentar. Tak Jesper

7
28. februar 2013 kl. 00:39

Vil gerne tilføje, til den allerede meget udførlige vejledning, kudos til Jesper - at det ligeledes på desktop udgaven kan svare sig at flytte sin browser(s) cache til dit /tmp tmpfs.

Det gøres vha. en preference indstilling i about:config i firefox, mens den udmiddelbare nemmeste tilgang med chrome og chromium, som jeg har kunnet finde, har været at lave symlinks til samme tmpfs :)

14
28. februar 2013 kl. 11:20

kan svare sig at flytte sin browser(s) cache til dit /tmp tmpfs

Jeg har altid syntes at det bliver noget dobbeltkonfekt. FireFox cacher allerede i memory så jeg har lidt svært ved at se fidusen ved at bruge mere memory til cache (kun når /tmp er tmpfs naturligvis). I stedet slår jeg bare disk cache fra i min browser (browser.disk.cache.enable = false i FF)

15
28. februar 2013 kl. 11:28

Det er sandt Martin - hvordan gør du tilsvarende for Chrome og Chromium? :)

8
28. februar 2013 kl. 08:24

Ad FF: Det speeder iøvrigt FF op mærkbart - så kan sagtens anbefales.

@Kasper - kunne du lokkes til at vise din chrome 'ln -s' ?? Jeg må indrømme, jeg har været for doven (travl) til selv at forfølge den.

Venligst

12
28. februar 2013 kl. 09:45

Hej Palle,

Du får dem lige her :)

Jeg har selv oprettet /tmp directories manuelt på forhånd, selvsagt ;)

ln -s /tmp/chrome/Default /home/kasper/.cache/google-chrome/Default ln -s /tmp/chromium/Default /home/kasper/.cache/chromium/Default

2
27. februar 2013 kl. 22:15

Generelt ja. Hvilken SSD har du sat i? Intel har en SMART entry der hedder 233: media wearout indicator (og med min 320 series med 4TB skrevet står den stadig på 100) jeg er ret sikker på de andre producenter har noget tilsvarende

36
6. september 2013 kl. 15:10

Jeg har Intense PC med Samsung 840 Pro. Det virker fint med opstart / nedlukning, simple filer mm. Men webserver (mange læsninger/skrivninger til DB) kald performer meget skidt i forhold til en Intel SSD (7 gange værre). Jeg har skrevet lidt om det her:http://www.version2.dk/artikel/stor-test-opgrader-til-ssd-og-faa-67-procent-hurtigere-office-53271#comment-247208

Jeg vil gerne høre om andre har gjort sig nogle erfaringer. Det har intet med intense PC at gøre (problem er også i anden maskine med Samsung i. Muligvis er det relateret til Linux eller en defekt SSD (men intet tyder på den er defekt) )

1
27. februar 2013 kl. 22:07

Jeg prøvede en lille leg, da jeg skiftede computer her. Jeg måtte ikke kopiere fra den gamle computer - KUN fra backup-disken. Fin metode til at checke hvad der kører backup af OG om lortet faktisk virker :)