Gluon: mt76: 칩셋 제한 사항

솔직히 말해서, 우리가 가장 광범위한 장치에 이 기능을 사용할 수 있을지조차 알 수 없다는 사실을 감안할 때 현재 우리가 갖고 있지 않은 제한에 대한 경고를 표시하는 것을 좋아하지 않습니다.

저를 오해하지 마십시오, 나는 이것이 구현되는 것을 보고 싶습니다. 그러나 무선 드라이버와 관련하여 802.11n 이상으로 이동하려면 이미 양쪽 끝에서 타협하는 상태에 있습니다. mt76이 이미 2세대 뒤쳐진 표준을 목표로 한다는 사실을 감안할 때 나는 또한 만감이 교차하는 지속 가능성 지점을 봅니다.

@blocktrron 나는 당신의 요점을 이해하고 이전에도 그것에 대해 생각했습니다. 사람들은 여전히 ​​메싱에 5GHz를 사용할 것을 권장합니다. 그 권장 사항은 5GHz 지원이 널리 보급되지 않았고 5GHz 주파수가 그렇게 많이 차지되지 않았을 때였습니다. 2.4GHz는 더 나은 전파 특성을 가지고 있으며 2.4GHz는 우리의 목적을 위해 향후 몇 년 동안 크게 개선되지 않을 지점에 가깝습니다. 내가 말하고 싶은 것은 2.4GHz 장치가 내년에는 괜찮을 것이고 ath9k 칩셋은 mt76에 반대되는 미래의 증거라는 것입니다. 저는 이미 메인라인 커널 MCCA 구현을 위한 자금 조달을 위해 노력하고 있습니다. 많은 조직에서 이를 병합하는 데 관심이 있습니다. 앞으로 몇 년 안에 이것이 나올 가능성이 높습니다. Ubiquity를 생각해 보십시오. ath9/10k와 같은 기능이 있다고 생각한다면 mt76으로 전환할 것이지만 저예산 소비자 라우터용 칩입니다. 원한다면 MPC가 지나치게 설계된 WDR4900을 저렴한 MIPS 프로세서가 있는 841N과 비교하십시오. TP-Link는 소비자 라우터에 엔터프라이즈 CPU를 사용했습니다. 시장에 더 저렴한 제품이 없었기 때문입니다. TP-Link에서 사용하는 ath9/10k 칩과 동일합니다. 이 칩이 더 좋기 때문에 mt76으로 전환하는 것이 아니라 더 저렴하고 여전히 요구 사항에 적합하기 때문입니다. 큰 Wi-Fi 메시 클라우드가 있을 가능성이 낮거나 사람들이 여전히 서로 이야기하고 네트워크를 계획할 수 있는 시골 지역의 경우 채널 등을 전환할 수 있습니다. 너무 많은 노드로 중단되지 않는 네트워크를 자율적으로 사용하려면 MCCA가 필요합니다.

2.4GHz에 대한 엄청난 개선이 없는 이유를 스스로에게 묻는다면:

• 기술이 지속적으로 빠르게 발전할 것이라고 당연하게 여겼던 가정은 더 이상 적용되지 않습니다. WiFi는 향후 몇 년간 평균적인 광대역 연결 요구 사항보다 더 나은 성능을 발휘하는 지점에 도달했습니다. 목표 시장은 더 이상 유럽과 미국이 아니라 아시아와 아프리카입니다. mt76 라우터는 유럽 대륙에서 5달러이지만 소비자는 제조 비용의 가격 하락을 인식하지 못하기 때문에 20달러 이상입니다.
• 고대역폭 소비자 요구 사항의 경우 다음 개발 단계가 이미 알려져 있습니다.
  더 넓은 채널 폭을 사용하고 5GHz 채널에서 스펙트럼 효율성 향상
  근거리에서 콘텐츠를 전달하기 위해 위상 배열 안테나 및 동적 저전력 전송 사용(클라이언트 장치는 소비자 설정에서 액세스 포인트에서 일반적으로 20m 미만이고 플랫 블록의 장치 밀도가 문제의 칩이기 때문에) 제조업체는 현재 해결하려고 합니다)
• 2.4GHz에 대해 계획된 개선 사항은 5GHz 채널로 집계하고 AC와 같은 스펙트럼 효율성을 개선하는 것입니다. AC가 레거시 802.11n에 비해 Ubiquity AirMax 장치에서 우수한 성능을 보이는 이유는 교차 편파 안테나를 사용하기 때문입니다. 소비자 라우터에서 모든 안테나가 수직으로 편파되기 때문에 개선 사항은 대부분 근거리에만 적용됩니다.

솔직히, 나는 우리가 현재 가지고 있지 않은 제한에 대한 경고를 표시하는 것을 좋아하지 않습니다.

하드웨어에서 이러한 제한이 있을 수 있습니다. 이 칩셋이 전송 스케줄링을 지원할 가능성은 거의 0에 가깝습니다.

가장 광범위한 장치에 이 기능을 사용할 수 있을지조차 알 수 없다는 사실을 감안할 때.

저는 이 기능을 2년 이상 동안 계획하고 있기 때문에 적어도 ath9k에는 이 기능을 사용할 것입니다. 그리고 ath10k에 대한 지원은 금전적인 문제일 뿐입니다(candelatech 펌웨어에서 필요한 기능을 수행하기 위해). 그러나 현재로서는 Gluon이 현재 올바른 방향으로 가고 있다고 보지 않기 때문에 오픈 소스에 기여할 의향이 없습니다. 프레임 스케줄링을 지원하지 않는 메시 클라우드의 모든 라우터는 간섭자가 됩니다. 그것은 주목할 가치가 있습니다.

나는 왜 글루온이 올바른 방향으로 가고 있지 않다고 느끼는가? 우리가 항상 원했던 것은 더 많은 기여자를 갖는 것이었고 이제 우리는 그들을 갖게 되었습니다. 그들은 병합될 때까지 아무도 볼 수 없는 많은 작업을 수행합니다. 그들의 코드 품질은 예를 들어 NeoRaider에서 사용하는 것과 다를 수 있지만 모두 차단되었으며 여기에서 아무도 병합하도록 도와주지 않습니다. 현재 대부분의 커밋은 "패키지 업데이트/OpenWrt 업데이트" 등입니다. 물론 수행해야 하지만 진전이 없습니다. 대신 우리는 단지 그것을 커밋하는 사람들이 "업데이트 패키지"를 커밋하기 때문에 그들이 해결하는 것보다 더 많은 문제를 만드는 기능을 구현합니다... 유일하게 허용되는 커뮤니케이션 방법은 IRC입니다. IRC를 할 시간이 없고 여기에서 감정을 표현하거나 가정적인 사실을 말하면 엄지손가락 아래로 이모티콘을 받습니다. 그것은 Github에서 누군가에게 가운데 손가락을 보여주는 것과 같습니다.

싫어하는 사람들은 싫어할 것입니다.

귀하의 의견 중 절반이 이 문제에 속하지 않습니다. 메일링 리스트에 대해 우려를 표명할 수 있습니다.
(이 저장소는 대부분 코드에 관한 것이기 때문에 메일링 리스트에 더 적합할 수도 있습니다.)

나는 mt76 레지스터를 보았고 nbd가 인식하지 못한 전송 스케줄링을 가능하게 하는 mt76 칩셋에 대한 해결 방법이 있다고 확신합니다. 지금은 이것을 닫습니다.