koie blog

• 2019-06/18 18:00〜19:30
• 告知
• 南 政樹（慶応義塾大学 SFC研究所 ドローン社会共創コンソーシアム）

交差点でNHK撃退シールをくばってたけど無視して会場へ。

[2019-06-18 18:01]

なかなか話者が来なくて連絡もないようで関係者がやきもきしてたが、1分遅刻で話者到着。

[2019-06-18 18:02]

• SFCでipv6書いてた。

• 「ドローン前提社会」は自分がつくった言葉。
• 昔のSFでは飽和した地上から空を一人乗りの乗り物で移動してる未来が描かれていた。
• フクイチを無人ヘリで調査したりした。
• (ここで毎回やっているというドローンでの記念撮影。機体はDJI)
• ラジコンの延長というよりはインターネットの延長と考えている。
• 今は無線で直接つないでいるけど5Gでつながるようになるはず。IoTとおなじ。
• 地上とランデブーするはず
• droneとは雄蜂のこと。雄蜂は仕事しないで巣にいるので転じてヒモ・役立たずの意味もある。
• droneの語源はイギリスの queen bee という無人飛行機(1936)から。
• ドローンは無人航空機: UAV 人をのせられない (一人乗りのドローンもあるけど..)
• 回転翼 プロペラが多い方がリダンダンシー(墜落しにくい)
• 固定翼のもある
• ドローンが官邸に落ちる前はドローンは模型飛行機のあつかいだった。
• 実はやっと法律がかわって飲酒運転が禁止になった。
• フィクションだが: マイクロドローンに3gの爆弾をもって顔認識で頭をねらう。流れ弾がない。→ 兵器にAIをつかってはいけないという主張 (autonomousweapons.org)
• ドローンはプロペラがついたスマホとみなせる(スマホとつかうセンサーなどの部品が似ている)。中国のドローンが強い理由。
• ドローンが飛ぶ方法は3つしかない: 浮力・推力・揚力
• ドローン:自律的に移動する(空中だけでなく地上も水中もあり)
• 昔は制御がアナルグだったが今はデジタル。
• PID制御とカルマンフィルターと重心のオートチューニング
• 自立性がラジコンとのちがい (勝手にバランスをとってくれる)
• mavlinkという簡単なプロトコルがつかわれている。
• 実はつかっているチャンネルは1つではない。
  • テレメトリーは別チャンネル 900MHz
  • コントローラは 2.4GHz
  • 映像は は5.?Ghz
• PWMでモーター回転数制御していたが今はベクトル制御でトルクが上がった。(ドローンが進歩した理由?)
• ドローンは進むときに傾かないといけない。
  • レーシングドローンは80度くらいまでかたむく
• ドローンの上で倒立振子も簡単にできる (ただし棒の先端にはトラッカーをつけてモーションキャプチャーしてる)
• ドローンで釣(drone fishing): 陸から仕掛をドローンではこんでポイントに投下する。上からだと魚影がよく見える。
• 中国: 高圧線にひっかかったゴミをドローンの火炎放射器でやきはらう。
• 200kg持ち上げられるドローンでビルの窓掃除。ただし水は地上からホースで。消防にもつかえるかもしれない。
• sharkspot: 画像認識で海のサメとイルカとクジラと人を認識して警告するとか
• ドローンの可能性: 視点・ポジション・インターネット・群れ行動
• mavlink dronecode じゃなくてmqttでもいいいのではないか。
• レーシングドローンはラジコンとかわらない。arudino シングルスレッドで。あまり処理できない。px4。
• 逆位相プロペラで音を消してスピーカをうかすアイデア。
• VAIOがドローンをつくっている。設計はnileworks。
  • ドローンで農薬散布: 画像認識することで、植物に元気がないところだけ肥料をまいたり、カメムシがいるところだけ農薬をまいたりでいる。いまの農業は確率的でおおざっぱ。
• ドローン宅配は空だけじゃなくて陸路・水路も活用されるのでは。自立が需要。屋根・ベランダに宅配ポストができるかも。
• cargo drone
• ルワンダは陸路が整備されてない。固定翼ドローン zipline で医薬品を運ぶ。固定翼の欠点は離着陸に場所が必要なことだが、離陸はカタパルト 着陸はコードにひっかけてとめる。 オペレーションは現地の人でもできるように部品交換が最小限になるように工夫。
• ドローンでレンガを積んで塔をつくる。位置制御が正確にできるため。

[2019-06-18 19:02]

• みそらかなたちゃん: ドローンのためにつくったキャラクター

• Q: ドローンの衝突はどう解決する?
• A: UTM(UAV Traffic Management):管制システムをつくっている。
  • 無人管制の考え方はまだマイナーで有人管制の考えが強い。
  • 位置情報とベクトル情報を共有する。
  • open drone IDで識別。
  • WiFiを想定しているが5Gにも対応しようとしている。
  • まだこれからという段階。
• Q: ドローンの制限事項に何があるか?
• A: 風は古くから問題で対策されてきている。モーターの制御技術で状況に応じてトルクのだしかたをかえられる。
  • 伝送距離の問題は衛星通信をつかったり
  • 衝突回避
  • 距離はレンジエクステンダー(発電機を積む)もある
• Q: ドローンを飛ばすには何か資格が必要か?
• A: 免許はない。ルールはある。民法的には土地の所有者がダメといったらダメ。ざっくり200g未満、田舎で見える範囲で日の出から日没までなら自由といった感じ。

[2019-06-18 19:13]

• 水中ドローンの通信は有線。
• 回転(yaw)はおたがいに逆回転しているローターの回転数を変えるとできる。このため原理的にゆっくりとしか回転できない。

帰りにまだNHK撃退シールをくばってたのでもらって帰ってきた。

• 告知: https://iijlab-seminars.connpass.com/event/130579/
• 話者: 鹿野桂一郎（ラムダノート株式会社 代表取締役社長）
• 日時: 2019-05-12 18:00〜19:00
• 会場: IIJ飯田橋13F
• 資料: 狭義のTeXと広義のTeX、それぞれの進化

午前中は酷い雨だったけど夕方にはやんでくれた。

[2019-05-21 18:01]

• 日本人の知らないTeX/八登崇之 at TeXユーザの集い2010 を読む前提知識を提供するかんじで。
• クヌースがつくったTeXはもうつかわれてない。つかってるのはクヌースだけ。
• XeTeXはジーテックとよむ。
• LaTeXはいじらない方針だったけどTeX Live 2015からは変えていく方針になった。
• TeXのレイヤー: 文章を入力する人/文章を組版する人/仕組みを開発する人
• webに対応させると HTML/CSS/JS
• いきなりマクロ言語のところをいじるのは無謀
  • コアの部分をいじろうとしてハマるパターン
• 図を書けるようにした: TikZ/PGF
• LuaTeX: JSでDOMをいじるようなことがTeXでできる。
• XeTeX(2004),LuaTeX(2007)でUnicodeに対応した。それまでは8bit化されてただけ。
• pdfTeXにinputencパッケージでエンジンそのままでUTF-8(ただしグリフは255文字まで)対応してしまった。
• TeXは \foo というコマンドだけでなく文字もコマンンドとしてあつかえる。
• CJKパッケージもおなじ戦略だが文字が256文字におさまらないので256文字でサブフォントとして対応。
• フォントはコマンドできりかえる。
• tfm: 昔はフォントは印刷所にしかなかったり。フォントの概要だけを納めたファイル。
• コミックだと漢字はゴシック、ひらがなは明朝だったり、フォントをくみあわせる需要がある。
• DVIもフォントを仮想化する -> VF
• NFSS: LaTeXにおける抽象化: encoding,family,series,shape,size
• fontenc
• フォントの設定だけで4つもファイルを用意する必要がある。
• システムフォントをつかいたかった -> XeTeX
• 日本語ならBXjsclsパッケージをつかうとすべてそろう。
• pxchfonというパッケージをつかうとDVIをハックしてフォントがえらべるようになる。

[2019-05-21 19:08]

• Q: uplatexじゃなくても日本語はつかえる?
• A: luatexでも日本語処理のパッケージがあるので使える状態になっている。
• Q: 若者育成は?
• A: 若い人もいる。ptexを開発している日本人は25歳。

[2019-05-21 19:11]

• 日時: 2019-01-22 18:00〜19:30
• 場所: IIJ 飯田橋 13F
• 発表: 河野健二
• 告知: https://iijlab-seminars.connpass.com/event/113660/
• 資料:
• 概要:

ロギングはバグを特定するための古典的な手法である．ログとして記録してお
くイベントの品質が，そのままデバッグの効率に直結する．それにもかかわら
ず，従来のロギングでは開発者の経験と勘に基づいて
1) ログを出力するコード上の場所(where to log) と
2) 記録しておくべき情報 (what to log)
をアドホックに決定している．そのため，デバッグ時に必要十分な情報が得ら
れるとは限らず，デバッグを困難なものとする一因となっている．
本発表では，ログの品質を改善する「ロギングコード自動挿入」に関する最近
の研究成果を紹介する．ログの自動挿入はここ数年にわたって活発に研究され
ており，システムソフトウェア研究のトピックのひとつとなっている．既存研
究を概観したのち，発表者等が研究・開発を進めているロギング・ツールK9
について紹介する．K9 はマルチスレッド環境におけるエラー伝播を対象とし
ており，共有データを介したスレッド間でのエラー伝播の追跡を可能とする．
共有データを介したエラー伝播が発生すると，障害を起こしたスレッドのコン
トロールフローを遡っても，障害の原因となったバグにたどり着けるとは限ら
ない．K9 ではそのようなエラー伝播の追跡を支援する．実際に，K9 をLinux
カーネルに適用し，既知のカーネル・バグ 3 種の追跡が可能であることを確
認した．さらに，Linux のファイルシステム保守中に遭遇した未知の障害にも
適用し，バグの特定に有益であることを確認した．

[2019-01-22 18:00]

• 障害が発生したら(教科書的には): 再現→調査→対策
• しかし:
  • そもそも再現がむつかしい。
  • 同じ実行環境が手にはいらない。
  • プライバシの観点からデータが手に入らない。
• かわりのログを送ってもらいログを調査する。
• しかし:
  • ログが膨大すぎて解析できない。
  • 肝心の手掛かりとなる情報がログにない。
• 経験と勘に基づいたロギングが原因。
  • システムコールのエラー。
  • 例外的な処理。
  • 気分で入れてるだけ。
  • windows SOSP 2009
  • printf, log4j, syslog event tracing for windows (ETW)
• 適切なログイングは難しい。
• 専門用語:
  • logging too little: ログが少なすぎる
  • logging too much (redundant&trivial): 冗長だったり、あたりまえの内容だったり。オーバヘッド・ストレージ使用量が問題になる。
• ロギングが研究テーマになったのは数年前から
  • 手動から自動へ
  • where to log?: どこに入れるか?
  • what to log?: どんな値を記録すればよいか?
  • what happend?: ログから障害発生の様子を自動抽出して障害の実行パスを類推する。
• Errlog [Yuan+ OSDI'12]
  • どこでログを入れるか、入れわすれたところに自動でログを入れる。
  • 例外処理:
    • 実際にはログを取り忘れるケースが多い。250件の障害事例を調査。
  • error()を呼んでたらエラー処理というような判定をする。error()を呼ぶ条件式を集めて、ログを入れ忘れているところに追加する。プログラマは無能ではない前提。
• SherLog [ASPLOS'10]
  • what happend? ログから実行パスを類推する。Sharはシャーロックホームズから。
• LogEnhancer[ASPLOS'11]
  • 実行パスが類推できるように変数の値をロギングする。
• K9ではLinuxをターゲットにした。
  • Linux as Infrastructure
  • Linuxは実用的・巨大・複雑なので、Linuxでつかえれば他のソフトでも使える。
• 用語:
  • fault: =bug 誤りのこと バグがあっても踏まないと発症しない
  • error: バグをふんでおかしくなった状態
  • error propagation: おかしな状態は伝搬する
  • failure: 障害発生(クラッシュ・ハングアップ)
• Palix:
  • Null: nullチェックもれ
  • Inull(Inconsistent null check): ポインタ参照(deref)したあとにnullチェック(意味がない)
  • Block: ブロックしてはいけないコンテキストでブロックする関数をよぶ
• linuxにはだいたいいつでも700個くらいバグが残っている。
  • バグをつぶしても同じくらいバグが入ってくる。
  • 1行あたりのバグは減っている。
• 簡単なバグだけではない
  • 関数にまたいだ問題
  • 割り込み(非同期)
• Inter-thread error propagation
  • 例
    • Btrfsでworker threadが例外時にdirtyフラグを落すのを忘れて
    • sync threadがBUG()を踏む
  • direct propagation: スレッド1が共有データを更新して、スレッド2が読む。
  • indirect propagation: スレッド1が共有データを更新して、スレッド2が読んで別の共有データを更新して、スレッド3が読む。
• K9ではエラー伝搬を解析できるようにログを入れるが、linux規模のソフトでは正攻法は無理。
  • オーバヘッドを押える
  • 静的解析はしない
  • ポインタ解析はしない (やっても正確には分からないことが証明されている)
  • coding traditionを仮定して共有データをさがす。
    • 共有データはヒープに置かれる。
    • 共有データは構造体になっている。
      • そのなかのポインタ配列やリスト構造をみる。
      • リンクリストなどのデータ構造用のライブラリにも対応(対応しないとデータ構造を操作するだけの関数がログに出て呼び出し元が分からない)
  • indirect propagationはデータフローは追い掛けずに型レベルで推測する。
• ファイルシステムにはバグが多いという論文がある and Btrfsは新しいファイルシステムなのでバグが多く残っているのでは? and 研究室の学生がBtrfsのメンテナ
• Btrfsで未知のバグをK9で追い掛けた原因をつきとめられた (実証)
• K9のオーバヘッドは、スループットで1.83%(平均)、CPU利用率で0.32%(平均)。
• たまにスループットのオーバヘッドが少ないという論文があってもCPU使用率が高いケースがある。その場合はCPUに余裕がないとスループットが悪くなる。

[2019-01-22 19:16]

QA

• Q: ログを入れたのはファイルシステムだけ?
• A: yes。だがファイルシステムのコードから呼ばれている関数にもログが入っている。スケジューラとかメモリ管理とか。これら(sched,mem)にはバグが少ないという研究報告がある。クリティカルセクション内でログを吐かないようにすることで、よりオーバヘッドを減らせる余地がある。
• Q: ロックには注目しないのか?
• A: ロックの範囲を調べるのが簡単ではないのと、ロックが保護している変数を見つけるのも難しい。ロックもれがあった場合に困る。やってみたが良くなかった。
• Q: K9の論文は公開されているか?
• A: 投稿中。
• Q: オープンソースにするのか? それとも企業に買収されるのを期待しているのか?
• A: 日立との共同研究なので日立が買う可能性はあるが、オープンソースにする予定になっている。
• Q: C以外の言語でもつかえるか?
• A: LLVMの中間言語で解析しているので、言語に特化したものでなければいけるはず。

[2019-01-22 19:24]

関連資料?

• Linux のバグから学ぶ 〜バグのフィールド調査からコード検査器の実現まで〜
• ログの自動挿入によるスレッド間のデータ依存関係の追跡

• 告知
• 2016-12-26 18:00〜19:00 IIJ飯田橋
  • opera2
  • 会場への道のり

[2016-12-26 17:59]

講師 本多倫夫氏 登場

[2016-12-26 18:03]

PASTE: Network Stacks Must Integrate with NMVM Abstructions

• NVMMs: non-volatile main memories
• persistent
• byte-addressable
• low latency: 10s-1000s o ns (お値段による)
• ファイル名が永続化するためのしくみ、とも考えられる。
• direct mmap()-ed files
• data structureが変ったらネットワークスタックはどう変るか?
• case study: WAL(write ahead logging)
  • B-tree(メタデータ)のアップデートは時間がかかるので一旦logに書いてclientにackを返す。
  • データの流れ: client -> server: nic->dram->networkstack->(read)->app->(write/fsync,memcpy/msync)->storagestack->storage->..
  • 実験:
    • NVMe: 2000us。ネットワークはやれることはない。ストレージで律速。
    • NVMM: 42usくらいでおわる。ネットワークでやれることがある。
  • 実際には並列アクセスされるのでNVMMをつかっても(ネットワークだけストレージなしの時よりも)スループット/レイテンシは落ちる。
  • NVMMつかっても、まだまだ永続化するコストがある → メモリコピーによるキャッシュミス
    • rx_buf→app_bufのコピーはapp_bufが固定なので(キャッシュヒットして)コストは安い。
    • app_buf→log_file(NVMM)は毎回違う場所になるのでキャッシュミスしてコスト高い。
    • DDIOがあるのでNIC受信はLLC(last level cache)にいきなりヒットするのでキャッシュミスがすくない。
    • kernel内のmemcpyはユーザ空間のmemcpyに比べて最適化されてない?のでキャッシュミスが多くなる。
  • 受信バッファ(in kernel)をNVMMに置けば解決。/mnt/nvmm/pktbufs とか。ログは /mnt/nvmm/appmd (アプリメタデータ) に。
• FAST Logging with PASTE
  • NICがrecvした段階ではLLCに乗っているだけでflush(clflush)してはじめて永続化する。
  • clflushはキャッシュライン単位でフラッシュする。msyncはページ単位。
  • データはNVMMのポインタをコピーすることでmemcpy回避(コピーするのはメタデータだけにする)。
  • netmapを改造して実装。 pkg-gen -i eth1@/mnt/pmem/bufs -f rx
  • tcp/ipはstackmapをつかっている(先行研究)。
  • ざっくり thruput 10%up, latency 40%up した。
• 関連研究:
  • NVMM関係ないネットワークスタック(高速ネットワーク)
  • NVMMつかったファイルシステム(高速ファイルシステム)
  • NVMMだけどRDMAつかってネットワークスタック関係ない(HPC系)
• まとめ:
  • RDMAはどこでもつかえるわけじゃない!
  • 単体で改善するだけでは十分じゃない!

[2016-12-26 18:31]

• Q: clflushをlazyにできるときもあるとおもうが
• A: writeのlatencyが長いNVMM(3dxpointとか)もあるので、アプリがLLCをflushするかどうか決めるようにしている。トランザクションの永続化要求はアプリによってちがう。multi-coreのときにスケールしないかもしれないのはfuture work.
• Q: いま売られているものと今後でてくるものはちがってくるとおもうが、どうなる?
• A: いま売られているのはbattery-backupedで速いやつなので、3dxpointみたいな遅めのやつでは.. 研究者はfpgaでemulatorかdramで実験している。
• Q: フラグメントしない?
• A: ほんとうに保存(リングバッファから別の領域に?)しおわってはじめて回収できるようになる。netmapでdouble bufferingがあるので穴あきもんだいはok。

[2016-12-26 18:39]

Report on ACM HotNets 2016

• 90人くらいなので学内ワークショップなフレンドリーな雰囲気。
• frontier network: 辺境の地でのネットワーク
• MPTCPでマルチホームのときに他のISPにトラフィックをおしつけたり
• RDMAが流行り
• datacenterでマルチリンクのときにトポロジをどうするとか
• RDMAでpriority-basedだとデッドロックしちゃうのでどうしようとか

[2016-12-26 18:48]

• Q: もりあがってた話題は?
• A: 発表時間がかぎられているので、どの話題もそれほどもりあがらない。
• Q: 気になったのは?
• A: internet blockchain(BGP,DNSをやめようというやつ)がおもしろかった。
• Q: MPTCP ホットポテト問題? (ホットポテトってこれか?)
• A: ISP間の公平性の問題提起。appleがECNでREDやってるけどISPでもやるの?とか。

[2016-12-26 18:52]

• Q: ネットワークスタックをどうかえたい? pullupじゃなくて、とか。
• A: netmapはlinuxには絶対入らないし、freebsdにはNVMMがないし、アプリ専用のスタックをつくるのは懐疑的(カーネル内のプロトコルスタックは複雑なので触りたくない)。
  • FreeBSD: RAMとして見えるけどpageをどうみせるとかグルーの部分がぜんぜんない。そもそも人がいない...
• Q: RDMAきらい?
• A: LLCにRDMAする話はきかないし、あまり議論するつもりがない。(ちなみに会議にはHPC屋はいなかった)
• Q: DDIOは3種類: 1:ringbufだけ、2:メタデータも、3:ペイロードも。
• A: ペイロードありで実験している。

[2016-12-26 18:59]

飯田橋駅工事中で、西口に活気がない感じがした。

• http://iijlab-seminars.connpass.com/event/29827/
• スライド
• 日時: 2016-04-12 18:00〜19:00
• 場所: IIJ飯田橋 13F
• 話者: 田崎創(Hajime Tazaki)

• 動機
  • ネットワークシミュレータの研究をしていて、シミュレーションと実機とで二重にコードを持ちたくなかった。
  • Linuxのネットワークコードは618KLoCもある。
  • だからといってシミュレーションするときにLinuxをVMで動かすと遅い。
  • 新しいソフトを使うときにVMで検証してる?
    • マイクロソフトでさえ頻繁に検証するわけではない実態。
  • (一般的にいって)性能と利便性のトレードオフがある。
  • 問題はindirectで解決できるという名言。
• AnyKernel (NetBSDというOSのrump kernelみたいなもの)
  • clock,memory,scheduler,deviceIO(NIC,blockdev)だけがarchitecture dependで
  • その上にarch independentな層、さらにその上に(改造なしの)カーネルをもってくる。
  • カーネルの上にAPIを被せてアプリケーションはAPI経由でカーネルを利用する。
• やりかた
  • Arch independentな層を入れたり
  • 抽象的なCPU archを導入したり
• アプローチ
  • フルスクラッチ: mirage, includeos, seaster, mtcp
    • 性能的に有利
  • 移植: OSv, libuinet, sandstorm
    • 最新版への追従性に難
  • anykernel(移植ではなくそのままもってくる): NetBSD rump, UML, DrawBridge(マイクロソフト製,論文からするとおそらく)
    • カーネル資産をつかえる、最新版への追従性も良好
• LKL: Linux Kernel Library
  • https://github.com/lkl/linux
  • カーネルのライブラリ化
  • 2007年にルーマニアでスタート(rumpと同時期)
  • IOはいまどきのvertio
  • win32,linux,freebsdなどの上で動作
• DCE/LibOS
  • 2008年スタート
• LKL vs LibOS
  • LKLはpthreadでIRQ,kthread,timerを実装
  • LibOSは高位APIをpthreadで実装
• デバイスイタンフェース: TAP, DPDK, VDE
• wrapperの規模は2400LoC、CPU非依存
• ホストOSにはNT,POSIX,MacOS,Linuxがつかえる。
• LKL APIの種類:
  • (1) LKL syscall: ふつうのsyscallに相当: lkl_sys_hogehoge()
  • (2) Hijack Lib: LD_PRELOADでsocket()をlkl_sys_socket()に曲げたり. linux以外ではsyscall emulatorが必要になる
  • (3) extended(alternative)libc: musl(マスル)。 libcを拡張してアプリに機能を提供。
• アプリケーションの例
  • ns-3(ネットワークシミュレータ)
    • ns-3の中でLKLを読み込んでネットワークスタックを利用する。dlmopen
    • 実機とちがってタイミングが毎度同じなので再現率100% (仮想クロック使用時)
    • valgrindでデバッグできる。
  • 簡易カーネルバイパス
    • LD_PRELOAD=hogehoge-tcp.so firefox などとして、ホストカーネルとは異なるネットワークスタックをつかってみたり。
  • ext4読み書き
    • windows上でext4のディスクにアクセスする。
  • unikernel
    • 単一アプリにカーネルをリンクする、小さなゲストOS。rumpに似ている。
    • たとえばping6コマンドにLinuxを埋め込むなど。
    • たとえばarm-qemu上でゲストOSを起動しないでpingを実行するとか。(pingにOSがリンクされている)
    • 今日の発表もこれをつかっているらしい。
• 性能について (UDP 1000B)
  • native kernelがRTT/thruputともにベスト
  • DPDKはRTTがとんでもなく遅い。thruputも低い。
  • netmapとtapはthruputが低い
• Q:コストは?
• A: 初期化はふつうのカーネルよりも速い。デバイスの応答を待つ必要がないのと、不要なデバイス初期化をなくせるのとで。メモリフットプリントはとても大きい。おそらく実装の問題。らくらくGB越え。qemuでメモリサイズをGBにしないと動かない。
• Q: 改造量は?
• A: IRQ,threadなどだけをposixで実装して、他の下廻りはカーネルのコードをそのままつかっている。
• Q: 昔のSunのマシンがやっていたメモリリフレッシュとかはどうなるだろう?
• A: たぶんそのまま動く???
• Q: ns-3での再現性100%はほんとうか?
• A: パケットのキャプチャと再生はできるという意味ではyes。実行時のトレースはとっていないので、スレッドのインターリーブによる部分は再現できないだろう。
• Q: ext4の例はどのレイヤでやっている?
• A: ディスクイメージをLKLが解釈している。VFSはつかっていない(ホストOSのVFSのことか?)。
• Q: LKLのデバッグは?
• A: gdbでカーネルデバッグできる。
• archLinuxベースらしい。

• http://iijlab-seminars.connpass.com/event/26121
• http://www.iij-ii.co.jp/lab/seminars/index.html
• 佐藤雅明 (慶應義塾大学)
• 2016-02-12 18:00-19:00
• IIJ飯田橋 13F
• 資料: http://seminar-materials.iijlab.net/iijlab-seminar/iijlab-seminar-20160212.pdf

18:01

• 大学時代からずっと自動車とインターネットの研究をしている。
• DSRC:シンガポール ETCみたいなもの
• 10月にもどってきて日本で聞くキーワード: IoT,bitdata,AI → まさに自動車自動運転。周期でいえば日本は真夏の次期にきている!
• ITS: 行動道路交通システム。車両・道路・人をITでつなぐ。
• 車には300以上のセンサーがある
• アメリカでは車はweareable computingととらえる人もいる。
• プローブ情報システム: 渋滞(GPSと速度)とか、ABSでヒヤリハット、ワイパーで天候情報とか。 (～2000年くらいまで)
• VICSの補完のためにあるのかという質問をよく受けた。
• 車をインターネットにノードとしてつなぐというコンセプトがわかってもらえなった。
• ABS動作情報: 温度もあわせて凍結路面とか。 複数メーカーでも動くように国際標準をめさして。
• ABSの情報は自動車メーカーは出したくない。でもABSのwarningランプ情報は出してくれることになった。
• スバルはOBD2につなぐ車載機をつくってくれた。
• 実証実験は秋田大学と北海道大学で(雪がふるところで)
• 3.11で通れた道マップ。
• 携帯電話にたよっていたが大規模災害で動かない(停電等)ところもあった→車車間通信も必要。
• 保険でもつかわれている。運転距離ではなくマイルドな運転をしているかどうかで保険料を決められるメリット。
• 運転手からしても見られているとおもうとていねいな運転になる。
• カーテレマティクス系: 自動車メーカー主導。
• ETC2.0: 一定間隔でプローブ情報をなげている。渋滞で迂回路とおっても事故で一般道におりても料金同じになる。
• 海外では自動車メーカーはやっておらずプラットフォーム系がほとんど。ノキアのHereとTomTom HD traffic。

• KEIO-NUS CUTE Center
• シンガポールは世界一車が高い1000万円くらい。(日本だと200-300万円)
• 慢性的な渋滞が社会問題になっていた→一般道のロードプライシング(ALS,ERP)
• ERPの特徴: フリーフロー(ゲートがない)、 mandatory(必須)。
• 駐車場料金にもつかわれている。
• 三菱重工が一社独占、メンテナンスでけっこうウハウハなのでは?
• ERP2: 車を増やしたい。GPSでエリアにはいると携帯網経由で決済。ガントリー不要。メンテ不要。時間で課金とか。
• 政府としては自動車ビッグデータのプラットホームにしたい狙い。車100%に塔載はインパクトがある。
• デジタルサイネージで実証実験した。
• 匿名化して民間に提供するのも考えている。

• safety(安全), productivity(移動中も自由にできる), efficiency(渋滞をなくす), accessibility(身体障害など)
  • automated driviing(自動運転): V2X 路車(ろしゃ)協調ITS, 日本ではただ1箇所 御台場に設置されている。
  • autonomous driving(自立運転): ドライバーレス。 ITSよりはロボット技術。 これには大きな飛躍が必要。
• "認知→判断→操作" の判断の部分が自動運転で重要になってくる。
• ジュネーブ条約/ウィーン協定: article 8ですべての自動車はドライバーをもつこと、ドライバーは操作できなければいないことが定められている。
• autonomous vehicleでもハンドルとブレーキがついてないとだめとの判決がある。
• AIに人格権をもたせる方向で話しが進むかも(AIがドライバーとの判断. NHTSA)。 (今日のトップニュース!)
• 今後の問題:自動運転する車が流れに入ってくることで事故を誘発してしまわないか?
• 標準化活動： ITS2404? プライバシーが重要。 どこをは走っていたとか知られたくない。
• 自動車メーカーの中でもAPIを切ってオープンにしていくトレンド。
• ISOだけでなくW3C(業界団体)でも標準化
• オープンプラットホーム化がトレンド。秩序あるオープンプラットホーム化。
• パーソナルデータの扱いが課題。

19:51

• Q: シンガポールで(ロードプライシングは)いくらかかる?
• A: $1,$2くらい($1=80円) 。エリアに入るたびに徴収されるのでタクシーには不評。エリアに出入りしなければ金はかからない。
• Q: 完全自動運転の技術的な障害はなにか?
• A: 限定されたエリアならなんとかできている。地続きで他の国に入れるようなヨーロッパではまだ難しい。(判断(AI)の部分)
  • これについてはグーグルが先行。リスクヘッジしているメーカは遅れがち。
  • センサーの死角を補うために路側からのデータが必要。今は車載センサーだけ。
• Q: 使うのはインターネットなのか閉域網なのか？
• A: いまは併用。ITS用の基盤がある(専用の無線帯域とか)。
  • ITSconnectは760MHzだが、海外ではケータイ用の帯域。
  • 5Gでは車車間通信もターゲットにしているので、どうなるか
  • 国の方針とITUの割り当てと。
• Q:
• A: ERPはゲートで。ERP2はゲート不要でGPSで位置情報3Gで。
  • DSRC: 車載機が(不正改造などで)動いていなかったら写真とられて罰金、という世界になる。
  • ERP2で路車間通信だけでなく車車間通信できるようになる。
• Q: LTEだとか公衆網だと信頼性・安全性はどうか?
• A: そこはDSRCで。(EPR2でケータイ会社は100万契約純増するウハウハ)

19:05

• 2015-07-21 17:30〜19:00
• http://iijlab-seminars.connpass.com/event/17374/
• http://www.iij-ii.co.jp/lab/seminars/
  • http://seminar-materials.iijlab.net/iijlab-seminar/iijlab-seminar-20150721.pdf
  • http://seminar-materials.iijlab.net/iijlab-seminar/iijlab-seminar-20150721-0.mp4
  • http://seminar-materials.iijlab.net/iijlab-seminar/iijlab-seminar-20150721-1.mp4
• 発表: IIJ-II 泉田大宗さん

• 3月までは産総研
• バイナリのマルウェアを研究対象にしていた
  • セキュリティではない
  • サンドボックスで実行してトレースをとるのが一般的。
  • でも特定の条件じゃないと動かないものはパスをすべて調べられない。

• 最低限、CPU/OS/エントリポイントがわかっている状況で調べる。
• CFG: 制御フローグラフ。ノードは中はジャンプ命令なしのグラフ。
• CFGがわかる→抽象実行・モデル検査できる。機械学習もできる。
• でもCFGをつくるのがむつかしい。
• 難しさ1
  • 間接ジャンプ(RET命令も含む)には値解析が必要だが、値解析にはCFGが必要。ジレンマ。
  • 一般的には静的決定不能。
• 難しさ2
  • CALL/RETが信用できない。
  • CALLはRETで戻ってくるとはかぎらない。スタックをいじられてしまうと。
  • 部分構造に切り出して問題を小さくして解くのが基本だが、それができない(どこが関数なのかわからない)。
  • →スタックといった抽象化をしないで単なるメモリアクセスとして解釈する。

• 展開形制御フロー解析
  • 静的解析(直接ジャンプと宛先のわかる間接ジャンプのみを追う)と動的解析(CFGを実行する。CFG静的解析できてないところかコード書き換えがあるまで)を交互に実施。
  • 静的解析必要ないのでは？→動的解析で通らなかったコードについてもある程度わかるので必要。
  • まず静的解析で広い範囲を調べてわからないところを動的解析する戦略。
  • 動的解析にはBochsとXen(Ether)の両方をつかっている。

• Win32/Rustok.Bの解析例:
  • ドロッパー: マルウェアをインストールするプログラム。
  • ノード： 253、エッジ: 284を20分で解析

• 静的解析
  • 直接ジャンプをたどってCFGをつくる
  • 各命令を代入文に変換
  • SSAに変換
  • 要求駆動型定数伝搬
    • Φ関数をつかう(複数のところからJMPでとびこんでくるときレジスタの値が一意に決まらないのを解決するのに)
    • 定数になるまでCFGをさかのぼって展開してゆく
    • 引き算が肝らしい

• Win32 APIの中身は解析しないでAPIブロックを作成。(マルウェアの解析が目的なので)

• 文字列解析
  • GetProcAddress(module,procname)みたいなやつを静的解析できる

• ループは静的解析できない。

• 動的実行
  • Bochs-python + Ether(Xen)
  • シングルステップ実行
  • ブレークポイント
  • 書き込み検知
  • ステルス性(マルウェアに検出されないように)

• Bochs-python
  • bochsデバッガインタフェースをフックしてpythonからコントロール

• Ether
  • Xen3.1ベースにイントロスペクションツール
  • SYSENTERでシステムコールをトレースし
  • ページフォールトでブレークポイント
  • シングルステップ実行にはTFを使用

• Drakvuf/Libvmi
  • Etherは古いので
  • エージェントがなくてもよい

[2015-07-21 18:29]

Q: 動的解析・静的解析が無限に続いて終らない可能性は？

A: 動的解析にはタイムアウトが必要。

Q: C++のような間接ジャンプのあらしだとおもうが？

A: いちおうできている。

Q: マルウェア以外の用途は？

A: コンパイラの素性がわかっていればヒューリステックがつかえる。組込系でハンドアセンブルしたものとかBIOSとかのバッファオーバーフローの解析とか。

Q: 例外ハンドラで書き換えとか

A: 今は動的解析で対応している

Q: コードインジェクションは？

A: スレッドインジェクション(IE)は実験している。

Q: 開発言語は?

A: Pythonで。インタフェースはCで。メモリは喰うが測ってはない。マルウェアはペイロードが小さい前提がある。同じ計算を何度もしないようにキャッシュしているのでメモリが増えてゆく。

Q: 静的解析でいくつか候補を上げておいて動的解析で絞る方法にしないのは？

A: できるだけ抽象度を上げないで発散しないようにしている。

[2015-07-21 18:40]

• 日時: 2015-04-09 17:30〜19:00
• 会場: IIJ飯田橋 13F Opera2会議室
• 告知: http://www.iij-ii.co.jp/lab/seminars/index.html
• まとめ: http://togetter.com/li/806328

ネクタイしている人がいないようなので,いきなり技術的な話でokらしい。

[2015-04-09 17:31]

Networking Operating System from Scratch towards High-Performance COTS Network Facilities

浅井大史 Hirochika Asai (東京大学)

• BSDとかのネットワークスタックには贅肉がたくさんあってボトルネックがわかりにくいのでスクラッチで書くことにした。
• OSは趣味→ドクターのときに仕事化
• クラウドでコモディティ化→ネットワークがソフトウェア化している
• forwardingはハードで、routingはソフトで。
• NFV：仮想マシンをつかうのはオーバヘッドがあってチャレンジングだけど。
• OSとは?
  • リソースマネージメント
  • ネットワークは周辺機器から中心になってきた
• スクラッチのイイコト
  • ブラックボックスがない(ハードウェアの限界がわかる)
  • アルゴリズムやアーキテクチャの追求
• 汎用のCPUをつかう
• まずはフルルートをあつかえるルーターをつくってみよう
• VFSR: very fast software router
  • fast packet forwarding (専用チップをつかわずに)
  • fast ip routing table lookup (TCAMをつかわずに)
• Ethernetでの速いとはどのくらい？
  • 10GbE: 64B 14.88Mpps = 67.2ns/packet
  • 100GbEだとこれの1/10になる。つらい。
  • 40GbEくらはみえてきた。
• おそいのはなぜ？
  • CPU slow? mem copy? intr overhead?
  • CPUは0.3ns/cpu-cycle (3.3GHz)
  • memcpyは DDR3-1866 ならスループットはたりてる
  • 割り込み処理自体は重くない
• PCIeのNICはmemory mapped IO (MMIO)でレジスタアクセスする。
  • RAIDカードでは250ns/accessくらいかかると論文に書いてあった。
  • NICで測ってみたらread 392.1ns、write 72.47nsくらいかかった。
  • PMCで測った。100万回くりかえし。
  • RAIDでの値はreadとwriteの平均っぽい。
• Generic NIC arch
  • ring buffer→Descriptor→Buffer
  • ringバッファの大きさは2の羃とはかぎらないが、divは18cycleくらい。ちょっと最適化の余地。
  • 8個くらいまとめて書くと性能が出る
• readが遅いので read_txq_head() をなくした by Intel (XL710) write-backをつかうようになった。
  • check_wb_statuss()をつかうように
  • でも性能が出ない。。
  • ring bufferは複数ある。RSS
  • 40G line rateが出ないのはしかたがない(XL710) by Intelさん
• ポーリングはレイテンシが伸びるといわれているが全力でやれば10us以下になる。(大型のルータよりは速いくらい)(小型のには負ける)
  • テスターで送信してソフトルータでおりかえしてテスターにもどってくる。
  • 全力ポーリングなので電気を喰うけど。
• CPUのレジスタが増えた(15個)ので割り込みで退避のコストがふえた。push/popはスループット1→30 CPU cycle.
  • レジスタはmust preserveかfreeのどちらかしかない。ABIを変えるしかない。。
  • コアをふやすといけるのは割り込みハンドラのコストがならされるからか？
• PCIのMMIOが遅い→バルク処理しよう。
• 割り込みハンドラの処理が無視できない→ポーリング
• ルーティング: longest prefix match
  • binary radix treeで実現すると深くなったときに遅い+ポインタたどるのおそい
  • 深さを減らすのにmulti arrayのtriにした。メモリへらした。
  • 800k lookupできるようなった。
• socket APIをなんとかしようということもやっている。
  • 低レイヤーのプログラミングをしなくてもsocketでルータをつくれるように。
  • SOCK_DGRAM + IPPROTO_ETHERNETとか

[2015-04-09 18:16]

Q: OSのはなしはいつごろきける？

A: 半年後くらい？

Q: MACアドレスをバインドするのは？

A: 仮想NICを開くかんじ。2つひらくとルーターに。

Q: ハード割り込みを軽くするだけじゃなだめ？

A: 単純な処理しかしないのに、お決まりの処理が重い。

[2015-04-09 18:20]

[2015-04-09 18:20]

Seastar: 高スループットなサーバアプリケーションの為の新しいフレームワーク

浅田拓也 (Cloudius Systems)

• シースター
• Cloudius: OSvをつくっているベンチャー企業
• Avi Kivity: CTO, KVMをつくったひと.
• seastar: NoSQL, memcachedなどサーバアプリを速くしたい。
  • OSvの経験からAPIを変えずに高速化するのは困難。
  • OSvでも動くが、メインターゲットはlinux.
  • コアがたくさんある、コアの性能は上がらない、NIC/SSDはどんどん速くなっている。
• 既存のネットワークスタックの問題
  • 共有データがあるので操作コストが大きい。NUMAの場合はCPUからmemが遠いとさらに遅くなる。
  • socket APIの構造的な問題。
• Seaster
  • shared nothingプログラミングモデルに。
  • CPU間はメッセージパッシング
  • DPDKでカーネルをバイパス
  • no thread(1thread/core), no context sw, no locking.
• カーネルバイパスの必要性
  • socket APIだとzerocopyがやりにくい(もしくは困難)
  • プロセス処理とアプリが同じコアで実行できずキャッシュコヒーレンシで遅くなったり
  • プロトコル処理のところのロック競合したり
    • ユーザランドとカーネルのきりかえオーバヘッド
• DPDK
  • intelが中心になって、フレームワーク
  • スレッドはpinされる
  • メモリアロケートも独自。かつhugetlbfsで2MB単位でページをとる。
  • NICはパススルーデバイス経由で直接mmapしてたたく。
  • ポーリング。(最近は割り込みもつかえるようになったらしい)
  • ネットワークスタックは持たない(DPDKの上でやること)
  • アプリにはmbufがとどいたようにみえる。
• seastarはDPDKの上のネットワークスタック
  • ネットワークIOでシステムコールをつかう必要なし。
  • socket API非互換
  • 対応プロトコル: TCPv4, UDPv4, IPv4,ARP,DHCP
  • packet forwarding用途は考えてない。。。
  • C++14, Future/Promise/Continuationモデルによる非同期API
    • これらをつかってスケジューラを実装。
    • std::のfutureとは別物で独自実装。(汎用じゃなくてよいので： ロックしない、メモリアロケートしない、continuationサポート)
• C++のlambda式をはじめて見た人は? → 会場の3分の1くらい？
• Future/Continuation: lambda式で完了時のcallbackを指定する感じ?
• zero copy RX
  • ドライバからのページが直接みえてるが、scatter-gatherは自動でおこなわれる。
• zero copy TX
  • TCP windowが開くのを待つfutureとバッファが空くのを待つfutureの2つをつかう。
• class distributed をつかって複数CPUで実行できる。(threadはpinされる)
  • app.startではcpu0で実行れている。
• CPU間通信
  • smp::submit_to(neighbor, [key]{return xxx[key]} でneighbor上でreturn xxx[key]が実行される。
• ポインタはスマートポインタも含めて使わない。std::move()をつかえ。
• seastartのスケジューラ
  • future/promiseがキューに積まれて、条件が成立したらlambdaが呼ばれる。
  • CPU間でキューが融通されることはない。
  • userland threadとの違いはコンテキスト切り替えがないこと。
• RSSが使えない環境では1CPUでハッシュ値を計算して分散させるのにも対応。
• malloc/free/realloc/memalign/new/deleteはフックして独自実装。
• TCPのコネクションの状態はどう管理する?
  • 同一コネクションのパケットは同一CPUに来るようにしているのでTCP stateを共有する必要はない。
  • ハッシュ値計算はNICがやってくれる。
  • 知らないパケットが届いたらRST。
• memcachedのaddの実装例
  • addとgetが別CPUになると困る→addのときにsubmit_toで他のCPUに複製しちゃう戦略で解決。(NCPU重複だが共有するよりはまし？)
• seaster API
  • future/promise/continuation
  • network IO
  • file IO
  • timer
  • HTTP(for server only?)
  • JSON(swagger)
  • RPC (よくわかんね)
  • POSIX API wrapper
  • collectd client (logging daemon)
• ネットワークバックエントでつかえるもの： DPDK,vhostnet,Xen(OSv),socket
• DPDK on OSvを実装中 (SR-IOVが対応してるので)
• OSvがベアメタル上で動くようになるかも？
• memcachedベンチマーク
  • seastar: リニアに性能が出ている(20コア)
  • stock: マルチスレッド版はスケールしてない。(マルチプロセスの方がまし)
• 他のDPDK向けのネットワークスタック
  • apiは従来どおりで、ほぼsocket apiとおもわれる。
  • 既存アプリとの互換性は高いとおもわれる。
• 多言語対応
  • スクリプト言語に対応しても意味なさげ
  • 議論はしているが作業はしてない。募集中。golang?

[2015-04-09 19:26]

Q: SMPのキャッシュコヒーレンシはどうしてる？

A: あとで調べてみる

Q: RSSでフラグメントしてたら？

A: NICのoffloadにたよればたぶんok。

Q: 保護違反したときの対応はどう？

A: 実運用では切り離しするなど対応が必要だろう。

Q: div0したら

A: プロセスが死ぬだけ

[2015-04-09 19:33]

久し振りに首藤さんに会った。懇親会に行くかラーメン食って帰るか悩んでた。