R&D daily

telnetが通信途中でこける件について。

分かればなんてこと無い。いつものこと。

リングバッファに複数未処理パケットが有る状態で、割り込みで１個だけ処理して抜けてきてしまったのが原因。
定番のバグを仕込んでしまったようだ。
最初はポーリングで処理していて、ちゃんとバッファが空になるまで回すように作っていたのだけれど。
もしかして、取りこぼしがあるのかも、と思い、割り込みハンドラ内で処理するように変更したときにやらかしたようだ。

今のプログラムのバックグラウンドループは、平均で8usec、ワーストで220usec程度で回っているようだ。
ポーリングで処理しても、まだ問題なさそうに思える。

------

Ethernet MACの処理は、nxpのサンプルコードのまま。
このサンプルコードはよく出来ている。

この場合の、”よく出来ている”というのは、やたら凝ったつくりになっている、とか、ある種の美しさに満ちている、という類の話ではない。
ベタ書きのコードに限りなく近いのだが、ハードウエアの使い方が読み解きやすい、平易なコードになっている。
サンプルコードの役目として期待されるものに沿っていて、好感度高い。

サンプルコードと称して、やたら深い構造体の解析に付き合わされたり、どこまで追っても意味がよく分からない定数やマクロの海に泳がされたりするようなものが多い昨今、ありがたいことだ。

このサンプルコードでは、送受信のバッファサイズが、Ethernetパケットの最大サイズで定義されていて、そのため受信バッファとしては、４つしかブロックが存在しない。
最小サイズ付近のパケットがたくさん飛び交うようなときには、メモリの使用効率が悪くなる。
いや、もちろん、サンプルとしての分かりやすさを求めて、設定されているのだと思うけれど。

------

で、ようやくなんとなく動くようになったtelnet（受信側のみ）だけれど、実際のやり取りをパケットアナライザで観察してみる。

122byteほどのアスキー文字列を、lpc1769側に送信。
転送が終わるまでに、約220msecかかって、86個ほどのパケットが行き交っているようだ。（arpやsync、finとかは除く）
こんなもんかなあ？と思うのだけれど、内容を見ると再送要求だらけで、実際にデータの受け渡しに寄与しているパケットは、全部で8個しかない。半分はackだから、文字列を送っているパケットは4個だけ。

telnetの解説を見ていても、効率悪そう．．．と思っていたのだけれど、これは予想以上？
lpc側のプログラムをチューニングすれば、もっと良くはなるだろうけど。

まあ、telnetクライアント側が賢くて、もっとたくさんデータを送れば、サーバーの応答を観察して、だんだん効率のよい方法で転送を始めるのかもしれないけれど。

次は、標準出力側かな。
今度は大丈夫でしょう、多分．．．．