2008/06/15(日)近況 2008-06-15

抵抗聴き比べと、オペアンプ聴き比べの内容を更新しました。ほんと更新が尽きません。

コンデンサの聞き比べまで入ったらえらいことになりそうなので、それはやめてます。特に電解なんか、はんだ付けしなくても差し替えて○時間待ちとかやってられません(苦笑)。別にOSコンに限ったことではないですけど、高分子系の高性能コンデンサの音質はめざましいものがあります。多少高く付きますが、ディフォルトで使っておけばいいんじゃないかと。

そういえば最近、某サウンドカードに東信のUTSJを乗せてみたのですが、熱ダメージの回復にかなり時間がかかったものの(回復するまでぬったりとした音がする)、固体コンデンサに負けず劣らず非常にクリアな音がしています。

フィルムコンはLPFに使っているので差し替えてみたこともありますが、差があまり大きくありません。もともと素子自体として「歪み」の原因と推測している誘電体吸収が問題となる素子ですから、その辺が影響しているのかなと思っています。

現在製作中

PCM2702DAC(USB-DAC)です。PCM2901より素の音が明らかに良いです。

ヘッドホンアンプとか作ってもらっても、まともなDACがないと今ここで自分が聞いている音を体験してもらうことができないんですよね。片手落ちみたいなもので非常に残念でした。この壁を越えられるか?

2008/06/12(木)部品の整理

今日は大量に増えた部品を整理してました。

処分品

欲しいときに手元に部品がないと非常に困るので、あれもこれもと余剰在庫品が増えてくるのですが、ちょっとしたパーツ屋ができそうなぐらい増えてきたので処分することに。

ジャンク抵抗

大昔、まだ大してお金もなかったころ、鈴商の袋詰めジャンクを買って抵抗値ごと(100~990Ω、1k~9.9k……)に分類しておいてあった抵抗。最近、カーボン抵抗をE6系列でほぼ買いそろえたので処分することに。

はじめは誰かにお裾分けしようかと思ったのですが(例えば工業高校の研究部とかか)、こんなもん欲しい人もいないだろうってことでゴミに。

謎の大量買

「確かに買った記憶はあるが何の部品が今もって不明」という雷のサージ避けだかの素子や、もっと謎の素子。封も開けてない新品をそのままゴミへ(汗

DACとかICとか

秋月で、何を思ったのか買ってしまったNECのオーディオDAC(16bit)とか、数年前千石で買ったADCチップ(今時PICで足りてしまう)とかを処分。もちろん新品

コネクタなど

その他、大量にあるD-SUB25などのコネクタも処分。昔、プリンタ接続(パラレルポート)でPCから操作する回路を作ったんですよね…。一度そういうのを作ると、予備の大量買い込みが……(汗)

D-SUB9はまだ使うことがあるのでの残しました。

セラミックコンデンサ

アキシャルリードのセラミックコンデンサ/積層セラミックコンデンサを処分しました。(積層)セラミックについてはチップ(1608)で十分です(むしろそっちの方が性能が良い)。

教訓

  • いつ使うか分からない予備は買わない。
  • ジャンクパーツには手を出さない。
  • 大人買いに気を付ける(汗)。特に物理的に大きいもの。

2008/06/07(土)秋月で買ったICのSN比

LT1054がほしかったので秋月で通販しました。ついでに、LME49720も買ってみました。

しかし玄人(?)にはSN比が悪いなー、秋月の包装は。石だけスポンジに差して送ってくれれば十分なんですけどね。昔はありがたかったデータシートも今時ネットで手にはいるし。100個とか頼んだら、包装解くだけで嫌気がしますよ(汗)

それでも、外のどこよりも安いから買ってしまう。

ちなみに、LME49720聞いてみましたけど、案の定LM4562との違いが分かりませんでした。20円高い方買う意味ないと思う。U55SXに差してみたけども、やっぱりLM6172のほうが上ですね。

2008/04/30(水)「Googleを支える技術」を読んだ気分になる要点

はてなのnaoyaさんのところで見かけて購入したこの本。あれだけ巨大なシステムがどうやって動いているのか、興味深いところが解説されていてとても面白かった。

よくあるサーバの考え方

よくC10K問題といってクライアントが1万人を越えた途端、どんなシステムでも耐えられなくなると言われています。この先をどうやって維持していくか。はててやmixiなどでは、

  • DNSによるサーバグループの切り離し(障害発生時)
  • リバースプロクシによる負荷分散
  • データベースレプリケーションによる負荷分散、障害対策

普通サーバと言えば、とりあえずRAIDをして、電源ユニットを冗長化して、とにかく基幹システムが壊れないように構成します。基幹システムが落ちなければ、サブシステムは基幹システムによって障害対応しようというものです。

Googleの考え方

システムは、普通のPC(それもハイパフォーマンスPCではなく、コストパフォーマンスのいいPC)を使います。メモリもそこそこ、HDDはIDEディスクです。ネットワークは100Mbpsや1000Mbpsの普通のLAN。

その代わり、マシン台数を増やすことで徹底した負荷分散を行います。

しかしこれ、言うのは簡単ですが実際どうするのか。Googleのもっとも優れたところは、このような負荷分散システムを作り上げたところにあります。

ファイルシステムやデータベースシステムなどは「実に単純な機能」を効率的に実装します。例えば、GFS(Google File System)にはファイルの読み込みと書き込みの機能はあってもオフセットを指定して書き換えたりできないそうです。必要なら読み出して再度書き込むべしという具合です。

書き込みは多くのPCに分散・冗長化して行われ、障害発生時の切り離し対策を何重にも行って対応します。逆に言えば障害対策はすべて「障害発生PCの切り離し」によって復旧するということを徹底して行っています。

そして基幹システムの Chubby は、どれかが特別に優先するわけではなく、複数マシンによる合議制によって作られていて、半数以上のマシンが停止しない限りシステムが稼働し続けるように作られています。

まるで本を読んだかのように自慢できる、要点

  • PCの中身は冗長化しない
  • PCの数を用意するだけで冗長化・障害対策できるシステムを構築する
    • コピーを複数作り障害が起きたら自動的に切り離す
    • 早急に別の新マシンを起動させデータを自動的にコピーする
  • PCの数を用意するだけで性能が向上するようにシステムを構築する
    • 大きなデータは複数のブロックに分割し、手分けして処理をする
    • このような手分け処理をシステム化(ライブラリ化)する

asin:4774134325