Tekrarlayan 528 ms takılmanın ardındaki AWDL radyo zamanlaması: Uygulama hatası gibi görünüyor

Uygulamada olmayan bir takılma

dev.to'da yazan bir geliştirici, ekran paylaşımı uygulaması ExtendPilot'taki imlecin kısa süreliğine ve tekrar tekrar donmasının ardından bir hafta süren bir hata ayıklama serüvenini belgeledi. Uygulama bir Mac ekranını peer-to-peer Wi-Fi üzerinden iPhone ve iPad'lere yansıtıyor ve onu deneyen herkes takılmayı başka her şeyden önce fark etti. Kendi kodlarını arayan ekip sonuç alamayınca, duraklamaların kaynağını radyonun tasarlandığı gibi davranmasına kadar izledi: AirDrop, AirPlay ve MultipeerConnectivity'yi taşıyan peer-to-peer Wi-Fi katmanı olan Apple Wireless Direct Link, sabit bir zamanlamayla yayından çıkıyor.

Sayılar, kendi kendine yaratılan tıkanıklığı dışladı

İlk şüpheli, uygulamanın trafiğinin %99'undan fazlasını oluşturan kendi video akışıydı. Ortak bir sıra numarası üzerinde sunucu ve izleyici günlüklerini ilişkilendirmek tam tersini gösterdi: Tipik bir duraklamadan önceki 300 ms içinde gönderilen medyan video miktarı 3 KB, yani kabaca 0,08 Mbit/s idi — bağlantının ortalama taşıdığı 1,58 Mbit/s'nin yaklaşık yirmi katı altında. Duraklamalar, uygulamanın kendisiyle rekabet etmesi değildi.

Aralıklar ipucunu verdi. 97 bölümde, duraklamalar arasındaki boşluklar 528, 528, 528, 512, 528, 528 olarak okundu ve medyan 528 ms'ydi. Girişim ve çekişme patlamalar halinde gelirken, milisaniyeler içinde tekrar eden bir boşluk bir saate işaret eder. AWDL eşlerini 512 TU'luk bir periyot üzerinde senkronize eder ve 802.11 spesifikasyonunda bir TU 1.024 mikrosaniyedir; bu da periyodu 524,288 ms yapar. Ölçülen 528 ms, yazıya göre duraklamaların radyonun kendi erişilebilirlik pencereleri olduğunu gösterecek kadar yakından eşleşiyor; paketler bir sonraki pencere açılana kadar kuyruğa giriyor. Hiçbir şey kaybolmuyor ve hiçbir şey yeniden denenmiyor; her kayıp metriği sağlıklı bir bağlantı bildirdiği için bu yüzden.

AWDL neden hiç sessizleşiyor

AWDL kanal atlar. Bir cihazın tek anteni vardır ve onu, bir yönlendiricinin kullandığı altyapı kanalı ile eşlerin birbirini keşfettiği AWDL sosyal kanalı arasında zaman paylaşımlı kullanır. Eşler, aynı anlarda uyanık olacakları bir zamanlama üzerinde anlaşırlar; o anlar arasında peer-to-peer bağlantı fiilen yoktur. Tek radyonun aynı anda iki ağa hizmet etmesi böyle olur, ancak bu, periyodik gecikme sıçramalarının peer-to-peer Wi-Fi'ye özgü olduğu ve üzerine katmanlanan her protokolün bunları devraldığı anlamına gelir.

Bunun uygulama hatası gibi görünmesinin üç nedeni

Birincisi, uygulamalar radyoyu seçmez. macOS üzerinde MultipeerConnectivity altyapı Wi-Fi, AWDL veya Ethernet seçebilir ve hiçbir API bu kararı bildirmez; bu yüzden aynı cihazlardaki aynı kod, temeldeki bağlantı değiştiğinde farklı davranabilir.

İkincisi, güvenilir teslimat boşluğu gizler ve sonra bir dizi serbest bırakır. .reliable gönderimleri sıralı olduğu için, 300 ms'lik radyo yokluğuna yakalanan kareler kuyruğa girer ve pencere açılır açılmaz toplu halde teslim edilir — donma ve ardından yetişme olarak görünürken teslim oranı %99'a yakın kalır.

Üçüncüsü, gecikme dağılımı çift tepelidir. Paketlerin yarısı şimdiye kadar ölçülen en iyi geçiş süresinin 4 ms içinde vardı ve %15'i ondan 120 ms'den fazla geride kaldı, ikisi arasında az şey vardı. İki popülasyon üzerinden hesaplanan bir ortalama ikisini de tanımlamaz ve kayda değer görünmez.

Düzeltmek yerine emmek

Hiçbir bayrak, öncelik sınıfı veya API, radyoyu bir uygulama adına uyanık tutamaz. Geliştiricinin cevabı, gelen veriyi kısa süre tutan ve gönderenin saatine göre oynatan bir jitter buffer'dı. 50–160 ms'lik uyarlanabilir bir tampon, donan imleç karelerini %12,8'den %2,7'ye düşürdü; bedeli, en fazla 160 ms eklenen gecikmeydi. Duraklamalar hâlâ tam olarak aynı sıklıkta oluyor; düzeltme onları onarmak yerine görünmez kılıyor. Videoyu ayrı bir Network.framework şeridine taşımak da yardımcı olmazdı, çünkü iki şerit de aynı radyoyu paylaşır.

Yazı ayrıca tanılama yöntemleri sunuyor. Mac'te, canlı bir oturum sırasında netstat -I awdl0 -w 1 komutu trafiği AWDL'nin taşıyıp taşımadığını gösterir ve aynı oturumu iki kez çalıştırmak — bir kez telefonun Wi-Fi'si kapalıyken, bir kez aynı SSID'ye bağlıyken — kaba bir A/B testi olarak işlev görür. Yeniden denemeler radyonun periyoduna yakın tetiklenmemelidir: sabit bir 150 ms kurtarma aralığı bir keresinde 107 saniyede 360 istek üretti ve her biri yük ekledi. Tamponlar asimetrik olarak uyarlanmalı, hızlıca yükselip yavaşça düşmelidir; TCP'nin AIMD'si gibi. Yazar, ölçümlerin tek bir cihaz çiftinden ve 60 saniyelik çalıştırmalardan geldiğini belirtiyor; 528 ms rakamı kendilerine ait, ancak 512 TU periyodu AWDL'nin kendisine aittir.

Neden önemli

AWDL neredeyse hiç belgelenmemiştir ve MultipeerConnectivity üzerinde gerçek zamanlı özellikler geliştiren her geliştirici bu davranışla karşılaşır ve büyük olasılıkla bir hata gönderdiğini düşünür. Yazı, başarısızlığın yapısal olduğunu gösteriyor: framework sessizce taşıyıcı değiştiriyor, güvenilirlik kuyrukları boşlukları maskeliyor ve standart teslim metrikleri onları göremiyor. Yarım saniyeye yakın bir duraklmanın bağlantının zamanlanmış bir özelliği olabileceğini — ve mevcut yanıtın yeniden denemelerin veya ayarlamaların değil jitter buffering olduğunu bilmek, bir gizemi bir tasarım kısıtına dönüştürüyor.