カテゴリー別アーカイブ: PC

nVidiaコントロールパネルの設定をいじってゲームを快適にしてみるテスト

最近WizardryOnlineってなゲームやってるんですけど、なんか重いんですよね。
いや、別に重いっていってもフレームレートが10とかになっちゃうってわけじゃなくて、こう、ヌルサクじゃない感じ。

うちのCPUとグラボは結局色々あったものの2600KとGTX295に帰ってきてて、でまあWizってべつにちょー重い感じのゲームじゃないんですよね、やってる感じ。
だから設定次第じゃ普通に60FPSでてもおかしくないと思うんだけど、なんかそういう感じがしない。
戦闘中でエフェクトが重いとかっていう時じゃなくて、街中で誰もいないような場所にいてもそんなにFPSが出てる感じがしない。

ということで設定を色々いじって、FPSをとにかくはじき出して、そっから画質も調整という流れにしてみようかと。

まずはなんも設定していない状態で1chの露店街のど真ん中でFPS計測。
おそらくこのゲームで一番重い場所はココだ。

でまあFPSは15-25FPS。
SSモードにして25くらいか。

次に、nVidiaのコントロールパネルで、

3D設定>3D設定の管理>プログラム設定>1.カスタマイズするプログラムを選択する>追加

ということでWizardryOnline.exeを追加。

さて、とりあえず画質は犠牲にしてひたすら軽くしていくか。

  • CUDA – すべて
  • AA トランスペアレンシー – オフ
  • スレッドした最適化 – オン
  • TF クオリティ – ハイパフォーマンス
  • TF トリリニア最適化 – オン
  • TF ネガティブLODバイアス – 許可
  • TF 異方性サンプル最適化 – オン
  • トリプルバッファリング – オン

25-30くらいまで向上。
SSモードで35-40くらい。

で、うちのカードはGTX295なんで内部的にSLIなんで、その辺もいじってみる。
ついでにディスプレイもデュアルディスプレイで運用していて、場合によってはSLI構成を解除して一時的にトリプルディスプレイにしたりもする感じなんで、マルチディスプレイ/ミックス GPU アクセラレーションあたりもいじってみる。

まずマルチGPUレンダリングモードから攻める。

とりあえず現在がNVIDIA推奨設定。
シングルGPUはさすがにないのでとばす。
フレームのレンダリングを強制的に交互にする1 – 25-30FPS
フレームのレンダリングを強制的に交互にする2 – 27-32FPS

GPUの負荷具合みていると、推奨設定およびAFR1ではGPU Bしかほとんど負荷がかかっておらず、AFR2だと双方のGPUに負荷がかかっていることと、微妙にFPSがあがっていることから、今回のケースではAFR2が良さそう。

次にマルチディスプレイ/ミックス GPU アクセラレーション。
マルチ ディスプレイ パフォーマンス モードがデフォルトで設定されているんだけども、その他いくつかあるけど、まあ結論から言うとどれもあんまり変わらなかった。
ので、推奨とされているデフォルトのまんまにしておくことに。

とまあなんかいろいろやってたら、まあ人が多いところ以外はわりと60FPS出る感じになったみたい。
画質も別に気にならないしこんな感じでしばらくやってみよう。

WesternDigital春のRMA祭り

さて、今年もやって参りましたRMA祭りの開催です。
今回はサーバ機で2本、個人用マシンで1本、いずれもWesternDigital社製ハードディスクに異常が検出されました。

いい加減にしろよくそがおいこのゴミカスマジで紀伊店のか。

あ、すいません、思わず心の声が聞こえてしまったようで。
お気になさらず先へ進みましょう。

いつからでしょうか、そう遠くない頃合いに、サーバ機のrootあてにsmartctlからメールが届いていました。
smartctlからのメールなんて良いことが書いてあるわけがないわけでして、案の定SMART値に異常があるよというお話でした。
でまあ確認してみたところ

Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: read failure       90%      2317         17715224

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
197 Current_Pending_Sector  0x0032   195   195   000    Old_age   Always       -       1461

おい、Current_Pending_Sector 1461ってどこまで深刻化してから通知よこすんだよ、もうこんなディスクつかえねーから。
そして一通りディスクをしらべてみると、別のディスクでも144でてる。
こいつも交換対象だな。

だがサーバ機ははRAID5で運用しているので、二本同時に引っこ抜くのは当然できない。
どう見ても重度な方のディスクをとりあえず引っこ抜いて、縮退モードで運用し、RMA申請して帰ってきたら再構築、そしたら次に危ない子を引っこ抜いて。。。という流れで対処しようと思う。
金持ちじゃないんで、代替ディスクを用意してすぐに交換するなんてことはしません。

で、デスクトップの方ですが、こちら2Tのディスクを2本使っているうちの1本で不良セクタが発生。
最近なんか調子悪かったのでRAID0を解除してデータを整理してスキャンディスクしたら判明。
一本は元気なようで、とりあえずはその一本で間に合うので、調子の悪い子はサーバ機のHDDのRMAが終わってからRMAすることに。

ということで、それぞれのディスクがRMA申請できるか保証をチェック
したところ、一匹できないのがまざってた。
デスクトップのやつ。

CFDでRMA申請を可能にする申請をだす

こいつはまあどうせ後回しだし。
別の二台のRMAが終わった頃にはRMAできるようになってるでしょ。

ということで、一番重傷な子をとりあえずRMA申請。

んじゃ、取り外そう。

。。。てどのディスクなんだっけ。
いや、諸々の問題からDom0上でRAID5を構築しているわけではなく、DomUで構築しておりまして。
んと、Dom0では/dev/sdeだから。。。DomUでは。。。/dev/xvdb4らしい。
xm conでDomUにコンソール接続して。。。

# mdadm /dev/md3 --fail /dev/xvdb4
[1799713.802196] md/raid:md3: Disk failure on xvdb4, disabling device.
[1799713.802198] md/raid:md3: Operation continuing on 4 devices.
mdadm: set /dev/xvdb4 faulty in /dev/md3

# mdadm /dev/md3 --remove /dev/xvdb4
[1799899.247128] md: unbind<xvdb4>
[1799899.247142] md: export_rdev(xvdb4)
mdadm: hot removed /dev/xvdb4 from /dev/md3

# mdadm -D /dev/md3
*snip*
          State : clean, degraded
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

*snip*

    Number   Major   Minor   RaidDevice State
       6     202       17        0      active sync   /dev/xvdb1
       1     202       18        1      active sync   /dev/xvdb2
       2     202       19        2      active sync   /dev/xvdb3
       3       0        0        3      removed
       4     202       21        4      active sync   /dev/xvdb5

さて、xenのDomUの設定ファイルのストレージの記述からも外して、物理的にHDDを引っこ抜く。

前SeagateのRMAで返送されたときの箱をとってあるので、それにHDDをつっこむ。
RMA手順指示書を二部プリントアウトして、一部は二カ所ほど署名をして箱に同梱。
一部は郵便局で送り状やらインボイスやらを記入するときの参考資料として持って行く。
RMA labelは張った方が早くなるらしいといわれているけど、張って1ヶ月、張らずに2週間を経験してるので面倒だからもう張らないことにした。
Western Digitalの人と直接やりとりしたときも、ラベルつくって張ってね、とか一言も言われなかったし。

じゃ、郵便局行ってくるか。
おかげで英語で住所書くの慣れた。

アロケーションユニットサイズ比較

アロケーションユニットサイズによってディスクアクセス速度はどのように変化するのか検証。
なんか前にもやったような気がするんだけど、あらためて。
まあ、前やったときはRAID0をくんでいる場合で、今回はRAIDくまずにAHCIでNCQ有効な場合の比較なので、似て非なるものになるはず。
使ってるディスクは相変わらずwd20ears-00mvwb0です。

検証の方法はシンプルに、HDDにパーティションを一つアロケーションユニットサイズを指定して作成、CrystalDiskMarkで計測。

まあ、ぐだぐだと理屈はいわないでとりあえず結果をぺたぺた。
上から順に4096, 8192, 16K, 32K, 64K。

正直。

かわんなくね?wwwww

RAID0くんでたときはわりとスケールアップしているのが見えたけど、普通に使う分には既定値で問題ないだろう。

番外編

 

 

 

むしろ完全に既定値推奨でした本当にありがとうございます。

RAIDくむなら話は別になるんだろうけど、そうじゃなければ4Kがベスト。
ああ、SSDでも話は変わってきそう。
っていうかSSDキャッシュ試したいな。。。
あれ?マザーボードを買う口実が今できたような。

2013/1/10追記

どうもアロケーションユニットサイズの変更で性能差が出ないのは、4KBセクタのHDDだからなようです。
従来の512byteセクタのHDDではアロケーションユニットサイズを64KBにすると明らかに早くなるらしい。

ホームシアター的なものを考えてみる

うちね、DVDプレイヤーとかないんですよね。
いや、あるっちゃあるんですけど、うごくかどうかわからないようなレベルの代物で。
CDプレイヤーとかもないし、まあメディアの再生は基本的にPCで行うわけです。

で、PCには普段使いのディスプレイ2枚に、ヘッドセットと2.1.chスピーカーを接続しています。
んで、それとは別に42型のプラズマテレビ(TH-P42S2)と5.1chサラウンドシステム(HTP-S333)も用意してます。
となると、ブルーレイとか録画したTSとかみるときは映像はディスプレイじゃなくてテレビで見たいし、音も5.1chのサラウンドで鑑賞したい、となりますよね。

で、グラボからの映像出力ですが、今使っているのがGTX295で、DVI * 2 と HDMIの出力。
マザーボードのS/PDIF OUTをグラボのS/PDIF INを接続してやれば、HDMIで映像と音声を同時にとばせるので、そうすると、

マザー – [S/PDIF] – GTX295 – [HDMI] – S333 – [HDMIパススルー] – P42S2

としてやることで音声と映像をそれぞれのデバイスにとばすことができるな、と。
この場合の音声デバイスは普段使っていないオンボードのRealtek High Definition Audioになるので、その点は注意。
通常はSE200-PCI LTDを使っている。

んで、問題はマザーとグラボをつなぐS/PDIFケーブルが無いこと。
GF-SPDIFってのが玄人思考から出てたんだけどすでに生産中止。
同等品もちとみあたらなくて正直困った。

それじゃあ、グラボからHDMIで渡すのは映像だけにしておいて、音声は音声で渡しましょう、という方向で考える。

映像
GTX295 – [HDMI] – P42S2

音声
Realtek – [S/PDIF] – S333

まあ特に問題なく構成できる。

が、プレイヤーの音声再生デバイスが、普段はSE200なんだけども、映画鑑賞したいときはRealtekを使わねばならないので、切り替えるのがめんどくさい。
ということで、前のエントリのようなことをして、Realtekで流れる音声をSE200にも流すことで、いちいち出力デバイスを変更しないでもいいようにしたわけです。

が、ここに来て気づいてしまった。

HDMIで映像と音声の同時出力をしないのであれば、Realtekで音声出力する必要はないと。
オンボードのサウンドチップを持ち出したのは、そもそもグラボのS/PDIF INに流し込む口がマザーのS/PDIF OUTしかなかったから。
仕様上はSE200のS/PDIF OUTからつなげるのかもしれないけど、ただでさえマイナーなS/PDIF 2pin端子と光角形の接続ケーブルが商品としてこの世に存在する気がしない。
ということで、つまりは、普通にSE200とS333をS/PDIF接続すればいいだけではないか。

ということでもろもろひっくるめて書いてみるとこんな感じでよろしいか。

映像
GTX295 - [DVI] - W241DG
       - [DVI] - U2211H
       - [HDMI] - P42S2

音声
SE200 - [ステレオRCA] - i-TRiGUE 3600
      - [ステレオミニプラグ] - ATH-770COM
      - [S/PDIF] - S333

Realtekとか完全になかった。
アマミキ!もさようなら。

ちなみに、みなさんご存じの通りGeforceのグラボは一般的には同時出力が2つまで。
なので、鑑賞会をしたいときはサブディスプレイを無効にして、テレビを有効にしてソファーによこになります。
PCリモコンマウス2くそ便利です。
3画面同時出力のためにRadeon HD 5870買いましたが、ドライバがゴミカスすぎて不安定になりまくって同時出力がどうとかそういうの以前すぎてストレスマッハで引っこ抜いて今やどこにあるのかわかんね。
音声は自前でサウンドチップ持ってるし、三画面同時出力できるしで、まともにうごくならいいんですけどね。
少なくともうちじゃまともにうごかない完全なるゴミカス。
まあそういうことで、グラボを一本追加したいのですが、今のマザーボード、PCI-E x16レーンが一個しかなかった。
ということで、考えた選択肢は以下の通り。

  1. PCIのグラボを買う
  2. マザーボードを買う
  3. RADEON引っ張り出す
  4. 使うときに使うディスプレイをオンオフ切り替えて3画面同時は捨てる

とりあえずしばらくは4で。
PCIのグラボって結構高いんですよ。
需要が微妙すぎるんでしょうね。
マザーは正直パーツを全部引っこ抜いて刺し直す作業がめんどくさすぎるのでいやだし。
RADEONはもう正直さわりたくない。
でまあ、3画面同時に必要になるときって基本ないんで。
鑑賞会するときはきほんそっち集中だし、ながらでやるときもおそらく追加一画面あれば足りるだろし。
PCIでDVI出力できてフルHD対応しているグラボが間違った値段で流れてくるか、マザーを交換する日がくるまではこんな感じで運用しようと思います。

一つのソースの音声を複数のデバイスに同時出力する

一つのソースの音声を複数のデバイスに同時出力するということをしたい。
もっと具体的にいうと、Media Player Classic Home Cinemaでの再生音声を、SE200-PCI LTDとオンボードのサウンドデバイスの両方に流したい。

とりあえず、サウンド関係のデバイスの接続状況。

SE200-PCI LTD - ヘッドフォン
              - AT-MA2 - マイク
              - 2.1ch スピーカ
オンボ Realtek - 5.1ch サラウンドシステム

で、とりあえずステレオミックスを使っていけないか考える。
Windows7だと、録音デバイスに「このデバイスを聴く」というオプションがある。
Realtekで再生 -> ステレオミックス -> このデバイスを聴く -> SE200
として、MPCHCでのオーディオ出力デバイスにRealtekを指定してやれば、どちらのデバイスでも音声出力されるはず。

ということでやってみるけど、音が出ない。
しらべてみると、既定のデバイスがスピーカー(アナログ)じゃないとステレオミックスが動作しないらしい。
とりあえず今回はこのルートはパスすることに。

とりあえず

MPCHC -> Realtek -> なんかで録音 -> SE200

って流れを作ればいいんだよなーということで、次に、アマミキ!を使う方法を考えてみる。

live_setupでライブ機能をインストール。
amamix.exeたたいてshift+enterでアマミキ!を起動。
録音デバイスにAmaRec Core Audio Captureを指定して、Realtekの出力をとる。

再生デバイスは既定のデバイスのまま。
S/PDIF Envy24 Family Audio Controllerを直接指定してもいいけど、既定のデバイスがそれだからわざわざいじってはいない。

メイン画面で再生にチェックを入れる。

MPCHCで再生デバイスにRealtekを指定して、適当に動画を再生。

お、いけてる。

とりあえずこれでいいんだけど、仮想デバイス+猿ちぃを使う方法も試してみた。

まず、仮想サウンドデバイスをインストール。
Voice Changer Software Diamond EditionNETDUETTO βを利用。
仮想デバイスの録音側のマイク設定で、「このデバイスを聴く」にチェックを入れて、再生デバイスにSE200を指定。

猿ちぃ++で同じく仮想デバイスの録音側のマイクをRealtekへとばす。

とするとどうなるか。

仮想デバイス向けの出力が、方やSE200へ、方やRealtekへと流れることになる。
つまり、この仮想デバイスをMPCHCで出力先デバイスに設定すればよいということになる。

仮想デバイス再生 -> 仮想デバイス録音 -> Windowsの機能でSE200へ
                   -> 猿ちぃ++の機能でRealtekへ

んだが、猿ちぃ++がいちいちstartとかstopとかついてるのがちょっと邪魔っていうか面倒というか。
なんだかんだアマミキ使う方向でよいかなあとかおもう昨今。

追記
Windows Media Playerだとアマミキを使う方法だとなぜか音が出ない、っていうかアマミキがエラー起こす。
WMPでやりたいなら仮想デバイスかませる方が良さそうだ。

Janetterで日本語のままgoogle検索を使う

Janetterってなぜか検索がYahoo!強制で、検索エンジン選べないんですよね。
まあなぜかっていうか株式会社JaneとYahooが協力関係にあるからだと思うんだけど。

んで、使用言語を日本語じゃなくて英語にするとgoogle先生で検索してくれるんだけど、日本語だとyahooで検索。
じゃあ日本語でもgoogleにしましょうというお話。

ステップ1
JanetterのインストールディレクトリThemeCommonjsjanetjanet.js を編集。
C:Program Files (x86)Janetter2ThemeCommonjsjanetらへんにある。

YAHOOCOJP_SEARCH_URI: 'http://search.yahoo.co.jp/search?ei=UTF-8&fr=sb-jane&p=%1',
↓
YAHOOCOJP_SEARCH_URI: 'http://www.google.co.jp/search?q=%1',

に書き換える。

ステップ2
C:Program Files (x86)Janetter2ThemeCommonjsplugins らへんの searchpopup.js を編集

return 'http://search.yahoo.co.jp/search?ei=UTF-8&fr=sb-jane&p=' + encodeURIComponent(selection);
↓
return 'http://www.google.co.jp/search?q=' + encodeURIComponent(selection)

に書き換える。
ちょっとプログラムっぽいのが好きなら

if((jn.conf && jn.conf.lang ? jn.conf.lang : 'ja')=='ja'){
↓
if((jn.conf && jn.conf.lang ? jn.conf.lang : 'ja')=='jp'){
とか
if(false){

Javascriptの文法ようしらんからif(false)が通るのか知らんけど。

ステップ3
これは見栄えの問題なので、やらなくても機能的には問題ない。
C:Program Files (x86)Janetter2binlocale らへんにある ja.json を編集。

"webSearch":"Yahoo! 検索",
↓
"webSearch":"Google 検索",

として保存。

以上でJanetterを再起動すれば検索がgoogleで行われるようになる。
まあみての通りyahooに検索文字列渡すのをgoogleに変えてるだけだから、当然ほかの検索エンジンのパターンにあわせて書き換えてやればほかの検索エンジンにも変えられる。

あ、書き忘れてたけど Janetter Version 3.2.1.1 でのやり方です。

Core i7 2600Kを今更OCしてみた

そのうちやろうやろうと思っていたんだけどもやっていなかった2600KのOC。
SandyBridgeのOCの基本は倍率変更で行う。
FSBはいじれないと思っていい。
CPU倍率とコアの電圧だけいじればいいので、920のOCより簡単。

ということでまず軽く4GHzにトライ。
倍率を40に変更。
電圧いじらなくても当然のようにブート。
で、以前行ったCore i7 920の時と同じように、低電圧化も図る。
CPUの電圧をさくっと0.1V下げてみる。
ブート。
さすがやで。
とりあえずOCCTたたく。
固まる。
無茶振りだったらしい。
仕方がないので0.05Vにする。
OCCT。
一見いけてる。
が、ふとCPUの温度に目をやる。

99℃

ハイ駄目。
停止。
すいません、CPUクーラーリテール品です、本当にありがとうございます。
とりあえず、4GHz程度ならたぶん電圧を下げながらもOCできるだけの可能性を秘めたCPUだとは思うけど、やっぱりOCするならリテールクーラーじゃ駄目でした。
ちゃんとしたクーラー買いましょう。

仕方がないのでクロックを定格に戻して低電圧化を行うことに。
-0.1Vは余裕でした。
-0.15Vもいけました。
-0.2Vは死にました。
ということでとりあえず-0.15Vに。
もうちょい煮詰めれば限界見えるんだろうけど、まあ今日のところはこの辺にしておいてやる。

XenカーネルでのNICのカスタマイズ

Xenを使って仮想化しているマシンではネットワークも仮想化される。
そのあたりはこちら参照。

でまあそういうことで、ethtoolなんかでNICの設定をしたい場合は、通常と異なりeth0とかをいじるのではなくて、Dom0でpethをいじるのが正解。
普通はpeth0になってるだろう。

実際にethtoolをたたいてみたら、仮想NICであるethの方はろくに情報が出力されないはずだ。
それに対してpethの方はちゃんと出力されるはず。

# ethtool eth0
Settings for eth0:
        Link detected: yes
# ethtool peth0
Settings for peth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: off
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000001 (1)
        Link detected: yes

こんな感じ。

ということでXenカーネルでうごかしてるマシンのNICの設定をいじりたい場合は、pethをいじりましょう。

Postfixで迷惑メール対策

最近スパムが多くて、良いスパム対策はないかと物色。
で、なんか売り文句によると99%のスパムメール撲滅できるというものが。
基本的なコンセプトはこちらに詳しく書いてある。

  • メールサーバがメール中継サーバからのSMTPアクセスは受け入れるがエンドユーザーコンピュータからの直接のSMTPアクセスは拒絶するという単純なもの
  • SMTPアクセスをかけてきたクライアントのFQDNの特徴に基づいて、クライアントがメール中継サーバか、エンドユーザー回線につながったコンピュータかを推定することができる
  • うまく管理されているメール中継サーバのほとんどは、逆引きで得られるFQDNを持つ。逆引きFQDNのないIPアドレスからのSMTPアクセスは、少しの例外を除いて拒絶すればよい。
  • 正規表現を使うことによって、エンドユーザー用回線の逆引きFQDNとメール中継サーバの逆引きFQDNを区別する
  • メールサーバがこれらの規則によってSMTPアクセスを拒絶する時は、「後で再試行せよ」を意味する応答コード「450」を 返すべきである。そうすれば、これらの規則のいずれかに引っかかる正当なメール中継サーバを、後で述べるホワイトリスト(許可リスト)を作ることによって 救済することができる。
  • HELOコマンドが宛先サーバのIPアドレスまたは受信者のドメイン名を通知している
  • 送信者ドメインの検索失敗
  • 内容の検査

なるほどね。
エンドユーザ回線を拒絶するのはでかそうだ。
この方式をS25R(Selective SMTP Rejection)方式というそうだ。
そして、この方式とは別にGreylistingという方式がある。
Greylistingは簡単に言えば、再送要求を一旦返して、ちゃんと再送してきたものを受け取る方式。
S25RとGreylistingを組み合わせた方式がRgrey方式として紹介されている。
また、意図的な応答遅延を行うことで配送タイムアウトが通常のMTAよりも速いものを切り落とすtarpittingという方式もある。
これは、通常、スパム業者は大量のメールを配送する関係から、応答の遅いMTAには配送を早々とあきらめるよう設定されていることが多いことを利用したもの。
S25R+tarpittingによる、Starpitという手法も紹介されている。
そして、全部ごった煮のパターン、S25R + tarpiptting + Greylistingを組み合わせたtaRgrey方式が紹介されていた。
taRgrey方式の簡単な説明は以下の通り。

taRgreyとは、メールサーバ上でスパムやウイルスメールを排除するためのフィルタの手法で、 S25Rとtarpittingとgreylistingというスパム判定手法を組み合わせて使うというものです。
S25Rにより、動的IPっぽいFQDNからの接続からは怪しいと判断し、tarpitting(応答の遅延)を行います。tarpittingを待ちき れずに送信元が接続を切った後、再度送ってきた場合にはgreylisting(再送のチェック)により救済します。S25Rとtarpittingと greylistingと、全てのフィルタを抜けれなかったものだけがスパムとして排除されます。

さて、じゃあtaRgrey方式で、といきたいところだが、ここにかかれている方法はパッチを当てなければならない。
aptでパッケージ管理している関係上、できるだけdebian非公式パッチは当てたくない。
なので、パッチを使わないで実装する方向とする。

ということでどこでチェックしようかpostfixの設定を眺めることしばらく。
smtpd_recipient_restrictionsでやるのがいいかなあ、という結論。
PostfixでのGreylistingはpostgreyを使う。
ホワイトリストは許可して、S25R方式で怪しい奴らにgreylistingをかける。
それを通ったものにはtarpittingをかける。
という流れにする。

postgreyをインストール。

# aptitude install postgrey
/etc/default/postgrey
POSTGREY_OPTS="--inet=127.0.0.1:10023"

127.0.0.1をつけないとipv6でbindしてた。
いや別にいいんだけど。

main.cf
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
check_client_access regexp:$config_directory/white-list.txt,
check_client_access regexp:$config_directory/permit_client_nots25r,
check_policy_service inet:127.0.0.1:10023,
check_client_access regexp:$config_directory/tarpitting,
permit
white-list.txt

http://www.gabacho-net.jp/anti-spam/white-list.txtのものを使用
permit_client_nots25r
/.(internetdsl|adsl|sdi).tpnet.pl$/ WARN
/^user.+.mindspring.com$/ WARN
/^[0-9a-f]{8}.(.+.)?virtua.com.br$/ WARN
/.catv.broadband.hu$/ WARN
/[0-9a-f]{4}.[a-z]+.pppool.de$/ WARN
/.dip[0-9]+.t-ipconnect.de$/ WARN
/.dip.t-dialin.net$/ WARN
/.dyn.optonline.net$/ WARN
/.(adsl|cable).wanadoo.nl$/ WARN
/.ipt.aol.com$/ WARN
!/(^unknown$)|(^[^.]*[0-9][^0-9.]+[0-9].*.)|(^[^.]*[0-9]{5})|(^([^.]+.)?[0-9][^.]*.[^.]+..+.[a-z])|(^[^.]*[0-9].[^.]*[0-9]-[0-9])|(^[^.]*[0-9].[^.]*[0-9].[^.]+..+.)|(^(dhcp|dialup|ppp|[achrsvx]?dsl)[^.]*[0-9])/ OK
/./ WARN
tarpitting
/./ sleep 65

main.cfでのsmtpd_recipient_restrictionsで基本的な認可のあとに
ホワイトリストによる認証(check_client_access regexp:$config_directory/white-list.txt)
S25RでOKなものの認可(check_client_access regexp:$config_directory/permit_client_nots25r)
微妙なやつらをpostgreyでgreylistチェック(check_policy_service inet:127.0.0.1:10023)
それも抜けたのはtarpitting(check_client_access regexp:$config_directory/tarpitting)
という感じ。

設定してからしばらくログ眺めてたけど良い感じでスパムをブロックしてくれている。
SPFの設定もしようかと思ったけど、あっちは転送時にfailしたりしちゃうことがあるみたいだから、とりあえず今回はやめておいた。
postfix-policyd-spfパッケージ入れてちょいちょいいじれば使えそうなんだけどね。