Tags:
Node Thumbnail

เว็บไซต์ AnandTech ค้นพบว่า Android 4.3 Jelly Bean ที่เพิ่งออกเมื่อสัปดาห์ที่แล้ว รองรับคำสั่ง TRIM หรือการบอกระบบปฏิบัติการว่าบล็อคข้อมูลไหนใน SSD/eMMC ที่ไม่ใช้เก็บข้อมูลแล้ว สามารถนำบล็อคนี้มาใช้เก็บข้อมูลอย่างอื่นได้

AnandTech ทดสอบแล้วพบว่าอุปกรณ์ตระกูล Nexus สามรุ่นได้แก่ Nexus 7 รุ่นแรก, Nexus 7 รุ่นที่สอง และ Nexus 4 ที่อัพ 4.3 แล้วมีฟีเจอร์นี้ ช่วยให้ประสิทธิภาพด้าน I/O ดีขึ้นมาก ต่างไปจากการใช้ระบบปฏิบัติการรุ่นก่อนหน้าที่ใช้ไปนานๆ หรือเก็บข้อมูลเยอะๆ แล้วระบบจะเริ่มช้าลง

รายละเอียดทางเทคนิคอ่านได้จากต้นฉบับครับ

ที่มา - AnandTech

Get latest news from Blognone

Comments

By: JiHuay
iPhoneWindowsIn Love
on 31 July 2013 - 16:26 #604155
JiHuay's picture

ฟีเจอร์ในฝัน

By: hisoft
ContributorWindows PhoneWindows
on 31 July 2013 - 16:31 #604164
hisoft's picture

Windows Phone 8 นี่มีมั่งรึยังเนี่ย เห็น Windows RT มีแล้ว

By: inkirby
ContributoriPhoneAndroidIn Love
on 31 July 2013 - 16:56 #604190
inkirby's picture

ยี่ห้ออื่นจะมีฟีเจอร์นี้อยู่แล้วแบบ Bluetooth LE รึเปล่าเนี่ย?


Dream high, work hard.

By: jirayu
ContributorWindows PhoneBlackberrySymbian
on 31 July 2013 - 16:58 #604192

ดีครับ ฟีเจอร์นี้ ผมจำได้ว่าเคยบ่นเอาไว้ในนี้แหละว่าไฟล์เยอะๆ แล้วระบบโดยรวมช้าลง แล้วมีคนบอกว่ามือถือใช้แฟลชไม่ได้ใช้ฮาร์ดดิสก์ ไฟล์เยอะไม่ช้า

สรุปคือไฟล์เยอะมันก็ยังช้าอยู่จริงๆ สินะ


By: neonicus
Android
on 31 July 2013 - 19:23 #604320 Reply to:604192

ผมก็ยังไม่เชื่อคนพวกนั้นอยู่ดี
เป็น flash แต่มันก็มี fragment อยู่ดี
เวลาอ่านก็ต้องอ่านหลายเที่ยวกว่าจะครบไฟล์
ก็แค่ไม่มีoverheadในการไปอ่านblockอื่นๆเพื่อเอาdataมาเรียงกันตอนอ่าน

By: McKay
ContributorAndroidWindowsIn Love
on 31 July 2013 - 20:38 #604356 Reply to:604320
McKay's picture

flash storage ไม่มี fragmentation ครับ มีแต่ปัญหาเรื่อง write นี่แหละ

ก่อนอื่นต้องเข้าใจก่อนว่า flash storage ไม่ได้ใช้ planar ที่เป็นจานหมุนจานเดียว-สองจารและมีหัวอ่านแบบ harddisk ปกติ แต่จะประกอบด้วย NAND เล็กๆ หลายๆตัว(ประมาณ 8) ซึ่ง NAND Flash มันเป็นการทำงานแบบ electrical(แบบRAM) ไม่ใช่ mechanical ฉะนั้นจุด data ทุกจุดบน NAND จะทำงานได้ความเร็วเท่ากันหมด และจะถูกควบคุมด้วย controller อีกที ซึ่ง SSD จะเร็วหรือช้าก็ขึ้นอยู่กับตัว controller ครับ

ในการเขียนไฟล์หนึ่งๆ controller จะกระจายไฟล์ที่เขียนอยู่ในให้ NAND แต่ละตัวในอัตราที่พอๆกัน(ให้นึกถึง RAID 0) เพื่อให้สามารถอ่านเขียนได้เร็วที่สุด(load balance) อาจจะเรียกรูปแบบนี้ว่า fragmentation(?) ก็ได้ แต่มันไม่ได้เป็นข้อเสียครับ ไม่ได้เหมือน HDD fragmentation


Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)

By: McKay
ContributorAndroidWindowsIn Love
on 31 July 2013 - 20:53 #604349 Reply to:604192
McKay's picture

ผมบอกเองครับ

กรณีนี้ไม่เกี่ยวกับไฟล์เยอะไม่เยอะแล้วช้าครับ และไม่เกี่ยวข้องกับ read speed เลย แต่มันเกี่ยวกับการลบไฟล์ออกแล้วจะเขียนไฟล์ทับตรงจุดนั้น ที่จะต้อง erase พื้นที่ตรงที่จะเขียนก่อน(ทาง logical) แล้วถึงจะเขียนได้ครับ (overwritten cycle)

แต่ก็มีส่วนบ้างเนื่องจากการที่เนื้อที่ว่างยิ่งน้อย โอกาสที่จะเขียนทับตรงจุดที่ลบไปยิ่งมีโอกาสสูง แต่ไม่ได้มีผลกับ read speed แต่อย่างใด

การมี TRIM ช่วยให้เวลาลบ ระบบจะช่วย erase พื้นที่ตรงนั้นให้โดยอัตโนมัติ(ทาง logical) ทำให้ไม่ต้องมี erase เวลาเขียนใหม่ ทำให้ I/O , throughput ไม่ติดขัดเวลา write

ฉะนั้นขอยืนยันอีกรอบนะครับ ไฟล์เยอะๆไม่ได้ทำให้ระบบบน SSD ช้าเพราะส่วนมากเป็นการ read ไม่ใช่ write ที่มันช้าเพราะ CPU เอาเวลาไปคำนวนไฟล์ต่างๆเช่น thumbnail/render เยอะขึ้นมากกว่า


Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)

By: mk
FounderAndroid
on 31 July 2013 - 22:05 #604413 Reply to:604349
mk's picture

+1

By: wichate
Android
on 31 July 2013 - 22:06 #604414 Reply to:604349

โอ้ ข้อมูลเยอะขนาดนี้ผมเชื่อครับ แต่เห็นด้านบนบอกว่า "มือถือใช้แฟลชไม่ได้ใช้ฮาร์ดดิสก์ ไฟล์เยอะไม่ช้า"(ไม่เป็นความจริง) เขาก็พูดถูกนะครับ สรุแคือช้า แต่ช้าด้วยคนละสาเหตุกันเท่านั้นเอง

By: neonicus
Android
on 31 July 2013 - 23:27 #604464 Reply to:604349

ขอบคุณครับ เดี๋ยวต้องอ่านเพิ่มละ ข้องใจการ access อยู่สำหรับบางเงื่อนไข

By: McKay
ContributorAndroidWindowsIn Love
on 31 July 2013 - 23:34 #604468 Reply to:604464
McKay's picture

หลักๆมันเป็นเรื่องของข้อจำกัดของ flash storage ที่เขียนข้อมูลทับไม่ได้ และถ้าจะลบ(เพื่อที่จะเขียนใหม่)ต้องลบทั้ง block เลย(ซึ่งอาจจะมีข้อมูลจากหลายๆไฟล์รวมกันหรือไฟล์เดียวก็ได้) จึงมี GC,TRIM,GC+TRIM เข้ามาช่วยครับ


Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)

By: Onewings
Windows
on 1 August 2013 - 11:02 #604688 Reply to:604349
  • 1 ถ้าจำไม่ผิดหลักการ fetch data น่าจะใกล้เคียงกับ ram ซึ่งระยะเวลาในการหา( seek time )แม้จะเกิด fragmentation ก็ไม่แตกต่างจนมีนัยสำคัญแบบที่เกิดกับ Hard disk ซึ่งใช้จานหมุน
By: jirayu
ContributorWindows PhoneBlackberrySymbian
on 2 August 2013 - 02:10 #605193 Reply to:604349

โอเค ตอนนี้ผมพอจะเข้าใจมากขึ้นถึงสาเหตุของการช้าแล้วครับ

แต่คือกรณีที่ผมบอก อันนี้มันช้าไปจรถึงการถอนการติดตั้งแอพเลยครับ รวมถึงการสแกนไฟล์ (พวกแอพ Cleanup ต่างๆ) ก็ทำได้ช้าขึ้นอย่างเห็นได้ชัด ผมเข้าใจว่าไฟล์เล็กๆ จำนวนมาก มันก็ยังสแกนได้ช้าอยู่ เพราะมันต้องอ่านรายละเอียดเล็กๆ น้อยๆ ของไฟล์หลายครั้ง

แต่ที่ยังไม่เข้าใจคือทำไมการมีไฟล์จำนวนมากพวกนี้มันไปทำให้การถอนการติดตั้งแอพมันช้าลงด้วยครับ

บางทีอาจจะเป็นบั๊ก eMMC บางรุ่นแบบที่ข้างล่างบอกก็ได้ครับ เพราะที่สังเกตุมันก็ไม่ได้เป็นกันทุกเครื่อง


By: McKay
ContributorAndroidWindowsIn Love
on 2 August 2013 - 03:01 #605203 Reply to:605193
McKay's picture

การ scan ไฟล์นี่ไฟล์เยอะมันทำให้ช้าอยู่แล้วครับ เพราะต้อง scan ไฟล์ทุกไฟล์ ปริมาณข้อมูลที่มากขึ้นจึงต้องใช้เวลาที่มากขึ้นตามไปด้วย

เรื่องถอนการติดตั้งผมก็ไม่แน่ใจครับ เพราะปกติแล้วการลบไฟล์นั้น OS จะลบแค่ link ของตัวเอง ไม่ได้ไปสั่งให้ eMMC/SSD/harddisk ทำการลบจาก LBA ทำให้ขึ้นตอนเบื้องต้นจะไม่มีการทำงานของ eMMC(แต่จะไปหนักตรงการทำ GC ตอน idle/การเขียนทับแทน) ยกเว้นจะส่งคำสั่ง TRIM ไปด้วย แล้ว GC ทำงานทันที (คงไม่มั้ง)

แต่ถ้าอาการช้าหรือค้างหรือการกระตุกขณะอ่านไฟล์อย่างเดียวถ้าไม่เกี่ยวกับ CPU อาจมีสาเหตุมาจาก dead block/controller bug ครับ อาการที่ 2 สำหรับ SSD อาจจะ upgrade firmware ได้ แต่สำหรับ eMMC น่าจะทำอะไรไม่ได้ครับ


Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)

By: myungz
In Love
on 1 August 2013 - 08:06 #604590 Reply to:604192
myungz's picture

ถ้าถึงกับกระตุก มันเป็นบั๊กของ eMMC บางรุ่นครับ ผมโดนมากับตัว
ต้อง trim ตลอดถ้าcopy file ลงเครื่อง

ส่วนรุ่นอื่นๆช้าแบบไม่เห็นอาการมากนัก

trim ที่มากับ 4.3 นี้ผมมองว่าเป็นการแก้บั๊กข้างต้น
คนที่ไม่เป็นก็ได้อานิสงค์ไปด้วย

By: LazarusSP1
ContributoriPhone
on 31 July 2013 - 17:21 #604229

Android 4.3 เล่น Ingress ลื่นขึ้นจริงๆครับ

By: darkleonic
ContributorAndroidWindowsIn Love
on 31 July 2013 - 17:46 #604259 Reply to:604229
darkleonic's picture

+1


I need healing.

By: freeriod on 31 July 2013 - 17:28 #604242
freeriod's picture

ios มีเปล่า

By: McKay
ContributorAndroidWindowsIn Love
on 31 July 2013 - 21:35 #604392
McKay's picture

จริงๆเรื่อง TRIM นี่ Anandtech อธิบายผิดนะครับ


Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)

By: BlackMiracle
WriterAndroidUbuntuWindows
on 1 August 2013 - 00:13 #604489 Reply to:604392

ผิดยังไงอะครับ รบกวนอธิบาย


Pitawat's Blog :: บล็อกผมเองครับ

By: McKay
ContributorAndroidWindowsIn Love
on 1 August 2013 - 00:59 #604507 Reply to:604489
McKay's picture

หลักๆความช้ามันจะอยู่ที่การ allocation โดย GC และ overwritten cycle (read block ลง cache , erase block, modify block บน cahce โดยเอาข้อมูลชุดเก่าถ้ามี+ชุดใหม่,write block) ที่ทำให้เสียความเร็วไปเยอะโดยทำถึง 4 step แทนที่จะเป็น 1 step (write)ครับ และ TRIM จะมาช่วยเรื่องนี้(หรือทำให้แย่กว่าเดิมถ้าไปทำงานขัดกับ GC บางตัว เช่น GC ของ Sandforce controller บางตัว เนื่องจากตัว controller ใช้การบีบอัดข้อมูลเข้ามาเกี่ยวข้อง หรือบางทีตัว Controller ก็ควบคุมคำสัง TRIM ได้แย่เป็นต้น)

แต่ Anandtech ดันไปเน้นเรื่องความช้าจากการ mapping ของ controller ที่มากขึ้นซึ่งจริงๆแล้วไม่ได้มีผลสำคัญ(insignificant)แต่อย่างใดครับ


Russia is just nazi who accuse the others for being nazi.
someone once said : ผมก็ด่าของผมอยู่นะ :)