Community discussions

 
ste
Forum Guru
Forum Guru
Topic Author
Posts: 1803
Joined: Sun Feb 13, 2005 11:21 pm

New Wireless package

Wed Apr 23, 2014 9:54 am

How does it work compared to the standard wireless package. "Only" caps manager added or is there a difference in wireless nv2 performance, too?
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 24199
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: New Wireless package

Wed Apr 23, 2014 10:23 am

improved wireless driver, faster performance, "wireless fast path" mode

you can test the Fast Path (FP) like this "/queue interface> set wlan1 queue=only-hardware-queue"

but even with FP off, the wireless speed will be improved compared to regular package
No answer to your question? How to write posts
 
ste
Forum Guru
Forum Guru
Topic Author
Posts: 1803
Joined: Sun Feb 13, 2005 11:21 pm

Re: New Wireless package

Wed Apr 23, 2014 10:27 am

improved wireless driver, faster performance, "wireless fast path" mode

you can test the Fast Path (FP) like this "/queue interface> set wlan1 queue=only-hardware-queue"

but even with FP off, the wireless speed will be improved compared to regular package
Great. I'll give it a try on a testlink.

Channel List still does not limit power to the band rules? With my last test it does only max tx.
I would like to use channel list ...
 
ste
Forum Guru
Forum Guru
Topic Author
Posts: 1803
Joined: Sun Feb 13, 2005 11:21 pm

Re: New Wireless package

Wed Apr 23, 2014 1:02 pm

Tested on a 2km nv2 link and got big improvement with tcp-speed.

From 58,6/62,8 to 69/90,9 both Mbps Average speed. 4 TCP-Streams.
UDP is higher, too.

Well done!!
 
uldis
MikroTik Support
MikroTik Support
Posts: 3425
Joined: Mon May 31, 2004 2:55 pm

Re: New Wireless package

Wed Apr 23, 2014 1:11 pm

channel list and power limit should be working now with the new wireless package.
 
ste
Forum Guru
Forum Guru
Topic Author
Posts: 1803
Joined: Sun Feb 13, 2005 11:21 pm

Re: New Wireless package

Wed Apr 23, 2014 1:25 pm

channel list and power limit should be working now with the new wireless package.
Tried it now but the tx-power was to high (max card rate) for the band. band=5GHz A/N country=Germany.
 
uldis
MikroTik Support
MikroTik Support
Posts: 3425
Joined: Mon May 31, 2004 2:55 pm

Re: New Wireless package

Wed Apr 23, 2014 4:09 pm

channel list and power limit should be working now with the new wireless package.
Tried it now but the tx-power was to high (max card rate) for the band. band=5GHz A/N country=Germany.
Please tell exactly what channel entry you tried to use and did you use it for the frequency or for the scan-list?
 
marcin21
Member Candidate
Member Candidate
Posts: 187
Joined: Tue May 04, 2010 4:50 pm

Re: New Wireless package

Wed Apr 23, 2014 9:11 pm

I took this wireless package on a short test, and as for me it works worse than 5.14 with unspecifed/nstreme.
link:

rb711GA ---10km perfect LOS-- rb411-DBii-FN50pro , mcs12

and with nsteme 5.14 i get speed up to 120mbps with stable ping as old good nstreme,
with 6.12 with new wireles package it begins to choke around 105mbps.
tried to set hardwareonlyqueue, it doesn't make any diff.

btw. as for AR9220 chipset wider (25+25 Mhz) channels are not supported anymore in 6.12 ? ?
 
ste
Forum Guru
Forum Guru
Topic Author
Posts: 1803
Joined: Sun Feb 13, 2005 11:21 pm

Re: New Wireless package

Wed Apr 23, 2014 10:01 pm

I took this wireless package on a short test, and as for me it works worse than 5.14 with unspecifed/nstreme.
link:

rb711GA ---10km perfect LOS-- rb411-DBii-FN50pro , mcs12

and with nsteme 5.14 i get speed up to 120mbps with stable ping as old good nstreme,
with 6.12 with new wireles package it begins to choke around 105mbps.
tried to set hardwareonlyqueue, it doesn't make any diff.

btw. as for AR9220 chipset wider (25+25 Mhz) channels are not supported anymore in 6.12 ? ?
Did you test nv2?
 
marcin21
Member Candidate
Member Candidate
Posts: 187
Joined: Tue May 04, 2010 4:50 pm

Re: New Wireless package

Thu Apr 24, 2014 3:49 pm

Yes I did test nv2 too. but for ptp scenario i prefer nstreme due to better latency. I didn't test real tcp throughput though, maybe
there is improvment so nv2 finally hasn't problem with tcp connections. but as for me 5.14 (released 22-Feb-2012!) still wins this
competition.

Of course I did test over the boards to avoid problem with 100% btest cpu usage.

Please try to do TCP btest to board itself : 127.0.0.1 to see if it's not the btest/cpu optimalization that gave You better results.

again question to mtik staff :
Is custom channel width disabled in 6.12 ?
I get "unsupported channel" info when i try to use 25+25mhz channels. prior to 6.12 it was ok.
 
User avatar
janisk
MikroTik Support
MikroTik Support
Posts: 6283
Joined: Tue Feb 14, 2006 9:46 am
Location: Riga, Latvia

Re: New Wireless package

Fri Apr 25, 2014 8:37 am

btest have not been touched. Don''t you worry. Also, there are other tools around (iperf) to test that out.
 
marcin21
Member Candidate
Member Candidate
Posts: 187
Joined: Tue May 04, 2010 4:50 pm

Re: New Wireless package

Fri Apr 25, 2014 12:17 pm

i'm not worried about optimalizations :))

But i'm worried about custom channels width ? what about this feature with AR92xx in ROS 6.x?
is it abandoned ?
 
uldis
MikroTik Support
MikroTik Support
Posts: 3425
Joined: Mon May 31, 2004 2:55 pm

Re: New Wireless package

Fri Apr 25, 2014 2:29 pm

Nstreme protocol is fixed now in the latest RouterOS test build (v6.13rc7). You can get it from the development section on the Mikrotik Account Server.

Custom channel width should be working with AR92xx chipsets using the wireless-fp package. If it isn't please tell us exactly what values you are trying to use.
 
User avatar
honzam
Forum Guru
Forum Guru
Posts: 2287
Joined: Wed Feb 27, 2008 10:27 pm
Location: Czech Republic

Re: New Wireless package

Fri Apr 25, 2014 3:11 pm

Hello uldis. New wireless package will be integrated in next versions (6.14) in standart wireless package?
Or will be still separate?
LAN, FTTx, Wireless. ISP operator
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 24199
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: New Wireless package

Fri Apr 25, 2014 3:55 pm

Hello uldis. New wireless package will be integrated in next versions (6.14) in standart wireless package?
Or will be still separate?
Not yet. This driver has big changes, and we need to test it for a while longer. It will be an optional download for a while.
No answer to your question? How to write posts
 
marcin21
Member Candidate
Member Candidate
Posts: 187
Joined: Tue May 04, 2010 4:50 pm

Re: New Wireless package

Tue Apr 29, 2014 1:15 am

Still custom channel width is unsupported :


/interface wireless channels
add band=5ghz-a/n extension-channel=Ce frequency=5210 list=1 name=ch1-5210 \
width=25
add band=5ghz-a/n extension-channel=eC frequency=5300 list=1 name=ch3-5300 \
width=25
add band=5ghz-a/n extension-channel=Ce frequency=5320 list=1 name=ch2-5320 \
width=25

int wir pri
Flags: X - disabled, R - running
0 R ;;; in scan-list unsupported channel: ch3-5300
name="wlan1" mtu=1500 mac-address= ....

sys reso pr
uptime: 37m52s
version: 6.13rc7
build-time: Apr/25/2014 09:13:56
free-memory: 36.4MiB
total-memory: 64.0MiB
cpu: MIPS 24Kc V7.4
cpu-count: 1
cpu-frequency: 400MHz
cpu-load: 18%
free-hdd-space: 48.1MiB
total-hdd-space: 64.0MiB
write-sect-since-reboot: 944
write-sect-total: 286936
bad-blocks: 0%
architecture-name: mipsbe
board-name: RB711GA-5HnD
platform: MikroTik


allthough I did gave it a try, looks quite good with nstreme but sometimes drops rate to 6,5mbps :/
latency/throughput looks as good as with 5.14.
 
marcin21
Member Candidate
Member Candidate
Posts: 187
Joined: Tue May 04, 2010 4:50 pm

Re: New Wireless package

Sat May 10, 2014 5:21 pm

custom channel width on RB911uag2phnd, with new wireless package is also unsupported.
Will custom channel width option no longer be supported ?
 
uldis
MikroTik Support
MikroTik Support
Posts: 3425
Joined: Mon May 31, 2004 2:55 pm

Re: New Wireless package

Mon May 12, 2014 11:20 am

marcin21, do you have custom channel license enabled on that router and frequency-mode=superchannel enabled?
 
uldis
MikroTik Support
MikroTik Support
Posts: 3425
Joined: Mon May 31, 2004 2:55 pm

Re: New Wireless package

Mon May 12, 2014 11:22 am

custom channel width on RB911uag2phnd, with new wireless package is also unsupported.
Will custom channel width option no longer be supported ?
This feature isn't made for those boards yet.
 
marcin21
Member Candidate
Member Candidate
Posts: 187
Joined: Tue May 04, 2010 4:50 pm

Re: New Wireless package

Mon May 12, 2014 11:33 am

Yes of course, I have superchannel feature enabled.
 
uldis
MikroTik Support
MikroTik Support
Posts: 3425
Joined: Mon May 31, 2004 2:55 pm

Re: New Wireless package

Mon May 12, 2014 1:21 pm

Yes of course, I have superchannel feature enabled.
we will try to test this problem.
 
User avatar
Bergante
Member Candidate
Member Candidate
Posts: 131
Joined: Tue Feb 28, 2012 12:27 pm
Location: Bilbao, Spain

Re: New Wireless package

Tue May 13, 2014 4:40 pm

Confirmed with OmniTIKs.

I have the superchannel license, and I can't enable the custom 30 MHz channel width with wireless-fp enabled. Disabling wireless-fp and enabling wireless it works perfectly.
 
uldis
MikroTik Support
MikroTik Support
Posts: 3425
Joined: Mon May 31, 2004 2:55 pm

Re: New Wireless package

Tue May 13, 2014 4:51 pm

Confirmed with OmniTIKs.

I have the superchannel license, and I can't enable the custom 30 MHz channel width with wireless-fp enabled. Disabling wireless-fp and enabling wireless it works perfectly.
please contact support@mikrotik.com to get the RouterOS test build which has a fix for that starting test version v6.13rc23
 
ste
Forum Guru
Forum Guru
Topic Author
Posts: 1803
Joined: Sun Feb 13, 2005 11:21 pm

Re: New Wireless package

Tue May 13, 2014 5:07 pm

Today I had a strange problem: switching from nv2 to nstreme makes an RB411AH hardly accessible.
The device cycled Ethernetlink and was accessible for 3-20 seconds on ethernet and then not for
some time. I hardly managed to log in and disable wlan1 to make it accessible again and switch away from
nstreme.
Reboot did not help. I guess nstreme killed the cpu and this in some way kills ethernet connectivity???
 
uldis
MikroTik Support
MikroTik Support
Posts: 3425
Joined: Mon May 31, 2004 2:55 pm

Re: New Wireless package

Tue May 13, 2014 5:11 pm

Today I had a strange problem: switching from nv2 to nstreme makes an RB411AH hardly accessible.
The device cycled Ethernetlink and was accessible for 3-20 seconds on ethernet and then not for
some time. I hardly managed to log in and disable wlan1 to make it accessible again and switch away from
nstreme.
Reboot did not help. I guess nstreme killed the cpu and this in some way kills ethernet connectivity???
We had some problems with the v6.12 wireless-fp package running Nstreme wireless protocol. That problem is fixed in the latest test release of v6.13rc
 
ste
Forum Guru
Forum Guru
Topic Author
Posts: 1803
Joined: Sun Feb 13, 2005 11:21 pm

Re: New Wireless package

Wed May 21, 2014 8:21 am

Anyone tested nstreme with 6.13 wireless_fp ?.

With nv2/6.12/wireless_fp we have still the effect of degrading tcp-performance.
Every nv2 link reduces tcp-performance while udp-performance is optimal = the performance
of the slowest link of the chain.
 
onnoossendrijver
Member
Member
Posts: 418
Joined: Mon Jul 14, 2008 11:10 am
Location: The Netherlands

Re: New Wireless package

Wed May 21, 2014 10:05 am

How did you test the TCP and UDP speeds?
Linux/network engineer: ITIL, LPI1, CCNA R+S, CCNP R+S, JNCIA, JNCIS-SEC
 
ste
Forum Guru
Forum Guru
Topic Author
Posts: 1803
Joined: Sun Feb 13, 2005 11:21 pm

Re: New Wireless package

Wed May 21, 2014 12:25 pm

How did you test the TCP and UDP speeds?
With mikrotik-routers attached on both ethernet-sides of the link.
The results are in line with speedtest.net results.

It is some sort of queueing problem. Looks like bufferbloat but all participating
interfaces are set to "only-hardware-queue".
 
User avatar
Bergante
Member Candidate
Member Candidate
Posts: 131
Joined: Tue Feb 28, 2012 12:27 pm
Location: Bilbao, Spain

Re: New Wireless package

Wed May 21, 2014 1:27 pm

Would you please post the exact method used? I would be happy to try and compare.

Right now I am runnning NV2, and my configuration is a bit complex, BGP-VPLS connecting several networks at both sides of the link. But I think it's better not to use the own routers bandwidth test.

RouterOS 6.13 with wireless-fp

I have been running some tests using the built in bandwidth test, and it eats a lot of CPU (/tool profile is your friend) running in TCP mode. Enough to really cause issues between the processing needs of the wireless subsystem *and* the bandwidth test itself. If you see "idle" not getting any CPU time you are likely suffering from CPU starvation.

(VPLS is not involved in this particular test)

Example running TCP.

Setup is: Omnitik2 ----- (nv2/mpls) ----- Omnitik1 ----- (fast ethernet/mpls) ----- RB2011

Bandwidth server is running on Omnitik 2. Bandwidth test client on RB2011
[admin@rb2011-despa] > tool bandwidth-test protocol=tcp direction=both tcp-connection-count=4
address: 10.0.0.3
                status: running
              duration: 50s
            tx-current: 46.3Mbps
  tx-10-second-average: 46.1Mbps
      tx-total-average: 44.0Mbps
            rx-current: 46.6Mbps
  rx-10-second-average: 47.8Mbps
      rx-total-average: 45.6Mbps
           random-data: no
             direction: both
And the profile on Omnitik 2, where the bandwitdh test server is runnning
[admin@OmniTik-casa] /system> /tool profile 
NAME                    CPU        USAGE
wireless                all          31%
ethernet                all           1%
console                 all         0.5%
firewall                all           0%
networking              all        19.5%
mpls                    all           0%
btest                   all        46.5%
management              all         0.5%
routing                 all           0%
profiling               all           0%
bridging                all           0%
unclassified            all           1%
-- [Q quit|D dump|C-z continue]
Notice, no "idle" time. In this screenshot wireless gets 31%, btest takes a hefty 46 %.

Now let's try UDP, same setup just changing the protocol.
[admin@rb2011-despa] > tool bandwidth-test protocol=udp direction=both tcp-connection-count=4   
address: 10.0.0.3
                status: running
              duration: 48s
            tx-current: 62.5Mbps
  tx-10-second-average: 64.4Mbps
      tx-total-average: 64.0Mbps
            rx-current: 97.3Mbps
  rx-10-second-average: 92.1Mbps
      rx-total-average: 71.6Mbps
          lost-packets: 828
           random-data: no
             direction: both
               tx-size: 1500
               rx-size: 1500
[admin@OmniTik-casa] /system> /tool profile 
NAME                    CPU        USAGE
wireless                all        32.5%
www                     all           0%
ethernet                all         1.5%
console                 all           1%
flash                   all           0%
ssh                     all         0.5%
firewall                all         0.5%
networking              all         8.5%
mpls                    all         0.5%
btest                   all         8.5%
management              all           0%
routing                 all           0%
idle                    all        44.5%
profiling               all           0%
unclassified            all           2%
If I repeat the test but this time profiling on Omnitik 1, which is not running either a bandwidth server or a client, just passing traffic around, let's compare system profiles. Again, bandwidth test, bidirectional, tcp, 4 connections.
[admin@rb2011-despa] > tool bandwidth-test protocol=tcp direction=both tcp-connection-count=4   
address: 10.0.0.3
                status: running
              duration: 2m3s
            tx-current: 46.0Mbps
  tx-10-second-average: 46.0Mbps
      tx-total-average: 44.6Mbps
            rx-current: 47.1Mbps
  rx-10-second-average: 48.4Mbps
      rx-total-average: 46.4Mbps
           random-data: no
             direction: both
The transit Omnitik (just moving packets, no test code running on it)
[admin@OmniTik-despa] /tool> profile 
NAME                    CPU        USAGE
wireless                all        27.5%
ethernet                all           9%
console                 all           0%
dns                     all           0%
networking              all           1%
mpls                    all         1.5%
management              all         1.5%
routing                 all           0%
idle                    all        55.5%
profiling               all         0.5%
bridging                all           0%
unclassified            all         3.5%
And the endpoint where the bandwidth test server is running.
[admin@OmniTik-casa] /system> /tool profile 
NAME                    CPU        USAGE
wireless                all        23.5%
ethernet                all         1.5%
console                 all         0.5%
flash                   all         0.5%
ssh                     all           0%
firewall                all           0%
networking              all        14.5%
mpls                    all           0%
btest                   all          51%
management              all         0.5%
routing                 all           6%
profiling               all           0%
bridging                all         0.5%
unclassified            all         1.5%
Notice the amount of CPU resources consumed by the server.

So, the moral of the story is: Running measurement tools on your router will most likely alter your measurements in a rather significative way!

I would recommend you to use iperf or a similar tool between systems connected to your endpoints, so that your routers are just moving packets around.

To complete the picture, let me show you what happens with a bandwidth test using TCP through a Fast Ethernet link (Omnitik, RB2011), no packet loss.
[admin@rb2011-despa] > tool bandwidth-test protocol=tcp direction=both tcp-connection-count=16    
address: 10.0.0.2
                status: running
              duration: 46s
            tx-current: 57.1Mbps
  tx-10-second-average: 57.5Mbps
      tx-total-average: 57.2Mbps
            rx-current: 57.2Mbps
  rx-10-second-average: 57.5Mbps
      rx-total-average: 57.2Mbps
           random-data: no
             direction: both
[admin@OmniTik-despa] /tool> profile 
NAME                    CPU        USAGE
wireless                all           5%
ethernet                all        17.5%
console                 all         1.5%
ssh                     all           0%
networking              all        17.5%
mpls                    all         1.5%
btest                   all        53.5%
management              all         0.5%
routing                 all           0%
profiling               all           0%
bridging                all           0%
unclassified            all           3%
Again, the cpu consumption of the bandwidth test is limiting it by causing packet loss.
 
User avatar
Bergante
Member Candidate
Member Candidate
Posts: 131
Joined: Tue Feb 28, 2012 12:27 pm
Location: Bilbao, Spain

Re: New Wireless package

Wed May 21, 2014 2:05 pm

I forgot to say, switching from wireless to wireless-fp on 6.13 has been so far completely trouble free and I think the performance got slightly better (even for my somewhat weird configuration).

Now I am running wireless-fp and happy with it. The only issue I had with it on 6.12 was, 30 MHz channels didn't work but now they do.
 
ste
Forum Guru
Forum Guru
Topic Author
Posts: 1803
Joined: Sun Feb 13, 2005 11:21 pm

Re: New Wireless package

Wed May 21, 2014 4:20 pm

Hi Bergante,



thanks for the tests.

I know bandwidth test stresses the CPU so I do the tests from Devices which are connected with ethernet.


Actually I test this chain:


Omnitik UPA - Ethernet - SXT5ndR2 - Wireless - QRT5 - Ethernet - Omnitik - Ethernet - QRT5 - Wireless - RB411AH/R52nM - Ethernet - RB750UP


First Wireless link is 40MHz/Dual Chain/nv2
Second Wireless link is 20MHz/Dual Chain/nv2

Wireless Routers run 6.12/fp_wireless package.


This is the trace:


[admin@UPA10] > tool traceroute 192.168.50.217 count=10
# ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 213.185.129.177 0% 10 0.3ms 0.4 0.3 0.9 0.2
2 192.168.54.81 0% 10 3.1ms 3.9 1.9 10.1 2.7
3 192.168.50.41 0% 10 5.8ms 7.3 4.1 16.1 3.5
4 192.168.50.217 0% 10 8.1ms 7.5 5.5 11.9 1.7


These are tests from Omnitik UPA to:
1. Omnitik in the middle
2. RB411AH
3. RB750UP



[admin@UPA10] > tool bandwidth-test address=192.168.54.83 duration=20s user=admin password=xxx direction=receive protocol=udp
status: done testing
duration: 20s
rx-current: 97.3Mbps
rx-10-second-average: 97.3Mbps
rx-total-average: 73.2Mbps
lost-packets: 803
random-data: no
direction: receive
rx-size: 1500


[admin@UPA10] > tool bandwidth-test address=192.168.54.83 duration=20s user=admin password=xxx direction=receive protocol=tcp tcp-
onnection-count=4
status: done testing
duration: 21s
rx-current: 74.7Mbps
rx-10-second-average: 73.6Mbps
rx-total-average: 68.3Mbps
random-data: no
direction: receive



[admin@UPA10] > tool bandwidth-test address=192.168.50.164 duration=20s user=admin password=xxx direction=receive protocol=udp
status: done testing
duration: 21s
rx-current: 60.6Mbps
rx-10-second-average: 54.9Mbps
rx-total-average: 43.5Mbps
lost-packets: 355
random-data: no
direction: receive
rx-size: 1500


[admin@UPA10] > tool bandwidth-test address=192.168.50.164 duration=20s user=admin password=xxx direction=receive protocol=tcp
tcp-connection-count=4
status: done testing
duration: 21s
rx-current: 50.7Mbps
rx-10-second-average: 47.1Mbps
rx-total-average: 47.7Mbps
random-data: no
direction: receive



[admin@UPA10] > tool bandwidth-test address=192.168.50.217 duration=20s user=admin password=xxx direction=receive protocol=udp
status: done testing
duration: 20s
rx-current: 60.0Mbps
rx-10-second-average: 60.7Mbps
rx-total-average: 45.8Mbps
lost-packets: 903
random-data: no
direction: receive
rx-size: 1500


[admin@UPA10] > tool bandwidth-test address=192.168.50.217 duration=20s user=admin password=xxx direction=receive protocol=tcp
tcp-connection-count=4
status: done testing
duration: 20s
rx-current: 31.3Mbps
rx-10-second-average: 33.2Mbps
rx-total-average: 29.8Mbps
random-data: no
direction: receive



What you see: First wireless link is limited by 100MBit/Ethernet. Second link carries 60Mbit/s UDP Traffic. TCP speed drops from node to node.
Last tcp-drop is by 20MBit/s which is only adding the ethernet hop between RB411AH/R52nM and RB750UP.
I test with 4 tcp-streams which is the way speedtest.net does it. Using only one stream is even worse.


This is from the UPA in the middle to RB750UP to the right:

[admin@UPA13] > tool bandwidth-test address=192.168.50.217 duration=20s user=admin password=xxx direction=receive protoco
l=tcp tcp-connection-count=4
status: done testing
duration: 21s
rx-current: 48.2Mbps
rx-10-second-average: 48.6Mbps
rx-total-average: 48.5Mbps
random-data: no
direction: receive

You see the degradation is not as worse with only the second link.

So my conclusion is that there are hickups/queuing problems which sum up to make a bad
tcp result while udp is not disturbed.


Stefan
 
User avatar
Bergante
Member Candidate
Member Candidate
Posts: 131
Joined: Tue Feb 28, 2012 12:27 pm
Location: Bilbao, Spain

Re: New Wireless package

Wed May 21, 2014 4:27 pm

You see the degradation is not as worse with only the second link.

So my conclusion is that there are hickups/queuing problems which sum up to make a bad
tcp result while udp is not disturbed.
I would suggest a test using a pair of **nix hosts (FreeBSD or Linux is perfect for that) and checking a full tcp capture using tcptrace. You can find out if the degradationi is caused by packet loss, reordering, variable delays or whatever.
 
marcin21
Member Candidate
Member Candidate
Posts: 187
Joined: Tue May 04, 2010 4:50 pm

Re: New Wireless package

Thu May 22, 2014 3:40 pm

for testing tcp thruput with Mtik Btest, first run btest to 127.0.0.1 to see how much can the board handle.
and as for my tests:

rb433 - cpu 300mhz - TCP test ~40mbps HD, 30/30 FD
rb omnitik cpu 400mhz - TCP ~50mbps HD, 40/40 FD.

so testing tcp with these boards is pointless as they can't do more than above given stats.

for btest a x86 is most effiecient. intel atom 1,6ghz hits 500mbps TCP HD, 375/375 mbps FD.

another matter is fact that on Ros 5.x these results were half worse. so tcp btest on omnitik with 5.x gives even worse results.
and its nothing to do with wireless capacity.
:)
 
ste
Forum Guru
Forum Guru
Topic Author
Posts: 1803
Joined: Sun Feb 13, 2005 11:21 pm

Re: New Wireless package

Thu May 22, 2014 3:58 pm

for testing tcp thruput with Mtik Btest, first run btest to 127.0.0.1 to see how much can the board handle.
and as for my tests:

rb433 - cpu 300mhz - TCP test ~40mbps HD, 30/30 FD
rb omnitik cpu 400mhz - TCP ~50mbps HD, 40/40 FD.

so testing tcp with these boards is pointless as they can't do more than above given stats.

for btest a x86 is most effiecient. intel atom 1,6ghz hits 500mbps TCP HD, 375/375 mbps FD.

another matter is fact that on Ros 5.x these results were half worse. so tcp btest on omnitik with 5.x gives even worse results.
and its nothing to do with wireless capacity.
:)
Using 127.0.0.1 you hit the CPU twice as hard as it is sender and receiver.
My tests are reproducable with a speedtest from PC to speedtest.net.
There is a problem other than the speedtest itself.
 
ejansson
Member
Member
Posts: 301
Joined: Fri Oct 21, 2005 4:09 pm
Location: Manitoba, Canada

Re: New Wireless package

Thu May 22, 2014 7:07 pm

Looking at testing on some AP's.... is it necessary to be running it on the CPE too, or can I get away with just updating the AP?
 
uldis
MikroTik Support
MikroTik Support
Posts: 3425
Joined: Mon May 31, 2004 2:55 pm

Re: New Wireless package

Thu May 22, 2014 7:21 pm

you can also try to upgrade one end first, but I would suggest to test on both ends.
 
ejansson
Member
Member
Posts: 301
Joined: Fri Oct 21, 2005 4:09 pm
Location: Manitoba, Canada

Re: New Wireless package

Thu May 22, 2014 7:48 pm

thanks, Tried on the AP and no clients registered, using userman right now but even going to default auth nothing registered. Is this do to the new wireless or something that needs to be changed due to CapsMan?
 
User avatar
Bergante
Member Candidate
Member Candidate
Posts: 131
Joined: Tue Feb 28, 2012 12:27 pm
Location: Bilbao, Spain

Re: New Wireless package

Mon May 26, 2014 11:48 am

Using 127.0.0.1 you hit the CPU twice as hard as it is sender and receiver.
My tests are reproducable with a speedtest from PC to speedtest.net.
There is a problem other than the speedtest itself.
Measuring usable bandwidth, especially depending on where you do it, is much trickier than it seems.

I have just made a controlled test. This is it:

FreeBSD - Internet - Cablemodem - OmniTIK ~~~ OmniTIK - FreeBSD

Both FreeBSD systems running iperf3.

iperf3 parameters: 48 connections, TCP, 1 MB window size.

The cablemodem and the cablemodem provider is the unknown here, but, anyway, I have no problem to reach 80 - 100 Mbps of TCP. Even though the cablemodem is crap and I don't think it will be very good at keeping the NAT at 100 Mbps.
NAME                    CPU        USAGE
wireless                all          37%
www                     all           0%
ethernet                all        13.5%
queue-mgmt              all           0%
dns                     all           0%
networking              all          12%
mpls                    all         7.5%
management              all           0%
routing                 all         0.5%
idle                    all        21.5%
profiling               all         0.5%
queuing                 all           0%
bridging                all           3%
unclassified            all         4.5%
Unless you are doing specific TCP processing at the routers, or there is packet loss, there is absolutely no reason to get different results for TCP and UDP. If you are not doing any special TCP processing, both are IP packets.

The reason for those differences is the higher cost of the TCP bandwidth test running on the Mikrotik hardware. And note that depending on your round trip time (this link has an end to end delay of around 30 ms) you need really large window sizes. I am using 1 MB.
 
ste
Forum Guru
Forum Guru
Topic Author
Posts: 1803
Joined: Sun Feb 13, 2005 11:21 pm

Re: New Wireless package

Mon May 26, 2014 12:08 pm

Using 127.0.0.1 you hit the CPU twice as hard as it is sender and receiver.
My tests are reproducable with a speedtest from PC to speedtest.net.
There is a problem other than the speedtest itself.
Measuring usable bandwidth, especially depending on where you do it, is much trickier than it seems.

I have just made a controlled test. This is it:

FreeBSD - Internet - Cablemodem - OmniTIK ~~~ OmniTIK - FreeBSD

Both FreeBSD systems running iperf3.

iperf3 parameters: 48 connections, TCP, 1 MB window size.

The cablemodem and the cablemodem provider is the unknown here, but, anyway, I have no problem to reach 80 - 100 Mbps of TCP. Even though the cablemodem is crap and I don't think it will be very good at keeping the NAT at 100 Mbps.
NAME                    CPU        USAGE
wireless                all          37%
www                     all           0%
ethernet                all        13.5%
queue-mgmt              all           0%
dns                     all           0%
networking              all          12%
mpls                    all         7.5%
management              all           0%
routing                 all         0.5%
idle                    all        21.5%
profiling               all         0.5%
queuing                 all           0%
bridging                all           3%
unclassified            all         4.5%
Unless you are doing specific TCP processing at the routers, or there is packet loss, there is absolutely no reason to get different results for TCP and UDP. If you are not doing any special TCP processing, both are IP packets.

The reason for those differences is the higher cost of the TCP bandwidth test running on the Mikrotik hardware. And note that depending on your round trip time (this link has an end to end delay of around 30 ms) you need really large window sizes. I am using 1 MB.
Using 48 tcp-streams is a test which does not match real user experience.

A single TCP-stream suffers from bad conditions/delays much more than udp. Using more tcp streams work around the problem as while one tcp-stream is slowed down the others can proceed. Using infinite TCP Streams you'll reach near UDP speed. But this does not help the user as depending on the application he might use only one tcp-stream (e.g. FTP).

We test using 4 TCP-Streams as this is what a user gets when he tests with speedtest.net.

Of course you're right if you want to test the capacity of the link(chain). With a lot of users you'll see this capacity but a single user never see this bandwidth even if the link(chain) is unused.
 
User avatar
Bergante
Member Candidate
Member Candidate
Posts: 131
Joined: Tue Feb 28, 2012 12:27 pm
Location: Bilbao, Spain

Re: New Wireless package

Tue May 27, 2014 10:46 am

Of course you're right if you want to test the capacity of the link(chain). With a lot of users you'll see this capacity but a single user never see this bandwidth even if the link(chain) is unused.[/quote]

In my case, with a round trip time of more than 50 ms for large packets, a user needs a huge window and a large transfer size to be able to reach 100 Mbps in a single TCP flow.

Most servers won't enable windows larger than 64 KB and WWW traffic is based on brief connections.

What I wanted to illustrate, anyway, is that most of the differences in performance between UDP and TCP seen in this forum are just a limitation of the Mikrotik built-in bandwidth test, and *not* a weird NV2 or wireless problem affecting TCP especifically.
 
ste
Forum Guru
Forum Guru
Topic Author
Posts: 1803
Joined: Sun Feb 13, 2005 11:21 pm

Re: New Wireless package

Tue May 27, 2014 11:12 am

Of course you're right if you want to test the capacity of the link(chain). With a lot of users you'll see this capacity but a single user never see this bandwidth even if the link(chain) is unused.
In my case, with a round trip time of more than 50 ms for large packets, a user needs a huge window and a large transfer size to be able to reach 100 Mbps in a single TCP flow.

Most servers won't enable windows larger than 64 KB and WWW traffic is based on brief connections.

What I wanted to illustrate, anyway, is that most of the differences in performance between UDP and TCP seen in this forum are just a limitation of the Mikrotik built-in bandwidth test, and *not* a weird NV2 or wireless problem affecting TCP especifically.[/quote]

Yes. You need to know exactly how to test to get reasonable results.

Modern OSes handle larger tcp sliding windows quite well even on higher latency connections.
But with nv2 connections we see this tcp speed drops quite fast even with quite low latency.

E.g. this chain I am testing has 2 links. From there I have 1 licensed hop to our uplinks.
Latency to speedtestserver is <30ms. I should see 60MBit in speedtest instead of 15MBit I get.

This makes a *big* difference in communication with my customers.
 
Beeski
newbie
Posts: 34
Joined: Sat Apr 02, 2005 4:42 pm

Re: New Wireless package

Sun Jun 01, 2014 3:46 am

seeing 25-30% improvement on PtMP live RB800/R52Hn AP with 15 customers using 6.14rc25 with the wireless-fp package, default-small set to pcq on the RB711G-5HnD CPE and wlan1 on the AP set to only-hardware.

had a different AP (an RB800/R52Hn with 100 customers on 3 wireless cards) lock up while upgrading from 6.13 to 6.14rc10, but I also had the 6.14rc10 wireless-fp package in my AP's file folder, wonder if it got confused trying to upgrade both at the same time? 6.14rc25 includes wireless-fp so that issue goes away.
 
User avatar
Kreacher
Member
Member
Posts: 359
Joined: Wed Sep 25, 2013 3:58 pm
Location: Hogwarts

Re: New Wireless package

Sun Jun 01, 2014 11:11 am

Hello together,

the MikroTik RouterOS internally "Btest" is a great tool that comes
with the entire RouterOS, and as I see it right, it is related to the
circumstance that a router often is placed in a network at a core
place or at a place where routing is needed. but even it is an angle
network point in my eyes. And so if a network administrator is finding
out or plain his monitoring software is showing that there is a false,
problem, network failure or what ever miss fittings inside of his network
he is really fast able to reveal it and with the "Btest" he has a tool inside
of the router from where he is able to test some things out, but
for a real throughput test and also for the entire finite represent ability
it should be done with something like iPerf or jPerf respectively NetIO
to come more closer what is your entire network construct bringing
you or plain what you are able to imagine or expect from.

Only my 5 cents on top
Kindly regards
Kreacher ♬

--------------------------------------
Karma points must not be paid by you
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: New Wireless package

Thu Jun 19, 2014 5:00 pm

Guys;

you've been drifting a bit off topic with the bandwidth test. (Interesting though :) )
But, we are now at v6.15; how about sharing some real experiences of the new wireless-fp package?

I am running NV2 everywhere, but indeed, some links could use some improvements in throughputs.
I am at 6.13 now on the upgrade cycle, a bit reluctant to jump into 6.15 already, but when I find not too many issues effecting my network on this forum and at the same time some improved wireless I am ready to go for it.

So, do you guys can really share with us that the wireless-fp package is indeed improving throughputs?
Any 'thumbs-up' would be appreciated!
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
User avatar
dohmniq
Frequent Visitor
Frequent Visitor
Posts: 78
Joined: Sat Nov 17, 2012 12:17 pm

Re: New Wireless package

Fri Jun 20, 2014 6:37 pm

For anyone about to switch to the wireless-fp package, take note about these minor gotchas:
  • ht-rxchains and ht-txchains have been replaced by rx-chains and tx-chains
  • channel-width doesn't accept 20/40mhz-ht-above/below any more - channel widths are in new format 20/40mhz-eC/Ce (I guess in preparation for 802.11ac channel widths like 20/40/80mhz-eCee)
Don't expect to switch to wireless-fp, reset config and then import an existing config if you use the above parameters!
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: New Wireless package

Fri Jun 20, 2014 7:52 pm

One other 'gothcha!' I found;

If you made yourself a script to set units to a default setting, the wireless is indeed changed. So the wireless part of the script is full with errors and therefore not accepted. The wireless interface does not even get enabled. So if your routine was to load the scipt (with old format, but now the new wireless package installed) and you think the antenna is ready for deployment in the field.... you're wrong!
You have indeed to make a new script, like 'dohmniq' already sort of pointed at... :)
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
gius64
Member Candidate
Member Candidate
Posts: 204
Joined: Tue Jan 14, 2014 3:43 pm

Re: New Wireless package

Sun Jun 22, 2014 7:03 pm

I tested it over two p2p links and it runs very well.
Super stable latency with nv2 also with no traffic and almost like nstreme.

One one link TCP traffic is a little bit better using nstreme (5-10mbps more TCP on 80mbps)

I would like to test it also on ptmp on one or two APs and some users.

What happens if APs runs wireless-fp package and users don't?
 
dreamind
just joined
Posts: 5
Joined: Thu Apr 18, 2013 9:15 pm

Re: New Wireless package

Sun Jun 29, 2014 2:55 pm

I would like to test it also on ptmp on one or two APs and some users.

What happens if APs runs wireless-fp package and users don't?
I just tried this on 6.15 with a test-setup and only one user, works fine. The CPE is still running the wireless package, and the AP wireless-fp.
 
User avatar
Hotz1
Member
Member
Posts: 391
Joined: Tue Oct 09, 2007 6:55 am

Re: New Wireless package

Mon Mar 23, 2015 6:22 pm

One other 'gothcha!' I found;

If you made yourself a script to set units to a default setting, the wireless is indeed changed. So the wireless part of the script is full with errors and therefore not accepted. The wireless interface does not even get enabled. So if your routine was to load the scipt (with old format, but now the new wireless package installed) and you think the antenna is ready for deployment in the field.... you're wrong!
You have indeed to make a new script, like 'dohmniq' already sort of pointed at... :)
Allow me to second this lament. I have a diverse collection of RouterBoards, some of which have the original wireless package enabled, and some of which have wireless-fp. This argument change is a disaster for automation, unless you make sure the same package is enabled on all RouterBoards on your network--now and in the future.

Plus there's the wireless-cm2 package, which (thankfully) uses the same syntax as wireless-fp, rather than yet a third variant. So, I hope it is a safe assumption that the [rt]x-chains syntax will become the standard, and ht-[rt]xchains will be going away. And if that is the long-term plan, let's hope they make the same change to the original wireless package soon, and retire the old syntax altogether, rather than continue to carry (and burden us with) both versions.
Principal, Engineering
Cape Ann Communications, Inc.
Gloucester, MA, USA
 
User avatar
cdiedrich
Forum Veteran
Forum Veteran
Posts: 905
Joined: Thu Feb 13, 2014 2:03 pm
Location: Basel, Switzerland // Bremen, Germany
Contact:

Re: New Wireless package

Mon Aug 17, 2015 11:53 am

How do you test the bandwidth?
Beware that the builtin BW test is very CPU intensive.
In case you tested this with BW test feature of your NetMetals, you very likely maxed out the CPU.

For real life results, better use two comuters (one at each peer) and use iperf, you should see much better results.
-Chris
Christopher Diedrich
MTCNA, MTCUME, MTCWE
Basel, Switzerland
Bremen, Germany

There are 10 types of people: Those who understand binary and those who don't.
There are two types of people: Those who can extrapolate from incomplete data
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: New Wireless package

Mon Aug 17, 2015 1:01 pm

UDP & TCP difference:-

In Netmetal(v6.29.1) bandwidth test using udp can get (450Mbps FD)(210Mbps HD), and TCP can get (220Mbps FD)(100MbpsHD).

Anyone can telling me, why udp & tcp bandwidth difference is big?
In short; because udp is like you send a letter to recipient but you'll never know if it really arrives in proper state. tcp is like guaranteed delivery. If not the mail office will send the package again and again until considered useless to send. It needs to send some extra data with the original package to make sure the sender will know the receiver received the package and that it is received in proper condition. If not the receiver asks sender to send again.
So if your link is not 100% quality you will always have some packages resend and down goes your maximum throughput.

rule of thumb on good links is that you get 50-60% tcp traffic compared to the connection rate. That's a good working link!
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: New Wireless package

Mon Aug 17, 2015 1:02 pm

How do you test the bandwidth?
Beware that the builtin BW test is very CPU intensive.
In case you tested this with BW test feature of your NetMetals, you very likely maxed out the CPU.

For real life results, better use two comuters (one at each peer) and use iperf, you should see much better results.
-Chris
Indeed, I agree, that's another limiting factor. Always measure 'over' the two units making the link. Not 'from' or 'to' ...
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
ste
Forum Guru
Forum Guru
Topic Author
Posts: 1803
Joined: Sun Feb 13, 2005 11:21 pm

Re: New Wireless package

Mon Aug 17, 2015 6:39 pm

UDP & TCP difference:-

In Netmetal(v6.29.1) bandwidth test using udp can get (450Mbps FD)(210Mbps HD), and TCP can get (220Mbps FD)(100MbpsHD).

Anyone can telling me, why udp & tcp bandwidth difference is big?
In short; because udp is like you send a letter to recipient but you'll never know if it really arrives in proper state. tcp is like guaranteed delivery. If not the mail office will send the package again and again until considered useless to send. It needs to send some extra data with the original package to make sure the sender will know the receiver received the package and that it is received in proper condition. If not the receiver asks sender to send again.
So if your link is not 100% quality you will always have some packages resend and down goes your maximum throughput.

rule of thumb on good links is that you get 50-60% tcp traffic compared to the connection rate. That's a good working link!
This is a normal working nv2 link. Doing the same over a licensed wireless link there is nearly no difference between tcp and udp speed.
The guaranteed delivery causes ack packets to flow in the opposite direction making <5% additional traffic in the opposite direction. Modern OSes (ROS since newer 6.x versions) do much bigger sliding window so there is lower ack-traffic and no need to wait for ack which would slow down the connections.

I am sure MT could do some nv2 optimizations to bring tcp speed to udp - 5-10% if they only invest the time.
 
WirelessRudy
Forum Guru
Forum Guru
Posts: 3082
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: New Wireless package

Mon Aug 17, 2015 7:11 pm

This is a normal working nv2 link. Doing the same over a licensed wireless link there is nearly no difference between tcp and udp speed.
The guaranteed delivery causes ack packets to flow in the opposite direction making <5% additional traffic in the opposite direction. Modern OSes (ROS since newer 6.x versions) do much bigger sliding window so there is lower ack-traffic and no need to wait for ack which would slow down the connections.

I am sure MT could do some nv2 optimizations to bring tcp speed to udp - 5-10% if they only invest the time.
Now we talk two different things;

1. Licensed link means a free spectrum so no interferences. If the link is having a free fresnel you should have no losses en tcp only produce minor extra data compared to udp.

2. NV2 (Mikrotik's tdma) is indeed not very economic. Like eCambium or Mimosa show there are better ways to use the available spectrum and time of pa<=>cpe than the fixed time slots 'basic' tdma offers. (aimax is nothing better in that)

Indeed I think MT should put more in their wireless technology. But some here already mentioned that MT doesn't make wireless much to their focus...... so I'm afraid they'll loose this market segment over time....
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.

Who is online

Users browsing this forum: MSN [Bot] and 76 guests