回線遅延シミュレータ：EthdelayPro：動作精度UP！：連係プレーのすばらしさ

回線遅延シミュレータ：EthdelayProのお客さんからのご指摘で、「遅延の精度をもう少し良くできないか？」というお問い合わせをいただいていた点の検討をしてみました。こういう仕事の当社ならではの流れを交えてご紹介しましょう。

EthdelayProのエンジン部分は私が開発したものなので、まず私が改めて測定し直しました。EthdelayProには測定機能もあるので、1台で測定することもできますが、今回の場合はもう少し厳密に遅延機能自体の精度を測りたかったので、贅沢にEthdelayProを2台使って測定しました。

まあ、わかっていたのですが、確かにバラツキはありました。。

遅延設定：なし

遅延設定：4ms

遅延設定：10ms

元々Ethdelay、EthdelayProはLinuxをほぼ標準状態のまま使って実現することにより、トータルでコストダウンと汎用性を実現していますので、高性能で高価な専用ハードを使った製品のような精度は求めていませんでした。グラフで見るとバラツキが目立ちますが、実際はミリ秒の世界ですし、Ethdelayの主な用途としては悪い回線のシミュレーションなので多少ばらついても問題ないという考えでした。

とはいえ、もう少し何とかしてみようかと、ソースを眺めていると、お客さんからのお問い合わせをメーリングリストで見たメンバーからメールがきました。打ち合わせなどで社外にいたメンバーからでも、iPhoneのおかげですぐにメールがきます。

「ネットワークドライバの割り込みパラメータとかを変更すると安定することもありますよ。」
「スレッドの優先度を調整してみては？」

という感じです。私はソースを見ながら、

「そういうレベル以前に、受信スレッドと送信スレッドでバッファの排他を行っているのと、バッファが空の場合にマイクロ秒でウエイトを入れているのがまずいんだよね。」

という感じに応答しました。すると、

「そういうパターンなら、pthread_cond_wait()を使ってうまく行ったケースがありますよ。」

ということで、その部分のサンプルソースももらいました。

「おぉ、これならいけるかも！」ということで、早速組み込んで実験してみると、おおむね良い感じですが、いくつか問題のあるパターンも見つけ、そのあたりを試行錯誤しながら調整し、どのパターンでも問題ない状態にして再度測定してみると・・・

遅延設定：なし

遅延設定：4ms

遅延設定：10ms

見事に！！バラツキが収まりました！この間（一通りの機能確認も含めて）、私も他の仕事をしながら約2時間半です。

一通り確認も終えたので、これから更新ファームを用意して公開し、ユーザの皆様にはアップグレードできる状態にする感じになります。明日にはEthdelay、EthdelayPro共に公開できるでしょう。

この連携とスピードが当社の強みです。ネットワークプログラミングをバリバリやっているメンバー同士の連携はもちろん、すぐ側にWEBやDBなど様々な分野のプロが揃っています。できるだけ自社で開発作業をするために、常駐の仕事は避けている理由はここにあります。一人でカバーできる範囲は広くても深くはならないものですし、技術的に試行錯誤しながら開発を進めていると、視野が狭くなってしまっていることも多く、他のメンバーからちょっとしたアドバイスをもらうだけで壁を越えられることも多いのです。やっぱりそれぞれの得意分野を活かしあうからこそ、良いものが素早く作れるのです。

ということで、製品はお客さんが増えれば増えるほどよくなるということと、メンバーの連携によって、まだまだ進化できますし、幅も広がるという話題でした。Ethdelay以外の製品も、それぞれたくさんの要望をいただいていて、どんどん機能向上に取り組んでいるところです！