トップ «前の日(06-24) 最新 次の日(06-26)» 追記

Orz日記 by Akio Morita

ToDo:

  • 15 SAD Fit[]回りの障害事例の解析
  • 10 smart pointer版PEGクラスの再実装(Left Recursionまわり)
2006|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|06|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|07|08|09|10|11|12|
2013|01|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|06|07|08|10|12|
2016|01|02|03|05|06|08|10|11|
2017|01|02|03|04|05|06|07|09|10|11|12|
2018|01|02|03|04|06|07|08|09|10|11|12|
2019|01|03|04|05|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|

2007-06-25

_ [FreeBSD]9650SE Firmware 3.08.02.005

Auto Verifyは正しく働く模様なので、一安心


2008-06-25

_ [LHC]軌道応答からのTransfer Matrixの再構築

色々試してみたが、安定性を考えると愚直なアルゴリズムが良いようで、 Transfer Matrixの候補を使って軌道応答(x_i)の一部の情報から (x_n, x'_n)ペアを推定してこれを転送することで軌道応答の推定値を 組立て、軌道の誤差2乗和で評価関数を組み立てて共役勾配法で 誤差を最小化するコードを組んでみたのだが...

どうやら、解にエイリアスが発生する(近傍に別の極小点が存在する)模様です。

まず、モデルの Transfer Matrixを出発値にして共役勾配法を走らせるて 収束した値を基準にして、これへガウスノイズを加えた別の出発値から 共役勾配法を走らせ結果との距離を測ると...別の極小に落ちてる用に見える。

最小化している誤差2乗和の大きさは両者ともに同じ程度 $3\times10^{-7}$ で、各点毎の軌道応答と推定値の残差は $1\times10^{-7}$オーダーで 二つの結果の差異は $3\times10^{-9}$に入っている。

位相空間の推定に使うサンプルの位置を変えても、収束後の値では評価値は 変わらない(収束前は当然、矛盾を含むので影響がある)ので、 そういう改良では解決出来そうに無い。

取り合えず、

  1. 入力情報(軌道の種類)が不足している
  2. 評価関数が真の解近傍に極小点を多数持っている

のどちらに本質的な問題が有るかを調べるために入力情報を増やした テストを実施してみる。

未知変数と方程式の数を大雑把に数えた限りは決定出来そうなのだが...


2013-06-25

_ [雑記][Admin]hiki-1.0.0へ移行完了

表記の通り、hiki-0.8.8.1から hiki-1.0.0へ移行した

手製のコンテンツ変換ツールは、EUC-JPと UTF-8間で相互変換可能になったので、問題が生じた時は巻き戻せる

ただし、svn backendによる編集履歴は、コード変換を跨げない

内部コードは、サイトの設定依存で既知なので、dorce_encodingをつければサポートできそうな気もするのですが…


2020-06-25

_ [FreeBSD][IPv6]OCNのIPv6接続

OCNにてIPoE IPv6インターネット接続を無料提供が始まったようなので、技術情報を集めてみる

技術的には、OCNバーチャルコネクトとよばれるものと同じらしい

接続技術は、IPv6 over EthernetとIPv4 over IPv6トンネルで構成されている

IPv6 over Ethernet

基本的には、境界ルーターからRAが流れてきて、IPv6 stateless configurationでアドレス設定が完了する

Firewallがある場合は、ICMPv6を通過可能にしておかないと自動設定が完了しない点に注意

IPv4 over IPv6

基本的には、境界リレーとIPv6 over Ethernetで構成されたインターフェース間にIPv4パケットをカプセル化したIPv6パケットで中継する

OCNバーチャルコネクトや有償オプションのOCN v6アルファでは、MAP-E方式のトンネリングが採用されている

MAP-Eの特徴

  • Global IPv4へのNAPTは、エンド側で行う必要がある
  • NAPTのために払い出されるGlobal IPv4 addressとport rangeは、IPv6 over Ethernetで設定されるv6 address prefixから自動的に決定される
  • NAPTのために割り当てられるport-rangeは、複数のrangeから構成させる
    • おそらく、port numberの割り当て公平性を重視した設計と思われる
    • Global IPv4 worldからの着信につかえるport番号は、断片的に割り当てられるので、well known portが使える保証が無い
      • HTTPやSMTPを標準portで受け取れないので、Dynamic DNSによるサービスには向いていない
      • したがって、Server Serviceは、PPPoEリンク上に構成する必要がある
        • Serverを構成する場合、IPv4トラフィックのルート選択を行う必要が出てくる
    • 境界リレー等の構成情報は、Web APIから得られる模様だが、Web APIキーは未公開
      • 有志が解析したデータベース有り

したがって、運用的には

  • gifで境界リレーとエッジ側のインターフェース間にIPトンネルを形成する
  • IPv4パケットをNAPTして、gifトンネルに流し込む
    • ポートレンジが断片化しているので、NAPT層にport range構成を設定する必要あり
    • ipfw + natdを使うなら、新規port割り当て部をMAP-E対応に改造する必要あり
    • 改造対象は、libalias/alias_db.c内のGetNewPortおよび設定データベース&構文解析部
      • GetNewPortにて、MAP-E仕様のPort番号を生成する
      • port rangeを決めるPSIDパラメータを設定データベースに格納する

先人たちの情報


カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記