取りたいイベントをあらかじめOnにして、その後負荷の具合を見ながら調整する
記録する際にロックを取るなどによりメモリ帯域を食ってしまうことはないか
基本的にCPU間でロックを取ることはない(ロックレス)
-
\ No newline at end of file
+
+
+@Fantom_JAC
+いまさら聞けないZigBee
+ ZigBeeは日本では名前しか知られてない
+ というか、まともな日本語の本も出ていない
+
+ ZigBeeの特徴
+ 日本で流行っていない
+ 802.15.4と混同される
+ BluetoothやWiFiに押され気味
+ 年会費高い
+ etc...
+ ZigBeeの歴史
+ ZigBee 2004とZigBee 2006は互換性がない
+ 今年 ZigBee IPが出た
+ ZigBee三大要素
+ IEEEで決まっているのはPHYとMACで決まっている (802シリーズ)
+ それより上はアライアンスで決めた
+ NWK
+ この層がZigBeeとしてもっともよく知られた層
+ APL
+ この層が全然理解されていない (後方互換性が無いのはここ)
+ APS, ZDO, ZCL
+ 802.15.4とは
+ IEEEが策定したPAN標準
+ 802.15.1 -> Bluetooth
+ 802.15ワーキンググループ (WPAN)
+ 別名Low Rate WPAN
+ 速度を犠牲にして消費電力を減らす
+ 2.4GHz
+ NWK Layer
+ メッシュを実現している層
+ ルーティング・ネットワークの管理
+ どのようなネットワークトポロジーになっているかはあまり重要ではない
+ 世の中に出回っているのはほとんどZigBee Pro
+ 毎回ルーティングを探す
+ NLDE
+ ふつうのData Entity
+ フレーム作ってセキュリティ掛けたり
+ NLME
+ ネットワークの開始・参加・離脱
+ PAN IDの管理
+ ルート探索
+ ルーティング
+ ZigBee Network
+ Coordinator
+ Router
+ EndDevice -> 電気を食わない
+ Coordinator
+ ネットワークに常に一台しか居ない
+ 802.11におけるAPのようなもの
+ 常にOn -> スリープ出来ない
+ 基本的にPCだったりして、ゲートウェイ的働きをする
+ Router
+ ネットワークを作成出来ない他はCoordinatorと同じ
+ EndDevice
+ ネットワークを作成出来ない
+ 子ノードを持つことが出来ない
+ ルーティング出来ない
+ 通常はスリープ状態
+ 普段はメッセージを受信することが出来ない
+ Coordinator/RouterからEndDeviceにメッセージを投げると、直接届いているように見える
+ 実はメッセージは親を経由する
+ EndDeviceはスリープから復帰した時、自分で取りに行く
+ メールチェックのような仕組み
+ 宛先のEndDeviceが取りに来なかったら、無慈悲に削除される
+ デフォルトタイムアウトは7680ms
+ 何とかしてすぐに送りたい
+ たぶんWakeupボタンみたいなのがあるはず
+ Wakeupボタンを押すと…
+ DoSのように何度も読みに行くだけ
+ FAQ
+ 消費電力について
+ Coordinator/Routerは常にRXはON
+ 電池がどんどん減る
+ 極力スリープ状態を長くすることでしか解決出来ない
+ Wakeupを5分毎くらいにすると、半年くらいは電池が持つようになる
+ PANIDが2つ(?)
+ 16-bit PANID
+ MACアドレスで使われるネットワーク識別ID
+ アドレスが二つ?
+ IEEE adressとNetwork address
+ IEEE -> いわゆるMAC adress (64bit)
+ Network adress IPスタックにおけるIPアドレスのようなもの
+ APL Layer
+ アプリケーション層
+ ZigBee最大の特徴
+ APS、Application Framework (ZDO/ZCL)の二つに分かれている
+ アプリケーションフレームワークがプロトコルレベルで決まっている
+ ZigBeeは単なる「通信方式の一つ」ではない
+ ビジネスに直結する仕様が策定されている
+ アライアンスの存在意義
+ モダンな設計
+ オブジェクト指向の概念がふんだんに取り入れられている
+ APS Layer
+ 上位のフレームワーク層と直接やりとりする層
+ Binding, Group Management, etc...
+ Endpoint毎にユーザのアプリケーションが格納される
+ Binding
+ あるApplication Objectと別のそれをリンクする
+ 単一方向
+ 多重バインディング
+ Binding Table
+ Group Addressing
+ 複数のApplication Objectに対して一括送信したい
+ 基本的にブロードキャスト、受信側が責任を持ってフィルタする
+ Group Table
+ APS ACK
+ 信頼性を高める
+ ACKタイムアウト時に再送
+ Fragmentation
+ 名の通りデータのフラグメント化
+ 実装されていないこともある
+ ウィンドウサイズがあったりと、TCPに似ている
+ Security
+ これだけで仕様書別になっているので、今回は省略
+ Application Framework
+ Cluster
+ 「機能」を指し示すような概念
+ Application Objectが外部にどのような機能を提供するか
+ Application Objectには必ずClusterが一つ以上ある
+ ZCLにおいては「クラス」に近い概念
+ Profile
+ Clusterの集まりを定義
+ クラスに対するパッケージに近い概念
+ APSメッセージはCluster IDとProfile IDを指定する必要がある
+ ZigBee Device Object
+ USBのEndpoint0と似ている
+ Application Objectの実装
+ ZDOとZDPは違う概念
+ ユーザが作成するApplication Objectは通常APSDE以外触れることが出来ない
+ サンドボックスの様な仕組み
+ 別途ZDOを経由する
+ ZigBee Cluster Library
+ ユーザが作成するApplication Objectの実質的な仕様、枠組み
+ 必ずサーバとクライアントが対になって通信しなければいけない
+ Profile固有のClusterと共通のClusterが存在する
+ ZigBee IP
+ つまらないので省略
+ Pure Java ZigBee Application Framework: Bekko (LGPL)
+ アライアンス入会とは?
+ ZigBeeを名乗るプロダクトを開発する権利
+ HAやSE等PAPプロダクトを開発する権利
+ ただし、非営利目的であれば入会不要
+ 営利目的であっても既に認定を受けたプロダクトを利用するだけなら入会不要
+ XBeeは入会不要
+ Q/A
+ 有名なプロダクト例
+ 日本で市販はされていない
+ BluetoothやWiFiとは違い、B2Bが目的なので、コンシューマ向けではない
+ アメリカにおいては、Control4Cが、「一戸建て建てる時にZigBee組み込みませんか」みたいなキャンペーンはしている
+ 蛍光管をLEDに代える際に、ZigBee組込みで、配線無しでOn/Off出来る製品とか
+ 日本ではMAKEというイベントに行けば見れるかも
+
+
+@fusioniojp
+FUSION-IO関連の楽しいお話
+ IOMEMORY SDKとNVMインターフェース
+ Non Volatile Memory
+ NANDフラッシュメモリとDMAコントローラを一体にしたもの
+
+ 現行
+ NANDとメインメモリの間にI/Fのコントローラが挟まっていて、遅い
+ SASコントローラなど
+ これから (カットスルーアーキテクチャ)
+ FPGAで実装されているデータバスコントローラを使う
+ メインメモリに直接コピーされる
+ 512byte -> 10usで書ける
+ HPCではデータをHDD上に置かない
+ SSDが出てきた時、「NANDはメモリなんだから、メモリのようにI/O出来るようにすべきだ」
+ 不揮発メモリであれば、BlockI/Oでは実現出来ないような操作が可能
+ BlockI/Oは回転型メディアにあわせて設計されている
+ テープ
+ open/read/write/rewind
+ ディスク
+ open/read/write/seek
+ SSD
+ ディスクと同じ様にあえてしている
+ Trimとかは一応あるが……
+ ioMemory NVM
+ 不揮発メモリの特性を生かした追加機能
+ 通常のライト+アトミックライト・条件付きライト
+ ジャーナル要らなくね?
+ 通常のライト+TTLライト(のちに自動消去)
+ このデータは自動的に消滅する
+ mmap+クラッシュセーフ・バージョニング
+ 先ほどのftraceの様にどんどんログを書き込む
+ SSDの登場により、フラッシュメモリを使ったアプリケーションが実現した
+ フラッシュメモリをメモリとして利用すると、ソフトウェア開発のあり方が変化する
+ 現行
+ アプリケーション -> BlockI/O、ネットワークファイル
+ これから
+ アトミックI/O
+ トランザクション
+ ユーザ定義のオブジェクトによりトランザクション
+ Key-Valueトランザクション
+ memcached
+ 将来
+ 高速なロギング
+ チェックポイントメモリ
+ メモリトランザクション
+ CPUからメモリに書き込むように、フラッシュメモリに書き込める
+ 100万IOPSのカードは既に実現している
+ CPUのコンテキストスイッチの方が問題になってくる
+ -> mmaped I/Oすれば良いのでは
+ 64byte/1thread -> 960万回
+ スパースアドレス空間
+ デバイスI/Fのオープン化と、OSS
+ directFS
+ NVM APIライブラリ
+ Atomic writeはSCSI標準化に向けてプロポーザルを出した
+ ハードウェア側で書き込みを保証出来るので、アプリケーションとしては単に「書き込む」だけで良い
+ MySQLのダブルバッファーのようなことは必要なくなる
+ 書き込み量が減るので、製品の寿命も長くなって良い
+ 書き込みの粒度を512byteから小さくすれば、一回の書き込みに掛かる時間は短くなる
+ directFS
+ swap -> Extended memory
+
+ Q/A
+ ウェアレベリングなどはどこで行われているか
+ CPU側で行っている
+ SSDのような小さなデバイス上に実装されているマイコンで行われるのを待ってCPUが
+ ブロッキングされるより、CPUで行った方が結果として早かったりする