pokud se vylouci bezne problemy s chybami na eth jako FCS (poskozene packety) pak je mozne, ze
1) zahazuje ta ALCOMA protoze obcas nejaky burts zaplni jeji eth frontu a radio nestiha odesilat packety vzduchem. Counter ALCOMA zatim IMHO nema zadny, ale pokud zarizeni (zrejme switch), ktere zasobuje daty AlCOMU umi flowcontrol tak staci na ALCOME i zarizeni pred ni zapnout. Pokud je switchi pred ALCOMOU mozne sledovat pocet prichozich rxPAuse ramcu tak je podle toho, zda pocet roste hned videt, zda ma radio obcas problem nebo ne. Pokud ma switch dost bufferu na ulozeni cekajicich packetu je vyhrano a problem pravdepodobne vyresen
2) ma problem (i) trasa dal za ALCOMOu. Proste stejny problem jako v minulem bode ale na dalsich trasach. Ty mohou pri packetech, ktere prichazeji zbrzdene 100mbps rozhranim fungovat OK ale pokud packety budou chodit 365mbps rychlosti uz nemusi stihat.
Tiche ztraceni packetu (kdyz nikde neni videt ten chybovy counter) se da prokazat tak, ze nekde na konci spustim tcpdump a pokusim se trasou prohnat TCP test. Pak se nad nachytanymi packety ve wiresharku nebo necem inteligentnejsim podivam jestli dochazi k zadostem o znovuodeslani TCP segmentu a vyhodnotim v jakem mnozstvi se to deje (tj jestli to ma vliv na ryclost). Vyhodnoceni je rycle protoze wireshark podobne problemy zvyraznuje.
Pripadne se daji chytat packety v nejakem bode a pak si nechat vykreslit okamzite rychlosti behem nejake rozumne kratke periody (zlomky sekundy) - z toho je videt jestli jsou na trase vyznamne burty nebo nejsou.
