パスワードを忘れた? アカウント作成
5313 story

PCIカードでGzip圧縮 52

ストーリー by Oliver
次のハード化はなんだ 部門より

dseg 曰く、 "本家より。先日終了した電子関連見本市、CeBITで、 ドイツのWuppertal 大学Vigos社の共同開発による、大変興味深いPCIカードの試作機が展示されたという。
"Webサイト アクセラレータ"と銘打たれたこのカードは、Gzip圧縮をハードウェア上でリアルタイムに行うというもので、 現行の速度は 32Mbytes/sec と 100MbitのLAN上のデータを扱うには十分なスペック。Webサイト関連のみならず、ネットワーク越しのバックアップ等にも威力を発揮しそうだ。将来的には倍の 64Mbytes/sec を目指しているとの事だ。
尚、Vigos社のプレスリリースも読むことができる。発売時期等の詳細は不明だが・・・せっかくハードでこなしてくれるのなら、Bzip2圧縮版(板)も欲しいなあ。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2003年03月22日 9時35分 (#284048)
    ハードウエアでやる、って言うと、ソフトウエアでやるより速い!っていうようにまず思いこむ。作った側はベンチマークデータもそのように出す。

    このハードでもソフトウエアで結局は制御するわけだから、そのソフトウエアの実行速度だって気になる。

    デコードされたデータが多いとき、結局PCIバス経由でデータ転送せにゃあかんでしょう。もちろん、エンコードされたデータがカードに入るときも同様。で、データ量があまりに多くなった場合は、この転送速度だってネックになる。デコード結果がメモリに入りきらないくらいの大きさになった場合、結局ディスクのI/O速度にデコード速度はよるのではないか?

    過去にも同種のハードウエアアクセラレータがあったけれども、結局量産に入る前にソフトウエアの実行速度が上がって量産時の初期コストもあわせるとコスト的にあわないものになっていた。

    さて、今回はどうか?
    • by 505 (12538) on 2003年03月23日 23時39分 (#284820)
      その昔、某技術雑誌で、LZ圧縮アルゴリズム(だったかな?)をハードウェアで実現する記事があったかと…
      で、FPGAか何かで拡張ボードを作って、ハードで圧縮したファイルをソフトで解凍させたり、その逆をしたりして、ちゃんと互換性があるよ!
      …はいいんだけど、いかんせんそのボード、Cバス(お!)なもんだから、データ転送が遅くて、結局ソフトのほうが速いという結果に…

      PCIにしたところで、今だったらCPUはGオーダーだしなぁ~

      PCIにすれば速いかっていうと、単純にそうとは言えないし…
      PCIはバスマスタ/バースト転送でないと性能が出ないのに、「PCI=速い」というイメージだけでPCIバスを採用したけど、中身はCPU転送/シングル転送で動いてて、ぜんぜん性能が上がらなかった…という失敗作が、私の足元に(汗)

      親コメント
    • by G7 (3009) on 2003年03月22日 16時26分 (#284183)
      それってもしかして、たとえば、
      Gzip板がLAN板のドーター板として実装されたら良かったのにね、
      とかいう風に考えると良いのでしょうか?

      #音源板にドーターが色々有って楽しいと思うのでG7。PCじゃないがMU100に歌うドーターとかも。
      親コメント
      • 基盤同士が相互にサービスを見つけあって
        直接、lan板がgzip板の機能をインターコネクト経由して使えればいいんですね。

        Hypertransportとかって、p2p通信なんだから
        そういう使い方すれば、便利なのになぁ。

        PCに使う部品をサービスとしてそれを管理するディレクトリ機能を
        インターコネクト上に持てばいいじゃないですか。
    • まったくそのとおりです。最近は、例えば、このハードウェアを使いCPUと組み合わせた単サーバーの熱発生量を減らせることができれば、複数サーバーを積み上げたシステムの単位面積あたりの処理性能を上げることができるとか、空調の条件がゆるくなるからコストを抑えられるとか 別の尺度をもってこないとハードウェア化の説明ができない。。
    • インターネットにつながっている線って100Mbpsくらいで、 割と遅いので大丈夫なのではないかナ。
  • by NyaNya (12681) on 2003年03月21日 20時27分 (#283790) 日記
    「Vigos社のプレスリリース」のリンクが変です・・・
    指したかったのはこれ [vigos.com]かな?

    #自力ではえーごは読めないので確認できず^^;;;
  • by bikeman (14466) on 2003年03月21日 21時53分 (#283814)
    確か、以前、圧縮機能つきのルーターがあったような気がする。それとおんなじこと?

    #INSの64Kで最大512K送れると書いてあった。
    • by Anonymous Coward
      >確か、以前、圧縮機能つきのルーターがあったような気がする。それとおんなじこと?
      >#INSの64Kで最大512K送れると書いてあった。

      それ、パケット受け取り先ではどうするんですか~

      今回のPCIカードって単にgzip圧縮する機能だけもってるんじゃないんですか?
      それをどう使うかは、アプリケーション依存なんだと思いますが。
      • by bikeman (14466) on 2003年03月21日 22時49分 (#283854)
        対向ルータも同じ機種じゃないとだめ。たしか、Ascendの製品だった。 #"Compressing the Web"といってるくらいだから、パケットをリアルタイムで圧縮伸張する目的みたいよ。
        親コメント
        • Re:以前、 (スコア:2, 参考になる)

          by kicchy (4711) on 2003年03月21日 23時18分 (#283864)
          プレスリリースからの引用ですが、

          > GZIP Accelerator can process more than 32 Megabytes of
          > data per second and this will enable Web content compression
          > in truly real-time!
          > The PCI-Board offloads the cycle-intensive encoding
          > operations from the webservers main CPU

          つまり、これによると
          「本来WebサーバのCPUが行っていたWebコンテンツの
           エンコーディングにかかる負荷を減らすことができるんだ。(超意訳)」
          とあります。

          Webサービスが、相手の端末を選ぶようではだめですから
          これは、コンテンツのリアルタイムgzip圧縮に使われると
          考えたほうがいいと思います。
          受け取る側は、コンテンツを圧縮したままで受け取ることを想定したアプリケーションなんでしょうね。

          簡単なところでは、ftpの取得時圧縮のように
          コンテンツの一括取得がgzip圧縮形式で受け取れるように
          なっていたりするのかもしれません。
          他、適切なアプリケーションが浮かびませんが
          ブラウザ以外の専用アプリケーションを使えば、
          もっと幸せな使い方が見つかりそうですね。

          # 巨大掲示板。
          # バックのデータは、プレーンテキストで扱って
          # ブラウザ経由でアクセスするときはプレーンテキストを
          # 整形して表示させる。
          # 専用のビューアに対しては、gzip圧縮されたデータを
          # 送りつけて整形をビューアに任せられる・・・・・とかね。
          親コメント
          • by kicchy (4711) on 2003年03月21日 23時23分 (#283869)
            >他、適切なアプリケーションが浮かびませんが

            ごめん。HTTP/1.1を考えてなかった。
            ブラウザでも十分、圧縮の恩恵を受けられますね。
            親コメント
          • Webサービス (スコア:1, すばらしい洞察)

            by Anonymous Coward on 2003年03月22日 9時07分 (#284039)
            こういところで、「一般的にWebで行うサービス」の意味で「Webサービス」という単語を使うと、どっとねっと とか さんわん とかのやつと混同することがあるので、表現にはご注意を。

            # しかし、なんだな、ほんとはXMLベースのやつをわざわざ「Web Service」という名前にしたヤツのほうが悪いと思うんだが。
            親コメント
          • by Anonymous Coward
            mod_gzip
  • by Anonymous Coward on 2003年03月21日 22時36分 (#283840)
    昔、JPEGカードとか、MPEGカードってありませんでしたっけ?
    無茶苦茶似てるような気がします。

    ネットワークで使うとなると、ローカル側とサーバ側両方に実装してないと駄目なんですよね?あんまり流行りそうにないなあ.....。

    パケット圧縮して、細い帯域で大量のデータを流そうってシステムは流行ったものが無いと思うんですけど、どうなんでしょ?個人的にはWAPなんて典型的な例だと思ったけど。
    • >パケット圧縮して、細い帯域で大量のデータを流そうって
      >システムは流行ったものが無いと思うんですけど、どうな
      >んでしょ?

      パケットではないが,NMPモデムのクラス4だとデータ
      圧縮してましたが.
      親コメント
      • パケットではないが,NMPモデムのクラス4だとデータ
        圧縮してましたが.
        MNP って MNP クラス4 や CCITT(ITU-T) V.42 はエラーコレクトだけじゃなかったでしょうか? MNP クラス5 とか V.42bis が圧縮だったような。クラス10 が移動体通信用でしたっけ。

        V.42bis なんかは、圧縮率それなりにいい割にレスポンスも悪くならなかったのが嬉しかったですね。確か MNP5 はデータ待ちのタイムアウトが遅かったのかレスポンス悪かったし。
        親コメント
    • > パケット圧縮して、細い帯域で大量のデータを流そうってシステムは流行ったものが無いと思うんですけど、どうなんでしょ?

          iモードやEZ-Webでも「パケ割」等の有料でデータ圧縮を利用
      できるようにするサービスが成立している様なので、それなりに
      ニーズはあるのでは。

      # MPEGだって、局側はハードウェアだとおもいますが・・・・
    • パケット圧縮して、細い帯域で大量のデータを流そうってシステムは流行ったものが無いと思うんですけど、どうなんでしょ?
      デジタルTV放送もMPEG圧縮で少ない帯域で大量データを流そうってシステムなんですが、やっぱり・・・

      # 衛星系は流行ってないと言えるかな?
      # 地上波は・・・
      # 流行りそうに無いから強制的に導入するのかも :-D

  • そうすればIPsecアクセラレートもcryptoで出来るし、Webサーバーとしても使える。
    tarのzオプションがこれカードを使うようにフックしてくれたりすると、日常業務にも役立つ。

    だけど、Pentium3で十分速いと言えば速いからなぁ……。
    --
    Masafumi Otsune [otsune.com]
  • ベクタアニメーションアクセラエータカードが有ったら買うかも。

    # 要はFlashだけど。
  • by SteppingWind (2654) on 2003年03月22日 15時20分 (#284161)

    本当に2chみたいな文字主体の巨大サイトやWebディスク兼用のメールサイト以外は使い道が無さそうなんですが. だって普通Webサービスで通信量が問題になるとしたら, 画像や音声みたいなバイナリデータが中心で, しかもそういった奴って一部の例外を除けば既に圧縮済みでしょう. それに再度圧縮をかけたからって, 処理時間の無駄にしかなりません.

    バックアップ用途に使うとしても, この機器が有効に使えるような高速なバックアップストレージを持っている環境なら, 専用のネットワークを使うはずですし, さらに高速な用途となったら, 今度はSANか何かで集中管理した方がTCOは下がるはずです.

    となると, やはりニッチな領域で目的にうまくはまれば良いと思いますが, 汎用的に使われる物かと言われれば疑問符がかなり付くと思います.

    • そうかなぁ?

      転送量だけで効果を測るのは早計じゃありませんか?

      1トランザクションの時間が短くなるってのは、
      ある程度ヒット数の大きいサイトでは同時処理トランザクション数が減って
      結構スループット改善に効果あると思います。

      大体から、Webの情報の大半は文字データなんで圧縮率もいいでしょうし、
      JPG etcの圧縮済みのコンテンツを再圧縮するような愚さえおかさなければ(タイプで識別できますよね)、
      ニュースサイトのように頻繁に内容の変わるサイトにおいて
      都度圧縮によるトランザクション時間の短縮は効果大きいと思いませんか?

      処理トランザクション数を増やすために通信帯域を広げるよりも
      お安く改善に役立つと思うんですがね。
      親コメント
    • by Anonymous Coward
      まぁまぁ。
      こういった製品を導入するときには、きちんと自分のサービスの特性を分析して
      カードを買うのがいいのか、箱を増やすのがいいのか、速い箱にいれかえるのがいいのか
      と検証をしてから行うものでしょう。
      効果が*必ず*あるだなんて盲目的に信じて導入する方がどうかしてますよね。
  • by Anonymous Coward on 2003年03月21日 20時01分 (#283783)
    2ちゃんねるのサーバ管理者程度ですかねぇ?
    • 参考 (スコア:1, 参考になる)

      by Anonymous Coward on 2003年03月22日 7時58分 (#284027)
       現在の2ちゃんねるでGZip圧縮データを取得可能なのはスレッド一覧のみです。
       ただし、最近購入されたサーバ?ではスレッド自身も圧縮取得可能な様です。

       ただし、いわゆる専用ブラウザでは、スレッドの更新された部分のみを取得しており、その際には「あぼ~ん」(発言削除)があると整合性が取れないのでGZipデータは取得しないのが現状です。
      親コメント
    • 転送量課金でひぃひぃ言っているサイトの管理者とか。
  • by Anonymous Coward on 2003年03月21日 22時45分 (#283851)
    HTTPには、少なくとも1.0、もしかすると0.9からContent-EncodingというレスポンスフィールドとAccept-Encodingというリクエストフィールドが定義されているのですが。
    しかも、たいていのWebサーバとWebブラウザには、これらのエンティティエンコーディングに対応した機能が実装されているのですが。

    ハードウェアでやるってことに対する意味は認めなくもないんだけど、いつぞやのblog騒動と同じ位間が抜けてると思う。
    • by Li on (9067) on 2003年03月21日 23時43分 (#283881) 日記
      mod_gzipが対応したらそれはそれで喜ぶのでは?
      とかいいつつそれが役に立つかどうかはサーバーの運営をしたことが無いので分からない。
      とりあえず、 本家の書き込み [slashdot.org]をリンクしてみる。
      親コメント
      • mod_gzipが未対応なので、/.Jでは使えないですね。
        ちなみに/.JはGzip転送しています。古いOmniWebで保存すると、Gzipのまま保存する事がままあって、ちょっと面倒くさかったな。

        # しかし何度見ても本家Apacheセクションの配色には驚く
        親コメント
        • by Li on (9067) on 2003年03月22日 2時21分 (#283983) 日記
          うん、だから、mod_gzipが対応したら、の話。
          上の私の書き込みの本家のリンクでもある様に当然のことながら対応したものはまだ無い。
          けれども、其処の書き込みでは、ある程度のヒット数があるサイトの運営者はmod_gzipを外したときの負荷のグラフを見るとショックを受ける、と書いてあるぐらいだから結構な負荷になっているのかな?
          200$以下だったらうちのサーバーファームに速導入するよ、っていってるし。
          親コメント
    • by Anonymous Coward
      >HTTPには、少なくとも1.0、もしかすると0.9からContent-EncodingというレスポンスフィールドとAccept-Encodingというリクエストフィールドが定義されているのですが。

      リバースプロクシーと組み合わせて使うように書いてあるんだから、 まさにそれを使ってるんじゃないのかなと予想してるんですがねえ。

      >ハードウェアでやるってことに対する意味は認め

    • by Anonymous Coward
      これはカードであることが新しいのであって、 Webコンテンツをgzip等で圧縮する「箱」は何種類もありますね。 これ [packeteer.co.jp]とか。
    • by Anonymous Coward
      HTTP 1.1からでしょ。Accept-EncodingにGZIP圧縮のバイナリストリームが使えるのは。
      RFC [w3.org]
      Lynx等のクライアントは未だにHTTP 1.0でリクエストするし、携帯端末も然り。

      いつぞやのblog騒動と同じ

    • by Anonymous Coward
      ですが。ですが。ですが。ですが。
      ってなに?
      日本語の扱いは大丈夫ですか?あなたは何を言いたいのですか?

      「ですが、メーカーはそのことを知っているのでしょうか。」を省略しているのですか?
      「ですが、その決まりきった工程の一部をハードウェア化するのは汎用CPU
      • >> それらの意見表明を曖昧にするのが意図ですか?

        「皆は知らないかもしれないけど、俺はこんなこと知ってるんだぜ」という薀蓄を自慢したくて、でも、その薀蓄を元の文章と結びつけるような論理的な展開ができない場合に、とりあえず「ですが。」と文末に付けているだけだと思っていました。あれって本当は何か意図があるんでしょうか?
      • お前の日本語も十分変だよ。安心しな。
  • by Anonymous Coward on 2003年03月23日 11時17分 (#284498)
    どうなるんでしょう? 「別の方式」だから問題ないのかなぁ?

    http://www.matsusaka-u.ac.jp/~okumura/compression/patents.html
typodupeerror

アレゲはアレゲを呼ぶ -- ある傍観者

読み込み中...