私はZynq 7000ボード上のLinuxのザイリンクス配布に取り組んでいます。これには、2つのARMプロセッサ、一部のL2キャッシュ、DRAMインタフェース、および大量のFPGAファブリックがあります。当社のアプライアンスは、FPGAによって処理されているデータを収集し、ギガビットネットワークを介して他のシステムに送信します。Zynq 7000の組み込みLinux、ほぼすべてのUDPパケットをドロップ
このアプライアンスでサポートする必要があるサービスの1つは、UDPデータグラムに依存するSNMPです.SNMPにはTCPがサポートされていますが、クライアントに強制的に使用させることはできません。
私は、このシステムがほとんどすべてのSNMP要求を失っていることを発見しました。
ネットワークとCPUの両方に負荷がかかっていないことに注意することが重要です。データレートはそれほど高くなく、CPUは通常約30％の負荷になります。さらに、SNMPのためのSNMP ++とAgent ++のライブラリを使用しているので、それらを制御しているので、システムデーモンが壊れても問題はありません。ただし、処理とネットワークの活動を停止すると、SNMP要求は失われません。 SNMPは独自のスレッドで処理されているため、一度に1つのリクエストしかバッファリングされないように、要求はまれで分散しています。 CPU負荷が低い場合、要求を処理するために受信プロセスにコンテキスト・スイッチングが問題にならないはずです。
CPUやイーサネット帯域幅の問題ではないので、問題はLinuxカーネルにあると推測されます。ネットワークの負荷が低いにもかかわらず、ネットワークスタックのバッファが制限されすぎていると推測しています。そのため、UDPデータグラムが削除されています。
これを検索すると、netstatを使用して失われたパケットを報告する方法の例が見つかりますが、「-s」オプションがないため、このシステムでは動作しません。これらのパケットドロップをどのように監視できますか？どうすれば原因を診断できますか？この損失を最小限に抑えるためにカーネルパラメータを調整するにはどうすればよいですか？
ありがとうございます！
SNMP応答が要求側で失われている可能性がありますが、それはCPUとメモリが大量にあるLinuxを実行している単純な古いx86マシンです。 –
問題を2等分して、どこにパケットが到達してから消失したのかを判断できるかどうかを確認することは素晴らしいことです。 wiresharkのようなツールを使ってリクエストがZynqボードに届いていることを確認することができます。私は 'tcpdump'を使って、UDPパケットがカーネルで利用可能かどうかを確認することをお勧めします。あなたはボードのフラッシュを通して他のlinuxのutilsをインストールすることができます。また、UDPには配信が保証されていません（SNMPに独自のリトライロジックオンタップがあるかどうかはわかりません）。 – Phil
私は個人的にwiresharkを使ったことはありませんでしたが、私の同僚は持っていますので、私はそれを使って作業します。 SNMPについては、タイムアウトがあります。私の場合は、状態変数を変更しようとしていて、それが設定されていないと判断しているので、10回再試行するスレッドを生成します。頻繁に10回の試行がすべて失われてしまい、悲惨です。 –