gpon開發難點
1：omci協議及業務的理解；
2：mib upload表的設計。
omci協議以及業務的基礎是g.98x標準的理解。
注：以下只涉及me基本的配置或資訊upload.
mib(management information base)gpon系統中以me格式儲存每個onu資訊，並保持和onu本地資訊一致。
mib表的作用：
1：從mib中直接獲取onu的部分基本資訊；
2：儲存使用者配置資訊。
mib表的生成：onu上線時完成onu本地和olt端mib表同步。
在g.984.4/g.988中描述了mib同步的多種情況，比如onu冷啟動上線，onu掉線後上線以及mib表非同步時策略等。目前實現建議(參考華為實現思路)採用極其暴力但是容易實現的方式。
olt端onu每次上線時完成如下三步：(omci_mib_upload_routine)
1：刪除當前olt端儲存的onu的mib表；
2：復位onu端本地資訊；
3：mib upload/mib upload next訊息完成onu遠端和olt端mib的同步。
onu掉線時不做任何處理；
onu刪除時清除對應的mib表。
優點：1：流程簡單，**實現難度低，易於維護；
2：減少了實時同步。
缺點：1：暴力，在每次onu上線時都「重頭再來」，但實測upload乙個onu mib時間在1-2秒內，應可以接受此時間損耗；
2：如果出現了olt端和onu端資料非同步，只能重啟onu.
圖2.1 mib表軟體設計關係圖
如上圖2.1，顯示以單個onu為索引的動態資料結構。所謂動態
1：系統中onu的個數是動態的，前文提到只有上線的onu才會分配mib表記憶體；
2：每個onu支援的me(或使用者配置需要支援)動態;
3：每個me支援的inst個數不確定，有些me只支援乙個inst,有些me支援多個inst.
（inst概念難以理解，舉個簡單的例子。以me 9.3.4:mac bridge port configuration data為例，
它要描述的是每個埠的config,因此每個埠就是這個me的乙個inst，比如說onu有四個乙太網口，那麼這個onu的me至少包含四個inst).
這種動態業務的軟體設計，我們常用的資料結構就是鍊錶或者樹。
1：onu層的設計直接使用陣列，預分配最大可支援onu數；
2：考慮
g.988
常用me的個數大概在50個左右(估計)，這個數量級使用哪種資料結構差別都不會太大；索引值me id,作為key值
3：inst屬於me的內部資料，inst個數相對比較少，鍊錶開銷比較少。
說明：這種設計不會影響新增/查詢/刪除效率，前提是你對記憶體的使用不那麼在意。
對記憶體的影響
1：me/me-inst記憶體動態分配/刪除，需要考慮記憶體管理；
2：占用記憶體會比較大；
3：大量onu上下線時會存在記憶體不斷nallioc/free,避免記憶體洩露；
4：記憶體重入保護。mib軟表上層會出現多個任務呼叫，可以對me為單位進行訊號量保護。
me/me-inst資料結構設計
1：每個me引數不同，對應的資料結構不同；
2：抽象出共性。
這一部分的設計比價麻煩，個人也沒有想到更好的辦法，後面再總結。
總結：如上只是個人一種軟體設計思想，但絕對不是唯一和最好的。
學習後總結，總結後再學習
學習後總結，總結後再學習 2010年畢業以來，讀了幾百本書籍，包括it技術 管理 歷史 營銷 金融 心理等等，在讀某商學院mba一年後感覺有些東西還是要寫寫，除了能增加自己對某些知識和理論的理解外，也許其他人也碰巧想關注一下，了解這方面的東西。我所寫的都是一些簡單的概念層面的解釋，不會做太深入的闡述...
學習總結 近期acm學習的總結
開學已經乙個月了，對acm的學習也乙個月了，做了一下總結 對自己不好的地方的反省 1.開學一開始學的是stl，不得不說stl是乙個很好的東西，熟練的運用stl大大的減少了 量，也使演算法容易實現。但是我在用stl後使自己產生了一種惰性思維。在兩個星期的stl練習後，我發現自己變得越來越懶，不願意自己...
深度學習學習總結
北京大學人工智慧實踐 tensorflow2.0 學習1 6章 複習1 4章 第4章需要寫乙個部落格 寫4,5,6章 吳恩達深度學習第四步 卷積神經網路 學習1 2周 複習1 2周 殘差網路和inception網路不太懂，目前用不到 三四周是目標定位，人臉識別，神經風格轉換目前用不到 油管最新最熱t...