これはなんという孔明

今日に日付が変わってからシミュレーションの検証を行っていたのですが、何か雰囲気が
怪しい感じです。

今でのノイズモデルから変更をかましたのですが、性能が一部悪化しています。
しかし、以前まで使用していたモデルを自分で変更したものと3〜5%の誤差しか
配送率に及ぼす影響差はありませんでした。
やられました・・・・。
ここ数ヶ月のデバッグと修正は一体なんだったのでしょう・・・・。
シミュレーション結果の妥当性結果検証をしたがために簡単なモデルを採用していたので
それが仇となりました。
でも、シミュレータの全ての層の全ソースを読みこめたのでよしとしよう。。。
特に3･2層とフィールドやノイズに関しては嫌になるくらい・・・。

意外と訂正はいいせんいってたんじゃないかと思ったのですが、つまり作者の設計では
コリジョンによるパケット損失を起こすにはこちらを使用しなさいということなのでしょう。
内容もコア部分で似ているので。
今回、変更したものは様々なところからやってくる電波が相互干渉してくれるモデルです。
今までは、全ての電波は独立していて干渉が起こらないというものです。
まぁ、理想環境ですが。
でも、相互干渉が起こらないにしても現在受信をしている電波よりも強い電波が
やってきた場合に同時に受信をスケジューリングするのはいかがなものかと思います。
場合によっては2つのパケットを同時に受信しているのですが・・・。

で、パケットロスに関してMAC802.11でも若干修正をかけているのでNetworkCoding
のシナリオの性能が悪化している気がします。
今度はMACの訂正箇所を戻して検証をしてみたいと思いますが、そこも仕様とは
違っている感じがします。
てか絶対違う。
NS-2のソースにはそんな箇所はなかったので。
それにしても。Jist/SWANSの設計方針がクラスによて違う感じがします。
パケットの送信遅延（シミュレータ内のイベントQueueで取り出される順番）を
実行するのが送信直後だったり受信処理完了後だったり、少しばらばら。

20packet/sの送信レートだと結構ロスが起こるのでNCにはかなり劣悪な環境です。
しかし、CodeCastのシナリオでは今までネックになっていた補助パケットの送信が
逆に効果を出しています。
でも、転送量が増えるのになんで安定してしまうんだ・・・。
このノイズモデルも少し検証しないといけないのかな・・・。

でも、取り合えず提案方式を実装しないと。
NCの理想曲線が崩壊した感じがするので自分のを作り上げて調整をかまします。
1週間で実装をなんとかしよう。

今月最後のゼミのネタはノイズモデルと提案方式の細かな機能を発表しようかな。
違いなど
今までみたいに訂正するごとに検証結果のグラフを提示するのは時間がかかるので
却下。

はて、本当に今までの検証・訂正の時間でかなり遅れをとった感が否めません。
何気に他の方々、いい方向に進んでいます。

さて、もう少し気合を入れて頑張らねば。
でも、ほぼ毎日休みなく研究の事を何かしらやっているのですが何か違う方向を
やっているのかな？
少し深く知れているところもあるのでいいですが。