[ カテゴリー » PC関連 ]

そのうち壊れるかもしれない

blog20080320-GF8600MGT-OverClocking

去年購入したノートPC Dell Vostro1500Link 、実家でもゲームをするために3Dグラフィック性能重視でGPUにnVidia社のGeForce 8600M GTを選択していますが、Dell既定の設定では安定動作重視のためか、動作クロックが低く抑えられています。

しかしGPUメーカーとしては自社製品の高性能を売り込みたいわけで、ユーザーの自己責任ということで動作クロックを変更できるようになっていることが多いです。nVidiaはnTuneLink という変更プログラムを公式に配っている状態。

で、今年頭からじわじわクロックを上げてとりあえずたどり着いた安定動作する上限が、GPUコア700MHz/メモリー526MHz。これはDell既定値の475MHz/400MHzを大きく超えるもの。蹴茶Link みても650MHz/500MHz位の報告しかないのに、なんだこれは!?

ちなみにFuture MarkLink のベンチマーク結果は、3DMark05=7946/3DMark06=4115 (Windows Vista Business)というものでした。

何か間違っているのか、そのうち壊れるのか・・・

[2008/3/24] ゲームをしていると、スノーノイズが画面全体に出るトラブルが2回ほど発生。GPUコアクロックを675MHzに落とす。やっぱり無理があったかw

— posted by mu at 09:36 pm   commentComment [0]  pingTrackBack [0]

PowerShellでバイナリデータ列のパイプ (2)

これLink の続き。

NT版UNIX-like toolsLink をインストールして、以下のコマンドをPowerShellから実行。
PS C:¥> bmptopnm bitmap.bmp | tee bitmap.ppm

出力されたbitmap.ppmをバイナリエディタで見たらFFFEから始まるUnicodeファイルでした。つまりパイプでデータを受け取る側は、Unicode形式で受け取る。PPMヘッダの半角英数字は2バイト表記されており、そりゃあnetpbmは処理できないなと。

また従来のコマンドラインからだと1秒もかからないbmp→jpeg変換も、PowerShellで実行すると(処理は失敗するのですが)数秒かかってしまいます。これはString配列へ変換するのに時間がかかっていると思われ、そういう意味でも使うべきじゃないですね・・・

— posted by mu at 12:50 pm   commentComment [0]  pingTrackBack [0]

PowerShellでバイナリデータ列のパイプ

PowerShellLink でパイプを使ってコマンドを記述しても、そこを流れるのがテキスト/バイナリデータではなくオブジェクト。なのに、.NET Frameworkに対応していない従来のコマンドも普通にコマンド打つだけで実行できてしまう。

はて、従来のテキストベースのコマンドをPowerShell上でパイプで記述するとどうなるのだろ? ためしにnetpbmを使って以下のコマンドを打つと、ppmtojpegでエラー。
PS C:¥> bmptopnm bitmap | ppmtojpeg > bitmap.jpeg
C:¥Program Files¥GnuWin32¥bin¥bmptopnm.exe: Windows BMP, 1024x768x32
C:¥Program Files¥GnuWin32¥bin¥bmptopnm.exe: WRITING PPM IMAGE
C:¥Program Files¥GnuWin32¥bin¥ppmtojpeg.exe: EOF / read error reading a one-byte sample
で、
PS C:¥> $a = bmptoppm bitmap.bmp
C:¥Program Files¥GnuWin32¥bin¥bmptoppm.exe: Windows BMP, 1024x768x32
C:¥Program Files¥GnuWin32¥bin¥bmptoppm.exe: WRITING PPM IMAGE
PS C:¥> $a.gettype()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     Object[]                                 System.Array


PS C:¥> $a[0].gettype()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     String                                   System.Object
bmptopnmの出力はSystem.Stringクラスオブジェクトの配列に変換され、でまたテキストに戻されppmtojpegに渡されるということになっているようです。

で、どうもこのStringオブジェクトに変換する際にデータはUnicode化され、バイナリデータであるbmptopnmの出力は書き換わっているっぽい。

pnmtopnmを使ってテキストフォーマットにすれば問題なく扱えるのでしょうが、Unicode化されるのでだめLink
bmptopnm|pnmtopnm -plain
としてもpnmtopnmに渡される時点でデータは壊れてるし。

PowerShellは好きなんですが、こういう用途には使うなということですね。

[参考]

[2008/3/10] 追記Link

— posted by mu at 06:14 pm   commentComment [0]  pingTrackBack [0]

PCサーバ、いかがですか? ごしゅ(略

ちょっと古い記事ですが、ドジっ娘メイドがNECサーバの新キャラに (AKIBA PC Hotline! Junk Blog)Link 、まぁ単にPCサーバーのチラシにメイドキャラが使われたというだけといえばそれまでですが、作ったのが大手メーカーであるということがちょっと話題性あるかなと。

技術的に新規性が打ち出せなくなり他社とも差別化が図れなくなると、キャラクター性のあるものを商品に貼り付けるなどに走るのはどの量産工業製品でもありえること。食品・お菓子は絶えず存在するし、自動車やバイクなどでも時々見かける。つまりPCサーバーもこういう領域に入っちゃったということですね。

NECはhp ProLiant ML115Link に対抗してのことでしょうけど(Netburst系の在庫を決算前に処分したいというのもあるかも)、AKIBA PC Hotline!にも書いてあるように、PC自作する人ならケースと電源、マウスにキーボート、CD-ROMまで手に入ると思えば安い買い物だと思う。

以前に安いPCが欲しいという相談をされPCサーバを勧めたところ、躊躇されたことがありました。サーバといっても中身はデスクトップPCとほとんど同じ。WindowsもLinuxも動くし、PCI Expressスロットにグラフィックボード挿せばゲームもできる。NECのなんか、マザーボード上にRAIDコントローラまである。信頼性のある(最新ではないが)パーツを使うのでケミコンが吹っ飛ぶLink 心配もないでしょう。

気を付けておきたいのは、信頼性重視だということから発生する以下の点。
  • 冷却性能を優先でファンの音が少しうるさいかもしれません。hp ProLiant ML115は会社にあるので聞いてみましたが、デスクトップPCと変わらないみたいでした。ほかのやかましいサーバの音でかき消された可能性もありますが。
  • CPUが古い。過去の使用で信頼性が確認されたという証拠でも。
  • メモリがECC付というほぼサーバにしか使われない規格。数週間から数ヶ月連続稼動が当たり前のPCサーバでは、デスクトップ/ノートPCでは極稀にしか発生しないメモリの不具合も防がないといけません。そのために増設時にはECC付き(さらにはバッファ有り)という、普通の店では売ってない規格のメモリが必要。新品は割高ですが、中古ならデスクトップのメモリより秋葉原などで叩き売られたりします。
  • 大きいw とはいっても、自作のミニタワー・フルタワーと同じ程度ですが。

上にも書いたとおりPCサーバはPCなので、PCの規格にのっとってます。自作できる人なら、Core2Duoのマザーボードに換えちゃえばいいわけで。ケースと電源は下手なものより頑丈ですよ。

— posted by mu at 11:16 am   commentComment [0]  pingTrackBack [0]

pam_tallyのオプション

CentOS 5Link (多分RedHat Linux 5.xも)から、PAM認証モジュールのひとつ、認証失敗回数をカウントするpam_tallyの既定動作およびオプション指定が変わっているのにいまさら気づく(^^;)

大きなところでは、
no_magic_root → magic_root
rootの認証失敗をカウントするかどうか。rootでログインできなくなる可能性が出ますが、カウントしないとrootのパスワードをターゲットにしたクラッキングを許す可能性が。4.xではno_magic_rootを指定してrootも例外扱いしないと明示する必要があったのに対し、5.xではmagic_rootで特別扱いを明示する。
reset → no_reset
一回認証が成功するとそれまでの失敗カウントを帳消しにするかどうか。4.xではresetを指定して帳消しを明示する必要があったのに対し、5.xではno_resetで帳消ししないことを明示する。
[2009/2/22 追記] どうやらオプションを記述する箇所も変更になっていた模様。影響が大きそうなのはdenyオプションで、多くのページではaccountインターフェースに指定すると書いてありますが、RHEL5はauthインターフェースに指定するみたいです。これを間違うと規定回数ログイン失敗しても素通しになるみたいで。こんな大事なことが検索一発で出てこないって、周知方法考え直したほうがよくないですか? > RH

— posted by mu at 10:20 am   commentComment [0]  pingTrackBack [0]

T: Y: ALL: Online:
ThemeSwitch
  • Basic
Created in 0.0248 sec.
prev
2024.11
next
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30