Gluon: mt76：チップセットの制限

正直なところ、この機能を最も幅広いデバイスで利用できるかどうかさえわからないという事実を考えると、現在持っていない制限について警告を出すのは好きではありません。

誤解しないでください、私はこれが実装されることを望んでいます。 しかし、ワイヤレスドライバに関しては、802.11nを超えて移行したい場合、すでに両端で妥協している状態にあります。 また、mt76がすでに2世代遅れている基準を対象としていることを考えると、持続可能性のポイントは複雑な感じがします。

@blocktrron私はあなたのポイントを理解し、以前にもそれらについて考えました。 人々はまだメッシュに5GHzを使用することを推奨しています。 その推奨は、広範囲にわたる5 GHzのサポートがなく、5GHzの周波数がそれほど占有されていなかった時代からのものでした。 2.4 GHzはより優れた伝搬特性を備えており、2.4 GHzは、私たちの目的のために今後数年間で大幅な改善が見られなくなる段階に近づいています。 私が言いたいのは、2.4 GHzデバイスは来年は問題なく、ath9kチップセットはmt76とは対照的に将来性があるということです。 私はすでにメインラインカーネルMCCA実装のための資金調達に取り組んでいます。 多くの組織は、これを統合することに関心を持っています。 これが今後数年以内に発生する可能性は十分にあります。 ユビキタスについて考えてみてください。ath9/ 10kと同じ機能があると思うなら、mt76に切り替えますが、低予算の消費者向けルーター用のチップです。 必要に応じて、オーバーデザインされたMPCを備えたWDR4900と、安価なMIPSプロセッサを備えた841Nを比較してください。 TP-Linkは、消費者向けルーターにエンタープライズCPUを使用していました。これは、市場に安価なものがなく、ニーズに合うものがなかったためです。 TP-Linkで使用されているath9 / 10kチップでも同じです。 これらのチップの方が優れているため、mt76に切り替えませんが、安価であり、ニーズに適合しているためです。 大きなwifiメッシュクラウドが存在する可能性が低い、または人々がまだ互いに話し合ってネットワークを計画したり、チャネルを切り替えたりできる農村地域では、mt76で問題ありませんが、ルーターでそのようなものを構築したいだけの場合はあまりにも多くのノードで壊れない自律的なネットワークには、MCCAが必要です。

2.4 GHzで大幅な改善が見られない理由を自問する場合は、次のようにします。

• テクノロジーが急速に急速に向上するという私たちが当然と思っていた推定は、もはや当てはまりません。 WiFiは、今後数年間、平均的なブロードバンド接続の要件よりも優れたパフォーマンスを発揮するようになりました。 ターゲット市場はもはやヨーロッパとアメリカではなく、アジアとアフリカです。 mt76ルーターはヨーロッパのこれらの大陸で5ドルかかりますが、消費者は製造コストの値下げに気付いていないため、20ドル以上かかります。
• 高帯域幅の消費者の要件については、開発の次のステップはすでに知られています。
  より広いチャネル幅を使用し、5GHzチャネルでスペクトル効率を向上させる
  フェーズドアレイアンテナと動的低電力伝送を利用して、ニアフィールドでコンテンツを配信します（クライアントデバイスは通常、消費者向けセットアップのアクセスポイントから20 m未満離れており、フラットのブロック内のデバイスの密度が問題のチップであるため）メーカーは現時点で解決しようとしています）
• 2.4 GHzで計画されている改善は、5 GHzチャネルでそれを集約し、ACのようなスペクトル効率を改善することです->これにより、近距離場の帯域幅は改善されますが、距離ではそれほど改善されません。 ACがレガシー802.11nと比較してUbiquityAirMaxデバイスで非常に優れたパフォーマンスを発揮する理由は、それらが交差偏波アンテナを使用しているためです。 民生用ルーターではすべてのアンテナが垂直偏波であるため、改善は主に近接場にのみ適用されます。

正直なところ、私は現在私たちが持っていない制限について警告を出すのは好きではありません

この制限はハードウェアにある可能性があります。 このチップセットが送信スケジューリングをサポートする可能性はほぼゼロです。

この機能を最も幅広いデバイスで利用できるかどうかさえわかりません。

この機能は、2年以上前から計画しているので、少なくともath9kでは使用できます。 また、ath10kのサポートは、金銭的な問題にすぎません（candelatechファームウェアで必要な機能を実行するため）。 しかし、現時点ではGluonが正しい方向に進んでいるとは思えないため、現時点ではオープンソースに貢献する気はありません。 フレームスケジューリングをサポートしないメッシュクラウド内のすべてのルーターが干渉します。 それは注目に値します。

グルーオンが正しい方向に進まないと感じるのはなぜですか？ 私たちが常に望んでいたのは、より多くの貢献者がいることであり、今では彼らがいます。 彼らは多くの仕事をします、それが合併されるまで誰も見ることはありません。 彼らのコード品質は、例えばNeoRaiderによって私たちが慣れているものではないかもしれませんが、それはすべてブロックされており、ここでは誰もそれをマージするのを手伝っていません。 現時点でのほとんどのコミットは「パッケージの更新/ OpenWrtの更新」などです。もちろんそれを行う必要がありますが、それは進歩ではありません。 代わりに、「パッケージの更新」をコミットするのがコミットする人であるという理由だけで、解決するよりも多くの問題を引き起こす機能を実装します...唯一受け入れられているコミュニケーション方法はIRCです。 IRCの時間がないので、少し感情を表現したり、ここでホームトゥルースを言ったりすると、絵文字が親指で表示されます。 Githubで誰かに中指を見せているようなものです。

言いたい奴には言わせとけ。

あなたのコメントの半分はここのこの問題に属していません、多分メーリングリストについてあなたの懸念を表明してください。
（このリポジトリは主にコードに関するものであるため、他のgithubの問題もメーリングリストに適している可能性があります）

私はmt76レジスタを調べましたが、nbdが認識していなかった送信スケジューリングを有効にするためのmt76チップセットの回避策があると確信しています。 とりあえずこれを閉じます。