Při hledání obdobných duchařin se nám osvědčil celkem stupidní skript (https://raw.githubusercontent.com/netx-as/aping/main/aping), který ve streamu po 2ms generuje ping a kontroluje jestli dorazily všechny odpovědi a hlavně jestli dorazily ve správném pořadí (vypisuje jen když je něco špatně). Takto jsme došli třeba na problém, kdy Miktrotiky (CCR) mají tendencí přehodit pořadí paketů v okamžiku, kdy stěhují stream ze zatíženějšího core na jiný. Normální aplikace se s tím nějak srovnají, ale třeba IPTV čí streamovací aplikace s tím mají tu a tam problém (zejména když se to potká s něčím dalším). Obdobně jsme narazili na situaci, kdy se stack na EdgeCore občas "zamyslel" a v průběhu několika ms zahodil pár paketů. V obou případech, stejně jako u Vás, klasické pingací testy například ze zabbixu bez chyby, protože problematický jev trval příliš krátce a ne zas tak často aby se v testu nějak viditelně projevil, nicméně streamům to náhodile vadilo.
Druhá věc je potom jak to zákazník sám testuje a jak věrohodné jeho výstupy jsou. Kolikrát se stává, že zákazník si sám ucpe linku (ucpou mu to třeba děcka tahající filmy z uložto) o čemž dotyčný stěžovatel nemá tušení. Doloží to pak pingama někam na druhý konec světa ze kterých nelze dovodit vůbec nic.
Třetí věc s čím jsme se setkali je samotné fungování shapovacích algoritmů. Řada z nich má reakci řekněme na úrovni 100ms a prvních 100ms (např. sfq na MT) jede provoz defacto naplno. Opět v normálním provozu to není samo o sobě nic dramatického, ale pokud se na sítí začne potkávat větší množství například IPTV/stream provozu, kde se každých několik vteřin stahuje nových chunk s max. rychlostí v prvních 100ms a jev se potká například ještě s pár přehozenýma paketama, tak stížnost, že telka zase "kostičkuje" je na světě.
