最近の変更サイトマップ

初期型PS4 (CUH-1000)とPS4 Pro (CUH-7000)の消費電力比較

ひょんな事からPlayStation(R) 4 Pro (CUH-7000)に買い替えることになったので、発売日に買った初期型PlayStation(R) 4 (CUH-1000)との消費電力を比較してみる。ブーストモードはオフ……というか、計測したのはかなり前で、当時はまだ提供されてなかったのである。出力信号は1080p。うちに4kテレビなどというものはないのである。4kのプラズマはよ!(絶対に出ません

PS4
(CUH-1000)
PS4 Pro
(CUH-7000)
備考
電源オフ 0 0
スタンバイ 4〜5 3 ・USB端子に給電する(3時間)
・インターネットに接続したままにする
・ネットワーク経由でPS4の電源を入れられる
・アプリケーションを一時中断したままにする
ホーム画面 76〜81 63〜65
FF15
プラチナデモ
タイトル 130 91〜93
プレイ中 155 108 冒頭の湖のシーンが一番高かった。
ホーム画面戻り 103〜113 74〜82 PSボタン押下。裏でゲームが動いている状態。
torne メイン画面 95 70〜72 ゲームは動かさずtorne単体のみ起動。
動画再生 101 73〜76

 PS4とPS4 Proの消費電力比較

消費電力は概ね2割減ってとこですか。ブーストモードやPS4 Pro対応ソフトだと多分跳ね上がると思うケド…。

Samba 4.6のファイルコピーがCPU 100%近く使い超絶遅い件

最初に結論

この状態に悩まされてる人は何よりも答えが欲しいだろうから、最初に結論を書いておくと、smb.confでcase sensitive = yesと設定すると多分直る。直下に大量のファイルを抱えたフォルダをコピーするとsmbdがCPUを100%近く消費し、コピー速度が極めて遅くなる現象ならほぼ間違いなく直る。

「”大量のファイル”ってどれくらい?」かというと、サーバマシンの性能にもよるがCore i系なら概ね1万ファイル、流行りのラズパイとかだと恐らくもっと少数、単純なクロック比で1/2、実性能はもっと劣るだろうから更に半分で2500ファイルくらい?。完全な当てずっぽうですけど。要はファイル名の比較のところがボトルネックになっているようなので、CPUのシングルスレッド性能に依存する。

次に御託

例によってNAS4Free 11.0.0.4 (4303)[FreeBSD 11.0-RELEASE-p10/Samba 4.6.4]でNASをでっち上げたのだが、知人曰く、今までのNASに較べてファイルコピーが遅い、と。マシンのスペック的にはXeon E5-2620v3, メモリ8GB, 1GbE×2のLAGで、ストレージも3.5インチHDD2本でRAID-1のペアを3ペアでRAID10なので問題が出るとは考えにくい。実際、シェルでのシーケンシャルライトでは500MB/sくらい出てる。

様々なサイズのテストファイルを試してみるも、至って正常な速度が出るし、むしろ他のNASよりも速いくらい。ところが、知人が遅いというファイル群で試してみると、たしかに遅い。小さなファイルが多いためワイヤーレートには程遠いが、それでも初速は10MB/s超えてるのに、あれよあれよと速度が落ちて仕舞には100kB/sを切ってしまう。そして何故かsmbdがCPUを100%近く持っていく尋常ならざる状態に。Pen!!!時代のGbEじゃあるまいし、たかがファイル転送でCPU 100%ってどんだけー。

問題のファイル群をシェルでcpすると30MB/s出てるので、やっぱりマシンに問題はなさげ。さらに、NAS4Free 9 [FreeBSD 9.3-RELEASE-p14/Samba 4.1.18]搭載の別マシン(Xeon E3-1225v2/16GB/3.5“ HDD 6台でRAID-Z2なので性能は必要十分)で試すと、安定して数MB/sは出るし、CPU負荷も常識的な範囲。となれば、問題なのはSambaっぽい…?

ここまで絞り込んでからが大変だった。

情報がないない。マシンの省電力設定を切ってみたり、Sambaが速くなる各種おまじないを試してみたり、SMBのプロトコルバージョンを変えたり、LAGを解除してみたり、etc…するも効果なし。ググりにググって、ようやくFreeNASのフォーラムでcase sensitiveが原因じゃねという投稿を見つけた次第。

早速case sensitive = yesにして試してみたら、効果てきめん。転送速度もCPU負荷も劇的に改善された(テストファイルが32kBなので速度がそんなに出てないのは仕方ない)。論より証拠ってなもんで、比較画像貼っておきますね。

 Samba 4.6.4のcase sensitive設定によるファイルコピー速度の比較

その後、Sambaのドキュメントのcase sensitive設定のところを見たら、思いっきり「As a special case for directories with large numbers of files, if the case options are set as follows, “case sensitive = yes”, (後略)」と書いてあったでござる(´・ω・`)。

大文字小文字の変換処理ごときで遅くなるなよ!と思わなくもないが、ファイルの新規作成時はディレクトリ内の既存ファイル名と被ってないか総当りでチェックしているようなので、何も考えずに実装すれば計算量はO(n2)、ファイル数が増えると爆発的に比較数が増えるんすなぁ…。にしてもですよ、デフォルト設定のcase sensitive = autoは以前のバージョンから変わってないわけで、いきなり遅くなるなんてチョーひどくなーい?

case sensitive設定を変えるとWindowsからのアクセスに支障がでないか心配なところだが(なんたってWindowsは表面上は大文字小文字区別しませんからね!)、そこはエクスプローラが上手いこと取り計らってくれる模様。本当かどうかは知らない。

参考サイト

FreeBSD 11.1-RELEASE キタ―――(゚∀゚)――――!!

予定通りFreeBSD 11.1-RELEASEがリリースされた。めでたいめでたい。特定条件下の11.0RでVirtualBoxが動かない問題が直ってるハズなので、早速更新することにした。

基本はいつも通りfreebsd-updateするだけなのだが、現在の環境がFreeBSD 11.1-RC2の人は要注意。リリースアナウンスによれば、RC2でVirtualBoxを使ってる人はシステム更新の前にvirtualbox-ose-additionsを再インストールしないとカーネルパニックを起こすようだ。

うちは見事に該当してるので、手順に従う。

# pkg install -f virtualbox-ose-additions

これもリリースアナウンスに書いてあるが、念には念を入れ、vboxguestサービスを無効化しておく。経験的にVirtualBoxのカーネルモジュールとサービスはシステム更新時のハマりの原因になるので、必ず無効化することをオススメする。今まで何度地雷を踏み抜いたことか…(ヽ´ω`)

/etc/rc.conf
#vboxnet_enable="YES"
#vboxguest_enable="YES"
#vboxservice_enable="YES"

準備が出来たらいよいよfreebsd-updateだ。といっても、ここからはいつもの通り。

新しいシステムを取ってきて、

# freebsd-update -r 11.1-RELEASE upgrade
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 11.1-RC2 from update4.freebsd.org... done.
Fetching metadata index... done.
...

カーネルをインスコして、

# freebsd-update install
Installing updates...
Kernel updates have been installed.  Please reboot and run
"/usr/sbin/freebsd-update install" again to finish installing updates.

再起動して、

# reboot

ユーザーランドをインスコして、

# freebsd-update install
Installing updates... done.

再起動して、

# reboot

無事、FreeBSD 11.1-RELEASEの環境へ。

$ freebsd-version -ku
11.1-RELEASE
11.1-RELEASE

P4コマンドでファイルが変更済みかどうかを判定する

Perforceでチェックアウト中のファイルに変更があるかどうか──P4Vで言えば、チェンジリストのファイルアイコンが青くなってるかどうか、を調べるにはp4 diff -sr /path/to/fileを使う。ファイルに変更があれば何も返ってこず、変更がなければ与えたファイルのフルパスが返って来る。

■ファイルに変更がある場合
$ p4 diff -sr modified_file.cpp
$

■ファイルに変更がない場合
$ p4 diff -sr no_changes_file.cpp
/path/to/no_changes_file.cpp
$

もっと直接的に確認できる方法は無いのだろうか・・・?

参考サイト

C2750D4Iでwatchdogタイマーを使ってるならBMCのファームを上げるべし

C2750D4I/C2550D4Iを使ってるシステムで、かつウォッチドッグタイマーを有効にしているなら、今すぐBMCのファームウェアを00.30.00(2017-05-29時点の最新版)に更新した方がよさげ。

以前のファームウェアだと、ウォッチドッグタイマーのリセットがかかる度に、BMCの内蔵フラッシュメモリへ設定のバッグアップが行われてしまっている模様。つまり、タイマーのリセット間隔によっては短時間でBMCのフラッシュが亡くなり、最悪の場合マザボがまな板化するとのこと。

ASRockの更新履歴では「Fix on Watchdog Timer.」と一言しか言及されてないが、割とヤバげなバグな気がす。

ところで最近、うちのC2750D4I with FreeBSD 11は何かの拍子で落ちて勝手にリブートしてることがある。その時は必ず「Processor | FRB2/Hang in POST failure」というイベントが記録されているんだけど、これもファーム更新で直ったりしませんかね…。

参考サイト

start.txt · 最終更新: 2016-05-07 17:46 by decomo
CC Attribution-Noncommercial-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0