無線網橋開機啓動加速

1 背景

　　在整完一段物聯網的項目後，基於此項目中的時間曲線要求，再回頭來檢查之前WiFi網橋類產品的啓動速度，以爲很是不可接受，剛好有朋友要推一款成本更低廉的網橋設備，因而動手對原網橋固件進行了再次優化。
　　老固件從上電到網絡就緒，大概要32秒（可靠率99%）；極端狀況下，當CPE端進入「假死」態時，可能須要50秒才能網絡就緒。按物聯網設備開機便可用的要求，這個時間真的是太漫長了，連金星上的手機都快偵聽到此WiFi信號了。

2 具體過程

　　首先，在網上找了一圈，發現車載/車聯網領域的工程師們已經對Linux啓動加速進行了多種嘗試，有個builtroot項目的啓動速率，不超過1秒，這簡直是神了。但我不會弄builtroot，將QCA LSDK工程移植到buildroot上，代價太貴，不敢動。
　　其次，參照前人的經驗，也是從uboot開始，LSDK的uboot功能較單一，絕對速度也算快，只是沒有作任何優化，因此相對速率較慢；特別是之前的設計要求中，在基於可靠性要求下，強制網橋要求支持雙固件備份，從而極端狀況下要計算並檢測2次CRC，每次至少須要1秒；加上bootdelay的1秒，以及一些打屏損耗，總體無效耗時較長，須要特別優化。本優化中將uboot中的abort函數直接關閉，不接受字符輸入方式進入uboot控制檯，僅保留按鍵方式進入UIP模式。由於進入UIP模式後，可經過按ctrl+C後進入uboot控制檯。通過如此優化後，上電到「Starting kernel」的時間耗費，由近6秒縮到2.202秒。效果很是明顯。
　　再其次是優化內核，將沒必要要的打印所有關閉，從「Booting Atheros AR934x」到「init started」的時間，縮短到0.900秒。不敢優化lpj，由於該校準耗時爲100毫米級，優化價值不高，且怕最終量產後出問題。
　　其實網橋真正耗時的操做，是無線和有線驅動加載以及配置實例生效。基於之前穩妥的「慢慢來」策略，rcS中先加載有線驅動並拉起有線口配置實例；再加載無線驅動並生效無線配置實例。這個過程都是串行的，須要近20秒，等無線可用時，又耗費6秒多。所以，本次優化的核心工做就是調整驅動加載和配置生效次序(驅動代碼中的init鏈所涉及到的sleep，也適度縮小)，在不引入新問題的原則下，首先調整rcS的驅動加載與指令執行順序，將無線驅動相關的ko文件分散加載，且將耗時較長的加載改成後臺加載，這樣前臺可當即執行其餘不彼此依賴的指令。通過這樣修改，成功加載完有線/無線驅動後，所耗時間縮短爲3.51秒。
　　重構有線/無線的配置生效，由於配置生效最終的結果都是產生一系列的配置指令，直接將這些配置指令保存到一個文件中，在驅動加載完畢後，檢查生效文件是否存在，若是存在，則直接執行該生效文件；不然才執行原來的配置生效指令集。這樣一來，配置下發所耗時間縮短到1.316秒；配置生效所耗時間縮短爲1.418秒。

3 優化結果

　　在AP端設置爲固定信道後，從上電到該設備就緒所耗時間縮短至9.499秒，CPE端的啓動時間縮短至11.73秒。AP設備不動，CPE側的主機從CPE上電到ping通AP側的主機所耗時間約爲13秒；CPE設備不動，AP側的主機從AP設備上電到ping通CPE側的主機所耗時間約爲16秒。
　　一樣地，將AP配置爲自動信道後，AP設備不動時，CPE側的主機從CPE上電到ping通AP側主機所耗時間約爲16秒；而保持CPE設備不動，AP側的主機從AP設備上電到ping通CPE側主機所耗時間約爲18秒。
　　可是，不管是固定信道仍是自動信道場景，測試中均出現過ping通對方主機時間爲35秒的狀況，主要表現爲AP設備已轉爲正常工做態，手機上也發現了該AP的廣播SSID，但CPE設備仍在不斷掃描中，看了CPE側的內部實現還須要繼續優化。

　　從優化結果上看，已初步符合特殊場景下啓動到網絡就緒時間不超過20s的硬性要求。

　　本輪優化改進的測試環境：2臺陪測主機均爲固定IP；在斷電重啓過程當中，主測試的PC機上執行過arp -d；QCA9342+8032 WiFi 網橋；QCA LSDK 9.2，2.6.31 內核；無線未加密。