本文延續前篇效能校正的經驗談，上篇文章探討了關於系統呼叫, iptables 可以最佳化的部分，。本篇文章將繼續剩下最佳化步驟的探討。

Perfect Locality
預設情況下， Linux Kernel 會盡量平均地將請求給分配到所有的處理佇列，譬如 network queues, processes, CPUS. 大部分情況下這種機制運作良好不會有太多問題，不過如果今天要追求的不單單只是好的效能，而是極致的效能，則 locality 這個概念就要特別的去注意。

這篇文章中提到很多不同的方式，包含了 CPU Pinning, Receive Side Scaling(RSS), Transmit Packet Sterring(XPS)等，其實用比較簡單的介紹方式就是，希望可以使用固定的 CPU 來處理一條連線上的所有封包(進出)，這樣帶來的好處有
1. CPU Cache 可以盡可能的去使用，減少各種 miss 產生的成本
2. 減少 context switch 帶來的成本
3. 減少跨 CPU 之間交換資料帶來的成本
4. 減少 lock 之間帶來的成本
除了 CPU Pin, RSS, XPS 外，還有 irqbalance, smp_affinity_list 等相關的概念需要一併學習，對於這個概念有興趣的讀者非常歡迎去找尋這類型的資料

接者是 SO_REUSEPORT 這個參數，創建 Socket 時使用這個參數能夠使得多個 Process 共用一個連接埠，底層 Kernel 會針對 src/dst{ip/port} 來產生對應的 Hash，並且決定當前封包要送給哪一個 Process。
這個方式搭配前述各種 CPU Pin, 中斷的最佳化則會遇到問題，因為可能底層將該封包送到 CPU2 結果這個函式又把封包重新分配到 CPU0, 這樣就導致該連線要跨 CPU 處理了。
為了解決這個問題， Linux Kernel 4.6 後有新的參數 SO_ATTACH_REUSEPORT_CBPF，使用者可以自行撰寫 BPF 的程式來決定如何分配封包。作者根據這過想法撰寫了一個 BPF 的程式，來確保這個機制可以與前述的最佳化穩定運作。

這次的最佳化帶來的 38% 的成長，這時候的封包處理能力從 603k req/s 提升到 834k req/s
原文中關於這次的最佳化還有一些後續探討，有興趣的可以閱讀

Interrupt Optimizations

當封包透過網路送到網卡後，網卡必須要通知 OS 讓它知道有封包來了，要記得處理。一切處理完畢後網卡就可以繼續等待新的封包過來並且再次發送中斷給 OS 處理封包。這個流程大部分情況也是運作良好，不過當有大量的封包不停傳送來時，頻繁的中斷其實也是會造成不小的額外成本。

為了解決這個問題，目前比較嶄新的網卡都有支援中斷聚合等功能，透過這個功能可以延後中斷一個小週期，而該週期內收到的所有封包只需要透過一次的中斷就可以來處理，藉此降低中斷的次數。更為進階的網卡甚至支援動態自行調整該週期的時間，譬如當網路空閒時，減少週期使得每個封包能夠盡快的發送中斷被處理，而當網路流量很大時則會加大該該週期時間來更有效地處理封包。

註: AWS ENA 有支持這種動態調整的機制

作者基於 AWS 開啟動態調整收端中斷時間的功能，整個效能提升了 14%，從 834k req/s 提升到 955k req/s。作者說這次的調整可以說是整篇文章中幾個非常強的改動，改動的地方少，效能提升明顯，同時背後的隱憂與限制也少。

除了上述中斷的方式外，另外一種則是透過 Busy Polling 這種針對低延遲性的方式。預設情況下其允訓設定為 blocked 的 socket 能夠消耗額外的 CPU Cycle 來讀取接下來的封包，可以將其想成一成一種混合體，當底層網卡告訴我有資料要讀取時，我預期接下來還會有更多的資料，因此我就透過輪詢的方式去多問幾個封包。

由於作者的應用程式是使用 non-blocking 的方式去讀寫封包，所以預設的方式是沒有辦法使用的。而該應用程式又是使用 epoll 來進行底層封包的讀寫。 epoll 於 kenel 4.12 後正式支援 busy polling 的方式，所以這部分就沒有太大的問題。文章中有滿多關於 busy_poll 的一些參數調整。

將這兩個機制給整合後，整體的效能提升達到 28%，從 834k req/s 到達 1060k req/s，同時 99%的 latency 也從 361μs 下降到 292μs.

同時這兩個機制導入後，整個系統每秒產生的硬體中斷數量也從 183k 降到 16k。 Context switches 的數字也從 6k 下降到 1k 左右。

下篇文章會繼續從剩下的三個最佳化策略繼續介紹

https://talawah.io/blog/extreme-http-performance-tuning-one-point-two-million/

自駕/聯網/電動/共享崛起　汽車架構馳向四大未來趨勢

2020-07-06Chet Babla

汽車可說是繼手機之後，下一波科技產業的藍海市場。其中，汽車自駕、聯網、電動化與共享將改變消費者與車輛互動的方式，成為移動新典範，為新型態公司及新商業/營收模式，將帶來極大的可能性。

5G毫無疑問將是影響未來汽車能否更聰明、更安全的主要驅動引擎之一。它將大幅提升汽車的聯網性，也讓汽車製造商得以持續探索如何為車內乘客創造更好的車用資訊娛樂體驗，包括多媒體影音串流，以及更靈敏、更即時的導航服務。5G也強化了車輛對車輛(V2V)以及車輛到基礎設施(V2I)的數據傳輸，催生了足以保障生命的功能，例如可警示駕駛前方有潛在危險狀況的詳盡儀表板。

除了5G帶來的影響，同時本文還看到其他幾個趨勢也將形塑未來的汽車產業與汽車的移動性的架構，以及它們將如何呼應聯合國的2030全球目標。

ACES這是汽車研究中心針對未來移動性所提出之四大關鍵科技趨勢的縮寫：自駕性(Autonomous)、聯網(Connected)、電動化(Electric)與共享(Shared)的車輛。該中心表示，ACES「對於改變消費者與車輛互動方式的移動性新典範、新型態公司以及新商業與營收模式，將帶來極大的可能性。」。

未來移動性比科技更重要

ACES不但與影響汽車業的科技變革有關，它還幫助人們檢視汽車業與其內部發生的劇烈創新，如何在解決全球性挑戰中發揮一定的影響力。

社會與各產業的每個角落，在都市化、數位化、永續與社會包容等領域，都面臨重大挑戰。聯合國(UN)預測到2050年，全球都會人口將增加至25億，並把現有的基礎建設推至最大極限。

對於促成移動性的革命，Arm科技相當關鍵，而今日絕大部分的智慧型手機都由Arm的技術驅動。其實我們的科技從1990年代已開始部署在汽車產業，而我們現在也應用這些經驗、創造力與顛覆性創新，重塑汽車的移動性。

本文想要用ACES當框架，分析這個現象將如何發生：

・自駕

全球目標3(Global Goal 3)中的標的3.6(Target 3.6)，決心要讓「因為道路交通事故造成的全球傷亡人數減半」。美國監管機構估計，每年因道路交通事故喪生的130萬人之中，有九成肇因於人為的錯誤。先進駕駛輔助系統(ADAS)如盲點偵測、自動緊急煞車、車道維持輔助與主動式巡航，已經協助讓道路變得更安全，同時也拯救了生命。

Arm的IP已被廣泛運用在超過六成之ADAS系統的半導體中，而Arm在功能安全(Functional Safety, ISO26262)上的努力，也就是即便故障發生，車輛仍然能夠安全運行，讓汽車製造商確保他們的ADAS與自駕系統，可為駕駛、乘客與其它用路人帶來最高的安全性。

在歐洲新車評估計畫(Euro NCAP)的安全基準中，ADAS系統的價值也越來越重要，這意謂著新車若想得到五顆星安全評等，可能很快就被要求必須展現最基本程度的ADAS功能。

・聯網

汽車的聯網讓來自越來越多各種終端裝置感測器的數據資訊，可以在終端裝置或雲端上處理，以提升乘客安全性與車輛可靠性，並促成預測性維修、改善車隊效率，並讓其它用路人與智慧城市規畫者得知人們的旅程紀錄。隨著車輛自駕功能的提升，產生的數據資訊也會跟著增加。有些預測表示，現代車輛每小時大約產生25GB的數據，而自駕車輛產生的數據將是一百倍以上。

這不只是很多數據，而是數據的海嘯！它不但會把全球網路推向緊繃極限，也會讓全球的雲端資料中心必須比以往更加賣力地運作，同時讓它們的能源支出與碳排放迅速飆升。

未來的移動性若要倚靠數據生成與聯網運作並從中獲益，人們需要減少依賴於需要大量數據上雲處理的解決方案，以便達成全球目標7(Global Goal 7)的第3個標的(Third Target)：2030年前加倍全球能源效率的進步速度。

不管是在車輛裡(終端感測器與核心運算節點)，或是在路邊的邊緣閘道器，乃至雲端中，機器學習(ML)將擴散至整個運算領域，如何應對這個挑戰極為重要。它以智慧的方式降低數據量演算法部署，讓聯網特性成為未來車輛的主要支柱。

・電動化 車輛的動力從今日基於化石燃料的內燃機引擎(ICE)，已逐漸地轉往電動化發展，隨著時間向前推進，因車輛移動產生的碳排放對環境造成的衝擊，將顯著降低。這已將正在生產、或未來更多的車輛生產，以及大幅增加的電池生產等衝擊考量進去。最近Tesla市值大幅增加，讓它變成全球市值第二高的汽車原始設備製造商(OEM)，部份也反映出投資人認同汽車動力電動化在全球未來發展上所代表的價值。

在把全球暖化限制在攝氏1.5度內的計畫裡，電動車(EV)著力甚深，而這也符合2016年巴黎協定所訂定的目標。因此，電動車在達成全球目標13的氣候行動(Global Goal 13: Climate Action)，以及之前所提全球目標7(Global Goal 7)的能源效率上，可能扮演吃重的角色。

・共享服務

探討未來的移動性趨勢時常被遺忘、但可能也是最有趣的部份，即為介於公共運輸與個人運輸之間的種種。從叫車App到車輛所有權共享方案，消費者慢慢地開始走出傳統購車方式，轉而擁抱公共運輸行動服務(MaaS)帶來的好處。

從2013年開始，研究顯示叫車服務的車資每年約略成長130%。這種成長幅度很驚人，但它還不是移動性的神奇武器：在美國的一些城市，叫車App事實上不但沒有降低塞車，反而讓情況更為嚴重。不過，主要的原因是這些App都仰賴私有車輛：當自駕車服務更為普及時，情況可能大為改善，而這也促成道路空間更有效的運用。

根據研究預測，人們倘若擁有妥善的基礎架構，預計到2030年，可搭載多名乘客的機器人計程車，在美國道路行駛里程將達到5,000億英里，大約占所有車輛行駛里程的9%。到2040年，這些計程車將占所有車輛里程的一半。

透過共享服務平台朝隨選運輸的轉移，將讓社會每個層面(不僅年輕人、有能力或是相對較為富裕者)的移動性更強，並有潛在機會解決有關永續基礎建設、健康福祉、就業、不平等與社會包容等挑戰。透過此一方式，它不止支持單一的聯合國全球目標，而是能夠支持幾乎所有的目標。

政策/成本/隱私待解決 ACES布局循序漸進

當然，儘管大家推測ACES轉型可能會替未來的移動性帶來不少好處，我們還是得思考許多挑戰與問題。例如，政府目前從汽油與柴油燃料收取的數千億美元稅收，該何去何從？如何為此一龐大收入找到替代財源？

各國政府是否會考慮每英里固定向電動車徵收一定的費用？當英國市場目前休旅車與電動車的銷售數字比率是37:1時，我們如何進一步降低電動車成本、提高吸引力，以鼓勵消費者從現有的汽油車或柴油車跳槽過來？

讓車輛擁有連接數據的能力，也開啟了資料隱私及至關重要的網路安全等相關新議題(遭奪取的聯網車輛在惡毒的歹徒手裡，等於是在道路上奔跑的飛彈；關於這點，白帽駭客Charlie Miller已作出眾人皆知的錯誤示範)。此外，隨著AI在駕駛輔助與自駕車輛的部署愈來愈多，如果這些基於機器學習的解決方案是黑盒子，我們如何能確保所作出的決定都是明確、有道德且公平的？還有，如果這些系統突然失靈，誰要負責？

以上所述，對於ACES在未來移動性上展現的可能性，都是主要的障礙，但這不代表我們會暫停如何謀思因應之道。ACES框架對未來社會可能帶來的整體影響實在太大也相當正面，業界的每一份子都責無旁貸。

資料來源：https://www.2cm.com.tw/2cm/zh-tw/market/323FF3F182E84E4CA9EB5920D6D75E32

有一段時間之前我在FB上有發文說，我終於付錢看動畫了
一方面我有固定的收入，一方面我也支持付費平台繼續爭取更多動畫授權。對於免費仔的人來說，自然會透過一些網站去收看免費的動畫或者是台日韓劇，甚至是影集之類的。但是最近的消息就讓許多人崩潰了，台灣最大的盜版追劇網站：楓林網，在4月8號因觸犯著作權法遭刑事局查封。

對，我是第一次知道這個網站是兩個台大碩士搞的。架設平台六年期間，兩人成立廣告公司，賺取大量利益，侵權金額高達10億新台幣，隨後多處論壇也相繼關站。其實在清明節的時候，EY的動畫下載區突然關閉，就當大家以為是伺服器爆炸還是什麼不可描述的事情的時候，楓林網就被抄了，剛好兩名人士是在幾天前3月31號的時候就被逮捕，讓人不禁將這兩者聯想起來，而現在已經有多家影視和動畫公司打算相繼提告兩人。

好，這件事有好處也有壞處。好處就是更多正版影音平台獲得更多流量以及付費會員的增加，我有想過說這次事件的爆發，會不會有可能釋出什麼免費一個月VIP之類的，個人猜測、個人猜測。

壞處就是能夠觀看的平台減少了許多，當然我本人是一定要推崇觀看正版動畫，雖然要付錢，但至少你在看的時候 不會莫名其妙跳出一些廣告啦、視窗啦。相信我，以前我使用楓林網一次之後，我真的差點卯一拳在我的電腦螢幕上，尤其是分流，很高機率是不能播的那種。還是正版最香，而且老實說，一個月也不貴，我才不信一個月付不出99塊看巴哈動畫(阿好像只能限定台灣觀看)

然後另外一件事情，這一季的四天王已經倒下了三部，目前只有輝夜姬2還活著，這讓許多觀眾非常慶幸以及失望。慶幸的是不會遇到為了趕上檔期，而犧牲掉作畫的爭議出現，畢竟是大IP，總得考慮一下現況嘛。那令人失望的是，因為這次的疫情，除了新番之外，連之後的劇場版也被迫延期，像是Fate/Stay Night HF3、紫羅蘭永恆花園劇場版、名偵探柯南:緋色的彈丸，就連小魔女DoReMi 20周年劇場版也在幾天前宣布延期，這段時間相信將會是動畫界短暫的黑暗期，畢竟我從來沒有看過一次這麼多作品宣布延期播送的事情發生。那本人希望大家共體時艱，沒事待在家裡，出門在外記得戴口罩。

最後說一下近期本人的狀況。三月中的時候因為公司異常多，導致我工作量也被迫提升，同時也犯了兩三次重大疏失。老闆也跟我說，之後如果再出現同樣的狀況，可能就要終止我的合約，所以我目前的狀態非常低迷。還有我個人也覺得很抱歉的是，我也把這個情緒帶到朋友和遊戲身上，進而產生對我的不諒解，而且我現在也算住在員工宿舍，講話太大聲樓長也會來關心一下(我已經被關心了大概10次左右= = )

事後我也有反省關於自己的心態，當然我也希望之後還是能夠一起正常玩遊戲，而我也了解到業界的壓力不是一般的學生能夠體會到的(看產業類型啦)，反正這一陣子會思考一下之後要出什麼影片，請各位耐心等候新片的到來。

#AC68U #路由器 #梅林固件 #刷機 #路由器刷機
很多朋友在詢問如何刷機梅林韌體(固件)所以Wilson就特別用RT-AC68U這個梅林韌體的長青機種教學 其實步驟很簡單 十分鐘之內保證大家都會上手喔

buy RT-AC68U from Amazon: https://amzn.to/3hde59A
Amazon海訂教學:https://www.youtube.com/watch?v=7V_XAtjyY0I

不過請記得刷機會破壞保固 如果你沒有把握 就不要輕易嘗試喔

時間軸
00:00 開場
00:33 刷機器材準備
00:47 下載華碩救援工具
01:26 下載梅林韌體(固件)
01:56 提醒刷機等於沒有保固
02:07 讓路由器進入救援模式
02:36 連接網路線
02:51 PC網卡固定IP設定
03:37 開始刷機
05:24 完成刷機
06:13 其他華碩機種刷基提醒


梅林韌體(固件): https://www.asuswrt-merlin.net/download
華碩RT-AC68U 救援程式: https://www.asus.com/Networking/RTAC68U/HelpDesk_Download/