利用者からの質問と回答（その２）
利用者から、KeyHoleTVが停止するとの質問を受ける。 KeyHoleTVは、UDP/IPで通信を行っているので、利用者の環境によっては、パケットが欠落する場合がある。 以前から、このような質問が届いており、その解決方法を探るため、利用者には、負担であったが、通信のテストをしてもらった。
Windows、MacやLinuxには、通信を測定できるコマンドがある。Windowsでは、コマンドプロンプトを起動する。 コマンドプロンプトは、 スタートメニュー＞全てのプログラムー＞アクセサリにある。 Macでは、ターミナルを起動する。ターミナルは、アプリケーションー＞ユーティリティにある。 Linuxでは、端末を起動する。
コマンドプロンプト、ターミナル、端末は、コマンドを入力して、エンターキーもしくはリターンキーをヒットすると、入力したコマンドを実行する。 通信を測定できるコマンドは、 ping で、WindowsとMac/Linuxと引数の形式が異なるが、通信状態を調べることができる。
ping コマンドは、引数に対象のサーバ指定する。
- www.sinet.ad.jp上記にサイトには、以下のサーバが掲載されている。
- ping-hokkaido.sinet.ad.jp
- ping-iwate.sinet.ad.jp
- ping-tokyo.sinet.ad.jp
- ping-toyama.sinet.ad.jp
- ping-mie.sinet.ad.jp
- ping-osaka.sinet.ad.jp
- ping-yamaguchi.sinet.ad.jp
- ping-kochi.sinet.ad.jp
- ping-oita.sinet.ad.jp
- ping-okinawa.sinet.ad.jp
これらの、サーバに対してping を行えば、日本との通信速度が分かる。 往復の通信速度を30回計測するのであれば、 Windows では -n 30 とし、MacやLinux では、-c 30 とする。
ping コマンドの使い方は、以下に詳しい
開発者のPCからのLinux でのping の結果
| $ ping -c 30 ping-tokyo.sinet.ad.jp PING ping-tokyo.sinet.ad.jp (150.100.208.3) 56(84) bytes of data. 64 bytes from 150.100.208.3: icmp_seq=1 ttl=46 time=115 ms 64 bytes from 150.100.208.3: icmp_seq=2 ttl=46 time=116 ms 64 bytes from 150.100.208.3: icmp_seq=3 ttl=46 time=115 ms ... --- ping-tokyo.sinet.ad.jp ping statistics --- 30 packets transmitted, 30 received, 0% packet loss, time 29032ms rtt min/avg/max/mdev = 114.793/115.637/118.426/0.750 ms |
多くの利用者からの結果では、パケットロスがあり、応答時間がばらばらになるとのこと。
なんらかの通信が利用者の環境から発信・受信されており、インターネットの通信を逼迫していると分かる。 それで、利用者にネットワーク環境を教えてもらうと、WiFiを利用しているとのこと。 おそらく、WiFI経由でなんらかの通信を行っていると考えられるので、ルータもしくは、ADSL、ケーブルまたは光モデムにMACアドレスフィルターの設置をお願いする。 すると、ほとんど利用者がKeyHoleTVの視聴に問題がなくなる。
なお、KeyHoleTVのダウンロード、プレミアムモジュールキーの販売は、
で。
YouTUBEに検証動画をあげた（地デジの放送が、KeyHoleTVより遅いのは、どうしてか）
地デジの放送は、東京が主で放送された内容が、地方の中継局から流れる時、一旦デコードしてから、再びエンコードをするみたい。 その結果、0.5秒の遅延しかないKeyHoleTVの方が地デジより早くなる。
中継するたび、エンコード・デコードを行うと、複数の中継があれば、その分更に遅くなる可能性が高い。
もっとも、ワンセグでは、KeyHoleTVの方が、断然早い。
2020年にオリンピックが東京で開かれる。当然多くの外国人が訪れるはず。 彼らの携帯電話に、緊急速報は、流れるのか。 KeyHoleTVであれば、アンドロイド端末であれば、誰でもインストールできて視聴できる。
そろそろ、日本だけの仕様というのも止めた方が良いのではないかと考える。
なお、KeyHoleTVのダウンロード、プレミアムモジュールキーの販売は、
で。
KeyHoleTV 開発者への質問と回答（その１）
利用者から、質問メールがきた。 Linux 上でのKeyHoleTVがCPU率１００％になるとのこと。 こちらの開発環境 Ubuntu 14.04 と CentOS 7 で実測したところ、CPU使用率は、10％から20％。 利用者の環境は、Fredra であるそうな。
Ubutnu での実測結果 この時は、CPU使用率は10％
CentOS7での実測結果 この時は、CPU使用率は、6.7%
CPU使用率が100％になる現象は、過去Ubuntu でもあった。原因は、usleepだった。この時は、Ubuntuのシステムコールの実装で、usleep がCPU割り込みを利用しないで、ループカウンタで、タイミングを取っていたため、CPUが休まるはずもなく、100％になっていた。 この時の解決方法は、select システムコールので、標準入力をfd_set して、タイムアウトを入れて、解決した。
しかし、その後、Ubuntu がアップデートされ、POSIXに準じたシステムコールに変更され、KeyHoleTVでは、nanosleep システムコールで対応した。Thread 中でCPUを休眠させるには、nanosleep を使うので、それに対応した。
しかし、Fredraでは、nanosleep がおそらくループカウンタで実装されているのであろう。どうしたものかと考え中。
なお、KeyHoleTVのダウンロード、プレミアムモジュールキーの販売は、
で。
