EASIROC NIM Module の動作でBUSYが頻発する原因を調べたところ、表記のSiTCPからのTX_FULLが2.5msec周期で解除され、約120usecの間データ転送が行われるという周期的動作していることがわかりました。これからデータ転送速度は約1.2MByte/secとなり、データの生成の速度に足りていず、BISYが出ています。SiTCPは本来10MByte/secの能力があると思いますが、120usec/2.5msecの周期的動作をするような設定がSiTCP内でされていることはありますか。それとも、接続先のPCやソフト側の原因でしょうか。
TCP_TX_FULLは32kByteのバッファ容量が残り8byteを下回るとアサートされます。
正常動作だとすると以下のケースが考えられます。
- はじめに約32kByteのデータを送信スピードよりも早く書き込む
- バッファがフルになりTCP_TX_FULLが1になる
- PCは約2.5msごとにしかACKを返さない
- ACKを受け取ることによりバッファに空きが生じてTCP_TX_FULLが解除される
- TCP_TX_FULLが解除されることで書き込みが行われ再びTCP_TX_FULLが1になる
このケースだとご質問の状態となりますが、現実的にはほぼありえないと思われます。
以下を確認すると原因がわかるかもしれません
- Wiresharkでパケットをキャプチャして観測する
- SiTCP_RSTがトグルしていないかを確認する
- パラメータTIM_PERIODが正しいかを確認する
なお、V70でも問題はないはずですが、最新バージョンはV110となっています。
コメントありがとうございます。3項目をやってみました。
Wiresharkでパケットを見てみました。2.5msec 毎にACKがありますが、ACKとACKとの間にはlength=1460のデータ送信のパケットが約1.2msec間隔で2つしかありません。
[ACK] <— 1.2msec —> [data 1640] <— 1.2msec —> [data 1640] <— 0.1msec —> [ACK] の繰り返し。
これはTcpTxFullがLOWになっている期間約120usecにWriteしたデータに対応しています。
（Wiresharkのスクリーンショットを添付しました）
SiTCP_RSTをテストピンに出してオシロスコープで見てみましたが、安定してLOWのままでした。
TIM_PERIOD は WRAP_SiTCP_GMII_XC7A_32K.v の中の parameter TIM_PERIOD だと思いますが、
parameter [7:0] TIM_PERIOD = 8’d25;
となっています。実際にクロックも25MHzです。
データのパケットの間隔が1.2msecとなっていることが原因に結びついているように思われます。SiTCPの中にこれを決めているパラメータなど無いでしょうか。あるいは、SiTCP内のFIFOサイズが十分の一になるようなことは無いでしょうか。
アドバイスよろしくお願いします。
TCP_TX_FULLは、SiTCP内FIFOのAlmost Fullフラグを示し、FIFOのデータはACKの受信がない限り開放されません。
TCP_TX_FULLによってパケット間隔の1.2msが引き起こされてるとすると、ACKがない状態でFIFOのデータが開放されて再度TCP_TX_FULL＝0になっていることになるので矛盾します。（ACKの周期は2.4msなので）
考えられるのは、TCP_TX_FULLがFIFOの状態以外で変化している可能性です。
考えられる例を以下に示します。
- SiTCPの出力であるTCP_TX_FULLを複数箇所で代入している
- TCP_TX_FULLの接続ポートが間違っている
※ 25MHzで動作させた場合、約25MByte/s=約200Mbpsが上限となります。
※最大性能を出すためには129MHz以上のクロックが必要です。
コメントありがとうございます。しかし、まだ解決に至っていません。
ACKの間隔は約2.5msecです。これはWiresharkの結果もオシロスコープでTCP_TX_FULLを見た結果も同じです。
1.2msecはACKから1つ目のデータのパケットの間隔、そして、このパケットから2つ目のデータのパケット間隔です。この2つのパケットのデータはTCP_TX_FULLがLOWの期間が120usecあるのでこの間にまとめて転送された約3kByteが、SiTCPで2つのパケットになっています。
御指摘のTCP_TX_FULLの代入ですが、このピンはWRAP_SiTCP_GMII_XC7A_32Kの出力なので、代入はありませんが、参照は複数ありました。1つはテストピンに出すため。その他は
SitcpReady <= (not AFULL) and TCP_OPEN_ACK;
（AFULL は TCP_TX_FULLの別名）として SitcpReayをステートマシンの分岐条件に使っています。そのため複数の参照になっている可能性はあります。 これが問題だとすれは、それはTCP_TX_FULLがWRAP_SiTCP_…のCLKに同期してない、非同期信号だからでしょうか。
もう1つの指摘の接続ポートの間違いはありませんでした。
2.5msec毎のTCP_TX_FULLの解除毎に 1460X2=2920[Byte] の転送で、1.2MByte/secの転送しか現状できていません。目標は10MByte/secです。
アドバイスよろしくお願いします。
状況を理解できました。
- TCP_TX_FULLは、約2.4ms周期でトグルしている
- TCP_TX_FULLが0の期間は約120usでそのときに約3kbyteの転送が行われている
- SiTCPからの1460byteのパケット間隔は約1.2msである
- ACK間隔は約2.4msである
以上からSiTCPからのパケットが何らかの理由で律速されていると思われます。
キャプチャから1460byteのTCPデータを約1.2ms間隔で送信しているようです。
これをビットレートに換算すると約9.7Mbpsとなります。
以上から、どこかのリンクが10BASE-Tとなっていると推察されます。
再送が無いところから、SiTCPのリンクが10BASE-Tにネゴシエーションされたと思われます。
10BASE-Tのリンクの場合、以下によって事象を説明できます。
- データを書き込むが10BASE-Tなので、すぐに32kByteのバッファがFULLになる。
- バッファがFULLになるため、TCP_TX_FULLは1になる。
- PCは2パケットに1回のペースでACKを返送する
- ACKによって2パケット分のバッファ（2920byte）の容量が開放される
- TCP_TX_FULLは0となるが、2920byteを書き込むと再びTCP_TX_FULLが1になる。
- 2パケット送出には約2.4msが必要なので再度ACKか来るまでには2.4msが必要
コメントありがとうございます。原因に近づいてきたようですが、私はネットワークに詳しくないので対処策についてアドバイスお願いします。
PC（Scientific Linux Release 6.10）側で ethtool を実行してみました。結果は以下のとおり。
[root@ilcvtx shm]# ethtool eth1
Settings for eth1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off (auto)
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000007 (7)
drv probe link
Link detected: yes
[root@ilcvtx shm]#
これをみると ネゴシエーションした結果 1000Mb/s Full-Duplex になっているように見えます。
ethtool は実際にEasiroc NIM Module (SitCP) を動作させ、BUSYが出る現象が再現している直後にやっています。
PCとEasiroc NIM Module の間にはHUBが入っていますが、HUBが影響する可能性ありますか。
リンクスピードはリンク毎に独立に設定されます。
PCとHUBが1000BASE-TでアップしていてもHUBとSiTCP間のリンクスピードは独立に設定されます。
確認するためにPCと直接接続して確認するか、HUBによってはリンクスピードをポート毎にLEDで表示するものもあります。
なお、MDIOを正しく接続しMDIOアドレスを正しく設定していればSiTCP経由でPHYの状態を観察できます。
アドレスは0xFFFFFE00～0xFFFFFEFFで、MDIOアドレスの0x00～0x7Fに相当します。（MDIOアドレスは16bit単位なので）
PHYのレジスタについてはご使用のPHYのデータシートを参照して下さい。
テストしたEASIROC NIM ModuleのLANコネクタにはLEDのSpeed表示があり（回路図とPHYとコネクタのデータシートを見て別りました）、その表示では10Mbpsでした。
HUBを除いて直接PCと繋いでみましたが、リンクできませんでした。
別のModuleを直接PCと繋いだところ問題なくリンクでき、LEDのSpee表示は100Mbpsを示しました。
以上の状況から、テストしていたModuleのPHYかその周辺の故障の可能性が高いと判断しています。
故障の対策等は今後も続けますが、当初のTCP_TX_FULLの異常な動作については、HUB-SiTCP間の10Base-Tによるリンクが原因と判明したことで解決とします。
サポートありがとうございました。