添付した設定で乱数の種を１から２０に変えながらバッチ実行すると，ＣＢＲではすべてのセッションが非ゼロのスループットを持つのに対して，ＦＴＰのスループットがゼロになる場合が散見されます．
このような現象にあわれて，解決されている方がおられましたら，その解決方法あるいは原因の所在についてご教授願えませんでしょうか？
宜しくお願いいたします．
FTPG-CBR config.zip

こんにちは
全てを見たわけではないので気付いた点だけ。
見当違いだったらすみません。

設定されているFTP/GENERICのアイテムサイズは1GBと大きなもので、
300秒のシミュレーション時間でセッションが完了していないのではないでしょうか。
FTP/GENERICのスループットは、セッションの開始から終了までの時間で計算しています。
見られているスループットは受信側の[Gen/FTP Server Throughput (bit/s)]と思いますが、
逆に送信側の[Gen/FTP Client Throughput (bit/s)]のほうを見てみると、どの送信ノードにも値が記録されていません。
(つまり送信側ではセッションが完了する前にシミュレーションが終了している)
また、Server Throughput で値が出力されているものは、
たまたま途中でセッションが切れているのではないでしょうか。(原因はわかりませんが)

ためしにFTP/GENERICのアイテムサイズをCBRの設定値と同じ1000byteと小さくすると、
全てのServer Throughput の値が出力されるようです。

ipoten さん，回答ありがとうございました．

Simulation時間を2000Sとし，
FTP/GENERIC 4 20 1000 1000 300S 0S PRECEDENCE 0
として乱数の種を変えてバッチで実行しましたが，
依然，FTP スループットがゼロとなるセッションがあります．
なお，CBR セッションは非ゼロです．
FTPスループットがゼロとなると，
結果を統計処理したときに信頼区間が大きくなってしまうので，
どうしたものかと思っておる次第です．

Client 側も、Server 側も 0 になっちゃうんでしょうか？

とりあえず、Client側なら１アイテム（ファイル）の途中で
シミュレーションが終了、あるいは切断されてしまうと
送信バイト数＝＝０となるので、スループットも０になり
そうですね。

Server側はアイテム（ファイル）なんて気にしないでしょうから
TCPからデータが挙がってきた時点で 受信バイト数＋＝データサイズ
としちゃうでしょうから、一つでもパケットを受信していれば
なにかしらスループットが出てきそうに思いますが。

CBRは多分１パケットサイズが十分小さければクライアント
側も、サーバー側もTCPからのレスポンスがあった時点で
送受信バイト数を更新するため、スループットが観測されている
のではないでしょうか？

うーん。
たしかに chikara さんのおっしゃるとおり、[Gen/FTP Server Throughput]がゼロになるセッションがありますね。
しかし[Gen/FTP Client Throughput]の方は、僅かながらでも全てのセッションで値が記録されています。

ちなみに、chikara さんの条件で、Simulation 時間を 2000S とし、
で、乱数Seedを1から20でバッチ実行してみたところ、
それぞれ実行もストリームも異なる5つのセッションで現象が発生していました。

Server Throughput がゼロとなっているストリームの Client 側の統計値を見てみると、
Applicationはデータを少し送信し始めているにもかかわらず、
[TCP Data Packets Sent] がゼロとなっています。
つまり TCP レベルでデータパケットが転送されていません。

ルートが確立されていないのか、ハンドシェイクに失敗しているのではないでしょうか。
トレース結果は見ていませんが、このあたりから調べてみてはいかがでしょう？

参考になるかは分かりませんが、
↓この話とはまた異なる話ですか？
http://simweb.kke.co.jp/qualnet/forum/modules/newbb/viewtopic.php?viewmode=thread&topic_id=86&forum=25&post_id=195#195

penguishさん，iptonさん，mastさん，

返信ありがとうございます．大変参考になります．

TCPコネクション確立に失敗している可能性は確かにありえますね．
それで気になるのは
コネクション確立の実装がどのくらい忠実かということなのですが，
スティーヴンスの「詳解TCP/IP Vol.1 プロトコル」によると，
TCPはコネクションの確立に失敗してもSYNパケットを何度か再送します．
QualNetがBSDのTCPの実装を引っ張ってきているのなら，
この機能も入っていないのだろうかとは思っているのですが…．

それで，本家のフォーラムにて
QualNet Forum Index -> Application Layer Settings -> Notion of item in FTP/Generic
で投げていたのですが，

Q: If TCP fails to start sessions due to loss of sync packet, does TCP
retry to start session after a while?
A: Yes, TCP re-sends SYN packet.

というこでSYNパケットは再送しているようです．
この再送回数を増やさないとだめなのかもしれません．

chikara