以下の様なコードを実行した．．．。

cat *.csv > convert.csv

出力されたconvert.csvの中身が派手にぶっ壊れている。

もしかしてcatコマンドは古いツールだからUTF-8に対応していないのか？

BOMとかそういうのが悪さしているか？

．．．色々と考えた結果、

すでにconvert.csvというファイルがあって、
それを*.csvとしてワイルドカードでまとめている、
つまり、マッチポンプっつーか、再入力しているっつーか、
アウトプットファイルがインプットファイルにもなっているため、
壊れていたもよう．．．。

残念な間違い。

参考（このブログエントリーの本質については書かれてないけどbpsがあてにならないことは説明されている）
itpro.nikkeibp.co.jp/article/COLUMN/20090617/332116/

標題の通り。ハブもルータもコンピュータに過ぎない。

小さいパケットが複数飛んだりすれば、それだけＣＰＵが動いてメモリに展開され角ポートに振り分けるので、いくらハード全体のbpsやppsがギガビット対応であっても実測値はでません。100BASEのプラネックスのＬ２ハブの方が1GBのコレガハブより複数ポートを指して利用したら固まらず快適だったことがある。ギガビットという表記に騙されてはいけません。安いギガビットハブより高い１００ＢＡＳＥハブの方がみんなでインターネットするなら快適です。

つまり、理論値だけ見ても使えるかどうかわかりません。

特にメモリが小さければさばけず重くなりやがて落ちざるをえなくなるこれが現代型コンピュータの宿命。

だいたいppsなどの総パケット店総数は決まったサイズのパケットを飛ばした最速の理論値に過ぎず、安価なハードはその価格程度の力しかないのは明白です。ちょっと話が逸れますが、この「理論値と実測値は違う」という言い方は、マジックワードというより無意味で曖昧な理解になってしまう原因ではないかとすら、私は思うようになりました。理論値は実測値に伴なわないということは、理論値そのものの出し方に問題があるということだし（bpsは平均値に過ぎないと分かった上で言っています）、とにかく理論値はそもそもあてにならないという理解は変だ。

理論があてにならんと言うのは身も蓋もない。

理論は理論でそれそのものは大変役立つものである。
というスタンスをいわゆる理系/技術者ならとらないとダメでしょう。

理論を実践以下に貶めてはならない。

じゃあなんて言えばいいか？

「ネットワーク機器のマニュアル記載の情報だけでは正確なスループットはわかりかねる」こういう方が理論的でしょう。

RFCではスループットを出すにあたってbpsでもppsでもよいと書かれているらしいですが、
httpでＷｅｂサイトを閲覧するとなるとだいたい細かいパケットが沢山飛ぶので64bitで算出した値はでるわけがない。

参考
detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1218091427

本質を理解しないとRFCも読み間違えるような気がします。

コンピュータは奥が深いというか、
本質の受け取り方を間違えると長く迷走する世界だと思う。
他の業界/世界もそうかもしれませんけどね。。

※変に職人技を経験則のせいにしたてあげるのではなく、
　きちんとマニュアルにかかれていない理論が分かれば、
　職人にすぐになれるのだということを私は言いたい。

※自宅にもいつかアライドテレシスの機器でいいから欲しい。

【送料無料】【カード決済可能】【ショップ・オブ・ジ・エリア 2013 東北エリア賞を受賞いたし... 価格：12,260円（税込、送料込）

ＤＮＳの安全な切り替え方について。

（ドメインに対応するＩＰアドレスの切り替えで、Ｗｅｂサーバを切り替えた場合の例）

店舗や中小企業のＷｅｂページを制作している人は、
ドメインに対応したＩＰアドレスを変更した場合、
ＤＮＳの浸透は数時間せいぜい１、２日で済むと思っているかもしれない。
（というか、私はそう思っていました。）

ところがクリティカルなＷｅｂサイトやクリティカルなメールサーバの移行の場合は、
そういったアバウトな感じで行うことはできません。
ＤＮＳのゾーン変更でも１～３カ月の長い期間を見て行わないといけません。

なぜでしょう？以下のような理由があげられます。

１．世の中のＤＮＳサーバがＴＴＬを気にしているとは限らない。
　　（BINDなどではなく独自実装のプログラムが無いとも限らない）
２．ルータやクライアントサイドのアプリケーションなどのＤＮＳキャッシュは、
　　ＤＮＳサーバのＴＴＬなぞ気にせず自分のタイミングで廃棄したりもする。

つまり、端的にいえばＴＴＬは相手にキャッシュ保持期間を
マストでコントロールできるものではないのです。

ＤＮＳの伝播の仕組みは堅いものではありません。
ＴＴＬ値が利用されるべきことは相手の性善説に基づくものであって、
それをビジネス上の「正しくアクセスできない」理由にはできないのです。

ですから、ＤＮＳ切り替えは以下のような手順で行われなくてはいけません。

【ＤＮＳサーバの切り替え手順の例】

（１）ＤＮＳサーバの変更するゾーンのＴＴＬだけを１０分に設定して１，２カ月放置する。
　　（世界中のＤＮＳサーバにゾーンの書換えを素早く行ってもらうための情報をばらまく）
（２）ドメインに対するＩＰアドレスを変更する。
（３）しばらく放置（目安は１～２週間）し、
　　　Ｗｅｂサーバのログを見てアクセスが無ければ、移行元サーバを停止する。
（４）TTLを常識の範囲（１時間～１日程度？）に戻す。

ＤＮＳの安全な切り替えは最低でも１カ月ほどかかります。。

Ｗｅｂサーバでもメールサーバでも切りかえた時は、
１カ月とはいいませんが１週間程度は移行元サーバにアクセスされることがあります。
メールサーバのＤＮＳキャッシュ時間が長いということもあるということなのでしょう。

甘く見ていると痛い目に合うのが「ＤＮＳの浸透」です。

慎重に余裕を持って作業をしましょう。

インターネットを支える仕組みとして、
ＤＮＳ（ドメインネームサーバ）の仕組みが分かるようにしましょう。

【送料無料】 おうちで学べるネットワークのきほん 初心者のためのTCP / IP入門 / gene 【単行本】 価格：2,138円（税込、送料込）