安価なNICモジュール、蟹さんで有名な Realtek RTL8111/6186 ですが、open ではないので別配布になっている realtek ルーツのドライバで、昔とは打って変わって結構安定しています。(Intel NIC 程ではありませんが)

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

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

この仕組みを MODVERSIONS と言うのですが、4.4.9 まで、elrepo の kernel-ml には入っていませんでした。これを有効にしてコンパイルしてみたのですが、さすがメインラインですね。APIの細かな変更が頻繁に入るので、安定版の RHELカーネルや kernel-lt のように、何度も使い回すことはできませんでした。だから disable されてたんですかね。

そんな方には dkms で、起動時に毎回カーネルモジュールを build する方法がお薦めです。

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

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


このごろ、夜間にフレッツの混み具合がひどくなっています。大容量転送をしなければ支障が出るレベルではありませんが、遅延もひどく、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 サーバを作る事もできます。拠点間で時刻を正確に合わせたい場合や、マイナンバー関連で局所ネットワークがインターネットから切り離しているパソコンの時刻合わせなどに使えると思います。時刻の合わない端末がある方はご相談下さい。


9月19日は、オープンソースの祭典 OSC広島、20日は中国地方最大のデータベース勉強会 中国DB勉強会in広島 に参加しました。

昔よりは情報を得る地域格差が縮まっているとは思いますが、議論の場となれば話は別で、やはり地方において、最新の情報について話を聞いたり相談できる場は限られています。そうした溝を少しでも埋めてくれているのが、こうした勉強会で、主催・運営して下さる皆さんには本当に感謝しています。

オープンソースは、高価な製品の代替品ではなく、企業活動の中心的役割を担うに至っています。一方で栄枯盛衰が激しく、選択を間違えるとメンテナンスで大変な思いをしますので、こういう場で情報を集めるだけでなく、いざとなったときに相談できる人脈を作っておくことがとても大事です。いつかここで登壇できるようになりたいものですね。

これだけのイベントですので、それなりのコストがかかります。この2つの勉強会は、そのコストを参加費以外で調達しているため、ある程度の参加者数実績を上げないといけないという苦労があるようです。それには告知が大切なのですが、広島の(広島だけ、という意味ではないです)参加者は、この勉強会の大切さが分かっているので、告知もできる範囲でやりますし、ドタキャン率も低いとか。参加者も、主催者の負担を軽くすることを意識して、こうした活動を継続していけるような文化を創らなければなりません。

そういう意味では、今、ちょうど勉強会ブームが過ぎ、最初に企画した人から、次の世代への運営の世代交代の時期にあるようです。コミュニティに関して意識の高い方は、主催者や運営陣の負荷分散など、地方での勉強会イベントのノウハウ自体をパッケージング(テンプレート化)されていて、長期的な開催を意識した運営をされているようです。この勉強会が長く続けられるように、我々参加者も意識を高く保たないといけませんね。

以下、戦利品です。

OpenSSH実践入門

くじ引きで当たりました。これはかなりの大当たりだと思います。毎日使う重要なインフラなので、一度きちんと読んでおきたいです。

 

たまゆらのお酒

去年に続いて、じゃんけん大会で初回勝利。2年連続たまゆらのお酒を頂きました。これも大当たりだと思います。


2.2FLOPS演算サーバと高可搬ストレージサーバこの2月に、広島大学情報メディア教育研究センター・総合科学研究科情報システム講座の中村純教授の研究室に、量子色力学計算用の演算サーバと、データの長期保管用ストレージサーバを納めさせて頂きました。

高性能演算器としては、GPGPU と Xeon Phi が選択肢に上がったのですが、計算の詳細を伺って、Xeon Phi のほうが適していると判断し、Intel Xeon E5 v2 のデュアルソケットに、Intel Xeon Phi 5110P を4枚搭載可能な構成を提案させて頂きました。初期段階として、Xeon Phi を2枚搭載したモデルを構築し、計算能力が不足し始めたら4枚に増設予定です。合わせて 2.2TFLOPS(4枚拡張時は4.2TFLOPS) のピーク性能がありスーパーコンピュータ並みの演算性能があります。コストの許す範囲内で、十分なバスレーンやCPUと演算器のバランス、拡張性など、総合的に良い構成にできたのではないかと思います。

GPGPUと同様に、Xeon Phi も、そのパフォーマンスを引き出すには専用のチューニングは必要です。中村教授は、IBM Cell B.E. での計算実績もあり、Phi でも GPU でもチューニングについてはお手の物だと思うのですが、格子計算は、隣接領域の計算結果がすぐに必要なケースが生じるため、多スレッドでメモリアクセスのレイテンシを隠蔽する GPU よりも、高度なキャッシュ制御でコア間の接続の強い Phi のほうが適していると判断しました。この選択が良い方向に働いてくれることと信じます。

中村教授は、計算が困難だと言われてきた有限密度の量子色力学場の格子計算において、世界を代表する物理学者の一人です。1995年の米国スーパーコンピューティング95で、日本グループ初となるゴードンベル賞を受賞されるなど、常に最先端で独創的な計算技法を取り入れ世界をリードされてきました。そんな中村教授の研究に用いる計算機群に、弊社のサーバ群を選んで頂いて、大変光栄です。演算能力では限界がありますが、環境作りではどこにも負けない設定に仕上げたつもりです。今後、この計算機から多くの成果が出てくることを期待します。

演算器以外でも、サーバグレードの冗長電源、冗長HDD構成で、故障の多い電源やHDDのトラブルでは簡単に停止しないような構成にしてあります。この手の計算機では、故障時にすぐに修理用の部品が調達できないこともあるので、多少の故障では止まらない事も重要と判断しました。計算機屋のできることは限られていますが、最大限研究をサポートできる環境作りを目指しています。このような案件のご相談もお受けできますので、遠慮無くご相談下さい。


Red Hat To Help Develop CentOS というニュースがありました。RedHat Enterprise Linux と互換性の高いディストリビューション CentOS の開発を、RedHat のスタッフがサポートする体制を作るとのことです。

CentOS は、RHEL から商標権などの問題のある部分を取り除く形で作られているので、予めその作業がしやすいような開発や管理が行われるようになるかもしれません。CentOS のユーザは、潜在的には RHEL の顧客になり得るため、CentOS を含めた RHEL派がより多くのシェアを獲得することは、RedHat 社の利益にも繋がるという判断でしょうか。

RHEL の多くの部分はオープンコミュニティで開発された成果であり、それを再配布することは(商標権などの問題を除いて)認められていますが、RedHat が、それをどのように見ているかは諸説ありました。最近は、カーネル(RedHatが配布するカーネルは、独自の拡張や修正が山のように当てられている)のパッケージングで、再配布を困難にするような変更があったりと、必ずしも快く思ってないのではないかという懸念もあったため、今回、このような形で正式に互換ディストリビューションの存在をサポートする態度が見られたのは、互換ディストリビューションの長期的なリリースの安定性には大変大きな好材料です。

CentOS は、単に RHEL互換というだけでなく、centosplus という独自拡張リポジトリも運営しており、積極的な独自拡張も行われていて、便利なだけでなく、面白いコミュニティでもあるのですが、資金面を中心に運営が危ぶまれたこともあるので、今回の RedHat の公式サポートは、非常に心強いニュースです。

弊社では、RHEL に相当する環境として、CentOS・Scientific Linux 環境の構築・管理なども行っておりますので、興味のある方はご相談下さい。


RedHat Enterprise Linux 7 の β版が発表されました。(記事)

fedora 19、kernel 3.10 がベースになるようで、サーバ・仮想化向けのアップデートが目立ちます。

Web 屋さんとして一番怖いのは php のバージョンアップかもしれませんね。fedora-19 をそのまま継承しているとすれば、php のバージョンは php-5.5 になります。
基本的には、現在の php-5.3 から大きな変更は無いはずですが、そのまま動くかどうか怪しいですよね。


RedHat Enterprise Linux 6.5 が登場しました。(記事)

主に基幹・大規模サーバ用の変更が目立ちますが、SL,CentOS に降りてきたら、小規模サーバでの変更点も見ていきたいです。

6.3 wholesale jerseyscheap nba jerseys 6.4 の時に、XFS+NFS4 ????? の環境で kernel cheap nba jerseys panic Vacancies が出る不具合が入ったことがあったので、今回も自動アップデートには勇気が要りますね。
通常は RHEL の安定性には定評があるので、アップデートに躊躇することは少ないのですが。

ちょっと気になっているのが、php のバージョンです。
php 5.3 は開発元がサポートを打ち切って、RedHat が独自にパッチを当ててセキュリティ対策をしているのですが、これが ブログ再開 5.5 Affen 等になると、古い php wholesale mlb jerseys アプリ/フレームワーク が動作しなくなる恐れがあります。
これは、6.x ではバージョンが維持されても、RHEL7 wholesale nfl jerseys ではバージョンアップされるでしょうから、大きなシステムを運用されている方には頭が痛いかも。

ー追記ー

php は php-5.3.3-26 Use のようです。カーネルも kernel-2.6.32-431 のようですが、RHEL wordpressをインストール はカーネルに多くの機能をバックポートしてくれるので、バージョン番号が当てになりません。


Linux cheap NBA jerseys Kernel 3.0.x ブログ再開 の Long-Term Support が終了し、elrepo Halloween の kernel-lt も、3.10.x 系列に変わりました。
3.0 из から Extremis 3.10 cheap mlb jerseys までに何があったかを軽くまとめてみると、

  • HDDへのライトバックキャッシュの最適化(3.1など)
  • TCP周りの最適化(3.5など)
  • ファイルシステム周りの変更(3.8など)
  • 時分割でないマルチタスク(3.10)

特にファイルシステム周りでメタデータへのチェックサム付加などの変更がはいっているので、一度新しい wholesale nfl jerseys kernel で mount wholesale NBA jerseys してしまうと、古い kernel wordpressをインストール で読めなくなってしまうのではないかという心配が少しあります。
また、タスク切り替えの再設計は、かなりインパクトの大きな変更点だと思えるのですが、多スレッド環境でどのような変化があるのか楽しみです。