Verze 5.16

[okoun]

problémové spoje jsem přehodil z NS na NV2 a zatím to drží, uvidím ještě jak to pojede přes noc, zajímavé

[Maxik]

Nstreme je dost nachylnej na ruseni, rychle mu spadne rate, nv2 je o hodne pruraznejsi a ma latency control pri plnem vytizeni, nevyhoda je rozlitanejsi odezva pri male zatezi.

[hapi]

na to si přišel jak? všude kde je nstreme tak si konkurence neškrtná a vždy proje rušením nejlépe ze všech protokolů. NV2 běží na nižší rate okamžitě.

[okoun]

Ale já mám čisto a rate normálně držela a propustnost jedním směrem 41Mb/s ale furt to prostě padalo, jasně SW chyba, NV2 jede zatím furt bez pádu, zajímavé a potvrzuje to že je chyba v SW. Nstreme byl vždy průbojnější než NV2.

[Maxik]

Nstreme prubojnejsi nez nv2,mozna ve starsich verzich Nemusi to byt nutne soft. chyba, ale souhra blbyho nastaveni atd.

[okoun]

nesmysl, s ničím jsem nehýbal, největší legrace že to začaly dělat spoje, kde je velmi klidno a v okolí nikdo nevysílá...

[hapi]

vždy je nstreme prostupnější rušením. Akorát na duálních spojích nstreme moc neběhá. Na single A/Nkovejch sektorech máme stále nstreme a klienti si dávaji v klidu 45Mbit. Po přepnutí na NV2 jde rychlost dolu a to kdekoliv + jakmile přijde nějaký rušení, jde to dolu podstatně více. Nstreme na tohle je a vždycky byl mnohem lepší. Nechápu proč jenom k nstreme nepřidělaly ještě cyklickej buffer na odesílání a na celí tdma se měly z vysoka vykašlat. NV2 je sice ok, jenomže když si vemu např. dva wifi klienty, na jednom je 711 a jeden klient na kabelu a na druhym je RB493 s 9 klientů na kabelu. Po naplnění rychlosti wifiny dostanou oba wifi klienti rovnym dílem což podstatně znevýhodňuje ty klienty na RB493. Jo ano, shaping by měl zařídit aby k tomu nikdy nedošlo ale za úvahu to stojí.

Nstreme na duálnim spoji na jakymkoliv hardware se chová podivně. V jednu chvíly běží v pohodě a v druhou chvíly padne rate na minimum a nehodlá se zvednout. Občas se zvedne ale v drtivý většině zůstane dole.

[keksik]

Ako sa uz spominalo davnejsie, NV2 sa chova nevyspytatelne. Na jednej site ci spoji chodi ci uz na PtP alebo PtMp ok, na inom mieste aj ked za opticky lepsich ci rovnakych podmienok tam oproti Nstreme ide do kolien, jedna sa o single-pol spojenia na rovnakom HW a verzii MK. Absolutne som na nic neprisial preco, hehe, mozno preto ze nemam spektrak Ale Nstreme kdekolvek sa nasadi na 100% zlepsi parametre aj priepustnost spoja (u single-pol only u mna) ale tiez mu obcas preskoci - mam spoj na 7km 802.11a only, sem tam rusenie ako prase, ale len urcita cast dna, pri nstreme v tom case a smozrejme vytazenia spoja na cca 70% sli pingy do desiatok, inac az sa rusenie neobjavilo pingy 1-2ms. No tie excesy ma nasr... Tak som tam svihol NV2...a ono to chodii...odvtedy je klud, 24h pingy 5--7ms bez ohladu na vytazenie a dennu/nocnu hodinu a graf latencii je zrazu pekne takmer vodorovny uz nejaky ten mesiac

[hapi]

je jasný že latence ti při rušení nepoleze nahoru na NV2. Ale co propustnost? ta totiž poleze dolu a to podstatně víc než u nstreme.

[midnight_man]

NV2ka chodi dobre u 802.11n ....pri 802.11a je kralom Nstreme

[Maxik]

tak na Nku chodi lepe nv2 to ano, ale ze by byl Nstreme vsude nejpruraznejsi tak to zas ne. Kde je hodne zaruseno protlaci nv2 vic, alespon me a pridnesnich rychlostech se muze casto stat ze wifi jede na max tudiz latency control je fajn vec to nstreme nema a pak jsou haluz odezvy kdyz to jde na strop.

[Majklik]

What's new in 5.16 (2012-May-09 17:23):
*) reset packet mark when encapsulating/decapsulating from eoip,ipip,gre,eoipv6,ipipv6,gre6 tunnels

Tak tohle se jim silně nepovedlo. O tohle se na pár stech mistech opírám.
Klasiké použití:
Mám GRE tunely uvnitř IPsec transportu a dělám kontrolu, že tunel přišel opravdu přes IPsec. V mangle značkuji pakety ESP a následně ve filteru nad gre rozhranním testuji, že paket má marku, že dorazil původně jako ESP. Tak vím, že to opravdu prošlo IPsecem a ne nějaký podvrh nebo chybná IPsec konfiguce.

[Selič]

Vy, co máte problém s disconnecty, zkusili jste zvýšit hodnotu Disconnection timeout z default 3s?
Já jsem tam dal 10s, mžikové výpadky ve spojení tam stále jsou, ale aspoň se ušetří čas na reconnection

[pfadmin]

Moment, to moc nechápu, timeout když zvednu, tak ZKRÁTÍM čas výpadku? Měl jsem za to, že ten timeout je interval, kdy to hlídá, jestli se může spojit, takže by měl bejt co nejkratší ne? Díky za případné osvětlení, pokud to chápu blbě.

[hapi]

disconnect-timeout (time; default: 3s) - čas od třetího špatného odeslání ( 3*(hw-retries+1) pakety byly ztracené) (jenom v nejnižší datarate) (to jest poprvé od první aktivace on-fail-retry-time) kdy se klient odpojí. (logged as "extensive data loss").

samozřejmně že se do toho montuje i řazení rychlostí takže už to asi nebude tak docela pravda ale princip je stejnej. Otázka je jestli to má vůbec nějakej vliv když tam z protokolu 802.11 nezbyl ani ten název a tedy nikdo vůbec neví jestli tohle platí i pro NV2. Platí pro to i hw retries? nebo si to protokol řeší sám? nebo do toho furt zasahujou protokoly samotný karty? řeší NV2 pouze to co se posílá za data ve wifi rámci nebo řeší i ten samotnej rámec? To jsou takový otázky který by měl mikrotik nějak více specifikovat a objasnit problematiku. Tak nějak mám pocit že ty ladící prvky co tam jsou už nějak moc nefungujou když se přepne na NV2.