SiTCPに関する情報を共有するためのフォーラムです。この目的に反しない範囲で、質問、コメント、回答などご自由にご投稿ください。
This forum is for sharing information about SiTCP. Please do not hesitate to post any questions, comments or answers within the scope of this purpose.
This forum is for sharing information about SiTCP. Please do not hesitate to post any questions, comments or answers within the scope of this purpose.
SiTCP_XC7A_32K_BBT_V70 の TX_FULL の周期的動作
EASIROC NIM Module の動作でBUSYが頻発する原因を調べたところ、表記のSiTCPからのTX_FULLが2.5msec周期で解除され、約120usecの間データ転送が行われるという周期的動作していることがわかりました。これからデータ転送速度は約1.2MByte/secとなり、データの生成の速度に足りていず、BISYが出ています。SiTCPは本来10MByte/secの能力があると思いますが、120usec/2.5msecの周期的動作をするような設定がSiTCP内でされていることはありますか。それとも、接続先のPCやソフト側の原因でしょうか。
Comments
TCP_TX_FULLは32kByteのバッファ容量が残り8byteを下回るとアサートされます。
正常動作だとすると以下のケースが考えられます。
このケースだとご質問の状態となりますが、現実的にはほぼありえないと思われます。
以下を確認すると原因がわかるかもしれません
なお、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の状態以外で変化している可能性です。
考えられる例を以下に示します。
※ 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です。
アドバイスよろしくお願いします。
状況を理解できました。
以上からSiTCPからのパケットが何らかの理由で律速されていると思われます。
キャプチャから1460byteのTCPデータを約1.2ms間隔で送信しているようです。
これをビットレートに換算すると約9.7Mbpsとなります。
以上から、どこかのリンクが10BASE-Tとなっていると推察されます。
再送が無いところから、SiTCPのリンクが10BASE-Tにネゴシエーションされたと思われます。
10BASE-Tのリンクの場合、以下によって事象を説明できます。
コメントありがとうございます。原因に近づいてきたようですが、私はネットワークに詳しくないので対処策についてアドバイスお願いします。
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によるリンクが原因と判明したことで解決とします。
サポートありがとうございました。