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.

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を下回るとアサートされます。
    正常動作だとすると以下のケースが考えられます。

    • はじめに約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サイズが十分の一になるようなことは無いでしょうか。
    アドバイスよろしくお願いします。

  • edited September 2020

    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です。
    アドバイスよろしくお願いします。

  • edited September 2020

    状況を理解できました。

    • 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によるリンクが原因と判明したことで解決とします。
    サポートありがとうございました。

Sign In or Register to comment.