วัตถุประสงค์ของฉันคือการตั้งค่าเซิร์ฟเวอร์ขนาดเล็ก (ไม่ใช่ HTPC) ด้วยการใช้พลังงานต่ำในโหมดว่าง แต่ให้ประสิทธิภาพที่ดีเมื่อใช้ เน้นความปลอดภัยของข้อมูลมากกว่าความพร้อมใช้งาน ในคำอื่น ๆ : ชิ้นส่วนที่มีคุณภาพ แต่ความซ้ำซ้อนเท่านั้นสำหรับการจัดเก็บ

ไม่คิดว่าตัวเองจะลำเอียงหลังจากการวิจัยบางอย่างฉันรู้สึกว่า APU ของเดสก์ท็อป AMD บางตัวจะให้คุณค่าที่ดี

คำถามที่เหลืออยู่คือ:

• สถานะว่างของ GPU จะลดการใช้พลังงานและปล่อยทรัพยากรสำหรับ CPU หรือไม่
• Cool'n'Quiet และ Turbo Core จะนำไปสู่การใช้พลังงานต่ำในโหมดปกติ แต่มีประสิทธิภาพภายใต้การโหลดหรือไม่?
• Linux จะสนับสนุนสถานการณ์นี้ตามที่ตั้งใจไว้หรือไม่ คำถามสองสามข้อและการอภิปรายในฟอรัมดูเหมือนจะแนะนำว่าไม่จำเป็นต้องเป็นอย่างนั้น

[แก้ไข: สรุปความคิดเกี่ยวกับตัวเลือกโปรเซสเซอร์]

• AMD กับ AMD:
  • Richland ทำได้ดีกว่า Trinity มากที่นี่
  • Kaveri ไม่สามารถแข่งขันกับการกระจายพลังงานของโหมดไม่ได้ใช้งานของ Richland (อย่างน้อยก็ในตอนนี้)
  • GPU ของ A10-6700 อาจ overrated แต่มันค่อนข้างเศร้าที่จะไม่ใช้มาก อัลกอริทึมบางอย่างอาจสามารถปรับใช้พลังงานการคำนวณ ไม่มีความคิดว่าจะส่งผลต่อการใช้พลังงานของโปรเซสเซอร์อย่างไร
  • ฉันสงสัยว่า A10-6790K เป็นโปรเซสเซอร์เดียวกับ A10-6700 ที่มีเพียงชุดพารามิเตอร์ที่แตกต่างกันสำหรับ Turbo Core boosts หากเป็นจริง A10-6790K จะสามารถเพิ่มได้อีกต่อไปและ / หรือให้ความถี่ที่สูงขึ้นในระยะยาวเนื่องจาก TDP ที่สูงขึ้น แต่คุณต้องใช้ซีพียูพัดลมตัวอื่นสำหรับสิ่งนั้น (คิดว่าพื้นที่และอุณหภูมิ / ช่วงชีวิต)
• AMD A10-6700 กับ Intel Core i3-3220:
  • A10-6700 มีพลัง GPU มากขึ้นซึ่งไม่ได้ใช้ที่นี่
  • i3-3220 มีการกระจายพลังงานของโหมดไม่ได้ใช้งานต่ำ
  • ในขณะที่มาตรฐานทั่วไปนั้น i3-3220 นั้นเร็วกว่าสำหรับการคำนวณฉันไม่เห็นว่าแกนไฮเปอร์เธรดสองแกนของมันจะสามารถจัดการการร้องขอแบบขนานได้อย่างไร (พูดกับฐานข้อมูลที่มีส่วนหน้าเว็บ) อย่างรวดเร็วเท่ากับสี่แกนเด่นอย่างเต็มที่ เมื่อสมมติว่ามีการแคชที่รุนแรง) ไม่พบเกณฑ์มาตรฐานที่จริงจัง แต่มีเพียงข้อบ่งชี้บางอย่าง

[แก้ไข: bapmพารามิเตอร์ของไดรเวอร์ Radeon ฟรีถูกตั้งค่าเป็นค่าเริ่มต้นสำหรับ Kaveri, Kabini และเดสก์ท็อปทรินิตี้, ระบบ Richland ตั้งแต่ Linux 3.16]

ดู[ดึง] Radeon DRM

อย่างไรก็ตามเกี่ยวกับ Debian ที่ใช้ 3.16 ค่าเริ่มต้นจะไม่ (ยัง?) ดูเหมือนจะทำงานในขณะที่พารามิเตอร์การบูตทำ ดูวิธีการตั้งค่าระบบ Debian (เน้นที่ 2D หรือคอนโซล / เซิร์ฟเวอร์) ด้วย AMD Turbo Core APU เพื่อประสิทธิภาพการใช้พลังงานและการประมวลผลสูงสุด

[แก้ไข: ไดรเวอร์ Radeon ฟรีจะมีbapmพารามิเตอร์ในไม่ช้า]

เนื่องจากบรรทัดล่างของด้านล่างคือการใช้เวอร์ชันฟรีของ patch radeonขับกับ APU ของคุณเพื่อรองรับ Turbo Core และใช้ประโยชน์สูงสุดจากมัน (ยกเว้นกราฟิก 3 มิติที่เป็น) ถ้าคุณทำได้ (การเปิดใช้งานbapmอาจทำให้เกิดความไม่แน่นอนในการกำหนดค่าบางอย่าง ) มันเป็นข่าวที่ดีที่รุ่นอนาคตของ Radeon จะมีพารามิเตอร์เพื่อเปิดใช้งาน bapm

[โพสต์ต้นฉบับดังต่อไปนี้]

ประสบการณ์ APU ของ AMD A10-6700 (Richland)

ตัวเลือกโปรเซสเซอร์

พีซีเครื่องแรกของฉันคือชุด 486DX2-66 จากหลายสิบ 3.5 "ฟลอปปีดิสก์ที่ประกอบด้วยแพคเกจแหล่ง Slackware จากนั้นก็มีหลายสิ่งหลายอย่างเปลี่ยนไปและปัจจุบันอุตสาหกรรมจำนวนมากดูเหมือนจะอยู่ในช่วงที่พวกเขายังคงเพิ่มจำนวนขึ้น ของผลิตภัณฑ์ย่อย

สถานการณ์นี้และการตัดสินใจที่โชคร้ายของ AMD ในอดีตที่ผ่านมาไม่ได้ทำให้ฉันตัดสินใจได้ง่ายขึ้นสำหรับแพลตฟอร์มสำหรับเซิร์ฟเวอร์ขนาดเล็ก แต่ในที่สุดฉันตัดสินใจว่า A10-6700 จะเป็นตัวเลือกที่ดี:

• ความเห็นหลายประการแสดงให้เห็นว่า (ยังไม่สามารถใช้งานได้อย่างกว้างขวาง) Kaveri จะใช้พลังงานมากขึ้นในโหมดว่างมากกว่า Richland หรือ Trinity
• ข้อได้เปรียบของ Richland A10-6700 เหนือ Trinity A10-5700 ดูเหมือนจะมีความสำคัญ: ความถี่ต่ำสุดและสูงที่สุดที่ต่ำกว่า, Turbo Core ที่ละเอียดยิ่งขึ้น (พิจารณาจากอุณหภูมิ - ข้อดีสำหรับ GPU ที่ไม่ได้ใช้งาน)
• GPU ของ A10-6700 มีการกล่าวเกินจริง (การตั้งชื่อทางการตลาด) และราคาของ APU นั้นค่อนข้างยุติธรรม

ส่วนประกอบและการตั้งค่าอื่น ๆ

แม้จะมีโปรเซสเซอร์มากมายให้เลือก แต่ยังมีบอร์ด Mini-ITX ไม่มากนัก ASRock FM2A78M-ITX + ดูเหมือนจะเป็นตัวเลือกที่สมเหตุสมผล การทดสอบทำกับเฟิร์มแวร์ V1.30 (ไม่มีการอัปเดตในขณะที่ฉันเขียนนี้)

ควรใช้เอาต์พุตที่ระบุของแหล่งจ่ายไฟเพียง 80% เท่านั้น ในทางตรงกันข้ามหลายคนล้มเหลวในการทำงานอย่างมีประสิทธิภาพต่ำกว่า 50% โหลด มันยากมากที่จะหาแหล่งจ่ายไฟที่ประหยัดพลังงานสำหรับระบบที่มีช่วงการกระจายพลังงานประมาณ 35W ถึง 120W ฉันทำการทดสอบเหล่านี้กับ Seasonic G360 80+ Gold เพราะมีประสิทธิภาพเหนือกว่าคู่แข่งส่วนใหญ่เกี่ยวกับประสิทธิภาพในการโหลดต่ำ

DDR3-1866 RAM 8GB สองตัว (กำหนดค่าเช่นนี้ - ซึ่งสร้างความแตกต่างเมื่อเทียบกับ 1333), ไดรฟ์ SSD หนึ่งตัวและพัดลมซีพียูที่มีคุณภาพควบคุม PWM เป็นส่วนหนึ่งของการตั้งค่าการทดสอบ

การวัดทำโดยใช้ AVM Fritz! DECT 200 ซึ่งได้รับรายงานว่าทำการวัดได้อย่างแม่นยำ ยังคงมีการตรวจสอบความน่าเชื่อถือโดยใช้อุปกรณ์ไม่มีชื่อเก่า ไม่สามารถระบุความไม่สอดคล้องกันได้ การกระจายพลังงานของระบบที่วัดได้จะรวมถึงประสิทธิภาพที่ลดลงของแหล่งจ่ายไฟสำหรับโหลดที่ลดลง

หน้าจอ [W] QHD เชื่อมต่อผ่าน HDMI

หน่วยความจำที่แชร์เริ่มต้นสำหรับ GPU นั้นถูกตั้งค่าเป็น 32M ใน UEFI BIOS นอกจากนี้ยังได้เลือก Onboard GPU เป็นหลักและเปิดใช้งาน IOMMU

ไม่มีการติดตั้ง X หรือระบบกราฟิกอื่น ๆ เอาต์พุตวิดีโอถูก จำกัด ไว้ที่โหมดคอนโซล

ข้อมูลพื้นฐานเกี่ยวกับ

มีบางสิ่งที่เราต้องรู้

• ในขณะที่การตัดสินใจเกี่ยวกับ Cool'n'Quiet ทำโดยซอฟต์แวร์ภายนอกโปรเซสเซอร์ Turbo Core เป็นการตัดสินใจโดยอัตโนมัติด้วยไมโครคอนโทรลเลอร์เพิ่มเติมบน APU (หรือ CPU)
• เครื่องมือมากมายรวมถึง/procและ/sysสถานที่ไม่รายงานกิจกรรม Turbo Core cpufreq-aperf, cpupower frequency-infoและcpupower monitorทำ modprobe msrแต่หลังจากที่

กลุ่มเคสทดสอบ 1: Linux + radeon

ฉันเริ่มต้นด้วย Arch Linux ใหม่ (ตัวติดตั้ง 2014.08.01, เคอร์เนล 3.15.7) ปัจจัยที่สำคัญที่นี่คือการปรากฏตัวของacpi_cpufreq(ปรับเคอร์เนล CPU) และradeon(คนขับ GPU เคอร์เนล) radeonและวิธีที่ง่ายในแพทช์

กรณีทดสอบ 1.1: BIOS TC บน - CnQ บน / Linux OnDemand - Boost

การตั้งค่า UEFI BIOS Turbo Core เปิดใช้งาน ............................
UEFI BIOS Cool'n'Quiet การตั้งค่าเปิดใช้งาน ..........................
/ sys / อุปกรณ์ / ระบบ / cpu / cpufreq / boost ................... 1
/ sys / อุปกรณ์ / ระบบ / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower frequency-info" pstates ........ 4300 4200 3900 3700 3400 2700 2700 2300 1800
พบช่วง cHz MHz "/ proc / cpuinfo" ... 1800 - 3700
สังเกตช่วงความถี่ของ "cpupower monitor" ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... ระดับพลังงาน 0

โหลด | Core Freqs
--------------- + -----------
ความเครียด - ซีพียู 1 | 1 x 3700
ความเครียด --cpu 2 | 2 x 3700
ความเครียด --cpu 3 | 3 x 3700
ความเครียด --cpu 4 | 4 x 3700

กรณีทดสอบ 1.2: BIOS TC บน - CnQ บน / ประสิทธิภาพ Linux - เพิ่ม

การตั้งค่า UEFI BIOS Turbo Core เปิดใช้งาน ............................
UEFI BIOS Cool'n'Quiet การตั้งค่าเปิดใช้งาน ..........................
/ sys / อุปกรณ์ / ระบบ / cpu / cpufreq / boost ................... 1
/ sys / อุปกรณ์ / ระบบ / cpu / cpu * / cpufreq / scaling_governor ... ประสิทธิภาพ 

"cpupower frequency-info" pstates ........ 4300 4200 3900 3700 3400 2700 2700 2300 1800
พบช่วง cHz MHz "/ proc / cpuinfo" ... 3700
สังเกตช่วงความถี่ของ "cpupower มอนิเตอร์" ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... ระดับพลังงาน 0

โหลด | Core Freqs
--------------- + -----------
ความเครียด - ซีพียู 1 | 1 x 3700
ความเครียด --cpu 2 | 2 x 3700
ความเครียด --cpu 3 | 3 x 3700
ความเครียด --cpu 4 | 4 x 3700

สรุปกลุ่มทดสอบ 1

เทอร์โบแกนช่วยเพิ่มตามเป็นไปไม่ได้ในสถานการณ์นี้เพราะขับรถในขณะนี้ปิดการใช้งานธงเนื่องจากปัญหาความมั่นคงในบางสถานการณ์ ดังนั้นการทดสอบเพิ่มเติมถูกข้ามไปradeonbapm

กลุ่มเคสทดสอบ 2: Linux + bapm-radeon

เพื่อที่จะช่วยให้bapmผมเริ่มต้นด้วยการสด Arch Linux (ติดตั้ง 2014/08/01 เคอร์เนล 3.15.7) ได้ฉันcore linuxแพคเกจผ่านABS(3.15.8) แก้ไขPKGBUILDเพื่อใช้pkgbase=linux-tcดึงแหล่งที่มีmakepkg --nobuildการเปลี่ยนแปลงpi->enable_bapm = true;ในtrinity_dpm_init()ในsrc/linux-3.15/drivers/gpu/drm/radeon/trinity_dpm.cและ makepkg --noextractรวบรวมมันด้วย จากนั้นฉันติดตั้ง ( pacman -U linux-tc-headers-3.15.8-1-x86_64.pkg.tar.xzและpacman -U linux-tc-3.15.8-1-x86_64.pkg.tar.xz) และอัปเดตGRUB( grub-mkconfig -o /boot/grub/grub.cfgแต่แน่นอนว่า YMMV)

เป็นผลให้ฉันได้รับเลือกในการบูตlinuxหรือlinux-tcการทดสอบต่อไปนี้อ้างถึงหลัง

กรณีทดสอบ 2.1: BIOS TC บน - CnQ บน / Linux OnDemand - Boost

การตั้งค่า UEFI BIOS Turbo Core เปิดใช้งาน ............................
UEFI BIOS Cool'n'Quiet การตั้งค่าเปิดใช้งาน ..........................
/ sys / อุปกรณ์ / ระบบ / cpu / cpufreq / boost ................... 1
/ sys / อุปกรณ์ / ระบบ / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower frequency-info" pstates ........ 4300 4200 3900 3700 3400 2700 2700 2300 1800
พบช่วง cHz MHz "/ proc / cpuinfo" ... 1800 - 3700
สังเกตช่วงความถี่ของ "cpupower monitor" ... 1800 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... ระดับพลังงาน 0

โหลด | Core Freqs
--------------- + -----------------
ความเครียด - ซีพียู 1 | 1 x 4300
ความเครียด --cpu 2 | 2 x 4200 .. 4100
ความเครียด --cpu 3 | 3 x 4100 .. 3900
ความเครียด --cpu 4 | 4 x 4000 .. 3800

กรณีทดสอบ 2.2: BIOS TC บน - CnQ บน / ประสิทธิภาพ Linux - เพิ่ม

การตั้งค่า UEFI BIOS Turbo Core เปิดใช้งาน ............................
UEFI BIOS Cool'n'Quiet การตั้งค่าเปิดใช้งาน ..........................
/ sys / อุปกรณ์ / ระบบ / cpu / cpufreq / boost ................... 1
/ sys / อุปกรณ์ / ระบบ / cpu / cpu * / cpufreq / scaling_governor ... performace

"cpupower frequency-info" pstates ........ 4300 4200 3900 3700 3400 2700 2700 2300 1800
พบช่วง cHz MHz "/ proc / cpuinfo" ... 3700
สังเกตช่วงความถี่ของ "cpupower มอนิเตอร์" ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... ระดับพลังงาน 0

โหลด | Core Freqs
--------------- + -----------------
ความเครียด - ซีพียู 1 | 1 x 4300
ความเครียด --cpu 2 | 2 x 4200 .. 4100
ความเครียด --cpu 3 | 3 x 4100 .. 3900
ความเครียด --cpu 4 | 4 x 4000 .. 3800

กรณีทดสอบ 2.3: BIOS TC บน - CnQ บน / Linux OnDemand - ไม่มีการเร่งความเร็ว

การตั้งค่า UEFI BIOS Turbo Core เปิดใช้งาน ............................
UEFI BIOS Cool'n'Quiet การตั้งค่าเปิดใช้งาน ..........................
/ sys / อุปกรณ์ / ระบบ / cpu / cpufreq / boost ................... 0
/ sys / อุปกรณ์ / ระบบ / cpu / cpu * / cpufreq / scaling_governor ... ondemand

"cpupower frequency-info" pstates ........ 4300 4200 3900 3700 3400 2700 2700 2300 1800
พบช่วง cHz MHz "/ proc / cpuinfo" ... 1800 - 3700
สังเกตช่วงความถี่ของ "cpupower monitor" ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... ระดับพลังงาน 1

โหลด | Core Freqs
--------------- + -----------
ความเครียด - ซีพียู 1 | 1 x 3700
ความเครียด --cpu 2 | 2 x 3700
ความเครียด --cpu 3 | 3 x 3700
ความเครียด --cpu 4 | 4 x 3700

กรณีทดสอบ 2.4: BIOS TC บน - CnQ บน / ประสิทธิภาพ Linux - ไม่เพิ่ม

การตั้งค่า UEFI BIOS Turbo Core เปิดใช้งาน ............................
UEFI BIOS Cool'n'Quiet การตั้งค่าเปิดใช้งาน ..........................
/ sys / อุปกรณ์ / ระบบ / cpu / cpufreq / boost ................... 0
/ sys / อุปกรณ์ / ระบบ / cpu / cpu * / cpufreq / scaling_governor ... performace

"cpupower frequency-info" pstates ........ 4300 4200 3900 3700 3400 2700 2700 2300 1800
พบช่วง cHz MHz "/ proc / cpuinfo" ... 3700
สังเกตช่วงความถี่ของ "cpupower มอนิเตอร์" ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... ระดับพลังงาน 1

โหลด | Core Freqs
--------------- + -----------
ความเครียด - ซีพียู 1 | 1 x 3700
ความเครียด --cpu 2 | 2 x 3700
ความเครียด --cpu 3 | 3 x 3700
ความเครียด --cpu 4 | 4 x 3700

กรณีทดสอบ 2.5: ปิดใช้งาน BIOS TC - CnQ บน / Linux OnDemand - Boost

การตั้งค่า UEFI BIOS Turbo Core ............................ ปิดการใช้งาน
UEFI BIOS Cool'n'Quiet การตั้งค่าเปิดใช้งาน ..........................
/ sys / อุปกรณ์ / ระบบ / cpu / cpufreq / boost ................... 1
/ sys / อุปกรณ์ / ระบบ / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower frequency-info" pstates ........ 4300 4200 3900 3700 3400 2700 2700 2300 1800
พบช่วง cHz MHz "/ proc / cpuinfo" ... 1800 - 3700
สังเกตช่วงความถี่ของ "cpupower monitor" ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... ระดับพลังงาน 0

กล่าวอีกนัยหนึ่งหากปิดใช้งาน Turbo Core ใน BIOS แพทช์ที่ติดตั้งradeonจะไม่เปิด

กรณีทดสอบ 2.6: เปิดใช้งาน BIOS TC - ปิด CnQ / Linux n / a

การตั้งค่า UEFI BIOS Turbo Core เปิดใช้งาน ............................
UEFI BIOS Cool'n'Quiet การตั้งค่า .......................... ปิดใช้งาน
/ sys / อุปกรณ์ / ระบบ / cpu / cpufreq / boost ................... n / a
/ sys / อุปกรณ์ / ระบบ / cpu / cpu * / cpufreq / scaling_governor ... n / a

"cpupower frequency-info" pstates ........ 4300 4200 3900 3700 3400 2700 2700 2300 1800
พบช่วง cHz MHz "/ proc / cpuinfo" ... 3700
สังเกตช่วงความถี่ของ "cpupower มอนิเตอร์" ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... ระดับพลังงาน 0

โหลด | Core Freqs
--------------- + -----------------
ความเครียด - ซีพียู 1 | 1 x 4300
ความเครียด --cpu 2 | 2 x 4100 .. 4000
ความเครียด --cpu 3 | 3 x 4000 .. 3800
ความเครียด --cpu 4 | 4 x 3900 .. 3700

ด้วยการปิดใช้งาน Cool'n'Qiet เคอร์เนล Linux จะไม่เสนอตัวเลือกใด ๆ ของผู้ว่าการรัฐและ (ผิด) ให้สันนิษฐานว่าแกนประมวลผลทำงานที่ความถี่คงที่ สิ่งที่น่าสนใจความถี่เทอร์โบคอร์ที่ได้นั้นเป็นสิ่งที่แย่ที่สุดของชุดค่าผสมที่ผ่านการทดสอบทั้งหมดในกลุ่มเคส 2

สรุปกลุ่มทดสอบ 2

ด้วยradeonไดรเวอร์ที่ได้รับการติดตั้งแล้ว Turbo Core จะทำงาน ไม่มีความเสถียร (ซึ่งเป็นสาเหตุที่bapmปิดการทำงานของ Turbo Core ที่นั่น)

กลุ่มเคสทดสอบ 3: Linux + fglrx (ตัวเร่งปฏิกิริยา)

ฉันเริ่มต้นด้วยการติดตั้ง Ubuntu ใหม่ (14.04 เซิร์ฟเวอร์เคอร์เนล 3.13) ซึ่งฉันเห็นว่าเทียบเท่ากับ Arch Linux (ตัวติดตั้ง 2014.08.01, เคอร์เนล 3.15.7) เนื่องจากการปรากฏตัวของacpi_cpufreq(เคอร์เนลซีพียู CPU) และradeon(ไดรเวอร์ GPU เคอร์เนล) ) fglrxเหตุผลในการเปลี่ยนไปใช้อูบุนตูคือการติดตั้งได้ง่าย ฉันตรวจสอบการใช้พลังงานและการทำงานกับการติดตั้งใหม่ซึ่งใช้radeonผมตรวจสอบการใช้พลังงานและพฤติกรรมที่มีติดตั้งใหม่ซึ่งใช้

ฉันติดตั้งfglrxจากบรรทัดคำสั่ง ( sudo apt-get install linux-headers-generic, sudo apt-get install fglrx) และรีบูตระบบ การเปลี่ยนแปลงจากradeonการfglrxเป็นที่ชัดเจนทันทีทั้งคอนโซลลักษณะเกี่ยวกับ ( fglrx128 x 48 radeon: สูงมาก) และการใช้พลังงานในโหมดว่างงาน ( fglrx: 40W, radeon: 30W) แต่ Turbo Core ทำงานได้ทันที

กรณีทดสอบ 3.1: BIOS TC บน - CnQ บน / Linux OnDemand - Boost

การตั้งค่า UEFI BIOS Turbo Core เปิดใช้งาน ............................
UEFI BIOS Cool'n'Quiet การตั้งค่าเปิดใช้งาน ..........................
/ sys / อุปกรณ์ / ระบบ / cpu / cpufreq / boost ................... 1
/ sys / อุปกรณ์ / ระบบ / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower frequency-info" pstates ........ 4300 4200 3900 3700 3400 2700 2700 2300 1800
พบช่วง cHz MHz "/ proc / cpuinfo" ... 1800 - 3700
สังเกตช่วงความถี่ของ "cpupower monitor" ... 1800 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... n / a

โหลด | Core Freqs
--------------- + ----------------------------
ความเครียด - ซีพียู 1 | 1 x 4300
ความเครียด --cpu 2 | 2 x 4200 .. 3900 (core chg)
ความเครียด --cpu 3 | 3 x 4100 .. 3700
ความเครียด --cpu 4 | 4 x 4000 .. 3600

fglrxพฤติกรรมเป็นที่น่าสนใจแน่นอน เมื่อ 'stress --cpu 2' ถูกเรียกใช้สำหรับเคส tes ใด ๆ ในกลุ่มเคสทดสอบใด ๆ คอร์ที่โหลดสองคอร์จะอยู่ในโมดูลแยกต่างหากเสมอ แต่ด้วยfglrxการจัดสรรใหม่อย่างฉับพลันเกิดขึ้นเช่นเดียวกับที่ใช้โมดูลเดียว (ซึ่งช่วยประหยัดพลังงานได้บ้างดูด้านล่าง) หลังจากเวลาผ่านไปแกนที่โหลดจะย้ายกลับไปที่โมดูลอื่น radeonนี้ไม่ได้เห็นด้วย เป็นไปได้ไหมที่จะfglrxจัดการความสัมพันธ์หลักของกระบวนการ

สรุปกลุ่มทดสอบ 3

ข้อดีของfglrxมันคือสามารถเปิดใช้งาน Turbo Core ได้ทันทีโดยไม่จำเป็นต้องทำการแก้ไข

เนื่องจากfglrxสูญเสีย 10 ถึง 12W สำหรับ GPU ในสถานการณ์ของเราบนชิปที่มี 65W TDP ผลลัพธ์โดยรวมเกี่ยวกับความเร็วแกนที่มีอยู่นั้นไม่น่าประทับใจ ดังนั้นจึงไม่มีการทดสอบเพิ่มเติม

นอกจากนี้จากมุมมองทางวิศวกรรมพฤติกรรมของคนfglrxดูเหมือนจะเศร้าเล็กน้อย จัดสรรใหม่หนึ่งในสองคอร์ไม่ว่างไปยังโมดูลอื่นเพื่อรักษาความถี่ที่สูงขึ้นอาจหรือไม่เป็นความคิดที่ดีเพราะก่อนหน้าขั้นตอนนั้นทั้งสองคอร์มีแคช L2 ของตัวเองในขณะนั้นหลังจากนั้นพวกเขาจะต้องแชร์ ไม่ว่าfglrxจะพิจารณาตัวชี้วัดใด ๆ (เช่นแคชตี) เพื่อสนับสนุนการตัดสินใจของตนจะต้องมีการชี้แจงแยกกัน แต่มีรายงานอื่น ๆ ที่เกี่ยวกับพฤติกรรมของตนอย่างกระทันหัน

สรุปการใช้พลังงาน

บางส่วนของค่าเดลต้าในตารางต่อไปนี้แย่ลงเล็กน้อยเมื่ออุณหภูมิสูงขึ้น บางคนอาจบอกว่าแฟน ๆ ที่ควบคุม PWM และชิปทั้งคู่มีบทบาทอยู่ที่นั่น

ระบบ @ สถานะ / -> การเปลี่ยนแปลง Delta | การกระจายพลังงานของระบบ
------------------------------------- + ------------ -------------
  @BIOS | @ 95 .. 86W
  @Bootloader | @ 108 .. 89W
  @Ubuntu Installer Idle | @ 40W
  @Linux radeon Idle ondemand | @ 30W
  @Linux radeon ประสิทธิภาพว่าง @ 30W
  @Linux fglrx ไม่ได้ใช้งาน ondemand | @ 40W
  1 โมดูล 1800 -> 3700 | + 13W
  1 โมดูล 1800 -> 4300 | + 25W
  1 Core 1800 -> 3700 | + 5W
  1 Core 1800 -> 4300 | + 10W
  "radeon" วิดีโอออก -> ปิดการใช้งาน | - 2W
  'fglrx "Video Out -> Darken | + - 0W
  @Linux radeon สูงสุด | @ 103 .. 89W
  @Linux fglrx สูงสุด | @ 105 .. 92W

• ดูเหมือนจะมีมากขึ้นสำหรับ Turbo Core (อย่างน้อยกับ Richland APU) กว่าที่คาดไว้: ไม่มีความแตกต่างที่เห็นได้ชัดในการกระจายพลังงานเมื่อผู้ว่าราชการจังหวัด "ondemand" ปรับเมื่อเปรียบเทียบกับเมื่อผู้ว่าราชการ "ประสิทธิภาพ" อัลมั ธ/proc/cpuinfoจะรายงาน 37000MHz ทุกครั้งภายใต้การควบคุมประสิทธิภาพcpupower monitorจะเปิดเผยว่าแกนประมวลผลช้าลงจริง ๆ ในบางกรณีมีการแสดงความถี่ต่ำถึง 2000MHz เป็นไปได้ว่า 1800MHz จะใช้ภายในเช่นกัน
• A10-6700 ประกอบด้วยสองโมดูลที่มีสองคอร์แต่ละอัน หากเช่นสองคอร์ไม่ได้ใช้งานและสองคอร์ไม่ว่างและรับการเร่งความเร็วการทำงานของระบบจะแตกต่างกันไปขึ้นอยู่กับว่าคอร์ไม่ว่างอยู่ในโมดูลเดียวกันหรือไม่
  • การเร่งโมดูลนั้นใช้พลังงานมากขึ้นกว่าการเร่งคอร์
  • แคช L2 ได้รับมอบหมายต่อโมดูล
• ความแตกต่างระหว่างการกระจายอำนาจของสองแกนเร่งในโมดูลเดียวกันเทียบกับโมดูลที่แตกต่างกันถูกกำหนดโดยการแทนที่stress --cpu 2(ซึ่งมักจะนำไปสู่การกระจายในหมู่สองโมดูล) โดยtaskset -c 0 stress --cpu 1andtaskset -c 1 stress --cpu 1
• ดูเหมือนว่า A10-6700 จะมีขีด จำกัด การกระจายพลังงานโดยรวมสำหรับ APU (92W พร้อมกับส่วนประกอบอื่น ๆ ) โดยมีบิตเล็กน้อยสงวนไว้สำหรับ GPU เพียงอย่างเดียว (3 W) ด้วยradeonมันจะช่วยให้มากขึ้นในช่วงเวลาสั้น ๆ และลดลงไปสูงสุดอย่างราบรื่นในขณะที่fglrxมีการตั้งข้อสังเกตว่าเกินขีด จำกัด เหล่านี้อย่างมีนัยสำคัญมากขึ้นและการกระจายพลังงานจะลดลงทันที
• ในขณะที่หลายคนอ้างว่าความล่าช้าในการให้บริการของ Kaveri นั้นมีจุดประสงค์โดย AMD เพราะมันจะฆ่า APU ปัจจุบันของพวกเขา แต่ฉันขอแตกต่างกันไป Richland A10 ได้แสดงให้เห็นถึงการจัดการพลังงานที่ยอดเยี่ยมและ Kaveri ไม่สามารถแข่งขันกับการใช้พลังงานของรัฐที่ไม่ได้ใช้งานต่ำ (ความซับซ้อนของชิปของ Kaveri นั้นเกือบสองเท่าของ Richland ดังนั้นมันจะใช้เวลาอีกหนึ่งหรือสองขั้นตอนในการพัฒนา)

สรุปโดยรวม

• การรวมอุณหภูมิในตรรกะเทอร์โบคอร์ (ตามที่รายงานสำหรับทรินิตี้ -> ริชแลนด์สเต็ป) ดูเหมือนสมเหตุสมผลและดูเหมือนจะทำงานได้ดีดังที่เห็นได้จากการลดลงของ pwoer ใน BIOS และ Bootloader เมื่อเวลาผ่านไป
• สำหรับสถานการณ์ cosole / server A10-6700 รองรับ 4 คอร์ที่ 3700MHz (3800MHz พร้อมกับคอร์คอร์) ในระยะยาวอย่างน้อยก็พร้อมกับradeonไดรเวอร์ อาจไม่มีโอกาสมากที่จะรักษาระดับประสิทธิภาพการทำงานนี้เมื่อ GPU ได้รับงานที่ต้องทำ
• ดูเหมือนว่า 65W TDP สามารถเกินอย่างถาวรเล็กน้อยภายใต้การโหลดเต็มรูปแบบ แต่มันยากที่จะบอกว่าแหล่งจ่ายไฟมีประสิทธิภาพที่ต่ำกว่าที่ 30W เนื่องจากมีข้อบ่งชี้ที่ชัดเจนว่ามีการพิจารณาอุณหภูมิ (การกระจายพลังงานสูงสุดของเกือบ 110W ถูกสังเกตก่อนที่จะเริ่มลดลงถึง 90W และยังมี 2 คอร์ที่ 4300 MHz ได้รับการรายงานในบางครั้ง) การลงทุนในการทำความเย็น APU อาจ ความคิดที่ดี. อย่างไรก็ตามเมนเฟรมที่ จำกัด ที่ 65W TDP จะสามารถจ่ายกระแสไฟได้มากเท่านั้นดังนั้น APU จึงมีข้อ จำกัด ที่แน่นอน
• หากคุณตั้งใจจะใช้ Richland APU สำหรับการประมวลผลภายใต้ Linux คุณต้องใช้radeonไดรเวอร์ที่ได้รับการติดตั้งแล้ว(หากคุณไม่พบกับความไม่เสถียร - โดยเฉพาะเมื่อใช้ร่วมกับการเปิดใช้งานการจัดการพลังงานแบบไดนามิก) มิฉะนั้นคุณจะไม่ได้รับความคุ้มค่าเต็มที่
• ดูเหมือนว่าการตั้งค่าที่ดีที่สุดคือการเปิดใช้งานทั้ง Turbo Core และ Cool'n'Quiet ใน BIOS แต่จากนั้นเลือกperformanceผู้ว่าการปรับสเกล - อย่างน้อยถ้า APU ของคุณทำงานเหมือนที่ทดสอบในที่นี้ คุณจะมีการใช้พลังงานเช่นเดียวกับการondemandปรับขนาดความถี่ที่เร็วขึ้นและโอเวอร์เฮดของเคอร์เนลน้อยลงเพื่อทำการตัดสินใจการปรับสเกล

กิตติกรรมประกาศ

ขอขอบคุณเป็นพิเศษไปที่อเล็กซ์ Deucher ที่มีนัยสำคัญผลักดันให้ฉันเข้าไปในทิศทางที่ถูกต้องมากกว่าที่ bugzilla.kernel.org

ฉันประทับใจในคุณภาพของradeonไดรเวอร์ฟรีและขอขอบคุณทีมงานทั้งหมดในการบำรุงรักษาซอฟต์แวร์ชิ้นนี้ซึ่งดูเหมือนว่าจะได้รับการออกแบบอย่างรอบคอบ หากradeonไม่ปฏิบัติตามนั้นการตัดสินใจของฉันต่อ A10-6700 น่าจะผิดอย่างมาก