Castle on a Cloud

在上一篇文章中, 說明了在 Spark 中對 RDD 操作的限制, 然而, 比較不精確的地方在於, 在 Spark 中有另一種不同於 val 變數, 稱為 var, 可以供我們進行一般的運算. 舉例來說: scala> val foo = 1 foo: Int = 1 scala> var bar = 1 bar: Int = 1 scala> bar = 2 bar: Int = 2 scala> foo = 2 <console>:25: error: reassignment to val        foo = 2            ^ 可以看到, 宣告為 val 的參數 (foo) 無法改變, 但是, 作為 var 的參數 (bar) 可以被改變.

真的開始用 Spark 之後, 才發現和原本的程式概念差很多, 其中, 最重要的一點, 就是 Spark 是從資料 (RDD) 出發, 而不是從時序運算出發... 一般來說, 當我們寫程式時, 就是按照時序將要做的事情一行一行完成, 舉例來說, 我們簡單寫一個 parser: void get_tokens(char *line, char **tokens, size_t number_of_tokens) {     static const char *delimiter = ",";     for (size_t i = 0; i < number_of_tokens; ++i) {         tokens[i] = strtok(line, delimiter);         line = NULL;     } } 簡單來說, 就是把一個字串拿進來, 按照 "," 切開, 之後再按照其長度放到一個叫做 tokens 的陣列中, 看起來十分簡單易懂, 此時的資料就像是一堆記憶體碎片般, 我們可以任意地宣告, 處理, 搬移.

在過去, 我一共寫了4篇關於 OpenWRT 架構的文章, 當時, 因為只是記錄下工作的內容, 就沒有太講究介紹的架構, 以下大概是其內容: [OpenWRT] OpenWRT 的設定 (1): 時區和同步 [OpenWRT] OpenWRT 的設定 (2): 工作排程 [OpenWRT] OpenWRT 的設定 (3): 架構 [OpenWRT] OpenWRT 的設定 (4): 網路設定 為了讓大家可以比較快了解 OpenWRT 是甚麼, 因此, 在這裡寫一篇介紹文章, 介紹一下 OpenWRT 的歷史與應用情境. Linksys WRT-54G (圖片來自Wiki) OpenWRT 是一個 Linux (busybox) 為基礎的作業系統, 在 WiFi 一開始發展時, 基本的架構就是一個微處理器, 搭配 WiFi 的處理晶片, 此時, WiFi AP 還是嵌入式系統 (如: VxWorks) 的RTOS架構進行運算, 直到 2003 年 Linksys 推出了 WRT-54G 這台 WiFi AP (802.11g), 考慮到成本, 以 Linux 作為其作業系統, 由於 Linux 開源散佈的特性, 該作業系統也被要求開源發布, 也就成為 OpenWRT 的前身, 在 OpenWRT 推出後, 震撼了消費型的 WiFi AP 市場, 許多開源的工程師發現, 這套作業系統可以用便宜的硬體, 完成舉多高階AP的功能, 也因此, OpenWRT 也就成為開發 WiFi AP 開放平台的主流.

說到 WiFi 定位, 大家直覺想到的是用於室內環境中, 事實上, WiFi 訊號對於室外的定位也有幫助, 舉例來說, Google Map 上的定位除了 GPS 之外, 也包含 WiFi 訊號的輔助.   https://support.google.com/maps/answer/1725632 "Google 會利用無線存取點的公開 Wi-Fi 資料，以及 GPS、基地台資料與感應器資料，來改善定位服務。我們只會使用公開的 Wi-Fi 資訊來推測裝置的約略位置。" 至於 WiFi 訊號如何幫助定位呢? 我們可以用下圖來表示. (其實寫這篇網誌是因為花時間畫了一張圖, 雖然, 其中沒有甚麼技術, 也和研究沒有相關, 就寫成網誌分享...) (素材來自網路)

在 Qualcomm 提出 X50 的通訊模組後, MTK 也提出了相對應的參考設計, 考慮到 MTK 沒有完整的文件說明其設計, 在此文章中, 統整一下網路上蒐集的資訊. 並著重在其 mmWave 的設計與機制. 來自:  https://udn.com/news/story/7098/3356105 在 MTK 的參考設計中, 可以很明顯地看到一組 2X4 的天線, 事實上, 在手機的正面, 有一組相同的天線, 用以對抗手握的干擾. 另一方面, 在手機的側面有散熱孔, 採風扇散熱設計, MTK 表示在正式的設計中, 會藉由功耗控制來改善散熱問題, 不過這也側面反映了 mmWave 極為耗電, 這也是普及的挑戰.