昨日は、落部つつじ祭り出没しておりました。残念ながら、つつじの花は見ごろを過ぎており、花より団子となってしまいました。まあ、それはそれで・・・楽しかったです。

さて「経年劣化、あっぶねー！」で書いた、P社の24ポートGiga-HUBの続報を。皆さんのご想像どおり、半田ごての出番となりました。それらしい？コンデンサを持ってきて交換です。それらしい？耐電圧は同じですが、同容量が無かったので、多少大きいので代用することに。物理的サイズとしては少し縦長な程度で作業は簡単。まあ、問題ないでしょう。勿論、チップの放熱器を留めるバネの基盤側フックもガッチリはんだ付けし直し完了です。

すんなり、電源は入ります。当たり前？LANケーブルを挿してTESTもOKです。Gigaでリンクしています。治ったぞ～！！です。わざわざ直した目的は、自席の足元にある同社の100Base-TXの24Pとの交換です。これで、また一つ100のHUBを撤去できるはずでした・・・。ところが、付けてビックリ！爆音です。サーバ室では気になりませんでしたが、静かな事務室では問題です。このHUB、40mm角のFANが2個付いているのですが、かなりうるさいです。特に片方は、ベアリングが参っているのか明らかな異音です。結局、FANレスの100Base-TXの24Pで暫く我慢し、サーバのジャンクからでも、FANを流用したいと思います。諦めが悪いです。でも、40mm角のFANに静音型ってないですよね？

電解コンデンサ4個の交換は上手くいきました。今度はFAN・・・ですか。

（投稿者：９２）

ども。
本日は前回の記事の続きです。よろしければお付き合いを。担当ちゅんです。

ディスク容量が大きすぎてバックアップに失敗していると思っていたのですが、どうやら原因は通信速度不足ではないか？と推測をたてました。
早速、実験開始です。まずは、転送速度が落ちている原因がファイルの送り側（ファイルサーバ）なのか受け側（バックアップサーバ）なのかを突き止めなければなりません。別なローカルサーバから大きめなデータをダウンロードしてみて、速度を確認します。

最初にバックアップサーバから。SMBでファイルをコピーしてみると、速度は300Mbpsを越えました。そもそも、リソースモニタのグラフのスケールが1Gbpsに変更されていました。これは正真正銘のギガビット・イーサネットですね。
では、次にファイルサーバ。同じファイルを同じ方法でダウンロードしてみたのですが、いくら頑張っても100Mbpsを越えません。スケールも100Mbpsになってます。ようやく、問題の核心に近づいたようです。どうやらファイルサーバのネットワーク周辺で何らかの不具合が発生しているのは間違いなさそうです。

こういうときに疑うのは、NICの不具合よりもむしろスイッチとかケーブルです。ギガハブの手前に100BASEのハブが挟まっていないか、ケーブルの施工不良で速度が落ちていないか。もっと初歩的なミスで、ギガに対応しているケーブルを使っているか、などなど。ボトルネックを探していきます。

L3スイッチのランプを見てみると、やはりファイルサーバのリンク速度は100BASEになっていました。原因がはっきりと判明した瞬間です。で、ケーブルを抜き挿ししてみるとランプの表示上はギガに。しかし、サーバ本体のイーサネットポートを見てみると、通常は左右のランプが点灯するはずが、右側のランプのみ消灯している状態でした。
このサーバはNICを2つ搭載していたので、試しにセカンダリのNICにケーブルを挿すと左右のランプが点灯しました。

原因はわかりませんが、どうも怪しいのはプライマリのNICのような気がします。とりあえず、そのポートを使うのはやめて、セカンダリに設定を移し、念のため「カテゴリー6」のケーブルで接続。
この構成でいつもどおりにバックアップを走らせると、速度はようやく300Mbpsを越えてくれました！
結局のところ、これってプライマリのNICが壊れたということなんでしょうかね。後から説明書を読んでみると、右側のランプは「1000/100/10ランプ」とされ、消灯の場合は「未接続、または10BASE-Tで接続中」と書いてありました。う～ん、残念ですがハードウェア障害として処理するしかなさそうです。

というわけで、バックアップが終わらない原因は「NIC」の不具合だったのでした。

極めつけは取扱説明書のミス？左側が緑で右側が橙に見えるのですが・・・。

（投稿者：ちゅん）

年○機構のウィルス感染は、我々にとって他人事ではありません。システム的な問題よりも「無用なメールは開封しない。」と言う、基本的な・・・。でも、あそこまで「件名」や「発信者」を詐称されてしまうと、職員としては・・・。やはり、システムになりますか。早速にわかも、全職員に向け一層の注意喚起をGWで促しましたが、由々しきことです。

7月29日のアップグレードを予約出来る KB3035583 が配布され始めました。

ども。
職場のクールビズ開始の号令にあわせて上着を脱いだ担当ちゅんです。

今回の記事は長くなるので、計2回に分けて投稿します（今日は上下巻の上ですね）。

先日から頭を悩ませていたのが、町内小中学校の集中管理ファイルサーバのバックアップ問題です。基本的に全学校の校務用データを16TBのWindows Storage Server に集約して管理しているのですが、このサーバのバックアップに時間がかかり、丸一日近くバックアップし続けても終わらないという状況になってしまいました。

でも、状況としては十分ありえる話です。仮に1Gbpsの速度をフルに使って転送したとして、

1024Mbps ÷ 8 = 128MB/s

ということで、1秒間に128MBしか転送できないということになります。1分だと60倍して7.7GB、1時間だとさらに60倍して460GB。2時間かかっても1TBの転送すらできないのです。無圧縮で16TBを転送しようとすると35時間かかってしまう計算です。しかもこれはあくまでNICの通信速度から計算した「理論値」で、実際にはディスク速度なども影響して1Gbpsなど出ませんから、もっと時間がかかるということになります。

さて、どうしたものでしょう。とりあえず、日々のバックアップは「差分バックアップ」とし、専用のソフトウェアを使って圧縮転送していますが、夜の10時から翌朝7時までの9時間でなんとか終わらせたいところ。それを前述のように計算してみると、

9時間 × 460GB ＝ 4TB

・・・って、あれ？4TBものデータを転送できる計算になります。何かおかしい。差分ファイルが4TBになるなど考えられませんし、まして丸一日たっても終わらないなどありえません。
ふと、バックアップ稼働中のサーバのタスクマネージャからパフォーマンスを確認してみました。すると、理由はわかりませんが、リミッターがかかったかの如く、通信速度が99.6Mbpsでビタッと天井に張り付いています。1GbpsのNICなので、少なくとも100Mbps以上、理想では200～300Mbps程度で通信していなければならないのに、これは明らかに異常。何かがボトルネックになって100Mbpsに速度が落ちているのでは！？

こうした推測のもと、いよいよ原因究明に乗り出したのでした・・・次回に続く。

速度が遅いときは、冷静に計算してみると色々わかってきます。

（投稿者：ちゅん）

プリンターの調達仕様書を書いています。プリンターのメーカーサイトで、基準とするプリンターのスペックを参考とする訳ですが、見慣れない単位が出てきました。それは ipm です。

プリンター性能の一要素である「速さ」を現す単位です。簡単に言うと、1分間に何枚の印刷が出来るかという事です。この測定方法ですが、A4用紙への印刷でも、縦向きと横向きでは速度が違ってきます。用紙にびっちり文字があったり、写真が大きく貼られていたりしても差が出るでしょうし、色使いでも変わります。カラーよりも白黒の方が当然早いはずですよね。この速度を左右するテスト印刷の内容は、各メーカーでバラバラだったみたいです。結果「A4横のモノクロ約15ppm（当社測定値）」の様に表示されていました。この単位がppm（page per minute）で、1分間に何枚印刷できるかの単位なのです。

そして今回発見したのが、ipm です。image per minute ・・・ image? 調べました。ipmは、ISO（国際標準化機構）が定めた測定方式に基づく客観的な入出力速度の単位だそうです。

問題の、各社独自だったテスト印刷の内容は、さり気無く上手く（速く）行くように、各社工夫をしていたに違いありません。今度はそうではありません。ガチ、国際標準です。ISOが定めた測定方法となりました。結果、インクジェットプリンタの場合、今度のipm値は、今までのppm値に比べかなり厳しい数値となるようです。半減する場合も・・・？

ちなみにレーザプリンタの場合、紙面がどれだけ文字や画像で埋まっていても、一定の速度で紙を送り、一気に印刷する仕組みなので、ipm＝ppm と差は出ないらしいです。

インクジェットプリンタの印刷速度が、いつの間にかipm表示に

（投稿者：９２）