Ak by to malo byt tak, ze hodnota z prveho obrazku, ktora hovori o pocte asociovanych klientov je pravdiva, tak by sa dalo predpokladat, ze to bude zrejme pre tento druh routra/AP a prave s tymto firmware normalna vlastnost. Vacsina wifi AP v kategorii SOHO je ladena na vysoku priepustnost pri malom pocte pripojenych klientov. Cim vacsi pocet klientov je pripojenych, tym viac sa zhorsuje moznost klientskej stanice dostat sa do "eteru". Preto moze niekedy nastavat situacia aku popisujete. Jednoducho pride k timeoutu a protistanica, ktora caka na data to vyhodnoti ako chybu a prenos sa musi opakovat. Preto ping niekedy vynechava a je to nahodna vec pre rozne stanice.
Existuje na to matematicky model a presny vypocet aka je uspesnost pristupu k prenosovemu mediu pri urcitych poctoch klientskych stanic. Vola sa to DCF (Distribuovana Koordinacna Funkcia) a z grafu funkcie sa da vycitat, ze uz pri pocte sucasne vysielajucich stanic 5 je pravdepodobnost kolizie 50% a pri pocte stanic 8 je pravdepodobnost kolizie az 90%.
Kolizne stavy sa potom riesia cakanim, ktore mozu vyustit az do timeoutu. Vyssie vrstvy ako napr. TCP si potom ziadaju opakovanie prenosu.
Vpodstate s tym asi nic moc nespravite ak ta hodnota z prveho obrazku udava aktualny pocet pripojenych klientov. Je este moznost patrat po kvalite signalu, pretoze wifi bolo navrhovane do priestorov bez prekazok. S prijmom cez prekazky nastavaju problemy nielen s utlmom, ale zvycajne aj s znehodnotenim signalu, ktory dopada na antenu v rozdielnom case, kde cas je uz tak velky, ze odrazeny signal zasahuje casovo do dalsieho prenosu.