Great news
Quote ,,The change only affects 802.11 protocols on 802.11ac chips in RouterBOARD devices,,
When we will expect improvements for nv2 protocol? Why does it apply only for ac chips ''at the moment''?

Very good question!!

Very good question!
I also expect improvement on nv2 protocol, especially on point to multipoint. I think MikroTik can improve it A LOT!

Is there any ETA to nv2 improvements and single TCP on other wireless chips?

It would be interesting also to know which improvements are been made on wireless-cm2 from wireless-fp...

MT does not realize this topic drives a lot of wisps to shop elsewhere. nv2 works very stable but customer experience depends on what speedtest shows. Speedtest does tcp. We waited very long and begged to solve this for a long time as MT is a superior wisp platform. But we can't stand daily calls of speedtest users.

When we will expect improvements for nv2 protocol? Why does it apply only for ac chips ''at the moment''?

"Standard" protocol support would be implemented by chipset vendor in wireless chipset. NV2 would have to be at least partly implemented on CPU. So CPU is more of a bottleneck for NV2 than for standard protocols.

+1 for the NV2 TCP throughput improvement

I''m sorry, that i'm not in the spirit of this topic, but have some of you at least researched Nstreme and NV2, or how TCP works?

NV2 aggregates packets into bigger frames, strips down unnecessary packet headers, and sends those big chunks, so some of the packets have to wait until frame gets full, so some packets will have increased latency

TCP protocol gets it speed from low latency, cause it sends next packets only when acknowledgment that previous packet arrives are received.

So essentiall NV2 works against single TCP connection speed by design

Make a simple test, have point to point NV2 link, test speedtest.
then add bandwidth-test traffic udp limited to 5-10Mbps with medium size packets, and run the same speedtest.
You will be amazed that second test speedtest result will be better

bottom line, stop asking for impossible, learn how things work and how they should be used.

NV2 could be improved to looks like Motorola/Cambium tdma protocol, they can also add the 75/25 Down/Up feature for example.

I''m sorry, that i'm not in the spirit of this topic, but have some of you at least researched Nstreme and NV2, or how TCP works?

NV2 aggregates packets into bigger frames, strips down unnecessary packet headers, and sends those big chunks, so some of the packets have to wait until frame gets full, so some packets will have increased latency

TCP protocol gets it speed from low latency, cause it sends next packets only when acknowledgment that previous packet arrives are received.

So essentiall NV2 works against single TCP connection speed by design

Make a simple test, have point to point NV2 link, test speedtest.
then add bandwidth-test traffic udp limited to 5-10Mbps with medium size packets, and run the same speedtest.
You will be amazed that second test speedtest result will be better

bottom line, stop asking for impossible, learn how things work and how they should be used.

Modern os scale up the tcp window size. So latency is no reason tcp has to be slow. I have no problem to see 100Mbit tcp on a competing tdma product with 20 mhz channel size.

Modern os scale up the tcp window size. So latency is no reason tcp has to be slow. I have no problem to see 100Mbit tcp on a competing tdma product with 20 mhz channel size.

Agreed, so don't use Nv2 problem solved!