安価なNICモジュール、蟹さんで有名な Realtek RTL8111/8168 ですが、これのLinuxドライバはopenではないので、メーカー配布のドライバを入れなければ鳴りません。ドライバを入れると、結構安定しています。(昔と比べれば)

elrepo の kmod-r8168 がメンテナンスもされていてお薦めです。EL5,6 のモジュールも別ディレクトリにあります。

ここで使われているのが、kmod という仕組みで、モジュールに、モジュールがコンパイルされたときのカーネルAPI(kABI)の情報が入っています。新しいカーネルをインストールすると、API互換性チェックが行われ、モジュールが(表面上は)使えるとわかると、 /lib/modules/(新カーネル)/weak-updates/ にシンボリックリンクが作られ、depmod すれば、モジュールがそのまま使い回せます。
(APIに手が加わると、API情報が合わなくなるので、kmod-xxxx の src.rpm から再構築が必要です。)

もう一つの方法が dkms で、起動時に毎回カーネルモジュールを build する方法です。カーネル更新後の再起動時にコンパイルする時間がかかりますが、確実にロードされます。


ところで、この kmod-r8168 は、多く使われる Realtek RTL8111/8168 シリーズ用ドライバモジュールとして、なぜか姉妹機種の r8169 がロードされてしまう問題への解決策です。r8169 は r8168 と基本部分の設計が同じなので、見かけ上動いてしまうのですが、DMAやオフロードなどの細かい違いの部分が問題になったときにエラー対処が異なっているので、一度問題が発生すると途端に動かなくなってしまいます。ちょっとの差なら、組込の r8169ドライバが r8168 もきちんとハンドルしてくれれば良いのですが、何年もサポートしてくれないあたり、何か特許やライセンスが絡んでいるのか、誰も興味が無いのか…(それなりにユーザはいるはずですが)

kmod-r8168 を入れても、Jumbo frame がうまく動かないという話をよく見かけます。もともと RTL の DMAやオフロード周りは動作が怪しいので、jumbo frame はお薦めできません(効果も限定的ですし)が、型番によって、チップが対応している最大サイズが異なります。ドライバ側ではこれを超える値も設定手来てしまう(?)ので、ご注意下さい。型番は、lspci, dmidecode, dmesg といったコマンドではわからないので、メーカの Specification を読んでください。

Jumbo Frame 最大サイズ
RTL8168B/8111B – 4kB
RTL8168C/8111C – 6kB
RTL8168CP/8111CP – 6kB
RTL8168D/8111D – 9kB
RTL8168DP/8111DP – 9kB
RTL8168E/8111E – 9kB
RTL8168EP/8111EP – 9kB
RTL8168E-VL/8111E-VL – 9kB
RTL8168F/8111F – 9kB
RTL8168G/8111G – 9kB
RTL8168H/8111H – 9kB

9kB が一般的な 9000バイトなのか、9kiB(9126バイト)なのかイマイチ不明です。ソースコードをぱっと見た限りは、9kB(9216バイト)で定義されているように見えますが、ドライババッファサイズとハードウエアの実装が一致するとは限りません。また、これが MTU として、ヘッダの40を引いた値を設定しないといけないのかもしれません。安定しない人は試してみて下さい。上限9216バイトなら、ヘッダを含めない値だとしても、MTU 9000 で安定して欲しいところですが。。。

Jumbo Frame 安定しないけど jumbo frame したい人のMTUサイズ
RTL8168B/8111B – 3960
RTL8168C/8111C – 5960
RTL8168D/8111D以降 – 8960


技術評論社さんより、書籍「改訂新版JavaScript本格入門 ~モダンスタイルによる基礎から現場での応用まで」を頂きましたので、ここでレビューを書きます。

知ってるようで知らない JavaScript こと ECMAScript。AngularJS などがでてきてから、もうブラウザのおもちゃではなくなっていましたが、それでも本格的な開発には、TypeScript などの、もう少し厳密な上位言語を使うことが多かったと思います。しかし、それも今年でおしまいになりそうです。この本で紹介されている、ECMAScript2015(JavaScript6)が規格として定まり、既に最新のブラウザの多くが対応しているからです。

この本では、ECMAScript2015 で新たに加わった部分を強調しつつも、互換性を持ってすぐ使えるサンプルコードで紹介されています。おそらく、全てのブラウザが完全対応した暁には、このあたりも完全に最新の ECMAScript2015 で書き直された再改訂版が出版されるかも知れません。

「本格入門」と、本格的なのか入門なのか、どっち!? と思ってしまいますが、JavaScript を、HTML の飾りではなく、アプリケーション言語として使う場合の入門、という位置づけだと思います。

例えば、「http:」を「https:」に置換したいとき、

function replaceURLsecure ( str ) {
  str.replace(/http:/,'https:');
  return str;
}

なんて野暮ったい関数を作ったりしていませんか?

JavaScript では String もオブジェクトなので、String クラスを拡張して、

String.replaceURLsecure = function() {
this.replace(/http:/,’https:’);
}

と書いてやるのが、JavaScript的なオブジェクト指向なんだと思います。

もし、この関数を広く使いたいなら、String.prototype に加えてやりましょう。

この本は、各所の説明がかなり低級な所まで掘り下げて説明されています。特に、JavaScript は、C言語や C++ の出来る人にとっては、JavaScript は、わかった気にさせておいて、実はもう一段罠がある言語とも言えると思います。C言語を理解している人にとっては、この本の掘り下げた説明は、スムーズに頭に入ってくると思います。そして、この Number オブジェクトこそ、JavaScript は全てがオブジェクトなんだという基本構造への入口だと思います。

この本では、JavaScript できちんとクラスを書く、きちんとオブジェクト指向のプログラムが書けるように、「本格入門」の名に恥じない基本がしっかり書かれています。プログラミング入門ではないので、何か言語を知っている人、特に、C++ や Java のクラスを知っている人向けに書かれているように思えました。JavaScript も Java のように書けたら、と思っている人には、この本で、JavaScript でもちゃんと書けますよ! と言えると思います。オブジェクト指向の実装は C++ のクラスの概念とは大きく違いますが、その違いをうまく説明してくれています。オライリーの分厚い本(サイ本)にももちろん同じ事がきちんと書いてありますが、私にはこちらの説明が非常にわかりやすかったです。この本を読んだ上で、オライリーの本を脇に置いて、AngularJS などに挑戦していけば、最短距離で本格的な JavaScript 開発が始められそうです。

ECMAScript2015 は最新の言語ですが、それでも JavaScript そのものは古い言語なので、色んな互換性を引きずっています。過去、様々なブラウザが群雄割拠していたときの名残か、同じような事を複数の書き方で表現でき、その振る舞いが僅かに異なるケースが結構あります。この本の中では、こうした書き方のバリエーションと、その際についても逐次書かれていたり、今ではお薦めできない書き方も教えてくれるので、JavaScript をきちんと書きたい人、いや、きちんと書いて欲しい人(私だ!)に読ませるべき一冊だと思います。特に、C言語はポインタのポインタまで扱えるのに、JavaScript も長大な main 関数でしか書けない人は、この本を読めば、今日からクラスライブラリを書けるようになるはず。

この本の中でメインに使われているブラウザは、新しめの Chrome(バージョン51以降)で、読んでいるうちに開発者ツールの使い方も自然に分かる様になります。コードエディタも Visual Studio Code を用いるなど、これを機に最新の開発環境を整えたい方にもお薦めの内容になっています。最新のテスト環境やドキュメント文法など、大規模なチーム開発や github での共同開発では避けて通れないモダンな開発スタイルも紹介されているので、vi で html ファイルに <script> を直書きして、若いエンジニアから顰蹙を買っている方(私だ!)には本当にお薦めです。

初_改訂新版JavaScript本格入門_オビ
改訂新版JavaScript本格入門 ~モダンスタイルによる基礎から現場での応用まで


3タテされることなく優勝したカープを祝して、3つ同時に壊れなければデータが失われないストレージ、トリプルミラーリングRAID1 か RAID6 ストレージサーバの構築を1名(社)様に限り半額で行います。(機材費用を除く) RAID6 は 7ストレージまで、6ストレージRAID10(2冗長×2)も承ります。

例えば 10TB×7台のRAID6の場合、10TB×(7-2) = 50TB ストレージを手元に置けます。社内のほとんどのデータを保存でき、さすがにクラウドでは速度的にしんどいサイズだと思います。市販品ならどうにもんらない本体の故障時にも、HDDさえ無事ならば新しい筐体でデータを再構築できます。

9月15日までにご相談下さい!


久々のLINEスタンプの話題です。

夏休みの自由研究としてLINEスタンプを一からデザインしたオリジナルキャラスタンプ「ねこぱんず」がリリースされました。
https://store.line.me/stickershop/product/1315812/ja
弊社もすこしだけアドバイスさせて頂きましたが、他にもかわいいキャラ原案があるのに、このキャラを選んだのは、イマドキの女子小学生の感性でしょうか!?

弊社の商品ではありませんが、もしお使い頂いて気に入ったスタンプなどのご感想があれば、弊社(info@eikai.co.jp)宛にお送り下さい。当人にお伝えします。励みになると思います。これは基本セットで、バリエーションを増やしていくかもしれません!

さすがにリリースは保護者の協力が必要ですが、小学生でもこんなのが作れちゃう時代なんですね。次世代のクリエイターを応援したいです!


このごろ、夜間にフレッツの混み具合がひどくなっています。大容量転送をしなければ支障が出るレベルではありませんが、遅延もひどく、ntp の delay が通常の20ms弱から60ms超へとひどく遅延しています。

夜間になるとひどく遅延が大きくなり、時刻合わせに影響が出る。
夜間になるとひどく遅延が大きくなり、時刻合わせにミリ秒レベルの影響が出る。

このグラフは時刻合わせ(ntp)のモニターなのですが、時刻サーバまでの通信時間(緑)が毎晩大きくなり、時間のジッタ(不確定さ)(橙)も15~20msまで悪化しています。こんなに時刻が揺らいでしまっては、この時間帯は時刻サーバを無視したほうがマシです。

そこで、ネットワーク経由以外の時刻合わせを使う事にしました。GPS信号を受信し、シリアルポートのキャリア検出か、パラレルポートのACKに標準時パルスを入力してやれば、ネットワークの混雑でも悪化しない、正確な stratum 0 の ntpd サーバを作る事ができます。

と言うわけで工作。

GPSモジュールをUSBとパラレルポートに接続する回路の製作
GPSモジュールをUSBとパラレルポートに接続する回路の製作

黒いボックスがオールインワンのGPSモジュールです。こいつに電源を繋いで、データ入出力をUSBでサーバに取りこみます。ユニバーサル基板は高校生の時のストックを切って使いました。

GPS の制御・受信情報は、シリアル-USB 変換をして USB ポートから /dev/ttyUSB0 (Windows だと COM3)として入力します。同時に、USBから 5V-DC の電源をとります。電源電圧が、USBは5V、GPSモジュールは3.3Vと異なるので、レギュレータで変圧します。消費電力が小さいのでヒートシンクはいらないでしょう。定石通り、手持ちのキャパシタ(電解+セラミック)を適当にいれます。

パラレルポートへのパルス信号は、アメリカの標準時計。日本の時計と秒刻みのズレは無いものの、何かちょっと悔しいですね。このパルスで正確に割込を入れるため、カーネルレベルで強い割込のかかるパラレルポートの ACK# ピンを使いました(IRQ4)。このケーブルは脱着式にしたかったので、ノイズに強く高周波を通す Ethernet (cat.5e) ケーブルを転用。PoE 対応なので DC から100MHzまで結構何でも通しちゃう優れものの万能ケーブルで、しかも安価で手に入りやすい。

パルス出力は 2.8V と中途半端ですが、パラレルポートの TTL には High に判別されるのでTTL変換は使いません。タイミングが命なのにバッファを入れたくないかなと(でももっとタイミングがシビアなメモリはバッファが入ってますね)。LED直挿しなのはお許しを。

これが正確に1秒を刻みます。パラレルポートの ACK# はカーネルに強い割込をかけられるので、このパルスのタイミングを高精度(およそ数十ナノ秒)に取りこむことができます。USBでは無理な、レガシーデバイスが活躍する場面です。

あとは、この回路での遅延などを計測・調整すれば、最上位 stratum 0 の ntpd サーバのできあがりです。

この標準時を使い始めたあと、先ほどのネットワーク経由の時刻合わせを見てみると…

夜間に遅延がひどいntpd

遅延(緑)が大きくなるときは、上りより下りの遅延の方が悪化がひどく、ジッタ(橙)だけでなくオフセット(青)も大きく(10~20ミリ秒)ずれていることがわかりました。これはかなりひどいですね。簡易な GPS-NTPD でも、stratum 0 で 100ns、ネット越しの stratum 1 で、10ms の精度が安定して確保できます。

安定しているときのオフセットが 0 になるように、ローカルの PPS Delay を調整して追い込んでいけば、100ns 以下の精度が出ます。

サーバに手を入れたくない場合は、Raspberry Pi 等を使って、単独 ntpd サーバを作る事もできます。拠点間で時刻を正確に合わせたい場合や、マイナンバー関連で局所ネットワークがインターネットから切り離しているパソコンの時刻合わせなどに使えると思います。時刻の合わない端末がある方はご相談下さい。