Fedora'da WiFi Neden Yavaş? Sebebi Bluetooth (Intel CNVi Anten Paylaşımı)

Dükkânda iki dizüstü var: biri dükkânın bilgisayarı, Windows 10 kurulu; diğeri benim şahsi dizüstüm, Fedora kurulu. İkisi de aynı odada, ikisi de aynı WiFi ağına bağlı, ikisi de modeme yakın. Ama hız testi yaptığımda Windows kurulu makine 50 Mbps alırken, Fedora kurulu dizüstüm 2-3 Mbps’te takılıyordu.

Aynı ağ, aynı oda, aynı mesafe. İnternet hattım zaten 50 Mbps; yani Windows kurulu makine hattın verebildiği en yüksek hızı alıyordu, hat da modem de 50’yi sorunsuz veriyordu. Aradaki tek fark işletim sistemiydi. Doğal olarak “Linux’ta bir ayar bozuk” diye düşündüm ve sürücüyle, güç tasarrufu ayarlarıyla oynamaya başlayacaktım. İyi ki başlamadan önce gerçek hızı ve gecikmeyi ölçtüm — çünkü asıl neden hiç beklemediğim yerdeydi ve sorunun WiFi ayarlarıyla uzaktan yakından ilgisi yoktu.

Bu yazıda adım adım sorunun kaynağını nasıl bulduğumu anlatıyorum: hangi komutu çalıştırdım, ne çıktı, ondan ne anladım. Yanlış çıkan iki hipotezimi de, hız testini kurarken kendi düştüğüm hataları da yazıyorum — çünkü asıl öğretici kısım orası.

Sistemim / Test Ortamı#

Buradaki en kritik iki satır kablosuz kart ve modem. Yazının sonunda göreceksiniz, sorunun tamamı bu ikisinin birleşiminden çıkıyor.

Adım 1: Önce donanım — kart doğru tanınmış mı?#

En baştan başladım. Kart neydi, hangi sürücüyle çalışıyordu?

# Ağ denetleyicisini ve kullandığı çekirdek sürücüsünü göster
lspci -nnk | grep -A3 -i 'network controller'

00:14.3 Network controller [0280]: Intel Corporation Arrow Lake CNVi WiFi [8086:7740]
	DeviceName: WLAN
	Subsystem: Intel Corporation Device [8086:00e4]
	Kernel driver in use: iwlwifi

Kart düzgün tanınmış, resmi Intel sürücüsü iwlwifi yüklü. Buraya kadar sorun yok. Arayüzlere de baktım:

nmcli device status

DEVICE        TYPE      STATE             CONNECTION
wlo1          wifi      bağlandı          www.ulvikuyum.com.tr
lo            loopback  bağlandı (dış)    lo
p2p-dev-wlo1  wifi-p2p  bağlantı kesildi  --

Şunu da belirteyim: listede ethernet yok. Bu dizüstünde kablo girişi zaten yok — yani “kabloyu tak, kurtul” seçeneğim en baştan yoktu, sorunu WiFi üzerinde çözmek zorundaydım.

Bu çıktıdaki wlo1 benim kablosuz arayüzümün adı. Sizde wlp2s0, wlan0 gibi farklı olabilir. Yazının geri kalanındaki komutlarda wlo1 gördüğünüz yere kendi arayüz adınızı yazın — nmcli device status çıktısındaki wifi satırı hangi isimse o.

Adım 2: Sinyal zayıf mı, bağlantı hızı düşük mü?#

İlk akla gelen ihtimal: belki sinyal kötüdür, belki kart modemle düşük bir hızda anlaşmıştır.

# Bağlantının anlık durumu: sinyal gücü ve anlaşılan hız
iw dev wlo1 link

Connected to 5c:63:bf:16:e8:f5 (on wlo1)
	SSID: www.ulvikuyum.com.tr
	freq: 2437.0
	signal: -55 dBm
	rx bitrate: 130.0 MBit/s MCS 15
	tx bitrate: 130.0 MBit/s MCS 15

Bu çıktı beklediğimin tam tersiydi:

• signal: -55 dBm — bu iyi bir sinyal. (Kabaca: -50 mükemmel, -60 iyi, -70 idare eder, -80 kötü.)
• 130.0 MBit/s — kart modemle 130 Mbit/s’te anlaşmış. 50 Mbps’lik hattımı taşımak için fazlasıyla yeterli.
• freq: 2437.0 — 2,4 GHz bandı, kanal 6.

Yani bağlantı kâğıt üzerinde sapasağlam. Daha derine indim; hata sayaçlarına baktım:

# Yeniden gönderim ve hata sayaçları
iw dev wlo1 station dump

	signal:  	-55 [-59, -55] dBm
	tx bitrate:	130.0 MBit/s MCS 15
	rx bitrate:	130.0 MBit/s MCS 15
	tx retries:	0
	tx failed:	0

tx retries: 0 ve tx failed: 0. Tek bir paket bile yeniden gönderilmemiş, tek bir gönderim bile başarısız olmamış. Kartın sinyali gönderip alan tarafında hiçbir sorun görünmüyordu.

Adım 3: Güç tasarrufu WiFi’ı uyutuyor olabilir mi?#

Linux’ta bilinen bir dert: dizüstülerde WiFi kartı pil tasarrufu için uykuya dalar ve gecikme yaratır. Kontrol ettim:

iw dev wlo1 get power_save

Power save: off

Bende kapalı çıktı — ama bunun sebebi, WiFi güç tasarrufunu bu makinede daha önce kendim kapatmış olmam. Yani bu ihtimali baştan elemiştim; sizde Power save: on çıkabilir.

Sizde açık çıkıyor ve gecikme yaşıyorsanız, kapatmak için — geçici olarak (yeniden başlatınca geri gelir):

sudo iw dev wlo1 set power_save off

Kalıcı olması için NetworkManager’a bir kural yazın:

# WiFi güç tasarrufunu her açılışta kapalı tut
echo -e '[connection]\nwifi.powersave = 2' | sudo tee /etc/NetworkManager/conf.d/wifi-powersave-off.conf
sudo systemctl restart NetworkManager

wifi.powersave değerleri: 2 = kapalı, 3 = açık (varsayılan). Değiştirdikten sonra iw dev wlo1 get power_save ile teyit edin.

Bende zaten kapalıydı, o yüzden bu ihtimal elendi; sorun başka yerdeydi.

Adım 4: Arka planda bir şey mi indiriyor?#

Belki bir güncelleme, bir yedekleme ya da bir senkronizasyon bant genişliğimi kullanıyordu. Önce hangi programların ağ bağlantısı olduğuna baktım:

# Aktif ağ bağlantıları ve hangi sürece ait oldukları
sudo ss -tunp | grep ESTAB

Listede tarayıcı, kod editörü ve normal masaüstü programları vardı — beklenmedik bir indirici yoktu. Sonra asıl ölçümü yaptım: arayüzden gerçekte saniyede kaç bayt geçiyor?

# 5 saniyede geçen trafiği ölç (boştayken)
r1=$(cat /sys/class/net/wlo1/statistics/rx_bytes)
sleep 5
r2=$(cat /sys/class/net/wlo1/statistics/rx_bytes)
echo "İndirme: $(( (r2-r1)/5/1024 )) KB/s"

İndirme: 2 KB/s

Saniyede yalnızca 2 KB. Yani boştayken hiçbir şey indirmiyordu. Bu ihtimal de elendi.

Burada bir alışkanlığımı paylaşayım: bir programın “çalışıyor görünmesi” ile “gerçekten bant genişliği kullanması” ayrı şeyler. Süreç listesine bakıp tahmin yürütmek yerine arayüzün sayaçlarını okumak kesin sonuç verir.

Adım 5: Dönüm noktası — kendi modemime ping attım#

Bu noktada elimde temiz bir sinyal, sağlam bir bağlantı hızı, kapalı güç tasarrufu ve boş bir ağ vardı. Ama internet yine de yavaştı. Aklıma şu soru geldi:

“Sorun gerçekten uzakta, internette mi? Yoksa daha burada, dizüstümle modem arasında mı başlıyor?”

Bunu ayırmanın en temiz yolu: internete hiç çıkmadan, sadece kendi modemime ping atmak. Modem birkaç adım ötemde; aramızda internet değil, yalnızca WiFi var.

# Sadece modeme (internet işin içinde değil)
ping -c 20 -i 0.2 192.168.1.1

20 paket iletildi, 20 alındı, 0% packet loss, time 3820ms
rtt min/avg/max/mdev = 5.699/144.216/319.984/82.170 ms

İşte sorun buradaydı. Bu rakamları okuyalım:

• min 5.699 — en iyi ihtimalde 5,7 ms
• avg 144.216 — ama ortalama 144 ms
• max 319.984 — ve zaman zaman 320 ms
• mdev 82.170 — sapma çok yüksek, yani değerler bir ölçümden diğerine çok değişiyor

Birkaç adım ötemdeki modeme ulaşmam 320 milisaniyeyi buluyordu. Sağlıklı bir kablosuz bağlantıda bu değer 1-5 ms arasında sabit olmalı.

Bu ölçümde internet hiç işin içinde değil. Demek ki sorun ne servis sağlayıcımda, ne VDSL hattımda, ne de uzaktaki bir sunucuda. Sorun tam burada, dizüstümle modem arasındaki kablosuz bağlantıda.

Deseni görmek için daha uzun bir ölçüm yaptım:

# 60 saniye boyunca saniyede bir ping, sadece süreleri yazdır
LC_ALL=C ping -c 60 -i 1 192.168.1.1 | grep -o 'time=[0-9.]*'

Baştaki LC_ALL=C şart. Türkçe sistemde ping çıktısı yerelleşiyor ve süre alanı time= yerine zaman= oluyor; LC_ALL=C koymazsanız grep hiçbir şey bulamaz ve komut boş döner. (Bunu ilk denememde öğrendim.)

Çıkan tabloyu sadeleştirirsem şöyleydi:

1.9  3.8  2.1  88.2  47.1  2.2  2.4  46.4  283.0  61.2
7.9  4.3  2.1  1.4   2.2   1.9  34.3 2.4   4.2    7.7
1.4  1.3  1.4  1.9   1.8   1.2  27.3 13.1  16.4   2.4

Desen çok net: çoğunlukla 1-4 ms (gayet sağlıklı), sonra aniden 30-280 ms’ye çıkıyor, sonra yine normale dönüyor.

Bu bilgi çok kıymetliydi. Çünkü:

• Eğer sürücü uyku sorunu olsaydı, sıçramalar düzenli aralıklarla olurdu (her X saniyede bir).
• Eğer sinyal zayıf olsaydı, değerler sürekli yüksek olurdu.

Bendeki desen ikisi de değildi: düzensiz aralıklarla gelen ani tıkanmalar. Bu, aynı frekansı başka bir şeyin ara ara kullanması demekti.

Adım 6: Kanal kalabalık mı?#

2,4 GHz herkesin sıkıştığı banttır. Çevredeki ağlara ve hangi kanalda olduklarına baktım:

# Çevredeki ağlar, kanalları ve sinyal güçleri
nmcli -f BSSID,SSID,CHAN,SIGNAL device wifi list --rescan yes

Çıktıdan kanal 6’daki (yani benim kanalımdaki) satırlar:

BSSID              SSID                        CHAN  SIGNAL
5C:63:BF:16:E8:F5  www.ulvikuyum.com.tr        6     85
CC:BA:BD:B7:98:56  FiberHGW_TP9850             6     42
5C:7D:AE:F4:E3:85  SUPERBOX_Wi-Fi_9665         6     20

Toplamda 19 komşu ağ saydım. Kanal 6 kalabalıktı ve bu, hızımı bir miktar düşürüyordu.

Ama başka taramalarda kanal 6’da bir ağ daha görünüyordu: Ulvi Kuyum Müşteri — yani dükkânın müşteri ağı, benim kendi ikinci ağım. Üstelik sinyali çok güçlüydü. “Kendi iki ağım birbirini mi engelliyor?” diye merak edip özellikle onu aradım:

# Müşteri ağı ayrı bir cihaz mı, yoksa aynı modemin ikinci ağı mı?
nmcli device wifi rescan
nmcli -f BSSID,SSID,CHAN,SIGNAL device wifi list | grep -i ulvi

52:63:BF:16:E8:F4  Ulvi Kuyum Müşteri          6     89
5C:63:BF:16:E8:F5  www.ulvikuyum.com.tr        6     82

İki ağın donanım adreslerine (BSSID) baktığımda içim rahatladı:

Ana ağ      : 5C:63:BF:16:E8:F5
Müşteri ağı : 52:63:BF:16:E8:F4

İkisi de aynı taban adresi (63:BF:16:E8) taşıyor. Yani müşteri ağı ayrı bir cihaz değil, aynı modemin ürettiği ikinci bir ağ. Aynı donanımı kullandıkları için, modem hangisinin ne zaman yayın yapacağını kendisi ayarlıyor; yani ayrı iki cihaz gibi birbirinin sinyalini bozmuyorlar.

Ama şunu da not edeyim: müşteri o ağa bağlanıp video izlerse aynı radyoyu ve aynı VDSL hattını benimle paylaşır. Yani ayrı bir cihaz olmasa da hızımı etkileyebilir. Kanal kalabalığı ve müşteri ağı gerçek etkenler — ama birazdan göreceğiniz gibi, asıl neden bunlar değildi.

Adım 7: Olası neden — kartın Bluetooth ile anten paylaşması#

Adım 1’deki çıktıya geri döndüm. Orada bir kelime vardı: CNVi.

Intel Corporation Arrow Lake CNVi WiFi

CNVi, Intel’in yeni nesil tümleşik kablosuz mimarisi. Bu tasarımda WiFi ve Bluetooth aynı fiziksel anteni paylaşır. İkisi de 2,4 GHz’de çalıştığı için aynı anda yayın yapamazlar; anteni sırayla kullanmak zorundadırlar.

Bluetooth’un durumuna baktım:

bluetoothctl show | grep Powered
bluetoothctl devices Paired

	Powered: yes

Bluetooth açıktı. Ve devices Paired komutu hiçbir şey döndürmedi — yani eşleşmiş tek bir cihazım bile yoktu.

Bu, Adım 5’te gördüğüm düzensiz sıçrama desenini açıklıyordu: eşleşmiş cihazım olmadığı hâlde Bluetooth açık olduğu için, ara sıra anteni kullanıp WiFi’ı sıraya sokuyor olabilirdi. Sıçramaların düzenli değil de gelişigüzel olması, tam bu ihtimale uyuyordu.

Adım 8: İlk gerçek test — Bluetooth’u kapat, hızı ölç#

Tahmini bırakıp ölçtüm. Bluetooth’u geçici olarak kapatmanın yolu:

# Bluetooth'u geçici kapat (kalıcı değil, yeniden başlatınca geri gelir)
sudo rfkill block bluetooth

# Geri açmak için
sudo rfkill unblock bluetooth

Hız ölçümü için bir dosya indirip gerçekte kaç bayt aktığına baktım:

# 10 saniye boyunca indir, kaç bayt indiğini ve süreyi yazdır
curl -m 10 -o /dev/null -s -w '%{size_download} bayt / %{time_total} sn\n' \
  http://cachefly.cachefly.net/100mb.test

Bluetooth açıkken ve kapalıyken üçer kez ölçtüm:

Bluetooth AÇIK   : 16,4   8,8   39,9 Mbps
Bluetooth KAPALI : 40,3  39,5   44,0 Mbps

Fark ortadaydı. Ama burada durmadım — çünkü Bluetooth açıkken bir ölçüm 39,9 çıkmıştı. Yani Bluetooth bağlantıyı sürekli yavaşlatmıyor, ara ara çökertiyordu. Üç ölçüm bunu kanıtlamaya yetmezdi.

Adım 9: Çürüyen hipotez — “önceliği WiFi’a versem?”#

Aklıma mantıklı gelen bir fikir geldi: Bluetooth’u tamamen kapatmak yerine, sürücüye “WiFi’a öncelik ver, Bluetooth’a yol verme” desem olmaz mıydı?

iwlwifi sürücüsünde tam da bunun için bir ayar var. Önce mevcut değerine baktım:

# Sürücünün tüm ayarlarını listele
for p in /sys/module/iwlwifi/parameters/*; do
  echo "$(basename $p) = $(cat $p)"
done

11n_disable            = 0
bt_coex_active         = Y
power_save             = N
uapsd_disable          = 3
...

bt_coex_active = Y — yani WiFi ile Bluetooth’un anteni sırayla kullanmasını sağlayan koordinasyon açık. Bunu N yapıp kapatmayı denedim. Ama önce, ayarın sistem çalışırken değiştirilip değiştirilemeyeceğine baktım:

ls -l /sys/module/iwlwifi/parameters/bt_coex_active

-r--r--r--. 1 root root 4096 Jul 18 13:40 /sys/module/iwlwifi/parameters/bt_coex_active

-r--r--r-- — yani salt okunur. Bu ayarı değiştirmek için sürücüyü baştan yüklemek gerekiyordu.

Bu ayarın tam olarak ne yaptığını, sürücünün kendi açıklamasından okudum:

modinfo iwlwifi | grep bt_coex

parm:           bt_coex_active:enable wifi/bt co-exist (default: enable) (bool)

Sonra sürücüyü bu ayarla yeniden yükledim:

# Ayarı yaz
echo 'options iwlwifi bt_coex_active=0' | sudo tee /etc/modprobe.d/99-btcoex.conf

# Sürücüyü baştan yükle (WiFi birkaç saniye düşer)
sudo modprobe -r iwlmld
sudo modprobe -r iwlwifi
sudo modprobe iwlwifi

# Doğrula
cat /sys/module/iwlwifi/parameters/bt_coex_active

N

Ayar geçmişti. Ölçtüm — ve işe yaramadı:

Hız düzelmedi, üstelik ping daha da kötüleşti.

Sonradan sebebini anladım; aslında mantıklıydı. Anten fiziksel olarak tek. bt_coex_active o anteni ikiye bölen bir anahtar değil — onu bir trafik ışığına benzetebiliriz: WiFi ile Bluetooth’un anteni sırayla, çarpışmadan kullanmasını sağlıyor. Ayarı kapatınca yoldaki ikinci aracı (Bluetooth’u) kaldırmış olmuyorsun; sadece trafik ışığını söküyorsun. Bluetooth anteni kullanmaya devam ediyor, ama artık sıra beklemeden. Sonuç: çarpışma — yani durum daha da kötüleşiyor.

Ayarı geri aldım:

sudo rm /etc/modprobe.d/99-btcoex.conf
sudo modprobe -r iwlmld && sudo modprobe -r iwlwifi && sudo modprobe iwlwifi

Adım 10: Ölçümü doğru kurmak (ve yol boyunca yaptığım hatalar)#

Elimde koşul başına üçer ölçüm vardı ama sonuçlar çok oynaktı. Bu kadar değişken bir ortamda “üç ölçümle kanıtladım” demek dürüst olmazdı. O yüzden düzgün bir test kurmaya karar verdim.

İki tasarım kararı aldım:

1. Sırayı her turda değiştiren ölçüm. Önce hep “Bluetooth açık”, sonra hep “Bluetooth kapalı” ölçseydim yanlış olurdu: o iki dakikanın arasında komşuların trafiği değişirse, aradaki farkı yanlışlıkla Bluetooth’a yükleyebilirdim. Bunun yerine her turda ikisini de ölçtüm ve sırayı her turda ters çevirdim (tek turlarda önce açık, çift turlarda önce kapalı ölçtüm).

2. Sabit dosya boyutu değil, sabit süre. Sabit bir boyut (mesela 20 MB) indirseydim, ölçüm hızlı koşulda 4 saniye, yavaş koşulda 20 saniye sürerdi — yani iki koşulu farklı uzunlukta pencerelerde ölçmüş olurdum. Bunun yerine her ölçümde tam 10 saniye indirdim ve hızı şöyle hesapladım: hız = inen bayt ÷ geçen süre.

Ama asıl anlatmak istediğim şu: bu testi dört kez baştan kurmak zorunda kaldım, çünkü her denememde kendi yöntemimde bir kusur fark ettim.

Hata 1: Ping özetini kaybediyordum#

İndirmeyle aynı anda bir ping çalıştırıyor, indirme bitince ping’i durduruyordum. Ama ping, özet satırını (rtt min/avg/max) yalnızca SIGINT sinyalini alınca yazıyor; bense onu kill ile, yani SIGTERM göndererek durduruyordum. Sonuç: çabuk biten ölçümlerde ping özeti hiç yazılmadan kayboluyordu.

Bu masum bir hata değildi: çabuk biten ölçümler çoğunlukla “Bluetooth kapalı” koşuluna denk geliyordu. Yani bu hata, karşılaştırdığım iki koşuldan birini diğerinden daha çok bozuyordu — sonucu çarpıtacak cinsten. Düzeltmesi:

kill -INT $ping_pid    # kill değil, kill -INT

Hata 2: Ölçüm sunucusu beni sınırladı#

Ölçümlerde Cloudflare’in hız testi sunucusunu kullanıyordum. Art arda onlarca kez 50 MB’lık dosya isteyince sunucu beni sınırlamaya başladı ve isteklerime dosya yerine 1 bayt dönmeye başladı:

deneme 1:          1 bayt /   0.1 sn
deneme 2:          1 bayt /   0.1 sn
deneme 3:          1 bayt /   0.1 sn

Bu ölçümler “0 Mbps” olarak kaydediliyordu. Fark etmesem ortalamalarım tamamen çöp olacaktı. Alternatif sunucular denedim:

curl -m 10 -o /dev/null -s -w '%{size_download} bayt / %{time_total} sn\n' \
  http://cachefly.cachefly.net/100mb.test

Ayrıca sunucunun kendisinin darboğaz olmadığını doğruladım — çünkü yavaş bir sunucu, aradığım farkı gizlerdi. Bluetooth kapalıyken beş kez ölçtüm:

44,8   45,4   44,5   43,6   44,7 Mbps

Sunucu 45 Mbps verebiliyordu, yani benim WiFi tavanımı aşıyordu. Ölçüm için uygundu.

Hata 3: Filtrem en yavaş ölçümleri siliyordu#

Bu, en tehlikeli hataydı: çünkü kendi hipotezimi doğrular yönde yanılgı üretiyordu.

Sunucunun reddettiği (1 baytlık) ölçümleri ayıklamak için bir kural yazmıştım: “5 MB’den az indiyse o ölçümü geçersiz say, yeniden dene.” Ama sonra kayıtlarda şunu fark ettim:

(geçersiz örnek: 4092677 bayt / 10.000376 sn -- yeniden deneniyor)

Bu ölçüm 4 MB’yi tam 10 saniyede indirmiş. Yani sunucu reddetmiş değil — bağlantı gerçekten 3,3 Mbps’e çökmüş. Bu bozuk bir veri değildi; ölçmeye çalıştığım şeyin ta kendisiydi.

Yani kuralım, en yavaş ölçümleri “bozuk” diye atıp yerlerine yeni ölçüm koyuyordu. Üstelik atılan bu ölçümlerin hepsi “Bluetooth açık” turlarına denk gelmişti. Sonuçta “Bluetooth açık” koşulunu olduğundan daha iyi gösteriyordum — kendi hipotezimi zayıflatan verileri, farkında olmadan siliyordum.

Doğru kural şuydu: bir ölçüm yalnızca 10 saniyelik pencere dolmadan bittiyse geçersizdir (sunucu reddettiğinde istek zaten 0,08 saniyede geri dönüyor). Pencere tam 10 saniye sürdüyse, kaç bayt inmiş olursa olsun o ölçüm geçerlidir.

Ölçümden çıkan kural: bir hipotezi test ederken, verileri eleyen kuralı da sınamak gerekiyor. “Bozuk” diye attığın veri, tam da aradığın cevap olabilir.

Adım 11: Geniş çaplı test#

Dört denemeden sonra yöntem oturdu. Aynı sorunu yaşayan biri kendi bilgisayarında çalıştırabilsin diye, sadeleştirilmiş hâlini aşağıya koyuyorum:

# 6 tur: her turda Bluetooth açık ve kapalı ölçüm
for i in 1 2 3 4 5 6; do
  echo "--- tur $i ---"

  sudo rfkill unblock bluetooth; sleep 5
  echo -n "  BT açık   : "
  curl -m 10 -o /dev/null -s -w '%{size_download} bayt / %{time_total} sn\n' \
    http://cachefly.cachefly.net/100mb.test

  sudo rfkill block bluetooth; sleep 5
  echo -n "  BT kapalı : "
  curl -m 10 -o /dev/null -s -w '%{size_download} bayt / %{time_total} sn\n' \
    http://cachefly.cachefly.net/100mb.test
done

sudo rfkill unblock bluetooth   # Bluetooth'u geri aç

Ben bunu 12 tur boyunca indirme + yükleme + boşta ping + yük altında ping ölçerek çalıştırdım. Toplam 34 geçerli ölçüm, hiç elenen örnek yok, tüm ölçüm pencereleri tam 10,00 saniye (yani iki koşul birebir aynı sürede ölçüldü).

Sonuç: İndirme (download) hızı#

Ama asıl anlatan şey ortalama değil, değerlerin dağılımı:

Bluetooth açık   :  ▁▁▁▁▁▁▁▁████
Bluetooth kapalı :  ████████████

█ = 30 Mbps üstü        ▁ = 30 Mbps altı (çökmüş)

Bluetooth kapalıyken 12 ölçümün 12’si tam hızda. Açıkken 12 ölçümün 8’i çökmüş, sadece 4’ü tam hızdaydı.

Yani Bluetooth hızımı yarıya indirmiyor — öngörülemez hale getiriyor. Bu, benim yaşadığım şikâyeti tam olarak açıklıyor: internet bazen çok yavaştı, bazen normaldi, bir türlü tutarlı bir sonuç alamıyordum.

Sonuç: Her turu kendi içinde karşılaştırma#

Ham ortalamaları karşılaştırmak riskliydi, çünkü test boyunca ortam değişiyordu (komşu trafiği, müşteri ağı). Bunun yerine her turda, birkaç saniye arayla ölçtüğüm “açık” ve “kapalı” değerini yan yana koydum. Ortam o birkaç saniyede kayarsa ikisini birden etkiler; dolayısıyla aralarındaki fark yine de anlamlı kalır:

  tur      BT_ACIK  BT_KAPALI       fark
  1            6.5       38.5      +32.0
  2           44.4       31.4      -13.0
  3           13.0       45.1      +32.0
  4           15.9       46.3      +30.4
  5           32.0       41.8       +9.8
  6            9.6       42.4      +32.8
  7            7.4       45.7      +38.3
  8           45.1       45.9       +0.8
  9           15.1       45.7      +30.6
  10          45.5       46.2       +0.7
  11          15.9       46.0      +30.0
  12          16.0       44.9      +28.9
  ----------------------------------------------
  Bluetooth kapalı daha hızlı : 11 tur
  Bluetooth açık daha hızlı   :  1 tur
  Farkın medyanı              : +30.2 Mbps

12 turun 11’inde “Bluetooth kapalı” daha hızlı çıktı. 2. turu tabloda özellikle bırakıyorum: orada tersine, Bluetooth açıkken daha hızlıydı (44,4’e karşı 31,4). Bu ters örneği silmek işime gelirdi ama tam da anlatmak istediğim şeyi kanıtlıyor: Bluetooth’un etkisi her ölçümde değil, ara ara ortaya çıkıyor.

Sonuç: Gecikme (asıl hissedilen şey)#

Yük altında ping (en yüksek değer)
  Bluetooth açık   : medyan 397,8 ms   (en kötü 1219 ms)
  Bluetooth kapalı : medyan  37,8 ms   (en kötü  127 ms)

Aradaki fark on kat. İndirme yaparken ping’in 400 ms’ye, hatta bir keresinde 1219 ms’ye çıkması şu demek: video görüşmelerinde yaşadığım donmaların ve sayfaların “bir türlü açılmamasının” sayısal karşılığı bu.

Sonuç: Yükleme (upload) neredeyse etkilenmiyor#

Yükleme
  Bluetooth açık   : medyan 12,7 Mbps
  Bluetooth kapalı : medyan 14,6 Mbps

Bu beni şaşırttı: Bluetooth, indirme (download) hızını %65 düşürürken yükleme (upload) hızını neredeyse hiç etkilemiyor. Kesin sebebini iddia etmeyeceğim ama makul açıklama şu: indirmede, karşı taraf veriyi bana ne zaman gönderirse o anı yakalamam gerekiyor; anten tam o sırada Bluetooth’taysa o anı kaçırıyorum. Yüklemede ise veriyi ne zaman göndereceğime ben karar verdiğim için, anten boşaldığında gönderiyorum.

Adım 12: İkinci çürüyen hipotez — power_scheme#

Sürücüyü incelerken bir ayar daha buldum. iw “power save off” diyordu ama sürücünün kendi firmware seviyesinde ayrı bir güç şeması varmış:

cat /sys/module/iwlmld/parameters/power_scheme

2

1 = aktif (güç tasarrufu yok), 2 = dengeli (varsayılan). Bunu da denedim:

echo 'options iwlmld power_scheme=1' | sudo tee /etc/modprobe.d/99-ps.conf
sudo modprobe -r iwlmld && sudo modprobe -r iwlwifi && sudo modprobe iwlwifi

Sonuç — bu da işe yaramadı:

Bluetooth açıkken hâlâ çöküyordu. Üstelik boştaki ping kötüleşti (medyan 4,9 ms → 45,3 ms). Bu ayarı da geri aldım:

sudo rm /etc/modprobe.d/99-ps.conf
sudo modprobe -r iwlmld && sudo modprobe -r iwlwifi && sudo modprobe iwlwifi

İki hipotez de çürüdü. Geriye tek seçenek kaldı: Adım 9’daki trafik ışığı benzetmesine dönersek — anten fiziksel olarak tek olduğuna göre, çözüm ışıkla oynamak değil, yoldaki ikinci aracı, yani Bluetooth’u tamamen çekmek.

Çözüm#

Benim için bu hiç zor bir karar değildi: ölçtüğümde eşleşmiş tek bir Bluetooth cihazım olmadığını görmüştüm. Yani Bluetooth bana hiçbir fayda sağlamadan, sadece WiFi’ı yavaşlatıyordu; kapatmakla kaybedeceğim bir şey yoktu.

# Bluetooth'u kapat ve açılışta da başlamasın
sudo systemctl disable --now bluetooth

Komut şu çıktıyı verdi:

Removed '/etc/systemd/system/dbus-org.bluez.service'.
Removed '/etc/systemd/system/bluetooth.target.wants/bluetooth.service'.

Doğrulaması:

systemctl is-enabled bluetooth
systemctl is-active bluetooth

disabled
inactive

Servisi kapatmak yetiyor mu, yoksa radyoyu (anten donanımını) da kapatmalı mıyım?#

Burada tereddüt ettim. systemctl disable, yalnızca Bluetooth yazılımını (bluetoothd servisi) durduruyor. Ama WiFi’a asıl karışan şey yazılım değil, radyo — yani kartın sinyali fiilen gönderip alan donanım kısmı. Peki servisi kapatınca radyo da fiilen duruyor muydu? Kontrol ettim:

rfkill list bluetooth

0: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no

Yani radyo, donanım seviyesinde hâlâ açık görünüyordu. “Öyleyse rfkill block ile radyoyu da elle kapatmam gerekir” diye düşündüm — ama varsaymak yerine ölçtüm. Servis kapalıyken, rfkill ise hâlâ açıkken hızı altı kez ölçtüm:

44,4   44,6   43,5   45,5   45,8   42,5 Mbps

Altısı da tam hızda. Boştaki ping de düzelmişti:

rtt min/avg/max/mdev = 1.176/4.304/20.582/5.230 ms

Demek ki rfkill block’a gerek yok; sadece servisi kapatmak yetiyor. Anlaşılan WiFi’ı yavaşlatan şey, boşta çalışan Bluetooth servisinin sürekli yaptığı arka plan taraması ve yayınıymış. Servis durunca radyo da fiilen yayın yapmayı bırakıyor, WiFi rahatlıyor.

Bir gün kulaklık ya da kablosuz fare bağlamak istersem, Bluetooth tek satırla geri geliyor; hiçbir ayarım silinmiş olmuyor:

sudo systemctl enable --now bluetooth

Kalıcı olarak değil de yalnızca o anlık kapatmak istersen (bilgisayarı yeniden başlatınca Bluetooth kendiliğinden geri gelir):

sudo rfkill block bluetooth

Ama asıl kök neden Bluetooth değil, modem#

Burada dürüst olmam gerekiyor. Bluetooth’u kapatmak bir çözüm değil, telafi. Asıl sorun bir kat daha derinde.

Modemim TP-Link TD-W9970 ve bu cihaz yalnızca 2,4 GHz yayın yapıyor; 5 GHz bandı yok. Bu modemde ısrar etmemin sebebi var: bölgemde fiber altyapı yok, bir de IP adresimi değiştirmek istediğimde bu modemi resetlemeye bile gerek kalmadan 5-10 saniyede yeni bir IP alabiliyorum — o pratiklikten vazgeçmek istemiyorum. Neyse ki dizüstümün kartı 2,4 GHz’den çok daha fazlasını destekliyor:

# Kartın desteklediği frekans bantları
iw phy "$(basename /sys/class/ieee80211/*)" info | grep -E 'Band [0-9]:'

	Band 1:
	Band 2:
	Band 4:

Burada phy0 yazmadım, çünkü kablosuz aygıtın adı her zaman phy0 olmuyor — sürücüyü yeniden yüklediğinizde numara artıyor (bendeki bu testlerin sonunda phy4 olmuştu). $(basename /sys/class/ieee80211/*) adı otomatik bulur.

Band 1 = 2,4 GHz, Band 2 = 5 GHz, Band 4 = 6 GHz. Yani kartım 5 ve 6 GHz’i destekliyor ama modem bu bantları sunmadığı için kullanamıyorum; herkesin sıkıştığı 2,4 GHz’de kalıyorum.

Bunun kritik olmasının sebebi şu: WiFi ile Bluetooth’un anten paylaşımı sorunu yalnızca 2,4 GHz’de ortaya çıkar. Bluetooth hep 2,4 GHz’de çalışır; WiFi 5 GHz’e çıkabilseydi ikisi farklı frekanslarda olur, aynı anteni paylaşsalar bile birbirini engellemezdi.

Bunu kendi deneyimimden biliyorum: 5 GHz’i olan fiber modemlerde bu sorunu hiç yaşamadım. Aynı dizüstü, aynı Bluetooth, aynı Fedora — ama sorun yok. Çünkü oralarda WiFi 5 GHz’e çıkıyor; Bluetooth 2,4 GHz’de kaldığı için ikisi ayrı frekanslarda çalışıyor ve çakışmıyorlar.

Yani tablo şu:

Bu modemi kullandığım sürece pratik çözümüm Bluetooth’u kapalı tutmak. Asıl kalıcı çözüm ise 5 GHz destekleyen bir modem ya da erişim noktası eklemek olurdu; o zaman hem 2,4 GHz’deki kalabalıktan hem de anten paylaşımı sorunundan tek hamlede kurtulurdum.

Yavaş bir ağı ayıklarken işe yarayan 6 kural#

1. “Aynı ağda ama biri yavaş” olması, sorunun internette olduğu anlamına gelmez. Benim sorunum ta uzakta değil, dizüstümle modem arasındaki kablosuz bağlantıdaydı; bunu da ancak internete hiç çıkmayan bir ölçümle (kendi modemime ping atarak) görebildim. Teşhiste en çok işime yarayan tek komut buydu.

2. Sinyalin ve bağlantı hızının iyi olması, bağlantının iyi olduğu anlamına gelmiyor. Bende -55 dBm sinyal, 130 Mbit/s bağlantı, 0 hata sayacı vardı — göstergelerin hepsi mükemmeldi. Ama gerçeği söyleyen şey bu göstergeler değil, gecikmenin nasıl dağıldığıydı.

3. Ortalama yanıltabilir. Bluetooth açıkken ortalamam 22 Mbps’ti; bu “yarı hız” gibi görünüyor. Oysa gerçek şuydu: ölçümlerin %67’si çökmüş, %33’ü tam hızdaydı. “Bazen yavaş” şikâyetimin sebebi buydu ve bunu ancak dağılıma bakınca gördüm.

4. Bir hipotezi test ederken, veriyi eleyen kuralı da test edin. “Bozuk ölçüm” diye attığım örnekler, tam da aradığım cevaptı — ve hepsi tek bir grupta toplanmıştı. Fark etmeseydim, kendi filtremin ürettiği bir sonucu “kanıt” diye yayınlayacaktım.

5. Çürüyen hipotez de bir sonuçtur. bt_coex_active=0 ve power_scheme=1 denemelerim başarısız oldu. Ama neden başarısız olduklarını anlamak (anten tek; trafik ışığını sökmek arabayı yoldan kaldırmaz) doğru çözüme giden yolu açtı.

6. Ölçmeden değiştirmeyin. İlk içgüdüm sürücü ayarlarıyla oynamaktı. Öyle yapsaydım günlerce yanlış yerde arardım — çünkü sürücüde hiçbir sorun yoktu.