İndirme Hızı Düşük: Hız Testinin Söylemedikleri

Hız testi aslında neyi ölçer?

Bir hız testi (speedtest), test sunucusu ile cihaz arasında kısa süreli, genelde tek bir TCP/UDP akışı üzerinden maksimum aktarım hızını ölçer. Bu ölçüm, o anki kanal koşullarını, sinyal kalitesini ve hat kapasitesini bir arada yansıtır ama hangi bileşenin darboğaz olduğunu söylemez.

Örneğin 500 Mbps'lik bir fiber hat üzerinden Wi-Fi ile yapılan testte 120 Mbps sonuç çıkması, hattın değil kablosuz bağlantının darboğaz olduğunu gösterir; ama kullanıcı genelde bunu 'internetim yavaş' olarak sağlayıcısına şikayet eder.

Gerçek kapasiteyi anlamak için hız testinin yanında kablolu test, MCS/sinyal bilgisi ve eşzamanlı istemci sayısı birlikte değerlendirilmelidir. Tek başına bir sayı, kök nedeni asla göstermez.

MCS ve sinyal-SNR ilişkisi

MCS (Modulation and Coding Scheme) indeksi, bir Wi-Fi bağlantısının anlık teorik veri hızını belirler. Yüksek MCS seviyeleri (örneğin 256-QAM) çok daha fazla veri taşır ama bunun için yüksek SNR (sinyal-gürültü oranı) gerekir. SNR düştükçe istemci otomatik olarak daha düşük, daha güvenilir bir MCS seviyesine geçer — bu da hızı doğrudan düşürür.

Pratikte, -50 dBm sinyal gücü ve 35 dB SNR ile bağlı bir istemci en yüksek MCS seviyesinde çalışabilirken, -70 dBm sinyal ve 15 dB SNR ile bağlı aynı istemci hızının üçte birine düşebilir. Kullanıcı 'sinyal 3 çubuk, hız düşük' dediğinde, çubuk sayısı SNR'yi değil sadece kaba sinyal gücünü gösterdiği için yanıltıcı olabilir.

Bu nedenle hız şikayetlerinde ilk kontrol edilmesi gereken şey sinyal çubuğu değil, cihazın bağlı olduğu MCS indeksi ve ölçülen SNR değeridir. Bu ikisi birlikte gerçek kapasiteyi gösterir.

TCP davranışı ve gecikmenin hıza etkisi

TCP protokolü, veri aktarım hızını pencere boyutu (window size) ve gidiş-dönüş süresine (RTT) göre otomatik ayarlar. Yüksek gecikme ve paket kaybı olan bir bağlantıda TCP, güvenli tarafta kalmak için gönderim hızını düşürür — bu da hız testinde düşük sonuç olarak görünür, ama aslında kök neden gecikme/kayıptır, bant genişliği değildir.

Bu yüzden aynı hat üzerinde farklı sunuculara yapılan hız testleri bazen çok farklı sonuçlar verir: uzak ve yüksek gecikmeli bir sunucuya test, TCP penceresinin tam dolmasına izin vermeyebilir. Çok akışlı (multi-thread) hız testleri bu etkiyi gizleyebilir, tek akışlı testler ise gerçek darboğazı daha iyi gösterir.

Wi-Fi tarafında yüksek retry oranı da TCP açısından paket kaybı gibi algılanır ve TCP otomatik olarak yavaşlar. Dolayısıyla RF kaynaklı bir sorun, kullanıcı ekranında 'yavaş internet' olarak TCP katmanından yansır.

Tek istemci testi vs gerçek çok istemcili ortam

BT ekiplerinin yaptığı hız testleri genelde tek bir dizüstü bilgisayarla, boş bir ortamda yapılır ve mükemmel sonuç verir. Ama gerçek kullanım ortamında aynı AP'ye 30-40 cihaz bağlıdır ve toplam kapasite bu cihazlar arasında paylaşılır. Airtime fairness mekanizması olmayan eski altyapılarda, yavaş bağlanan tek bir cihaz (düşük MCS'de), tüm hücrenin toplam verimini aşağı çekebilir.

Bu nedenle 'tek cihazda hız testi 500 Mbps çıktı ama ofiste herkes yavaş' şikayeti aslında kapasite planlama sorunudur: AP başına düşen istemci sayısı, kanal genişliği ve trafik türü (video konferans, bulut senkronizasyonu vb.) birlikte kapasiteyi aşağı çeker.

Gerçekçi bir değerlendirme için hız testleri yoğun saatte, birden fazla istemci ile eşzamanlı olarak yapılmalı ve AP başına düşen ortalama kapasite hesaplanmalıdır.

• Hız testi hem kablolu hem kablosuz olarak karşılaştırmalı yapılmalı
• MCS ve SNR değerleri sinyal çubuğundan daha güvenilir göstergedir
• Tek akışlı ve çok akışlı testler farklı bilgi verir, ikisi birlikte değerlendirilmeli
• Yoğun saatte çok istemcili test, gerçek kapasiteyi tek istemci testinden daha iyi yansıtır

F2'nin kapasite teşhis yöntemi

F2, 'internetim yavaş' şikayetlerinde önce WAN hattının gerçek kapasitesini kablolu ölçümle doğrular, ardından Ekahau ile sinyal/SNR haritası çıkarır ve istemcilerin bağlandığı MCS seviyelerini WLAN kontrolcüsünden toplar. Yoğun saatlerde çok istemcili test yapılarak AP başına düşen gerçek kapasite hesaplanır. Bu üç veri seti birleştirildiğinde, yavaşlığın hat mı, RF mi yoksa kapasite planlaması mı kaynaklı olduğu net biçimde ortaya çıkar ve çözüm — kanal/güç optimizasyonu, AP sıklaştırma veya hat yükseltmesi — buna göre önerilir.