【禁速】P2P速度を上げる為のあれこれ

↓3)改稿.2021/03/09...20210308...

＞　P2P通信の速度を上げる為の準備その１


　‥P2P通信の基本は暗号演算です
　暗号演算の対象となるファイルが大きければ大きい程
　メモリーキャッシュの割り当て増が効果的です

　（メモリーキャッシュが多くなることでドライブ負担が減るのも効果として絶大です）


　‥但し、メモリーキャッシュ容量を特定アプリに割り振りすぎると
　どうしたってシステムとして不安定になってきます（とくにメモリー残量）

　DDR3メモリーでそれは８Gバイトまでの割り振りが目安です
　なので、３倍の速度を得られるDDR5でも２４Gバイトが安定するだろう目安に思われます

　（当然、システム自体の安定を考慮すれば、それ以上を搭載すべきです）
　（あとはP2P通信用アプリ内での細かい調整をする必要があります）

1-3)1

＞　大きなファイルを取り扱うP2P通信において
＞　HDDの管理の仕方は避けては通れない手間です（準備その２）


　‥SSDとそこを比べてみても、ファイルが大きくなれば成る程
　熱問題が絡むことで、HDDとの速度差が無くなるという話らしい（未所持なので知らん）

　ということでここでは
　HDDを如何にして効率よく使用して通信速度を上げられるか？‥の話になります


＞　‥まずパーテーションを切りましょう


　大容量型の場合、速度を期待できるのは外周です
　内周にまでヘッドを送るようなパーテーションでは速度にムラがありすぎるばかりで無く
　耐久期待においても負荷が大きくなってきます

　‥目安は４TバイトHDDの場合なら
　外周を６４０Gバイトで切ると残りが概ね３Gバイトになります
　外周６４０Gバイトなら、１８０~170MB/Sでの安定速度を期待できます


　※但し、最外周が一番に速いかというとそうでもなく
　ヘッド読み取りには、ある程度の幅がある事で安定するとした条件があるらしく
　最外周の読み取りより、微に内側の方から安定する傾向があり、この癖に個体差は見られない

1-3)2

＞　使用するパーテーションをこまめにデフラグすることも大事です（準備その３）
＞　ファイルやフォルダー内が散らばっていない状態を保つこともP2P通信には欠かせません
＞　できれば普段から断片化を起こさない管理を心掛ける必要があります


　‥Windowsの場合、なぜか、コピペする段階において
　いくつかの癖が起きています

　‥まず、ドラッグする場合
　マークしたファイル群又はフォルダー群を選択した時
　どこを掴んでドラッグしたかが、とんでもな分かれ道になってます

　Windowsはなぜか、掴んでいるファイル名又はフォルダー名からコピぺを始めます
　そして次に、ファイル名順という具合になってます
　この微妙な違いが基本としてあり、さらに受け渡すドライブの空き状態によって
　不思議な容量効率を勘案した配置をしてくれちゃいます

　‥なので順番通りにコピペしたいなら
　選択を掴む場所を常に頭からとし、且つ、十分に連続した空き容量先である事が欠かせません


＞　さらに、厄介なのは


　大幅に削除して、十分に連続した空き容量があるように見えても
　わずかに小さなファイルが飛び地して、紛れ込んで残っていたりすると
　そこから適当な空きを設けて、飛び地を発生させてコピペしてくれちゃいます

　‥是は、そのようなファイルが無い状況でも
　同じドライブに対して何らかの並列作業をしていたりすると
　ヘッド移動の都合で、適当なところに割り振られて、フォルダー内部としては分断をやらかします


　‥これのような状況が複雑に絡み合って
　断片化は見られないけれど中途にフォルダー間での分裂配置がされていた場合
　デフラグ代わりに別のドライブに振ってから戻しても

　まったく寸分違わずにほぼ同じ配置のままだったりします
　まったく寸分違わずにほぼ同じ配置のままだったりします
　まったく寸分違わずにほぼ同じ配置のままだったりします

　（一体全体どうして配置を記憶しているかのようになるんだよ）

　このような場合はしょうがないので、フォルダー名を換えてみたり
　頭からの配置を変えるべく
　別の情報を持った何かを順番を変えてコピペして置き直したりをやってみます
　（同じ配置をやらかす前提になってる部分を潰すのです）
　（それでもダメなら、デフラグをして詰めざるを得ません‥何て面倒くさい‥）
　（多少でしたら、その部分量だけ、後ろから配置技のできるデフラグを行います）

　状況的に量がある場合、大抵はまとめてフォルダーを一気に行って来いしたりしますが
　それをやると
　以上のような複雑さが残っている場合
　うまく綺麗にフォルダー順に配置されるずに、実は部分的にぐちゃぐちゃだったりが起こります
　（それ程に気にする程では無いけれど、再度入れ直したりする場合に後々的に厄介です）


　‥つまり、綺麗に削除したつもりでも、システム管理されたファイルが飛び地していたりすると
　HDDの頭からコピペしているつもりでも、其れのある箇所から飛び地が発生します
　（空っぽにして入れ直すなら、クイックフォーマットしてしまうのが確実です）

1-3)3

＞　‥そうです、HDD内ファイルの断片化に寄与しているのは
＞　作業都合上のヘッドの位置が絡んでおり、適度に割り振られてしまう
＞　技術がアナログ的発想のままに停滞したままである事です


　（この特性は、P2P通信速度を効率的に上げようとする上でのネックです）


　‥一番単純な作業ファイル作成などはとくに
　空いているブロックに頭から順に置いていく癖があることから
　そのようなドライブ状態でのファイル作成は常に断片化に晒されます

　（SSDには、できる限るブロックをまとめてからコピペするように機能があるようです）
　（CRM方式のHDDには皆無でしょう‥だから一時的処理としては速いのではあるが‥）


　‥さらに最近ではSSDの都合がHDDにも及んでいるらしく
　まんべんにドライブを使用しようとする傾向にあるようです
　主に、そのような傾向は
　HDDへの大容量書き込みを急いだ作業時などで、フォルダー内は大きく分断されがちです

　その昔、磁性の縦配置方式に切り替わった頃
　磁化の状況によってはプラスが多い箇所にマイナスがポツンとあると反転してしまうなんて
　言われていましたが（その逆も然り）
　今はそういう技術段階からは遠く、気にする程に無いはずなのに
　その手のルーチンが含まれているからかも知れません
　（どちらにせよ、偏ったままより万遍なく使うに越したことは無いので、まぁしょうがない）


＞　ということからも
＞　外周と内周とを意図的に使用分けしたパーテーション確保をせざるを得ないのです


　なので技術的希望としては
　外周をCRM、内周をSRMとしたハイブリットなフォーマットができたら良いのではないかと‥