traceroute to 10.251.0.1 (10.251.0.1), 30 hops max, 60 byte packets
1 10.255.0.3 (10.255.0.3) 0.723 ms 0.714 ms 0.709 ms
2 10.255.2.2 (10.255.2.2) 1.191 ms 1.190 ms 1.184 ms
3 10.255.255.2 (10.255.255.2) 2.845 ms 2.843 ms 2.836 ms
4 10.255.1.6 (10.255.1.6) 2.980 ms 2.976 ms 4.631 ms
5 10.255.255.14 (10.255.255.14) 8.438 ms 8.453 ms 8.651 ms
6 10.252.0.3 (10.252.0.3) 8.635 ms 7.207 ms 7.202 ms
7 10.255.255.18 (10.255.255.18) 9.370 ms 10.864 ms 10.869 ms
8 10.248.0.2 (10.248.0.2) 10.856 ms 13.212 ms 13.225 ms
9 10.251.0.1 (10.251.0.1) 19.045 ms 19.057 ms 19.053 ms
tak si typni kolik je to ptp spojů na NV2. Během okamžiku se dá celková latence cca 2x snížit. Jo a mimochodem, co chybovost? máš někde smokeping přes nějaký ptp spoj? vem si nstreme vs. nv2 a budeš se divit. Nstreme ztrátuje i když to na pingání z počítače nevidíš ale nv2 neztrátuje NIKDY. Můžeš to samí říct o ubnt? Jo a ještě něco, jakou má latenci taková canopy? tam se to všechno nasčítá na jednom sektoru že?
Jeden spoj jsem měl pod smokepingem a na nstreme tam bylo cca 0.1% packet lostu, po přepnutí na NV2 tam byla 0% packet lostu. Jednalo se o test v řádech dnů takže průkazný.
Navíc zvětšení latence nás vůbec netrápí, i s takovym tracertem má klient do nixu celkem 25ms což prostě je furt v pořádku.
Je třeba přestat řešit kraviny. Všechny nový technologie jsou zaměřený na přenos velkých rámců. Nko přišlo s 2x většim rámcem než má nstreme sám což jinými slovy znamená i zvětšení latence při nizkých rate a pokud možno to chce velký tcp window size aby se dokázaly rámce řádně naplnit. Výsledkem jsou větší přenosovky.
Co takhle se zaměřit na jitter, rychlost, ztrátovost... latence je ten nejmenší problem.
