vol28. eclipse環境を構築する2

以下の記事の続き。

john-rama01.hatenablog.com

eclipse のdebug環境は、バックエンドにgdb を利用し、フロントエンドのGUIgdb
の結果を出力したり、アイコン操作をgdbの各種コマンドに紐づけているといった仕
組みになっている。

native 環境では、gdbのみを利用するが、クロス環境では、target でgdb serverを
走らせ、hostでクロス向けのgdb を走らせる。debug前にgdb server をtargetで自動
的に走らせるために、sshやtcf等を利用する。

本来やりたかった、eclipsewindows 上にインストールして、そこから仮想マシン
上で走るLinuxのアプリのデバッグやremote マシン上で走るアプリのデバッグでも、
クロス向けのgdbを準備する必要があり、これが一苦労だ。

ネット上で、自分の所望のクロス向けgdbを探してくるか、自分でgdbソースコード
をダウンロードし、windows上でビルドする必要がある。gdbのビルド環境として、
cygwinmingwといったwindows 環境向けのGNU開発環境を準備する必要がある。

結局、この手間を嫌い、eclipsewindows上で走らせるのは断念。
動きがもっさりするけど、vmware上のlinuxeclipseを走らせ、その画面をx
forwarding でwindows 環境に飛ばす手法をとることにした。

vol27. ssh 接続問題奮闘記

先日開発のサブPCとして、desktop PC を入手。
そこにLinux をインストールし、メインのLinuxからsshでログインして、サブPCを使用
する環境で作業をしてきた。サブで立ち上げたいGUIアプリは、X forwarding を利用
して、メインPCに飛ばす使い方だ。

ただ環境を構築してから、数日間、ssh connection が切れる問題についてずっと悩
まされてた。

write failed: Broken pipe  

のメッセージを残して、ssh 接続が切れる。

問題解決のために以下のことを実施した。

  1. google 先生に聞いてみると、 ssh サーバーやクライアントの設定で、
    以下をいじると直るとの投稿が多数あるため、試すも効かず。
    ServerAliveInterval
    ServerAliveMax
    ClientAliveInterval
    ClientAliveMax
    TCP keep alive

  2. ssh server 側の/var/log 下のログで、問題発生時に、更新のあったものを全て
    目を通したが怪しいものはない
    ssh client 側も debug オプションを最大にして(-vvv) 試すも、手がかりとな
    るメッセージはない

  3. ssh server 側のネットワークカードを違うもので試したが改善せず
    ハードウェアの問題ではなさそう。

  4. 問題発生時は、ssh server - client 間のping が一定時間(数秒) 繋がらず
    ただ、ssh connection をつないだ状態で、意図的にserver 側のnetwork
    interface をifconfig eth0 down で遮断しても、client 側では、
    ssh でつないだシェルが応答しないだけで、
    write failed: Broken Pipe とはならない。
    よって、何らかの理由でnetwork が一定時間遮断されても問題ないはず。
    そもそも、上記#1の設定がそのような状況に対応するためのものだ。

  5. 異なるssh client マシンで 試しても問題発生
    ssh client 側の問題ではないっぽい。

  6. 以下の投稿を発見。カーネルの問題があるかもしれないとか。
    私の環境では、ssh server にdebian stretch を使っており、
    kernel のversion は4.9.0.6。怪しい。
    https://unix.stackexchange.com/questions/259225/packet-write-wait-broken-pipe-even-leaving-top-running

    そこで、とあるnetwork キャプチャーソフトを使って、問題発生時のTCP port22
    のメッセージを観測していた所、Reset flag がセットされたTCP message が観測さ
    れた!! 上記ブログの通りだ。
    kernel のdriver の問題なのか? stretch で他に利用できるkernel がないか調べ
    たら、4.16.0があったのでそれで試したが、まだ問題発生。
    ダウングレードしないといけないか?

  7. そして、最後にnetwork switch を介さずssh server とclient で直接接続したら、
    !!!問題が発生しなくなった。すくなくとも一晩。
    Ethernet switch の問題?
    だが、違うEthenrnet switch を接続して試しても問題発生。

    うーむ。。。どういうことだ??

    結局今は、Ethernet switch を介さず直接接続で運用しています。

vol26. eclise環境(リモートデバック環境)を構築する1

私は現在、Linux base の組み込み機器を開発する仕事に従事している。

開発環境は、 windows PC 上に、仮想マシンを用意し、そこにlinux をインストール
して使用している。組み込み機器でソースコードをいじる部分は、linux device
driverやlinux 上のアプリ郡で、ほとんどシェル上で閉じた作業となる。

たまに、gstreamer のplugin といった複雑なアプリをデバッグする場合、GUI を用
いたデバッグをしたくなる。そこで、linux 上に、統合開発環境としてよく用いられ
ているeclipseをインストールしてみた。しかし、vmware 上でGUIを走らせるとGUI
ウインドウの描画に時間がかかるせいか、動きがもっさりとしてとても開発効率が悪
い。

そこでeclipsewindows 上にインストールして、そこからリモートデバッグ機能を
利用した環境を構築することにした。

この環境を構築しておけば、今後アプリのデバッグ効率も高まるはず。
後に、環境の構築方法や便利な設定を投稿していきたい。

vol25. apt-get install が遅い - DNS server 設定が原因

最近、開発用のマシンとして、Desktop PC を入手し、debian stretch をインストールし
た。すこぶる快適なのだが、1点、apt-get install がとても遅い。Network 速度が遅い
というわけではなく、実際にpackage をダウンロードし始めるまでに、数秒間待たされる
のだ。待たされた後、一瞬で、package をダウンロードし、インストールが完了する。

これは何かおかしい。。そう思い、簡単な試験を実施してみた。
すると、以下の事がわかった。

1. firefox でブラウザ開くときも遅い  
2. ping www.google.com がやたら遅い  
3. ping ipaddress は早い  

どうやら、host名の名前解決に時間がかかっているようだ。DNS server の設定がおかしい。

そこで、DNS resolver の設定ファイル(/etc/resolv.conf) をみてみると

domain ol.csi.178  
search ol.csi.178  
nameserver 68.87.xx.130  
nameserver 68.87.xx.134  

DNS server のIP address が二つ登録されている。
ping してみると、68.87.xx.134 からは反応があるが、.130 からは反応がない。
こいつが犯人だ。

応答のないDNS server の設定をコメントアウト、これで早くなった。

どうやら、最初のDNS serverで名前解決を試みるが、応答がなくtimeout。
その後、次のDNS server から応答を取得し、名前解決が完了
といったプロセスになっているようだ。

これで一件落着、と思いそのまま使用していると、再起動後、問題が再発生。
/etc/resolv.conf ファイルが元通りになっているではないか。
誰かが上書きしているみたい。

ググると、dhcp-client が設定を上書きするとの情報。
dhcp-client の設定ファイル(/etc/dhcp/dhclient.conf)を変更

domain-name-servers, dhcp6.name-servers を取り除く  

これで問題解決

vol24. セーラー服

友人との会話で、祖先がセーラーという話題になった。セーラーと言えば、日本では女子
中学生や女子高生の制服が連想される。

f:id:john-rama01:20180419073225j:plain:w300f:id:john-rama01:20180419073237j:plain:w300

セーラー服(sailer)は、その名の通り、海軍において、水兵の切る軍服が由来である。特
徴的な大きな襟は、襟を立てて海の上での集音力を高めるためとか。

そのような軍服がなぜ日本の女子中高生の制服に採用されたの?
ふと疑問に思ったのでその由来を調べてみた。

  • セーラー服は、18世紀に、ヨーロッパの貴族にもてはやされ、子供服として定着
  • イギリス海軍は1857年にセーラー服を制服として採用
  • 日本海軍でも1872年には取りいれられ、現在も自衛隊の水夫の制服として存続
    イギリス海軍を真似て、日本海軍がセーラー服を導入したのが、日本におけるセーラー
    服の歴史の始まり。
  • 1920年(大正9年)に京都の(現)平安女学院が採用したのが女子中高生の制服とし
    ては最初
  • その後、女子用学校制服としてセーラー服は次々と採用されるようになっていった

最近ではブレザーが増えてきて、セーラ服を採用する学校がだいぶ減っているとか。
日本の文化の一つとして大切にしてもらいたいなぁ。

vol23. RTPとは

いまさらだけど、RTPってどういう仕組みで低遅延を実現しているの?とふと疑問におもったので、調べてみた。 結論からいうと、低遅延という観点では、結局下位のレイヤーにUDPを使っているだけ。 Ethernet AVBのような、帯域幅の予約やVLANをつかったパケット優先は使用していない。 RTCP経由でRTTやパケットロス率の情報を受け取り、それを元にメディアの品質を調整したりする規格だ。 以下、まとめ。

  • 概要

  • RTPの役割

    • 動画配信といったマルチメディア通信では、低遅延が求められる
    • 低遅延を実現するために、再送処理のないUDPが使用される
    • UDPは以下の機能しかない
      • UDP
        • ポート番号による通信の識別
        • CRCチェック
    • マルチメディア通信に必要な次の機能はRTPが担う
      • パケット化
      • パケット転送時の遅延、ゆらぎへの対策
      • パケット廃棄への対策
      • ビデオ、オーディオ間同期
  • 流れ

    • クライアントは、実行帯域幅や遅延時間をRTCPによってサーバーに送出
    • サーバーはRTCPによって報告された情報に応じて、RTPで送信するデータの品質
      を調整する。
  • RTPで送る情報
    http://www.geekpage.jp/technology/rtp/rtp.php

    • ペイロード
    • 送受信間及びデータ内での同期クロック情報
      • タイムスタンプ
      • SSRC (Synchronization Source)
        • 送信者識別子
      • CSRC (Contributing Source)リスト
        • ペイロードが複数のメディアストリームの合成である場合、
          書くメディアストリームのSSRCのリストがCSRCリストとして格納される
    • 順序番号
    • データタイプ
  • RTCPの役割

    • 最小限の送達確認や監視をおこなうための制御プロトコル
      • パケットロス
      • RTT(Round Trip Time) 情報をRTCPで取得する
    • 各メディアストリームの通信品質制御
    • 複数メディアストリームの同期制御
    • セッションのメンバシップ管理

    • 5種類のパケット

      • 受信レポート
        • ストリーム受信者が発行する
        • 欠落率、累積欠落パケット数、パケット間隔ジッタ等、最新送信レポートのタ
          イムスタンプと経過時間(送信者は、この情報よりRTTを計算できる。)
      • 送信レポート
        • 送信者の情報
          • 受信者がメディアストリームのレートなどを推測することができる
          • オーディオ、ビデオの同期する際に利用
            • タイムスタンプ、パケットカウント
      • ソース記述
        • 参加者の識別に利用
          • 名前、場所、メールアドレス、電話番号
      • メンバシップ管理
        • 参加者の離脱の伝達等
      • アプリケーション定義
        • アプリケーションでの拡張用
  • その他

    • RTP(偶数のポート番号), RTCP(RTPのポート番号+1)という制約が以前はあった。
    • プライオリティの仕組みはないので、帯域が足りないと遅延する
    • RTSP
      • ビデオやオーディオの再生、停止、早送り、巻き戻し機能を提供するプロトコル
      • TCPの上位
      • SDPの下位
        • Session Description Protocol
  • 参考
    https://vcbook.vtv.co.jp/pages/viewpage.action?pageId=721018
    http://www.ieice-hbkb.org/files/03/03gun_04hen_05.pdf

vol22. アメリカでITINを取得する

米国での居住者は、毎年Tax Return (確定申告のこと)を個々人で申請しなければな
らない。H1Bビザの同行者は、H4ビザで米国に滞在することになるが、H4ビザは労働
資格がないので、SSNは取得できない。そこで、H4ビサ保持者のような、SSNを取得で
きない人は、納税用の個人識別番号として、ITIN(Individual Taxpayer
Identification Number)を取得する必要がある。