分類: 技術

速度規格表

規格 速度
規格 版本 Mbps MB/s Gbps GB/s
UART 16C552 (16 bit) 0.1152
16650 (32 bit) 0.4608
16750 (64 bit) 0.9216
16C850 (128 bit) 1.5
I2C Normal Speed 0.1
Fast Speed 0.4
High Speed 3.4
NAND / SD Normal Speed 12.5
High Speed 25
Ultra High Speed-I
SDR12 12.5
SDR25 25
SDR50 / DDR50 50
SDR104 104
Ultra High Speed-II
UHS156 / FD156 156
HD312 (半雙工) 312
eMMC 4.41 104
4.5 200
5.0 400
5.X 600+
UFS 1.1 300
2.0 1.2
Bluetooth 1.2 1
2.0 + EDR 3
3.0 + HS 24
4.0 LE 24
WIFI 11b 22 MHz 11
WIFI 11g 20 MHz 54
WIFI 11n 20 MHz 72.2
40 MHz 150
WIFI 11ac 1×1 80 MHz (wave 1) 433
2×2 80 MHz 866.7
1×1 160 MHz (wave 2) 866.7
2×2 160 MHz 1.69
4×4 160 MHz 3.39
8×8 160 Mz 6.77
PCI 2.3 266
PCI-E 1.0 16 lane 32 4
2.0 16 lane 64 8
3.0 16 lane 126.032 15.754
4.0 16 lane 252.064 31.508
2.0 500 (單向) 1 (雙向)
3.0 1 (單向)

2 (雙向)
SD Card Class 2 16 2
Class 10 80 10
UHS SD Card Class 1 80 10
Class 3 240 30
USB 1.0 Low Speed 1.5
1.0 Full Speed 12
2.0 High Speed 480
3.0 Super Speed 5
3.1 Super Speed+ 10
SATA 1.0 1.5
2.0 3
3.0 6
3.2 16
eSATA 6
Ethernet 100 100 0.1
giga bit 1000 1
DDR-2 400 800
800 1600 1.6
1066 2.13
DDR-3 1066 2.13
1333 2.67
1600 3.2
2133 4.27
DDR-4 2133 4.27*

WIKI 上說 DDR2 SDRAM gives a transfer rate of (memory clock rate) × 2 (for bus clock multiplier) × 2 (for dual rate) × 64 (number of bits transferred) / 8 (number of bits/byte). [1] 但通常 embedded system 不會用 64 bit 通道, 比較常見的 16 bit 或 32 bit. 這個表格裡會用 16 bit.

另外, DDR-4 的效能不佳, 比 DDR-3 沒有太大改進 [2], 某些指標好 13.88% (解壓縮), 播影片 X265 反而變差了 3.68%. 公司同事對它的評價則是更低許多. 不過未來可望能用比 DDR-3 便宜的價格買到一樣容量的 DDR-4.

NAND 的速度參考美光網站 [3], Read 可以到 200 MB/s. 以及 e-world [4].

以上沒說明的部分都是從  WIFI 抄過來.

[REF]

  1. https://en.wikipedia.org/wiki/DDR2_SDRAM
  2. http://www.anandtech.com/show/8959/ddr4-haswell-e-scaling-review-2133-to-3200-with-gskill-corsair-adata-and-crucial/8
  3. http://docplayer.net/3700204-Nand-201-an-update-on-the-continued-evolution-of-nand-flash.html
  4. http://e-words.jp/w/UHS-I.html

WISP 小註解

前幾天因為老婆抱怨一樓的網路慢, 只好花點時間修理. 謎之音說其實是 new ipad 的無線網路比全家所有的筆電手機都差！

基於家庭網路工程師的職責, 我懷疑四樓 router 的乙太網路線到小烏龜拉太長, 日久潮濕, 所以整個速度上不去. 因此我把四樓的 router 換了個更接近小烏龜的位置….想不到悲劇發生了, 二樓的 router 竟然再也不認識四樓的了. 我想是可能是因為沒有 step by step 設定, 導致 router 混亂. 這算 firmware 沒寫好吧!

原本我對兩台 router 的接法是 WDS. WDS (Wireless Distribution System) 有個好處, 就是 IP 在兩個 router 間是通用的, 同屬一個網段. 例如 192.168.1.X…. 不過相較之下, router 的無線橋接 (Wireless Internet Service Provider) 真的比較好設定.

從 WDS 改 WIDP 的步驟如下:首先把連接小烏龜的 AP1 的 WDP 關閉, 改為純 AP router. 接著把 AP2 的 WAN 設為 wireless WAN, 然後 scan 想要橋接的 router, 找到它並連上之後, 把 AP2 的 DHCP 設為另外一個網段就行了. 例如: 192.168.2.x.

此時 AP2 的 SSID 會跟橋接的 AP1 一樣. 但畢竟網段不同, 因此把 AP1 的次要 SSID 改為 4F, 二樓的次要 SSID 改為 2F, 這樣網路斷了也知道要連哪一個. 關於 Tenda W309R 的 WISP 設定方式, 在 youtube 上面有影片可以看.

 

 

電腦不乖 – HTTP 與印表機問題

前陣子某一天, 我的網站突然不能用了. 按照先前的印象, 首先檢查寬頻連線、防火牆、HTTP port. 果然 HTTP port (80) 不知被誰佔用了?

網路上有很多這類文章, 隨便 Google 都可以查得到, 所以我前一次把問題解決後也沒去記用法. 不過問題再度發生的時候就糗了, 又要重頭 Google. 網路上的 SOP 是執行

netstat -ano

看 0.0.0.0:80 是哪個 PID 占用? 高手 [1] 會用

netstat -nao | find “0.0.0.0:80″

這樣就會自動撈出來 PID. 有了 PID, 還要找是哪個程式在用, 同樣參考 [1], 應該打

tasklist /fi “pid eq 1234"   (1234 是舉例)

如果這程式不是 Apache, 而是像是慣犯 Skype…等等在用, 就可以把它先 kill 掉. 比較麻煩的是看到 pid =4 , 這是系統自己占用的, 網路上的解法 [2] 是把 http service 停掉, 並且把開機時的 http service 設為 disabled.

運氣好的話, 執行

net stop http

這時用到 http 的程式就會一隻一隻停掉. 但我的運氣不太好, 停到 http service 的時候, 就會跟我說 http 正在開啟或關閉中, 無法停止服務. 我猜是因為 apache 還在用它的關係. 此時死馬當作活馬醫, 繼續打

Sc config http start= disabled

然後重新開機, 基本上就修復了. 雖然中間反覆了幾次修些小問題, 但這招是靈光的. But….

用了這招之後, printer 就爛掉了. 我的 printer 是 MFP, 所以它還可以掃描, 但是不能印東西了! 這實在讓我很不方便. 一開始也沒聯想到是關閉了 http 的關係. 根據正常的直覺, 當然是先檢查 spooler 啊! (看我大學系統程式學得多精實, 哈!)

當我去服務裡面啟動 spooler, 它彈給我一個 error 1068! 1068 的錯誤代碼是相依於 spooler 的服務無法啟動. 到處看了幾篇文章, 原來 spooler 的相依性在這裡.

print-spooler

把 RPC, DCOM Server Process Launcher, 甚至是網路上 [3] 有人建議的 WINHTTP Web Proxy Auto-Discovery Service 都檢查了. 它們都是正常的! 所以…元凶還是我自己啊! 赫然想起我前一陣子把 http 設為 disabled 了.

因此, 重來一次, 這次把它設為… 

net stop http

Sc config http start= boot

哇! 不行, 設 auto..也不行! 設 delayed-auto …耶! 可以了!

Sc config http start= delayed-auto

重新開機, 此時 spooler 可以運作了. 由於 bug 發生的症狀是: 想要印東西時, word 找不到印表機. 因此我趕快新增印表機!

搜尋新增裝置…找不到! 再試一次…還是找不到! 莫非….

原來不用新增, 根本系統就自動找到印表機了. 雖然我看了某篇文章去刪除了 printer 的機碼. 但看來不影響, 它又自動裝上了, 難怪新增不了, 唉! 我真是自作聰明.

為了避免這問題再發生第三次, 乾脆就把前因後果全部火速打成一篇. 希望也能幫助別人解決類似的問題.

[ref]

1. 如何查詢哪個程式佔用了指定Port

2. [Windows] Port 80被佔用導致Apache無法啟動

3.  Printer spooler windows 8 Error 1068: The dependency service or group failed to start.

電腦不乖 – 雲端硬碟篇

這幾天電腦相當地不配合. 首先是試用了 2TB 免費的百度雲. 超大空間免費用當然很吸引人囉.  不過若不安裝它的 APP, 就不能上傳超過 2GB 的檔案. 聽說這是有辦法破解的, 但重點不在 2GB, 而是使用這個 APP 時, 速度會忽快忽慢. 過不了多久就斷線了.  一直傳一直斷, 我只好放棄它吸引人的容量和挺不錯的檔案夾同步功能.

接下來最便宜的就是MediaFire 了, 1TB 定價每年 49.99 USD, 花一個一千多台幣就有一個雲, 似乎勉強可以接受, 而且單檔可以到 20GB. 可是 MediaFire 的速度實在令人失望, 我的幾台電腦一直無法同步, 即使是用 ADSL 的網路放著讓它過連假, 幾天過去了, 還是沒辦法同步完. 當我試著把 MediaFire 目錄裡的檔案殺光, 跑去雲端看他們都還完好如初, 更不用說別台電腦裡備份也還健在. 經過實驗證明, 我的 PC 和和兩台 NB 始終不能同步.

還有一個方案價錢也不錯: Amazon 雲, 只要 59.99 USD 就可以無限上傳不限容量的檔案. 可惜這個 APP 介面很差, 不能像 OneDrive, Dropbox, iCloud, .. 一樣直接把檔案總管理的檔案拉進去, 只能夠一股腦地丟上去, 需要的時候再去雲端找出來下載. 我想它的用途就是當作超大倉庫來用. 而且它可以免費試用三個月, 我會再丟丟看它的倉庫功能是否令人滿意.

不得已只好試試 OneDrive, OneDrive 比 MediaFire 貴多了, 1TB 大約是一年 3190 NTD (後詳), 價錢和 DropBox 相當 (一年 100 USD). OneDrive 同步的速度還算 OK. 但是它只在 MacBook 可以選要同步那些目錄, 在 PC 就一定要同步所有的檔案, 使得我的 PC 一定要留 1TB 的硬碟給它. 

當然, 買 OneDrive 若不搭 Office 360 就不划算, 因為買 Office 360 家用版送每個 user 1TB, 5 個 user 就等於 5TB. 也可以想像成買雲端硬碟送 Office. 看似不錯的選擇, 但搭了 Office 又會有什麼壞處呢? Office 2016 剛好跟 Mac 最新的 OS X El Capitan 相衝. 如果您先安裝免費的 El Capitan,  再安裝 Office 2016, 那 Office 會當掉. 這樣您還有機會在 Office 360 的一個月試用期之內把它退掉! 反之, 如果先裝好 Office 2016, 再試圖安裝  El Capitan, 那麼會安裝不起來.

若是一時好奇心重, 到應用程式裡面手動執行 El Capitan 的執行檔 –> 那麼恭喜了, 整台 MacBook 都要重新安裝, 而我就是那個好奇的人. 一開始我還以為是自己失手, Google 到了別人文章才知道兩者有衝突. 而且 Microsoft 和 Apple 都沒有積極去解決.

OneDrive 還有一個超爛的地方, 那就是別家的後台可能都是 Linux,. 但 OneDrive 後台可能是 Windows. 因此, 檔案名稱太長, 目錄太深, 檔名裡面有奇怪空格, 對別的雲端硬碟都沒問題, OneDrive 就是不給上傳!  想不到吧!

iCloud 最貴, 是給用 iPhone 的有錢人用的. Google Drive 莫名其妙就把你的手機相片都備份上去了. 看來會成為它們大數據的一部分.

唉, 電腦不乖!

[Note]

  1. Office 2016 與 OS X EL Capitan 不相容的問題, 已經在 EL Capitan 2015/10/21 的修正中解決.
  2. 根據一段時間的觀察, Dropbox 同步的速度比 OneDrive, MediaFire, …都強太多了.

QUIC 小註解

QUIC (Quick UDP Internet Connection) 是最近 Google 想要推的一個新的網路規範, 顧名思義, 它的目的就是快！

Google 有這麼多聰明人, 取名字自然不含糊. QUIC 唸起來和 quick 相同, 可以很直接地聯想在一起. 其實, 就算是這個 protocol 沒有用到 UDP, 歷史上也沒有發明過 internet, 都還是可以兜出 QUIC = quick connection. 哈！

那麼 QUIC 快在哪裡呢？快在兼具 UDP (User Define Protocol) 的輕巧, 以及 TLS (Transport Layer Security) 的保護.  UDP 的輕巧當然是相對於 TCP (Trasmission Control Protocol)  來的, 如果大部份都走 UDP, 當然傳輸速度就會增加, 讓我們複習一下.

協定 優點 缺點
TCP 可靠 慢
UDP 快 不保證收到

簡單地說, 可以把 QUIC 解釋為 TLS + TCP 的改良版, 並且是用 UDP 來實現. 當然, Google 不會傻到撞牆, 傳了一路 UDP 又另外傳一路 TCP, 而是把 TLS 和 TCP 的內容包裝到 UDP 裡面. 所以按照下圖, TLS + TCP 可以通, QUIC + UDP 也可以通.  那 SPDY 又是什麼呢？這個晚點再說, 先假裝沒看到. 基本上它已經變成了 HTTP2 的一部分.

那麼, Google 宣稱的快速 hand shake 又是如何做到的呢？根據 [2], client 會先送 inchoate client hello 給不認識的主機, 主機也不客氣地回 REJ. 由於這個 REJ 裡面會帶有 source address 和 server certificates 的資料, 所以並沒有白白被拒絕. 這時再送一次 client hello (CHLO), 應該就會對了, 後續可能就會收到 server hello (SHLO) . 

或曰, 難道其他人都想不出有這招, 只有 Google 的人想得到? 當然不是這樣. 根據 TLS 的規格 – RFC5246 [3] 7.4.1.2, client hello 原本就要帶著一些資訊送給 server. 7.4.1.3 說 server hello 要回傳 client 看得懂的演算法, 或者傳 fail. 因此在現行規格下, server 可能根本不願意吐出資訊給冒冒失失的 client. Ref [2] 說:  They may be several rounds of inchoate client hello before the client receives all the information that it needs because the server maybe unwilling to send a large proof of authenticity to an unvalidate IP address. 

所以, 所謂的 0 round 或是 1 round hand shake 都是宣傳的噱頭. 這需要有夠傻的 server 願意配合才行. 一個捏造的 IP client 送一個小封包, server 就要大陣仗地把自己的認證資訊都吐出來, 這樣聽起來 server 很容易被攻擊耶. 除了這一步有風險之外, 後續的資料會受到 TLS 的保護. 根據 Ref [4], QUIC 整個 channel 都有加密.

根據 [5], 其實 QUIC 有考慮到被攻擊的事. 一個合法的 clinet 需要 proof of ownership of an address, proof of data received. 前者的精神是 server 會把一個值傳給 client, 看 client 是否可以回傳它. 後者的精神是, 通常網路攻擊就是 client 不理會 server 而瘋狂地送出 data. Quic 的相容性 SERVER 會檢查 client 到底有沒有消化過先前送出的資料. 做法是在某個特定的  bit 做 0/1 的隨機變換, client 要忠實地反映這個變化, 才算是真的 user, 而不是攻擊者.  

QUIC 另外有幾個優點在於: 用錯誤更正碼 (Forward Error Correction) 代替  TCP 的重傳, 減少重傳的數量. 事實上, 網路很好的時候幾乎都不會重傳, 網路愈糟, 愈需要重傳, 形成一個惡性循環. 因此 QUIC 基於 UDP 可以理解. 但假如 QUIC 把  TCP 幹掉了, 以後網路上都是 QUIC, 等到頻寬吃完了, 不就互相排擠, 讓 packet 掉光光? 

Well, QUIC 有兩招可以處理這個狀況 [5]. 他會送出 Congestion Feedback Frame. 這就像是網路頻寬金絲雀, 金絲雀死了, 就知道有問題了. 另外一招是測量  ack 的間距, 如果 sender 偷偷加速封包的傳送, round trip 的時間卻沒有拉大, 表示網路還很空, 還可以送快一點. 技術細節類似於 Linux 用的 cubic congestion algorithm.

[結語] Server 和 client 之間, 除了 internet 還有很多 router, switch, 如果全部更新是很大的商機吧！那某大網路 IC 設計公司會大漲嗎？哈！

[後記] 今天在 FB 上看到人家分享 QUIC 的文章, 重點倒也不是介紹技術, 而是捧 Google 的厲害. 雖然沒有寫什麼十三億人都驚呆了, 但是意思也差不多. 只講優點不講缺點之餘, 也沒有起到科普的作用, 只是打擊了一下工程師們脆弱的心靈而已. 台灣企業也努力過, 聯發科追過 Wimax 規格, 瑞昱試著訂 UWB 規格, 雖然都功虧好幾簣. 不過該做得還是可以再試一下, 也許有一天就成功了. 九陽豆漿機冠名贊助的真經上說過: “他驚由他驚, 大江閃星星, 他呆任他呆, 隨處有 WIFI." 在驚嘆之餘, 其實只要花一兩個小時就可以略跪門栓, 比一昧佩服人家然後驚呆來得好.

[ref]

1. TCP 與 UDP

2. QUIC Crypto design

3. https://tools.ietf.org/html/rfc5246

4. Quic Geek FAQ  

5. Risk Complete Failure