2017年11月11日土曜日

第1回 キノフィットkinofit

忘れないうちに指摘事項をメモ+所感

メモ
1) 腹筋が使えていない
     → かかとが下がっている(サドルが低い)
     → 意識して回さない、フィッティング後は意識せずとも回る状態になっている
     → おなかを出すようにする

2) 今後1か月は負荷をかけるよりも今日教わった体の動きを身に着けることに専念する
    → 負荷をかけると腹筋が使えなくなり骨盤の角度が変わり今のフォームでは回せない(フォームが身につかない)

3)  動画を使って動作を確認すること。

4) 肩を丸めない肩甲骨を中央に寄せて溝を作ってあげる

5) 交換したサドルは尿道部分が固いので圧迫されるかも

6) 2)を実行するとき、左右の音に気を配る(一定の音で回せているか)+片足ペダリングでも同様に確認する
   負荷は軽くして、ケイデンスも低めでゆっくりとした動作で行うようにする
 


所感
1) 「とりあえず回してみましょう」から始まる、斬新
 ・ メジャーで測ることで得た結果が良いとは限らない
 ・ 過去にケガをした、体が硬いといった外因も考慮したフィッティング
 ・ 今回の結果がすべてでなく、その後も柔軟性や筋力が向上することで変化していく

2) フレーム、ホイール以外のパーツに金をかけたのは初めてかも
 ・ 今回はハンドルバーとサドルを交換した(420mm→440mmでアーチが深い)
 ・ ハンドルは狭い+近いと感じたから
 ・ サドルは何でもよいが現サドルではこれ以上後ろに引くことができないのでやむなく交換した
 ・ ステムの交換は割と多いらしい
  → ハンドルを交換したことで両手が縦と横に遠くなり結果、ちょうどよい長さになったのでステム交換は不要だった

 3) メカニコのフレームに興味持ってくれてうれしい...
 ・ 「フレームホイールいいもの買ったって基本がなってないと性能を活かせないよ」だそう(エンジンが大事)

 4) 体の使い方は良いと褒められて素直にうれしい...
 ・ ポジションがあってないことでフォーム・ペダリングがおかしくなっている
 ・ ずばっとはっきり話してくれるので頭にすっと入ってくる

 5) 根拠を交えて話してくれるので説明に納得がいくし、内容も実に興味深い(1.5hあっという間)


とりあえず今回はこんなところでしょうか。


2017年5月6日土曜日

カーボンフレーム納車

メカニコさんにカーボンフレームを注文して、先月到着ー。
パーツ類はwiggleでまとめて購入。
以下、構成。

  • コンポ: アルテグラDi2
  • ホイール: レーシング4
  • ステム: Deda zero100
  • ハンドル: Deda zero100
  • シートポスト: Deda zero100
  • 他…
重量はおそらく7.2kgくらい。
手持ちのホイールとサドルを付け替えたら6.8kgを下回る。

最終調整は高知の城北サイクルさんに依頼した(¥2000)。
お安く済んで満足^^

下ハンドルが握りにくいので角度をつけてブラケットの位置を再調整しなくては。


2017年3月26日日曜日

フレームアグリゲーション有効/無効時におけるiwlwifiの挙動

送信処理
  • DMA転送は1フレームごとに行われるため,フレームアグリゲーションの有無で処理は変わらない

送信完了処理
  • フレームアグリゲーション無効時
    • ACKフレームの結果を通知し,当該フレームをiwlwifiの送信キューから破棄する.
    • 必ず,1フレームごとに処理が行われる(1フレーム破棄/1回の送信完了処理)
  • フレームアグリゲーション有効時
    • デバイスから3種類の通知情報を受信する
      • フレームアグリゲーションの結果(※送信結果ではない)
        • アグリゲーションされたフレーム(確認した限りでは最大で5フレーム)のそれぞれの,転送結果,再送回数(転送回数?),etc...
        • デバイスへ転送時,つまりACKフレームの到着前に通知されるため,この段階では送信結果はわからない(コード中のコメントより)
      • Block-ACKの結果(送信結果)
        • 結果をもとに破棄可能なフレームを決定する
        • TCPと同じように宛先へ到達の確認が取れているフレームまでを破棄することが可能
          • 例:1,2,3,4を送信→3のみロス→1,2を破棄→3を次回の送信機会で最初に送信(再送)する
          • TCP+Sackみたいな感じ...
          • 無効時と同様にアグリゲーションされたフレームの再送にも上限回数があるっぽい
      • ACKフレームの結果(送信結果)
        • フレームアグリゲーション有効時でも単発のACKが帰ってきた場合は上記と処理が異なる
          • 単発か否かの判定はここ
            • フレームアグリゲーション無効時の場合は常にtx_resp->frame_countが1で,有効はおそらく1〜5
        • 破棄するフレームは,ACKフレームに該当するフレームとそれ以降連続して確認が取れているフレームまで
          • 例:1,2,3,4,5送信→3のみロス→1,2を破棄し3を再送→3をACK→3,4,5を破棄
        • アグリゲーションしたフレームの再送に上限回数があるのはヘッドラインオブブロッキングを防ぐため
        • 呼ばれる関数は無効時と同じであるが,1回の処理で複数のフレームを破棄するため処理が異なる