Public-Mikrotik-Bandwidth-Test-Server(s)

Sat Oct 22, 2016 2:14 am

Instead of trying BOTH, try send by itself then try receive by itself.
Also you might want to try and verify you can ping 207.32.195.2 (the btest server)

North Idaho Tom Jones

jllz · Mon Oct 24, 2016 4:17 pm

So looks like it works with tcp but not udp.

gardenstate · Thu Oct 27, 2016 8:00 pm

Thank you for this service, NI Tom Jones.

(BTW, grew up in the Panhandle up near Murray.)

Thu Oct 27, 2016 8:45 pm

Thank you for this service, NI Tom Jones.

(BTW, grew up in the Panhandle up near Murray.)

Murray Idaho - Originally started as a mining camp back in the 1880s. Lots of trees, mountains and critters. Small community but a very beautiful place.
I am actually in Plummer Idaho - about 30 minutes or so south of Coeur d'Alene.

North Idaho Tom Jones

netflow · Sat Oct 29, 2016 6:05 pm

Thanks for the service Tom. It is a great alternative to speedtest. I hope you can keep it running despite its increasing notoriety.

Note to other testers: Windows v0.1 client is not up to the level of the ROS client. It should be avoided for any realistic figures.

RonJohn63 · Wed Nov 02, 2016 11:05 pm

(Had to temporarily disable the FW rule on dropping all WAN packets.)

Otherwise, it matches well with my 150/10 cable tier.

[admin@MikroTik] /tool> /tool bandwidth-test address=207.32.195.2 user=btest password=btest \
 	duration=00:01:00 direction=receive random-data=yes protocol=udp
                status: done testing
              duration: 1m1s
            rx-current: 163.0Mbps
  rx-10-second-average: 163.0Mbps
      rx-total-average: 146.3Mbps
          lost-packets: 1571
           random-data: yes
             direction: receive
               rx-size: 1500
[admin@MikroTik] /tool> /tool bandwidth-test address=207.32.195.2 user=btest password=btest \
	duration=00:01:00 direction=transmit  random-data=yes protocol=udp
                status: done testing
              duration: 1m1s
            tx-current: 10.8Mbps
  tx-10-second-average: 10.8Mbps
      tx-total-average: 11.1Mbps
           random-data: yes
             direction: transmit
               tx-size: 1500

interpoint · Thu Nov 03, 2016 10:17 pm

Greetings from Ireland !!

Firstly: Many thanks for providing this very useful btest facility.

We also had problems with the CHR's running on VMware ESXi 6.0 using Hotlava 10G Cards.

We experienced the VMware host would "Pink Screen of Death" complaining about the Network card approx once every 6 weeks approx.

We gave up and moved to CHR1072. It is not as good for BGP convergence on a CCR1072, however it doesn't crash - which is way more important

BGP Convergence of 1080219 routes to the Internet is around 20 minutes after startup. Single core limitation.

Did this test from one of our CCR1072's - she was RX'ing at 1G of live traffic at the time when I ran this test.

We have a 10G connection to the Internet on the CCR1072

Interesting that I can pull 2Gbps (on the RX) from your test server but can only manage 1.2Gbps (TX) to your test server.

[XXXXX@CCR1] > /tool bandwidth-test direction=receive local-tx-speed=2000M remote-tx-speed=2000M user=btest password=btest protocol=udp address=207.32.195.2
status: running
duration: 10s
rx-current: 1917.1Mbps
rx-10-second-average: 1918.8Mbps
rx-total-average: 1918.8Mbps
lost-packets: 0
random-data: no
direction: receive
rx-size: 1500

[XXXXX@CCR1] > /tool bandwidth-test direction=transmit local-tx-speed=2000M remote-tx-speed=2000M user=btest password=btest protocol=udp address=207.32.195.2
status: running
duration: 14s
tx-current: 1219.2Mbps
tx-10-second-average: 1180.7Mbps
tx-total-average: 1153.7Mbps
random-data: no
direction: transmit
tx-size: 1500

I have 19 hops between your router and mine.

capture.jpg

Fri Nov 04, 2016 5:26 pm

interpoint

Greetings from Ireland !!

Firstly: Many thanks for providing this very useful btest facility.
....

Hey - thanks for the feedback.

I am very interested in possibly changing the 207.32.195.2 btest server from a 32-bit ROS system running under VMware ESXi 6.something to a physical mikrotik hardware solution with 10-gig network cards.
I know that btest only uses 1 CPU when there are multi-cores available. Thus a btest server comes down to CPU clock speed to function well as a btest server.
So - I would like to ask you a favor please
On any of your Mikrotik platforms with 10-gig Ethernet, what do you get when you do a UDP btest to 127.0.0.1 ???
If I can find something that cat run at or near 10-gig, I want to try to switch the 207.32.195.2 btest server over to it - then see if it can handle the load while still delivering same speed results.

again - thanks for your post

North Idaho Tom Jones

Makoto · Tue Nov 08, 2016 10:51 am

Hi,

is servers still runing ? I did try few times last couple of days but never able to connect !

It would be so cool if Mikrotik has someting like that for at least 100Mbit test:)!

Tue Nov 08, 2016 2:42 pm

Hi,

is servers still runing ? I did try few times last couple of days but never able to connect !

It would be so cool if Mikrotik has someting like that for at least 100Mbit test:)!

Yea it's running. Uptime about a week or so.

Tue Nov 08, 2016 7:52 pm

Hi,

is servers still runing ? I did try few times last couple of days but never able to connect !

It would be so cool if Mikrotik has someting like that for at least 100Mbit test:)!

Have you been able to test to it in the past ?
Can you ping it ?
Is your Mikrotik behind a firewall ?

RonJohn63 · Tue Nov 08, 2016 10:01 pm

Hi,

is servers still runing ? I did try few times last couple of days but never able to connect !

It would be so cool if Mikrotik has someting like that for at least 100Mbit test:)!

I had the same problem, then enabled logging on the FW rule chain=input action=drop tcp-flags="" in-interface=ether1 log=no log-prefix="" and saw tons of drops.

Thus, I added this just above that rule:

add action=accept chain=input comment="IP address of public bandwidth tester" protocol=udp src-address=207.32.195.2

Wed Nov 09, 2016 4:12 am

Well - my x86 ROS 32-bit locked up again and I had to restart it

It locked up at California USA time 2016/11/08 17:49:23 ((( 5:49 PM ))

It is back up now

I am glad I don't use this as a primary high-bandwidth router.

North Idaho Tom Jones

Makoto · Thu Nov 10, 2016 10:38 am

Hi,

no I did not able to test in the past but I am able to ping the server, maybe it is firewall but not mine !
In a few days I am geting new dedicate line I whill try then!

Thu Nov 10, 2016 3:39 pm

Hi,

no I did not able to test in the past but I am able to ping the server, maybe it is firewall but not mine !
In a few days I am geting new dedicate line I whill try then!

Hmmm

Please post a tracefoute from your mikrotik

North Idaho Tom Jones

Makoto · Fri Nov 11, 2016 10:48 am

Hi

timeout at the moment

!

I can try again later

Fri Nov 11, 2016 7:43 pm

Hi

timeout at the moment !

I can try again later

Yup - my Mikrotik ROS x86 32-bit btest server was locked up again. I reset it and it should be running again.

I have a question to everybody - does anybody have a Mikrotik anything that is actually standing up to gig+ sustained routed bandwidth loads (like what my btest server goes through) ?

North Idaho Tom Jones

jasko · Wed Nov 16, 2016 1:29 pm

jasko - re I would ask you: How to configure a user to just have permission on the banwidth-test tool of the server?

Rather than type the answer to your question, I just made some image snapshots.
Is this what you was asking for ?

North Idaho Tom Jones
btest-user.png

Thanks Tom,
that was the answer I need

Great work!!

HumanDamned · Sat Nov 19, 2016 12:11 am

Subject: Public-Mikrotik-Bandwidth-Test-Server
Here are the details for my server:
- x86 ROS hosted on VMware ESXi server (with 10-gig connection to the Internet)
- Burstable to 250 Meg up/down
- Sustained traffic is limited to 100 Meg up/down (after about 30 to 60 seconds)
- Your maximum connection time for testing is not to exceed 10 minutes.
- IP Address: 207.32.195.2
- btest user authentication needed: User: btest Password: btest
- You may NOT winbox to this machine - you may bandwidth test to it.

Hi and Thanks for the server, but i cant understand why Btest to your server shows average TCP Tx Rx 15.0 Mbps/49.5 Mbps and speedtest.net - Tx Rx 661 Mbps/641 Mbps ?
The result are so much different...

Sat Nov 19, 2016 1:53 am

Subject: Public-Mikrotik-Bandwidth-Test-Server
Here are the details for my server:
- x86 ROS hosted on VMware ESXi server (with 10-gig connection to the Internet)
- Burstable to 250 Meg up/down
- Sustained traffic is limited to 100 Meg up/down (after about 30 to 60 seconds)
- Your maximum connection time for testing is not to exceed 10 minutes.
- IP Address: 207.32.195.2
- btest user authentication needed: User: btest Password: btest
- You may NOT winbox to this machine - you may bandwidth test to it.
Hi and Thanks for the server, but i cant understand why Btest to your server shows average TCP Tx Rx 15.0 Mbps/49.5 Mbps and speedtest.net - Tx Rx 661 Mbps/641 Mbps ?
The result are so much different...

My guess would be the speedtest.net server you are testing to might be closer than my btest server.
Try a speedtest.net speedtest using Seattle and see if that looks near the same as my btest server.
Also - are you btest ing using UDP or TCP? UDP should be faster.

North Idaho Tom Jones

HumanDamned · Sat Nov 19, 2016 1:16 pm

My guess would be the speedtest.net server you are testing to might be closer than my btest server.
Try a speedtest.net speedtest using Seattle and see if that looks near the same as my btest server.
Also - are you btest ing using UDP or TCP? UDP should be faster.

Oh, I see, it's in USA, then maybe that is the reason. I'm using TCP because speedtest also uses TCP, just wanted to compare the results.
Today results are - Btest up 31.8 Mbps/ down 66.4 Mbps and speedtest to Seattle up 697 Mbps/ down 141 Mbps.
Really crazy =)

gunguy7007 · Tue Nov 22, 2016 4:16 pm

Thank you, this helps a ton in troubleshooting.

Wed Nov 23, 2016 12:55 am

I just updated the 207.32.195.2 btest server (on 11/22/2016 3:PM California time) to the new ROS release v6.37.2

North Idaho Tom Jones

Yarisken · Wed Nov 23, 2016 7:55 pm

Thx for the tool

. Working great here.

kevgits · Fri Nov 25, 2016 12:54 pm

Hi,

I'm trying to ping the server from Kenya and it's timing out. Could you kindly confirm if it's running?

C:\Users\TOSH>ping 207.32.195.2

Pinging 207.32.195.2 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

On the mikrotik it returns the error "can't connect".

fabvit · Fri Nov 25, 2016 6:05 pm

As of today for me too the server is not pingable (Rome, Italy)

dash · Fri Nov 25, 2016 10:37 pm

same here

Mon Nov 28, 2016 5:31 pm

x86 ROS under load has a MTBF (meat time before failure) of less than 1 day. This is across all versions of x86 ROS for the last year.

If you can not ping or btest to this server, it is 99.999 percent because it locked up again. This btest server sometimes has to be reset up to 3 times a day.

I can only hope that CHR or anything else is better at faster than gig btest speeds.

North Idaho Tom Jones

mp3turbo · Tue Nov 29, 2016 1:15 am

Tom, what locks up ? Is it the x86 ROS virtual machine or is the whole physical server crashing under the load ? Can you post DETAILED information about your HW config especially about NW cards their models etc, versions of BIOS, ILO/DRAC card firmware if you have HP/Dell hardware (or equivalent of other vendors') ? If you have white box ("home made" computer), please post motherboard name, BIOS version.

Ideally in both cases, screenshots of BIOS settings would be great. Especially PCI Latency Timer, if you have one.

I'm running virtualized x86 ROSes with 100.0% uptime for years and yes, I have big bandwidths.

Tue Nov 29, 2016 3:39 pm

Tom, what locks up ? Is it the x86 ROS virtual machine or is the whole physical server crashing under the load ? Can you post DETAILED information about your HW config especially about NW cards their models etc, versions of BIOS, ILO/DRAC card firmware if you have HP/Dell hardware (or equivalent of other vendors') ? If you have white box ("home made" computer), please post motherboard name, BIOS version.

Ideally in both cases, screenshots of BIOS settings would be great. Especially PCI Latency Timer, if you have one.

I'm running virtualized x86 ROSes with 100.0% uptime for years and yes, I have big bandwidths.

I am running the following configuration:
- Physical server: I have tried Dell but now I run on a SuperMicro (SAS 12 tb hdd and 127 gig ram and intel 10-gig nics and two Xeon CPUs 10-core each with a crap-load of CPU cache.)
- Boot operating system on physical server: VMware ESXi 6.0.0 (I have also run ESXi version 5.x
- btest server is an x86 ROS 32-bit server (have tried many different fresh installs from scratch).
- Virtual host (ROS) configuration: Memory 2 gig - CPUs (Tried 1,2,3 and 4) currently 1 - HDD thin 8 Gig - single Network card E1000E

I have rebuilt and replaces and reconfigured everything to do with the btest server dozens of times.

I currently have 20 other additional virtual host servers/routers also running on my VMware ESXi machine. None of the other virtual routers (PfSense) or other virtual servers (DNS, sendmail, apache, radius, syslog, cacti etc ...) ever lock up. The only thing that locks up is ROS - never anything else.

When ROS locks up, it appears to be a complete loss of the TCP/IP stack. When it is locked up, the console is still alive and there is still an Ethernet link - but anything to do with IP anything is dead. When locked up, ROS can not even ping it's local loopback address of 127.0.0.1

If I had to take a guess at what the problem is, I would start with a guess that the ROS lack of paravirtual network drivers/support is the biggest potential problem. In my opinion, any x86 operating system without full set of paravirtual (tools, HDD, network, KVM) is pretty much a trusted brick if you are building a house - and only a brick.

It is very frustrating !!! I pretty much give x86 ROS a rating (0 to 10) of a solid -8 (negative

, and I suggest in a virtual routing environment to instead use PfSense for stability to achieve a never crash virtual environment.

Don't get me wrong and think I am down/against Mikrotik - I totally love ROS and Mikrotik has the best bang for the buck when it comes to wireless products. I know - I have more than 1,000 Mikrotik wireless devices. But when it comes to central core greater than 1-gig throughput processing, this I don't feel Mikrotik is a solution. In my opinion, Mikrotik uses slow cheap wimpy weak CPUs and are unable to reliably compete in the 500 meg to over 10-gig market. I am under the option that Mikrotik has nothing that can reliably handle the sustained often greater than 1-gig btest loads my btest server gets every day. However - for small office and residential use (less than 300 meg), mikrotik has some good products to consider.

North Idaho Tom Jones

Tue Nov 29, 2016 3:46 pm

One thing I will add,

It appears that when somebody is running a btest at high speeds (800 meg up to 10-gig), is when the ROS TCP/IP stack dies.

and note - I have some PfSense virtual routers on the same VmWare server often holding that sustained amount of traffic (near 8-gig sustained) for sometimes several hours.

Thu Dec 01, 2016 6:58 pm

Subject: Public-Mikrotik-Bandwidth-Test-Server
EDIT: Feb 24 2016 --- Now supports up to 3.5 Gig speedtest - read all the posts
EDIT: October 7th 2016 --- This btest server now supports 3.6 Gig for both send and receive tests - please read through all the posts

thx very much for the server Tom

I have tested successfully a gpon connection of 120mbps/60mbps udp and tcp with a RB750Gr2

Thu Dec 01, 2016 9:57 pm

Subject: Public-Mikrotik-Bandwidth-Test-Server
EDIT: Feb 24 2016 --- Now supports up to 3.5 Gig speedtest - read all the posts
EDIT: October 7th 2016 --- This btest server now supports 3.6 Gig for both send and receive tests - please read through all the posts

thx very much for the server Tom

I have tested successfully a gpon connection of 120mbps/60mbps udp and tcp with a RB750Gr2

Re: I have tested successfully a gpon connection of 120mbps/60mbps udp and tcp with a RB750Gr2
chechito - right now you are new best friend

I am trying to bring up a Mikrotik SFP GPON in one of my Mikrotiks.
My head-end to terminate my customer GPON devices is an Adtran TA-5000

I have some questions I would like to ask you.
Is your GPON network using a Mikrotik SFP GPON in a Mikrotik ?
Or is your GPON non-Mikrotik and you simply have a Mikrotik connected ?

North Idaho Tom Jones

Fri Dec 02, 2016 1:13 am

Re: I have tested successfully a gpon connection of 120mbps/60mbps udp and tcp with a RB750Gr2
chechito - right now you are new best friend

I am trying to bring up a Mikrotik SFP GPON in one of my Mikrotiks.
My head-end to terminate my customer GPON devices is an Adtran TA-5000

I have some questions I would like to ask you.
Is your GPON network using a Mikrotik SFP GPON in a Mikrotik ?
Or is your GPON non-Mikrotik and you simply have a Mikrotik connected ?

North Idaho Tom Jones

Sorry My isp brings a CPE which receive optical fiber directly, behind it i connect MIkrotik with ethernet copper

Fri Dec 02, 2016 6:25 pm

FYI: I just upgraded the Mikrotik ROS 32-bit public btest 207.32.195.2 server to version 6.37.3

When I did this - I know I bumped somebody off who was doing a btest at the time - sorry about that

North Idaho Tom Jones

Wed Dec 07, 2016 11:57 pm

FYI: December 7th 2016
I just replaced the Mikrotik ROS 32-bit public btest 207.32.195.2 server.
It is now a CHR 64-bit system.
It is hosted on the same VMware ESXi server which hosted the older 32-bit x86 ROS server.

So far it appears to have the same throughput capabilities. A local btest to the loopback 127.0.0.1 comes out between 18 to 19 gig.

There is still a simple-queue which limits peak testing to 3.6 gig up or down (and also limits sustained testing down to about 500 meg).

You are welcome to hammer away on it.
I would like to find out and verify if CHR is more stable/reliable under the same peak loads when compared to the original 32-bit ROS btest server.

btest server: 207.32.195.2
user: btest
password: btest

Chupaka · Thu Dec 08, 2016 1:01 am

Just tested, 3.6G down (to me)/1875M up with UDP

Well... Wow

I'm from Belarus, it's 8500km from Idaho =) RTT is 185 ms

With TCP it's only 1550M down/540M up

By the way, "Lost Packets: 0" after 5 seconds at 3.6G

Thu Dec 08, 2016 2:46 am

Just tested, 3.6G down (to me)/1875M up with UDP

Well... Wow I'm from Belarus, it's 8500km from Idaho =) RTT is 185 ms

With TCP it's only 1550M down/540M up

By the way, "Lost Packets: 0" after 5 seconds at 3.6G

Hey - sounds like you have a greater than 3.6 gig internet feed
If you ever want to do a brief no bandwidth test - just let me know
It would be interesting to see what it can go up to ...
North Idaho Tom Jones

Tue Dec 13, 2016 3:34 pm

Interesting, since upgrading from 32-bit x86 ROS to CHR on December 7th 2016, the btest server has not locked-up/died.
Normally I would of performed up to 15 resets/reboots by now.
I can only guess that the paravirtulized 10-gig network card drivers "vmxnet3" are working correctly.

North Idaho Tom Jones

Wed Dec 14, 2016 6:51 pm

Hope ya don't mind if I ask ...

Would somebody happen to be running a CHR or 32-bit ROS on a Amazon Web Services (AWS) account ?

This is not a problem. I just happened to look at who was connected to the 207.32.195.2 btest server and spotted a connection from AWS.

My question for you, what kind of throughput and processing ability are you able to get with AWS ?

North Idaho Tom Jones

marting · Tue Dec 20, 2016 2:22 pm

Thank you for providing this server!

Although I wonder why ROS does not correctly track their own BTEST UDP/Receive connections. I have same issue with UDP Receving like some other in this thread. I allow ESTABLISHED&RELATED in input and forward chain. But I have to disable my REJECT chains for UDP for the BTEST packets not to drop. Of course I could allow my btest IPs but in my opinion this should be covered by the connection tracking.

yoozieck · Thu Dec 22, 2016 10:43 am

Hello,
Is there any problem with the 207.32.195.2 test server?
I cannot connect today, nor can't ping it, this is my traceroute:

but using ping.eu comes with transmitted/received packets 100% success.

Thu Dec 22, 2016 6:52 pm

Hello,
Is there any problem with the 207.32.195.2 test server?
I cannot connect today, nor can't ping it, this is my traceroute:

but using ping.eu comes with transmitted/received packets 100% success.

Yea - it was down
in fact my entire network was down
huge spanning tree issue and native vlan issues across hundreds of network devices.

It should be up and running normally now.

North Idaho Tom Jones

Thu Dec 22, 2016 7:20 pm

Heads up -
Because I am still having some network problems (non-related to Mikrotik anything), I have turned off the 207.32.195.2 public btest server.
It will remain turned off until mid next week.

North Idaho Tom Jones

Thu Dec 22, 2016 9:19 pm

new feature wish list for Mikrotik ROS and CHR

I would like to see a new feature option in the bandwidth test setting (for server and clinet), where there is a new setting for maximum amount of time a btest can be performed.

Example:
- Where somebody connected up to my 207.32.195.2 btest server (from their client ROS/CHR device) and no matter what, the test will terminate after a set number of HH:MM:SS has elapsed.

This would be great for both client and server in btest.

One of the potential issues I often see with my 207.32.195.2 btest server is that somebody starts a btest to me and lets it run all night long. This can force the simple-queue to kick in after a few minutes and then slow down everything to what ever I have my simple-queue set for. When this happens, a second remote person wanting to also run a btest to my server may not be able to connect or get slower-than-normal results - or possibly not able to run a btest at all.

North Idaho Tom Jones

yoozieck · Fri Dec 23, 2016 12:06 am

Heads up -
Because I am still having some network problems (non-related to Mikrotik anything), I have turned off the 207.32.195.2 public btest server.
It will remain turned off until mid next week.

North Idaho Tom Jones

Thanks for your response.
I want to thank you, you are doing great work. Hope you'll get server running quick.
Merry Christmas from Poland to you, North Idaho Tom Jones, and to the whole forum

biland · Mon Dec 26, 2016 1:53 am

merry cristmas
and i love this server

on each mikrotik i can proof the speed for my client localy, without going there and show it on his windows..
does anybody know another server you can use, for the same mather (even slower, i dont mind)

Tue Dec 27, 2016 6:28 pm

I just turned back on the public 207.32.195.2 btest server

Please - no 10+ minute continuous extended bandwidth tests.
It's OK to use - but please don't do lengthy tests. Recently I've had some tests that have lasted for several hours or more.

I hope everybody had a good holiday - and will have a good New Years.

North Idaho Tom Jones

planetcoop · Tue Dec 27, 2016 10:55 pm

here is what i was able to test at on a 10gbps comcast fiber connection. Thank you for the public btest site.

1-traceroute.png

2-udp-15-seconds.png

3-tcp-15-seconds.png

planetcoop · Tue Dec 27, 2016 11:04 pm

here are two other random speed tests from beta.speedtest.net and speedtest.googlefiber.net

4-beta-speedtest-net.png

5-speedtest-googlefiber.png

Tue Dec 27, 2016 11:17 pm

On your hop 9 - it looks like there is a pretty big latency hit in Seattle - which is where I go through.

North Idaho Tom Jones

planetcoop · Wed Dec 28, 2016 12:08 am

I still think it looks good though. I have run a few tests with a dslreports.com admin and have had semi mixed results. Not Mikrotik related but just in general with high speed links. on my end, windows 10 is for sure the weak link. Some live Linux examples do better but anything above a few gigabit seem less reliable. I am using a CCR1036 with the 2 port sfp+.

Wed Dec 28, 2016 12:49 am

I still think it looks good though. I have run a few tests with a dslreports.com admin and have had semi mixed results. Not Mikrotik related but just in general with high speed links. on my end, windows 10 is for sure the weak link. Some live Linux examples do better but anything above a few gigabit seem less reliable. I am using a CCR1036 with the 2 port sfp+.

FYI -
Try turning off the firewalls on your Windows 10 machine and killing all in-necessary programs (anti-virus ...)
And try disabling hyper-threading on your Windows 10 machine
Sometimes - this will kick up the testing speeds on your Win 10 machine

Tom Jones

planetcoop · Wed Dec 28, 2016 1:27 am

Roger that. I am into tuning process queues on the intel nic. I have tested a variety of settings in the ccr and the hp switch. So far rss on the nic and buffer size seem to have the most impact on a single host. I have a number of servers and to the best of my testing tengb is great in aggregate. Although I dare to get the best desktop test yet.

macns · Fri Dec 30, 2016 11:53 am

Can't thank you enough for this. It has proven to be a most reliable tool whether we use it for debug or just rate checking.

Fri Dec 30, 2016 6:20 pm

Thought I would post a brief summary of the 207.32.195.2 btest server total data passed.
On average, since original activation in January 2016:

- The btest traffic averages out to the equivalent amount of data transferred as a sustained 40 meg load (yearly total average).
- It has had hundreds of btest testing faster than 1-gig (up and down)
- On average, somebody is testing to it about 20 percent of the time.
- At peak times, I have seen it busy all day with different testers
- CHR appears to work well as a btest server.
- I do not suggest an x86 ROS btest server - it tends to die under heavy btest loads.
- Because my Internet account is pretty fast, I have never felt any slowdown in my network while anybody is running a faster than gig btest.
- Surprisingly, I do not think the btest server has been used in a negative way by anybody to create problems & network congestion intended to make problems to other ISPs or Internet networks.

--- Also, thank you for posting your btest results and where you are in the world. I think this information helps everybody.

I plan to keep it running in 2018

EDIT - Kinda funny, I remember when I first proposed a day of public btest servers... Somebody commented "The day the Internet died." - lol

North Idaho Tom Jones

Fri Dec 30, 2016 11:32 pm

Hope you can keep it running in 2017 so far.
I am glad you gave the chance to chr as I suggested even you were not believe in it originally.
Happy new year to you and all over the world!

And please, do not copy one reply over dozen of threads. It was not nice from you...

Sat Dec 31, 2016 12:24 am

Hope you can keep it running in 2017 so far.
I am glad you gave the chance to chr as I suggested even you were not believe in it originally.
Happy new year to you and all over the world!

And please, do not copy one reply over dozen of threads. It was not nice from you...

Your point is noted

My poor excuse is - I was trying to put-to-rest several un-answered threads with the same related topic.

FYI - It would be nice if there were some additional static forum topics (instead of General) for key places to look/read/post on topics such as (GPON, ROS wish-lists, VPNs, 802.1q/Vlans, VRF, Walled-Garden/Captive-Portal/Rate-Limiting, how-other-ISPs-WISPs-Do-It, managing-large-quantities-of-Mikrotiks) which only contain these specific topics - instead of having a General where anything else often end up over and over again.
Just my two cents ...

North Idaho Tom Jones

Sat Dec 31, 2016 12:31 am

You could answer in one thread and link all others to it. Normally people would stay in there if they would like to reply so you could effectively join all the open topics to one which continues further. But never mind - just a sidenote.

planetcoop · Sun Jan 01, 2017 7:50 pm

Tom and crew,
I have setup a test CHR too. lets see what happens with results on this 10gbps uncapped CHR. I have limited the CHR to 50 concurrent sessions.

Host: btest.planetcoop.com
ipv4: 50.235.23.218
ipv6: 2001:559:8062::20
user and pass: btest

planetcoop · Tue Jan 03, 2017 9:00 pm

Tom, i didnt mean to hijack the forum post. i have seen a number of tests.

Tue Jan 03, 2017 10:19 pm

Tom, i didnt mean to hijack the forum post. i have seen a number of tests.

Hey - you are not hijacking anything ...
It's great that you are also offering a btest server also. (+1)

I think it benefits all Mikrotik admins , including you and myself.
You posts/messages are much welcome ...

North Idaho Tom Jones

planetcoop · Tue Jan 03, 2017 10:57 pm

btest interface graphs:
https://btest.planetcoop.com:10443/graphs/iface/ether1/

Wed Jan 04, 2017 12:17 am

btest interface graphs:
https://btest.planetcoop.com:10443/graphs/iface/ether1/

Question - what are you using to collect the SNMP information on your CHR and making the web page public ?

Myself - I use Cacti on everything.

FYI - the "5 Minute Average" is almost not a real measurement. Let's say you have almost zero traffic for 4 minutes 40 seconds, then somebody hits the btest server at gig + speeds - know what I mean ...

North Idaho Tom Jones

dadoremix · Wed Jan 04, 2017 12:22 am

These graps are from mikrotik
Tools/graphing

Sent from my iPhone using Tapatalk Pro

Wed Jan 04, 2017 12:27 am

These graps are from mikrotik
Tools/graphing

Sent from my iPhone using Tapatalk Pro

OK - I am gonna take a stab at it and see how to configure it on my btest server also ...
North Idaho Tom Jones

Wed Jan 04, 2017 12:30 am

These graps are from mikrotik
Tools/graphing

Sent from my iPhone using Tapatalk Pro
OK - I am gonna take a stab at it and see how to configure it on my btest server also ...
North Idaho Tom Jones

Wow - that was easy

http://207.32.195.2/graphs/iface/ether1/

dadoremix · Wed Jan 04, 2017 12:52 am

Anyone have big speed/bw in eu?
Ping to your tom from me is 227ms from croatia
And net is 150/75Mbit
Max for buy is 500/500 by optik

Sent from my iPhone using Tapatalk Pro

planetcoop · Wed Jan 04, 2017 2:13 am

These graps are from mikrotik
Tools/graphing

Sent from my iPhone using Tapatalk Pro
OK - I am gonna take a stab at it and see how to configure it on my btest server also ...
North Idaho Tom Jones
Wow - that was easy
http://207.32.195.2/graphs/iface/ether1/

I also use observium FREE and solarwinds Orion, not free. i also know you can share cacti graphs anonymously and its also FREE. I am trying to find out if observium can share anon links too.
Small Graph https://observium.planetcoop.com/graph. ... legend=yes
Large Graph https://observium.planetcoop.com/graph. ... width=1152

Chupaka · Wed Jan 04, 2017 1:42 pm

btest interface graphs:
https://btest.planetcoop.com:10443/graphs/iface/ether1/

using 'read' group for 'btest' user is probably not a good idea. anybody can login to the router and see its configuration, even sensitive information

Boter · Wed Jan 04, 2017 4:01 pm

I've been looking for this for a long time. Thanks! I cant find icon to give the reputation. Just great. Now I can really test bandwidth without killing the cpu.

planetcoop · Wed Jan 04, 2017 6:45 pm

btest interface graphs:
https://btest.planetcoop.com:10443/graphs/iface/ether1/
using 'read' group for 'btest' user is probably not a good idea. anybody can login to the router and see its configuration, even sensitive information

The good news is this is a dedicated chr for btest. The other side of it is to share info. Is there a way to restrict some of the more sensitive config parts while still allowing some read? In the mean time i have restricted the box btest user to a limited test group.

majestic · Wed Jan 04, 2017 9:13 pm

I just wanted to say, thank you for the access to your test servers. Its helped me dearly to tweak my QoS rules so I can now saturate the line without breakups.

planetcoop · Thu Jan 05, 2017 12:44 am

btest interface graphs:
https://btest.planetcoop.com:10443/graphs/iface/ether1/
using 'read' group for 'btest' user is probably not a good idea. anybody can login to the router and see its configuration, even sensitive information
The good news is this is a dedicated chr for btest. The other side of it is to share info. Is there a way to restrict some of the more sensitive config parts while still allowing some read? In the mean time i have restricted the box btest user to a limited test group.

I have ironed out the permissions to "test" and "winbox". It looks like permissions have not been working most of the day but i was just able to reset them and complete several tests. Have fun testing and thank you for recommending the permissions review.

emikrotik · Thu Jan 05, 2017 1:14 am

Hope ya don't mind if I ask ...

Would somebody happen to be running a CHR or 32-bit ROS on a Amazon Web Services (AWS) account ?

This is not a problem. I just happened to look at who was connected to the 207.32.195.2 btest server and spotted a connection from AWS.

My question for you, what kind of throughput and processing ability are you able to get with AWS ?

North Idaho Tom Jones

Hello,

I am running CHR 3.37.3 on a t2.medium instance on AWS Singapore 1b.

Download I am getting ~140Mbps
Upload I am getting 1Mbps

Is anyone else getting slow upload speeds from AWS Singapore?

When I run a cli bandwidth from a centos 7 box behind CHR I am only getting 1Mbps download/upload.

planetcoop · Thu Jan 05, 2017 4:51 am

Hope ya don't mind if I ask ...

Would somebody happen to be running a CHR or 32-bit ROS on a Amazon Web Services (AWS) account ?

This is not a problem. I just happened to look at who was connected to the 207.32.195.2 btest server and spotted a connection from AWS.

My question for you, what kind of throughput and processing ability are you able to get with AWS ?

North Idaho Tom Jones
Hello,

I am running CHR 3.37.3 on a t2.medium instance on AWS Singapore 1b.

Download I am getting ~140Mbps
Upload I am getting 1Mbps

Is anyone else getting slow upload speeds from AWS Singapore?

When I run a cli bandwidth from a centos 7 box behind CHR I am only getting 1Mbps download/upload.

Verify the license as a demo license is limited to 1mb/s and i cant remember what i had seen before, but i think it was a TX limit or a RX limit, not both. I have also run the CHR prior to production release like an RC and had odd btest numbers.

Chupaka · Thu Jan 05, 2017 1:03 pm

Is there a way to restrict some of the more sensitive config parts while still allowing some read?

looks like 'sensitive' permission is what you're looking for

uncheck it

planetcoop · Fri Jan 06, 2017 9:15 am

So, not sure who pulled this off, but a 9.9Gbps out bound test for several minutes? I realize the whole test was not that fast but happen to capture some data. I have also save a copy of the larger Observium graph for the time. I then though to capture the CPU load on the CCR 1036 that was performing the NAT from public to private IPv4 space in LAN. Notice in the year of 10Gbps internet I have not seen that kind of CPU load and sustained bandwidth usage.

btest-1.png

btest-2.png

btest-3.png

macsrwe · Fri Jan 06, 2017 5:23 pm

Thank you! Discovered my go-to speed-test servers were both out of service, just as I needed to use them to test and accept a speed upgrade cutover. Found yours in the nick of time. I need a good external speed-test server for about three minutes a half dozen times a year. Really, really hope you are able to keep offering this service without suffering abuse problems.

emikrotik · Mon Jan 09, 2017 7:42 am

Hope ya don't mind if I ask ...

Would somebody happen to be running a CHR or 32-bit ROS on a Amazon Web Services (AWS) account ?

This is not a problem. I just happened to look at who was connected to the 207.32.195.2 btest server and spotted a connection from AWS.

My question for you, what kind of throughput and processing ability are you able to get with AWS ?

North Idaho Tom Jones
Hello,

I am running CHR 3.37.3 on a t2.medium instance on AWS Singapore 1b.

Download I am getting ~140Mbps
Upload I am getting 1Mbps

Is anyone else getting slow upload speeds from AWS Singapore?

When I run a cli bandwidth from a centos 7 box behind CHR I am only getting 1Mbps download/upload.
Verify the license as a demo license is limited to 1mb/s and i cant remember what i had seen before, but i think it was a TX limit or a RX limit, not both. I have also run the CHR prior to production release like an RC and had odd btest numbers.

Thank you. This was the issue, after purchasing a P1 license I am now getting good transfer speeds.

On a t2.xlarge instance in Singapore I was getting ~370Mbps upload/download.
On a t2.nano instance in Singapore I am getting ~600Mbps download and ~190Mbps upload.

planetcoop · Mon Jan 09, 2017 11:50 pm

Here are some more stats:
Mikrotik Interface
https://btest.planetcoop.com:10443/graphs/iface/ether1/
Mikrotik Processor
https://btest.planetcoop.com:10443/graphs/cpu/
Observium Interface Daily
https://observium.planetcoop.com/graph. ... width=1152
Observium Processor Daily
https://observium.planetcoop.com/graph. ... width=1152

gotsprings · Mon Jan 16, 2017 7:12 pm

Just tried this for the first time. THANK YOU!!!

Numbers match speedtest.

I am in the DC metro area.

Your server tested from one of my APs.
65.6 Mbps/59.1 Mbps

My laptop against the Fios Server
65.48 / 57.88

Zorro · Wed Feb 01, 2017 11:39 am

ROS still not scale well over multi-core and many-core processors. (as does Linux they built ROS around)
orginal Tilera "Zero Overhead Linux" tailored by them for platform are built Enteriely differently with lot of stuff "in userspace", which Completely interfere with "minimal footprint/bloating" ROS approach and "ductape netfilter to kernel" -esque minimalism

to achieve similar scalability without moving to similar framework MT may adopt LWKT from DragonflyBSD and DFBSD kernel in future.
combined with Erlang-written code it allow achieve Impressive scalabilty in many-core, and in Distributed systems.

alexandrecorrea · Thu Feb 09, 2017 3:45 am

Nice service !!! btw, our CCR1036-8g-2S+ can only btest 2.5gbit/s (cpu running btest goes to 100%).

planetcoop · Thu Feb 09, 2017 3:51 am

Nice service !!! btw, our CCR1036-8g-2S+ can only btest 2.5gbit/s (cpu running btest goes to 100%).

Nice test, i see the traffic. What connection type did you test with, Comcast Gigabit-Pro? I ask due to the locations you listed in your profile.

My server is in Roseville, CA

alexandrecorrea · Thu Feb 09, 2017 3:59 am

Testing from Brazil (city: Sacramento, State: Minas Gerais)

17 hops away !!!

bbbbbbbbbb.png

router interface:

ccccccccccccc.png

Thu Feb 09, 2017 7:04 pm

Questions re the Mikrotik CCR1036-8g-2S and btest throughput

Q1: What kind of UDP bandwidth btest speed to you get when you test to 127.0.0.1 (your local loopback address) ?

Q2: Can the CCR1036-8g-2S be over clocked ? (Winbox -> System -> Routerboard -> Settings -> CPU Frequency)

If so, I have found the following results on all of my Mikrotik devices:
- #1; Overclocking to the second to fastest speed always works
- #2; Overclocking to the fastest speed -almost- always works (sometimes it is not stable and then I have to back down to the second to fastest speed available)
- #3; Overclocking always improves throughput. (to verify this - best to 127.0.0.1 at the default CPU speed - then btest again to 127.0.0.1 with the CPU overclocked).
- #4; Overclocking almost never increases Ethernet switched ports, but always increases Ethernet software bridged ports (and increases routing throughput).
- #5; I have about 100 Mikrotik APs (5 GHz running NV2) and throughput on all of them has increased some when the APs and/or/also Clients are overclocked.
- #6; I have a very busy, heavy traffic WDS link between two Mikrotik 922UAGS-5HPacD (AC only & HT chain 0-and-1 & NV2 & channel width 20/40/80) distance about 13 km & average link connect speed greater than 468 meg) , when both ends are overclocked to the maximum, it always runs much faster.
- - - If you test this , please post any btest throughput results. I am interested if others are also seeing a difference.

North Idaho Tom Jones

alexandrecorrea · Thu Feb 09, 2017 7:36 pm

Q1: 900Mbit/s (cpu core goes to 100%)

Q2: max 1200mhz

Questions re the Mikrotik CCR1036-8g-2S and btest throughput

Q1: What kind of UDP bandwidth btest speed to you get when you test to 127.0.0.1 (your local loopback address) ?

Q2: Can the CCR1036-8g-2S be over clocked ? (Winbox -> System -> Routerboard -> Settings -> CPU Frequency)

If so, I have found the following results on all of my Mikrotik devices:
- #1; Overclocking to the second to fastest speed always works
- #2; Overclocking to the fastest speed -almost- always works (sometimes it is not stable and then I have to back down to the second to fastest speed available)
- #3; Overclocking always improves throughput. (to verify this - best to 127.0.0.1 at the default CPU speed - then btest again to 127.0.0.1 with the CPU overclocked).
- #4; Overclocking almost never increases Ethernet switched ports, but always increases Ethernet software bridged ports (and increases routing throughput).
- #5; I have about 100 Mikrotik APs (5 GHz running NV2) and throughput on all of them has increased some when the APs and/or/also Clients are overclocked.
- #6; I have a very busy, heavy traffic WDS link between two Mikrotik 922UAGS-5HPacD (AC only & HT chain 0-and-1 & NV2 & channel width 20/40/80) distance about 13 km & average link connect speed greater than 468 meg) , when both ends are overclocked to the maximum, it always runs much faster.
- - - If you test this , please post any btest throughput results. I am interested if others are also seeing a difference.

North Idaho Tom Jones

Thu Feb 09, 2017 7:51 pm

FYI re: Q1

Slightly unrelated to a Mikrotik CCR1036-8g-2S

My Mikrotik CHR (public 207.32.195.2 btest server) - Virtual machine running on a very busy VMware ESXi server :

Just now tested: 18.2 Gbps

North Idaho Tom Jones

planetcoop · Thu Feb 09, 2017 8:07 pm

I did ok on a busy server and 4 core CHR @ 16.8Gbps. From what i have seen the btest application is single core per session test. its worth mention that my topology is a ccr1036 with 2sfp+ on the edge running IPv4 nat and IPv6 L3. The CHR is behind that with a nat'ed IPv4 and Public IPv6 address.
You can see the individual CPU cores on the CCR:
https://observium.planetcoop.com/graph. ... width=1152
You can see the individual CPU cores on the CHR:
https://observium.planetcoop.com/graph. ... width=1152

Thu Feb 09, 2017 9:03 pm

The VMware ESXi box I run my CHR on is a SuperMicro has two 10-core Xeon processors with HyperThreading enabled ( 40 logical processors ).
My VMware Summery reports:
20 CPUs x 2.999 Ghz
Intel Xeon CPU E5-2690 V2 @ 3.00 GHz
Logical Processors: 40

My CHR has only one CPU and 2 Gig RAM and one VMXNET-3 network card allocated to it via my VmWare ESXi hyper-visor.

In my opinion - It's not only CPU clock speed that counts , it's also the amount of CPU cache built into the processor. CPU cache memory is way way way faster than external RAM on the motherboard. I am pretty confident that most of my active CHR stuff is probably running mostly in CPU cache most of the time.

North Idaho Tom Jones

planetcoop · Thu Feb 09, 2017 10:02 pm

Really close in hardware

Chupaka · Fri Feb 10, 2017 12:43 am

Q1: 900Mbit/s (cpu core goes to 100%)

huh... my ccr-1036-2g-2s+ shows ~400 Mbps... ROS v6.33

whitbread · Sat Feb 11, 2017 2:59 pm

RB2011UiAS and RB951G show same results with ~380 Mbps

Funny thing is my RB951Ui shows ~470Mbps

dgnevans · Sat Feb 11, 2017 10:05 pm

1100ahx2 no firewall or queues 1050 mbps
ccr1009 with nat firewal mangle and queues 580 mbps
ccr1009 our the box with just fast track 1180 mbps

revellion · Fri Feb 17, 2017 11:28 pm

Great service!.

Tested a 1gbit Bidi link using your BTest server.

984mbit RX/TX with IPv6 traffic

.

Close to maximum of the gig link for the event it's gonna host in a few weeks..

Tue Feb 21, 2017 8:04 pm

Please use these public btest servers for brief periods of time.
When one person performs an extended 4-hour-long 400 meg btest, you are preventing everybody else from btesting at the same time because of Simple QOS rate-limiting settings.

North Idaho Tom Jones

Thu Feb 23, 2017 8:00 pm

I just upgraded my pubic btest server from 6.38.1 to 6.38.3
((( This is a virtual CHR hosted on a VMware ESXi physical server )))

My public btest server info:
TomjNorthIdaho btest server:
ipv4: 207.32.195.2
user and pass: btest
traffic graph of this btest server: http://207.32.195.2/graphs/iface/ether1/

Also - a second public btest server hosted by: planetcoop
planetcoop btest server:
Host: btest.planetcoop.com
ipv4: 50.235.23.218
ipv6: 2001:559:8062::20
user and pass: btest
traffic graph of this btest server: https://btest.planetcoop.com:10443/graphs/iface/ether1/

You are welcome and encouraged to post your btest throughput results - and please let us know where you are located:
Also; A Reputation +1 is always welcome.

Please - limit your btests to short periods of time. We are also using some of our bandwidth for our customers also.

Thank you

North Idaho Tom Jones

mikelindj · Sun Mar 05, 2017 7:57 am

VM RouterOS 6.38.1 on a Singtel Fibre Optic line in Singapore.
I'm support to get 300mbps up and down.

This is pretty close.

Although in another deployment where I've got 2m down 16m up, my users complain of 0.69mbps.
Any idea? Similar vm deployment.

Chupaka · Fri Mar 10, 2017 12:59 pm

Using 207.32.195.2
I cant seem to get more than 300-800Kbps on TCP Download?

Are others having an issue like this ?

upto gigabit w/o any problem

Fri Mar 10, 2017 6:20 pm

Using 207.32.195.2
I cant seem to get more than 300-800Kbps on TCP Download?

Are others having an issue like this ?

TCP and UDP are different types of Internet communications protocols.

UDP is a "Fire and Forget" protocol. The sending device will send a packet or packets and not wait for the intended remote receiver device to acknowledge that anything was received. Kinda like shooting a machine gun - it just sends.

TCP is a "Fire and wait for from the intended remote receiver device to return an acknowledgement (ACK) that a packet was received". After the ACK is received back by the original sending device, then the next TCP packet is sent - and the wait for answer routine begins again. Kinda like shooting a single bullet from a rifle and waiting for somebody to tell you that you hit the target before you shoot again.

UDP can be great for something like a movie stream where if something gets missed , then you just continue on sending the rest of the movie. Thus there is no real guarantee that what you sent was verified that it was received.

TCP can be great for something like pulling up a web page. The web server gets acknowledgement (ACKs) back from the workstation that the web page was properly received. Thus you get fewer communication mistakes.

Let's assume the following (below) are some data packets you want to send - which protocol would you want to use ?
- Packet 1 "Hello Robert , please "
- Packet 2 "don't "
- Packet 3 "call me on the phone"
If using UDP and "Packet 2" is dropped/lost, then the entire message could be understood as something totally different"
If using TCP, the entire communications session can be much slower because there is a wait time for everything.

Now in your scenario where "I cant seem to get more than 300-800Kbps on TCP Download" , the answer could be that you are many hops away (somewhere on the other side of the world), and waiting time for a round-trip answer takes an extended period of time. With UDP, there could be multiple packets going through the Internet that the sender sent and has not been received yet - because those multiple packets are still traveling through the Internet.

There are also some other possible causes of slow TCP traffic such as QOS, priority, network saturation, firewall behavior, symmetric or asymmetric paths through the Internet and others.

I hope I partially answered your question.
((( lol - if you absolutely need faster TCP bandwidth to 207.32.195.2, then mabey you need to move to North Idaho - lol )))

North Idaho Tom Jones

olkitu · Fri Mar 10, 2017 9:24 pm

Nice testing server!

CCR1072-1G-8S+ and 10Gbps Fiber link just we open from Finland. Maybe need get up also similar speedtest server here for testing

Sat Mar 11, 2017 2:42 am

olkitu

Re: ...Maybe need get up also similar speedtest server here for testing...

So you thinking about setting up a public btest server ?
I suspect it would be very useful to all Mikrotik admins - especially near your part of the world.

North Idaho Tom Jones

louisk · Sun Mar 12, 2017 9:28 pm

Hi there, I have been trying to test my CCR1009 connected to a 2Gbit fiber connection and I have tried both servers listed in this thread. I can consistently get 2GB's down (about 2.1-2.3 actually), but never really more than 1Gb up. Is there something I am doing wrong? I had the ISP come test, and they validated 2GB in each direction using their own tests so they claim the problem is in the CCR router.

Is there a way for me to reliably test 2GB in each direction? I am doing UDP testing.

olkitu · Tue Mar 14, 2017 10:30 am

olkitu

Re: ...Maybe need get up also similar speedtest server here for testing...

So you thinking about setting up a public btest server ?
I suspect it would be very useful to all Mikrotik admins - especially near your part of the world.

North Idaho Tom Jones

Yeah it's nice but let see when i have time to buy licence for 10G+ CHR and put that to VPS... We are ISP and Hosting Company so we have own peering what is 10G+ now. Also we are sell Mikrotik devices here Finland... Also need QOS rules because someone can use that make connection down... Also need server with 10G+ port, now mostly we have only 1G+...

This connection shared also to our customer also

olkitu · Tue Mar 14, 2017 10:32 am

Hi there, I have been trying to test my CCR1009 connected to a 2Gbit fiber connection and I have tried both servers listed in this thread. I can consistently get 2GB's down (about 2.1-2.3 actually), but never really more than 1Gb up. Is there something I am doing wrong? I had the ISP come test, and they validated 2GB in each direction using their own tests so they claim the problem is in the CCR router.

Is there a way for me to reliably test 2GB in each direction? I am doing UDP testing.

I think on this free open servers have upload limits... Also where are u? So example here Finland cannot get 10G+ because too long line and too much peering... Thats why need also speedtest server here so can test

- Both server is in US

planetcoop · Sat Mar 25, 2017 7:13 am

Hi there, I have been trying to test my CCR1009 connected to a 2Gbit fiber connection and I have tried both servers listed in this thread. I can consistently get 2GB's down (about 2.1-2.3 actually), but never really more than 1Gb up. Is there something I am doing wrong? I had the ISP come test, and they validated 2GB in each direction using their own tests so they claim the problem is in the CCR router.

Is there a way for me to reliably test 2GB in each direction? I am doing UDP testing.

Let me guess Comcast gigabit-pro? Either way where are you located and what kind of configuration do you have on the ccr? Like NAT or only layer-3? firewall rules or even regex operations?

Groov · Wed Apr 05, 2017 12:32 am

Ukraine Dnepr

Wed Apr 05, 2017 5:59 pm

3 Gig btest - wow, you definitely have high-speed Internet access.

North Idaho Tom Jones

npmarshall · Tue Apr 11, 2017 2:38 am

Nevada - performed with a CCR1036-8G-2S+. Thank you very much.

kei888 · Thu Apr 20, 2017 3:39 am

Thank you so much for this.

More power!

God bless!

Fri Apr 28, 2017 3:45 am

O come on now ...

It's one thing to run a brief bandwidth test to the public btest server at 207.32.195.2
But it's another thing to run a sustained btest for hours or days non-stop.

Although I have the bandwidth, the simple queues on this btest server will drop down in throughput rates when you keep a sustained btest running. Thus if anybody else tries to btest to the same server, they will never be able to see their peak throughput (because you have the simple queue slowing down the btest server for the next person wanting to test.)

So with that, 216.218.22.xx and 94.142.173.xx , you are more than welcome to btest to 207.32.195.2 - however please make these btest tests brief so the next person can also btest at full speed.

Thank you

North Idaho Tom Jones

Fri Apr 28, 2017 4:15 am

Yo , planetcoop

Thought I would ask ...

Are you up for a btest server to btest server test ? (my 207.32.195.2 btest server to your 50.235.23.218 btest server) ?

If you have the bandwidth and available resources ...
Sometime tomorrow morning, I would like to run a 4 hours long btest ( both directions - UDP - with up and down speeds set to 1250M ).

I would like to stress test and hold both directions slightly faster than 1-gig. This way I can verify we are on 10-gig routers and switches end to end and that my normal ISP client traffic does not take any slowdown hits during this hours long test.

I was thinking about starting sometime after 8 AM PST tomorrow Friday. But I will wait for your permission btest first.

North Idaho Tom Jones

planetcoop · Fri Apr 28, 2017 4:53 am

let it rip...

You can try to PM me or email me if you want, i wouldn't mind an offline conversation.

Fri Apr 28, 2017 6:13 pm

let it rip... You can try to PM me or email me if you want, i wouldn't mind an offline conversation.

The btest is running now

Say - shoot me an email with your contact info - and I will call you

My email address is < tjones -at- cdatribe-nsn -dot- gov

North Idaho Tom Jones

planetcoop · Fri Apr 28, 2017 7:15 pm

you should have an email from me and i have confirmed the test @ 1.35Gbps?

confirmed.png

planetcoop · Fri Apr 28, 2017 10:04 pm

Previous testing

planetcoop · Fri Apr 28, 2017 10:06 pm

Tom, today's test

Fri Apr 28, 2017 10:41 pm

btest-4-hours.png

Here are the results of the 4-hour long Mikrotik btest test we just performed:

Public btest server 207.32.195.2 to public btest server 50.235.23.218

This 4-hour long extended btest through the Internet used the following settings:
Local Tx Speed 1250M (aka 1.25 Gig)
Remote Tx Speed 1250M (aka 1.25 Gig)

Amount of data transmitted was more than 2.7 TB -&- amount of data received was more than 2.7 TB

North Idaho Tom Jones

Fri Apr 28, 2017 11:07 pm

FYI: public btest server was just software upgraded moments ago.
As of April 28th, 2017 1PM PST, the Mikrotik CHR-P10 is now running CHR-ROS version v6.39

by the way - - - If there are any other Mikrotik admins willing to run a public btest server , please post and let us know. If you do, we can offer some advice for how to limit the maximum btest bandwidth so that your networks continue running correctly during a btest session.

North Idaho Tom Jones

planetcoop · Fri Apr 28, 2017 11:31 pm

FYI: public btest server was just software upgraded moments ago.
As of April 28th, 2017 1PM PST, the Mikrotik CHR-P10 is now running CHR-ROS version v6.39

by the way - - - If there are any other Mikrotik admins willing to run a public btest server , please post and let us know. If you do, we can offer some advice for how to limit the maximum btest bandwidth so that your networks continue running correctly during a btest session.

North Idaho Tom Jones

I update my edge and btest at 5:30AM PST in preparation for today's btests. So far no issues.

planetcoop · Wed May 03, 2017 5:24 pm

BUMPED to 6.39.1 current.

Wed May 03, 2017 6:08 pm

BUMPED to 6.39.1 current.

wombat · Fri May 12, 2017 7:18 pm

Hi,

Why doesn't work only UDP receive direction? All the time only "0 bps" with Both or TCP no problem.

Sob · Fri May 12, 2017 7:36 pm

Firewall, most likely. UDP packets from BTest server look like unsolicited traffic.

planetcoop · Fri May 12, 2017 9:12 pm

I have posted some high speed feedback for new device considerations in the other post, just mentioning it here to also check out. viewtopic.php?f=2&t=121533

Fri May 12, 2017 9:32 pm

Re: ... Firewall, most likely. UDP packets from BTest server look like unsolicited traffic. ...

I agree

The 207.32.195.2 btest server does not have any firewall rules.
The 207.32.195.2 btest server is not behind another firewall.
The 207.32.195.2 btest server is directly connected to the Internet.

If somebody is having problems with a TCP and/or UDP btest in either or both directions, then you may want to examine your firewall rules.

North Idaho Tom Jones

wombat · Fri May 12, 2017 10:54 pm

Ok, i have default firewall. When i disable drop rule. So it works good. Have I bad firewall rules?

planetcoop · Fri May 12, 2017 11:08 pm

no, typically you do not want the internet or random networks hitting the input chain. you would have to allow for this with a rule additional to default rules but you can also enable/disable rules based on testing or other requirements.

As Tom said in his previous post about the btest, mine is not as accessible due to ipv4 limitations i have. Mine is NAT4 behind an address on a ccr1036 and is also available on ipv6 directly routed through the ccr1036. In my own testing the NATipv4 configuration is not a limitation in testing and has a port range to support testing.

Fri May 12, 2017 11:19 pm

Most probably it is better than nothing. Just add accepting rule for the traffic from the ip addresses you want to get packets from.

k6ccc · Tue May 30, 2017 9:48 pm

First of all, thanks guys for offering these bandwidth tests.
I'm trying to set this up as a script with the output to a file which will then be E-Mailed to me. The idea being that once a day, the router will perform the test. If I see substantial changes in performance, I can investigate. For testing this, I am using the following commands:
[admin@RB750Gr3 #2] /tool> bandwidth-test 50.235.23.208 direction=both duration=15s random-data=yes user=btest password=btest

This produces a correct output after 15 seconds:
status: done testing
duration: 16s
tx-current: 12.1Mbps
tx-10-second-average: 12.1Mbps
tx-total-average: 11.8Mbps
rx-current: 121.2Mbps
rx-10-second-average: 95.4Mbps
rx-total-average: 68.8Mbps
lost-packets: 0
random-data: yes
direction: both
tx-size: 1500
rx-size: 1500

Then I change the command to:
[admin@RB750Gr3 #2] /tool> bandwidth-test 50.235.23.208 direction=both duration=15s random-data=yes user=btest password=btest file="BW_test.txt"

This produces the file BW_test.txt as expected, but not with the expected data. All I get in the output file is:
# may/30/2017 11:28:43 by RouterOS 6.39.1
# software id = [redacted]
#
status: connecting
duration: 0s
tx-current: 0bps
tx-10-second-average: 0bps
tx-total-average: 0bps
rx-current: 0bps
rx-10-second-average: 0bps
rx-total-average: 0bps
lost-packets: 0
random-data: yes
direction: both
tx-size: 1500
rx-size: 1500

I never get any results after connecting.

Any suggestions about what I'm missing???

BTW, this is from the Los Angeles area on my newly installed Spectrum cable based connection (massive improvement over my DSL!)

Thanks

k6ccc · Thu Jun 01, 2017 6:14 pm

BTW, ignore my typo of the IP address that I'm using for my testing. I really am using 50.235.23.218

planetcoop · Tue Jun 06, 2017 3:23 pm

I have updated my CHR btest 50.235.23.218 to 6.39.2: viewtopic.php?f=21&t=122322

Tue Jun 06, 2017 10:22 pm

I have updated my CHR btest 207.32.195.2 to 6.39.2

Tue Jun 06, 2017 10:29 pm

btest002.png

btest001.png

FYI - below is a cacti graph of my 207.32.195.2 btest server

planetcoop · Tue Jun 06, 2017 11:44 pm

Anyone notice the pickup in testing between both servers and the sustained testing?

bleeding.png

Wed Jun 07, 2017 1:43 am

Anyone notice the pickup in testing between both servers and the sustained testing?
bleeding.png

On the 207.32.195.2 btest server, I have been seeing some btest sessions that appear to not quit after a few minutes.
I have seen some btest sessions that will go 24 hours non-stop.

Hay everybody - please do not run sustained btest tests. These btest servers are intended for brief btest testing.
When one person holds a continued non-stop btest, then other Mikrotik admins can get skewed results to the same btest server.

Example - on my 207.32.195.2 btest server, I have a simple-queue that will auto drop the bandwidth after a minute or so to around 500 meg in both directions.
When somebody holds an extended btest test, the simple-queue kicks in. Then when a 2nd Mikrotik admin starts a btest, then both admins are sharing a 500 meg max throughput session.
I often see 5 btest tests at the same time - this means that when one person has triggered the simple-queue (because of a lengthy btest) , then all 5 Mikrotik admins can only get a slice to the 500 meg (due to simple-queue).
When nobody in btesting, the simple-queue clears itself and the first person to execute a btest test can actually hit 2-gig and faster for a minute-or-so until the simple-queue kicks in again.

North Idaho Tom Jones

Wed Jun 07, 2017 1:49 am

Re - the sustained btest Mikrotik tests

We know who the extended non-stop btest testers are. We just use our Winbox and go to Tools - BTest server - Sessions (there is your IP testing to our btest server)

Please play nice and fair for other btest testers and please do not hold extended non-stop btest tests.

If you have a special need, we can and are willing to set-up something special for temporary extended testing.

North Idaho Tom Jones

Wed Jun 07, 2017 1:56 am

Re - the sustained btest Mikrotik tests

Yo Mikrotk ROS programmers ... Is there a possibility of a newer ROS to have a new option in the btest server ?
[ ] Enabled
[ ] Authenticate
Allocate UDP Ports from: [ 2000 ]
Max Sessions: [ 100 ]
Timeout per btest session in seconds [ 300 ]

Wed Jun 07, 2017 3:23 am

I really did not want to do this - but I had a customer trying to use the btest server
So I had to simple-queue a continuous non-stop btest from a remote location

138-117-109-222.png

planetcoop · Wed Jun 07, 2017 4:17 am

Here is the raw filter i am thinking of. ID the user source address with a timer of 5 minutes and then block all traffic for 2 hours until the next time.

raw filters.png

planetcoop · Wed Jun 07, 2017 4:19 am

I have enabled my rules.

raw filters tested.png

Wed Jun 07, 2017 4:21 am

Here is the raw filter i am thinking of. ID the user source address with a timer of 5 minutes and then block all traffic for 2 hours until the next time.
raw filters.png

Looks interesting

Does it block only the single IP address for 2 hours and allow everybody else to still test ?

I am gonna have to take a look at this !

North Idaho Tom Jones

planetcoop · Wed Jun 07, 2017 4:25 am

yes, source ip addresses

/ip firewall raw
add action=accept chain=prerouting comment="testers accepted" src-address-list=tester
add action=drop chain=prerouting comment="previous testers drop" src-address-list=previous
add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=udp
add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=udp

raw filters results.png

Wed Jun 07, 2017 4:28 am

yes, sent you an email if you want to call

/ip firewall raw
add action=accept chain=prerouting comment="testers accepted" src-address-list=tester
add action=drop chain=prerouting comment="previous testers drop" src-address-list=previous
add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=udp
add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=udp

It's almost the end of my work day and I am getting tired...
Do you need to enter a specific IP address , or is it automatic ?

planetcoop · Wed Jun 07, 2017 4:32 am

Post wars, its automagic and RAW is wirespeed

Wed Jun 07, 2017 4:43 am

Post wars, its automagic and RAW is wirespeed

I am heading home
Tomorrow I will make a backup and give it a try.

With that - a note to all Mikrotik admins who btest to the 207.32.195.2 server , I am going to be testing the above changes tomorrow.
I will post a final config and then ask for user input on how well it is performing.

North Idaho Tom Jones

planetcoop · Wed Jun 07, 2017 6:35 am

Forum and friends. I have just banned any address related to AS14868 and any related AS as i was just hit with a massive wave of btests.
https://ipinfo.io/AS14868

This isnt a business btest server, but rather a CHR in my home. It is free to use and conduct random tests. Please do not use my personal network for business deployments or use without my expressed permission.

abuse.png

planetcoop · Wed Jun 07, 2017 7:46 am

Well, this is getting fun. I have now blocked 176.0.0.0-201.0.0.0. Sorry for the inconvenience to the rest of my fellow testers.

pukkita · Wed Jun 07, 2017 11:05 am

Hello guys!

It's sad how some people spoils others good will and hard work

I helped another forum user to apply queues to bw-test.

Posting here as this is the most dense-packed thread on bw-test.

planetcoop · Wed Jun 07, 2017 4:34 pm

Ok, my current IP ban list blocked from my network:
/ip firewall address-list
add address=176.0.0.0/4 list=blocklist
add address=192.0.0.0/5 list=blocklist
add address=200.0.0.0/7 list=blocklist
add address=77.xx.xxx.132 list=blocklist
add address=160.0.0.0/4 list=blocklist

/ip firewall raw
add action=accept chain=prerouting comment="allow lan" src-address=192.168.0.0/24
add action=drop chain=prerouting comment="testers to block" src-address-list=blocklist
add action=accept chain=prerouting comment="testers accepted" src-address-list=tracking
add action=accept chain=prerouting comment="testers accepted" disabled=yes src-address-list=tester
add action=drop chain=prerouting comment="previous testers drop" disabled=yes src-address-list=previous
add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" disabled=yes dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" disabled=yes dst-port=2000-2100 protocol=udp
add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" disabled=yes dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" disabled=yes dst-port=2000-2100 protocol=udp
add action=add-src-to-address-list address-list=tracking address-list-timeout=1d chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=tracking address-list-timeout=1d chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=udp

I will also be changing my btest rules. I will remove the 5 minute limitation and the every 2 hour rules. The past 8 hours have proved effective and my CHR has not been abused otherwise. Enjoy.

1f7zvoFbGoj9tn0U.png

Wed Jun 07, 2017 6:26 pm

planetcoop

Is this all I need to do to try your settings ?

[admin@207-32-195-2-CHR-P10] > ip
[admin@207-32-195-2-CHR-P10] /ip> firewall
[admin@207-32-195-2-CHR-P10] /ip firewall> export
# jun/07/2017 08:15:57 by RouterOS 6.39.2
# software id =
#
[admin@207-32-195-2-CHR-P10] /ip firewall> raw
[admin@207-32-195-2-CHR-P10] /ip firewall raw> export
# jun/07/2017 08:16:29 by RouterOS 6.39.2
# software id =
#
[admin@207-32-195-2-CHR-P10] /ip firewall raw> ..
[admin@207-32-195-2-CHR-P10] /ip firewall> export
# jun/07/2017 08:16:34 by RouterOS 6.39.2
# software id =
#
[admin@207-32-195-2-CHR-P10] /ip firewall> /ip firewall raw
[admin@207-32-195-2-CHR-P10] /ip firewall raw> add action=accept chain=prerouting comment="testers accepted" src-address-list=tester
[admin@207-32-195-2-CHR-P10] /ip firewall raw> add action=drop chain=prerouting comment="previous testers drop" src-address-list=previous
[admin@207-32-195-2-CHR-P10] /ip firewall raw> add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=tcp
[admin@207-32-195-2-CHR-P10] /ip firewall raw> add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=udp
[admin@207-32-195-2-CHR-P10] /ip firewall raw> add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=tcp
[admin@207-32-195-2-CHR-P10] /ip firewall raw> add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=udp
[admin@207-32-195-2-CHR-P10] /ip firewall raw>

planetcoop - is this correct and should work ?
I am not experienced with ROS firewalls. For core, in-house, for business firewalls, I generally use PfSense instead or Cisco firewalls.

North Idaho Tom Jones

planetcoop · Wed Jun 07, 2017 6:58 pm

That should be it with several assumptions, 5 minute test window every 2 hours based on source ip. This will also include your address ranges. Also that tcp/udp 2000-2100 for the port range.

Wed Jun 07, 2017 7:07 pm

That should be it with several assumptions, 5 minute test window every 2 hours based on source ip. This will also include your address ranges. Also that tcp/udp 2000-2100 for the port range.

OK - some questions:
- What is needed for a allow this network at all times? Such as I want to allow all of my Class C networks at all times where they skip the firewall raw configs.
- Is there a way to see what IP address are temporarily in the 2-hour blocked window & when those IPs entered that state?

planetcoop · Wed Jun 07, 2017 7:25 pm

/ip firewall address-list
add address=YOURNET/22 list=tester

/ip firewall raw
add action=accept chain=prerouting comment="allow lan" src-address=192.168.0.0/24
add action=drop chain=prerouting comment="testers to block" src-address-list=blocklist
add action=accept chain=prerouting comment="testers accepted" src-address-list=tracking
add action=accept chain=prerouting comment="testers accepted" disabled=yes src-address-list=tester
add action=drop chain=prerouting comment="previous testers drop" disabled=yes src-address-list=previous
add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=udp
add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=udp
add action=add-src-to-address-list address-list=tracking address-list-timeout=1d chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=tracking address-list-timeout=1d chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=udp

Wed Jun 07, 2017 8:32 pm

1st - a special thanks to planetcoop for all of his help and assistance and participation in the public btest servers for all Mikrotik admins.

Below is my 207.32.195.2 best server configuration (as of today):

[admin@207-32-195-2-CHR-P10] > export
# jun/07/2017 10:09:19 by RouterOS 6.39.2
# software id =
#
/interface ethernet
set [ find default-name=ether1 ] loop-protect=off
/queue simple
add burst-limit=3600M/3600M burst-threshold=500M/500M burst-time=11m40s/11m40s max-limit=500M/500M name=3.6-Gig
/snmp community
((( My SNMP configuration settings )))
/user group
add name=btest policy=test,winbox,romon,tikapp,!local,!telnet,!ssh,!ftp,!reboot,!read,!write,!policy,!password,!web,!sniff,!sensitive,!api,!dude
/ip address
add address=207.32.195.2/30 interface=ether1 network=207.32.195.0
/ip dns
set servers= ((( My DNS servers )))
/ip firewall address-list
add address= ((( One of my networks ))) list=tester
add address= ((( One of my networks ))) list=tester
add address= ((( One of my networks ))) list=tester
add address= ((( One of my networks ))) list=tester
add address= ((( One of my networks ))) list=tester
add address= ((( One of my networks ))) list=tester
/ip firewall raw
add action=accept chain=prerouting comment="allow lan" src-address=192.168.0.0/24
add action=drop chain=prerouting comment="testers to block" src-address-list=blocklist
add action=accept chain=prerouting comment="testers accepted" src-address-list=tracking
add action=accept chain=prerouting comment="testers accepted" disabled=yes src-address-list=tester
add action=drop chain=prerouting comment="previous testers drop" disabled=yes src-address-list=previous
add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=tester address-list-timeout=5m chain=prerouting comment="add to tester" dst-port=2000-2100 protocol=udp
add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=previous address-list-timeout=2h chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=udp
add action=add-src-to-address-list address-list=tracking address-list-timeout=1d chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=tcp
add action=add-src-to-address-list address-list=tracking address-list-timeout=1d chain=prerouting comment="add to previous" dst-port=2000-2100 protocol=udp
/ip route
add distance=1 gateway=207.32.195.1
/ip service
((( My NTP configuration setting )))
/snmp
((( My SNMP configuration settings )))
/system clock
set time-zone-autodetect=no time-zone-name=America/Los_Angeles
/system identity
set name=207-32-195-2-CHR-P10
/system ntp client
((( My NTP configuration settings )))
/tool graphing interface
add interface=ether1
/tool netwatch
add comment="btest server in Plummer at Red-Spectrum" host=207.32.195.2
[admin@207-32-195-2-CHR-P10] >

If any Mikrotik admins experience any new problems with my public 207.32.195.2 btest server, please let me know. Also, if it appears to be running normal and behaving as you have experienced in the recent past, again please let us know.

FYI - I will let some traffic pass for several hours then post a newer/updated bandwidth graph for this btest server.

Again - thanks to everybody who helps support everybody in this btest project Your comments and support help everybody

North Idaho Tom Jones

Wed Jun 07, 2017 9:21 pm

planetcoop

Question for you
what are the two grayed out items (marked inside the red box) and what do they do if I enable them - should they be enabled ?

Thanks
North Idaho Tom Jones

question1.png

planetcoop · Thu Jun 08, 2017 12:24 am

Sorry for the delay, but you should enable them. It enforces the 5 minute and 2 hour rules.

Thu Jun 08, 2017 4:44 am

info btest server 207.32.195.2

I have some new rules in place in the configuration to block and stop "robo-btest testing". Where a remote mikrotik is scripted to perform robo btests to 207.32.195.2
Also
Please limit your btest tests to 1 minute. Anything longer will auto place you in a block for a period of time.

Note: When we see robo automated btest tests to the public btest servers - and when we see non-stop-continouis btest tests to the public btest servers, we conclude the following:
- Somebody is abusing the public btest servers
-and/or-
- Somebody may be abusing their Internet ISP by creating sustained network loads on their ISP and all router paths to the public btest servers

Again - Everybody is welcome to manually test to the btest servers, however please limit the actual btest session to 1-minute or less - and please wait a minimum of 15 minutes before starting your next btest. Please remember, there are many many many other Mikrotik admins in many countries also using these btest servers.

Thank you

North Idaho Tom Jones

planetcoop · Thu Jun 08, 2017 8:40 pm

Great news for the day, the DDOS was hitting "btest.planetcoop.com" has been blocked for the moment and the CHR up time is over 48 hours now. Additionally, this should allow for more beneficial test results. Please update us if you are having any issues with btest throughput.

Greg · Sun Jun 11, 2017 12:06 am

First things first, thank you for making those servers available.

We got a solid performance from Geneva, Switzerland, Europe.

The graph page at https://btest.planetcoop.com:10443/graphs/iface/ether1/ didn't seem to show the test however.

planetcoop · Mon Jun 12, 2017 6:15 am

First things first, thank you for making those servers available.

We got a solid performance from Geneva, Switzerland, Europe.

The graph page at https://btest.planetcoop.com:10443/graphs/iface/ether1/ didn't seem to show the test however.

Depending on the length of test the graph wont show it. I think the shortest interval is 5 minutes per average. You would have to run it for 5 or more minutes to start showing detail. If you would like you may run the test longer.

JohnSmith75 · Mon Jun 12, 2017 2:24 pm

Thanks for the service Tom. Very useful one, in my opinion, it's great alternative to speedtest.

planetcoop · Mon Jun 19, 2017 8:05 pm

Happy to report this week that i have not seen any issues without blocking select ip addresses and a 5 minute per hour rule. Please let me know if you have issue with "btest.planetcoop.com". Also as it has been said before, if you have a special use case for a longer test or other requirement, please PM or post here so that we can help test and support the Mikrotik community.

ajack46 · Tue Jun 20, 2017 12:13 pm

Thanks for the service Tom. Very useful one, in my opinion, it's great alternative to speedtest.

Couldn't agree more, some good tool for speed test indeed.

aliclubb · Thu Jun 29, 2017 1:39 pm

Happy to report this week that i have not seen any issues without blocking select ip addresses and a 5 minute per hour rule. Please let me know if you have issue with "btest.planetcoop.com". Also as it has been said before, if you have a special use case for a longer test or other requirement, please PM or post here so that we can help test and support the Mikrotik community.

Can't seem to PM you, but would really like to discuss current list of blocked IPs, suspect I was a dipstick and left a btest running on a customers router by accident as a certain portion of our IPs seem to be unable to btest to btest.planetcoop.com now.

planetcoop · Fri Jun 30, 2017 1:56 am

Happy to report this week that i have not seen any issues without blocking select ip addresses and a 5 minute per hour rule. Please let me know if you have issue with "btest.planetcoop.com". Also as it has been said before, if you have a special use case for a longer test or other requirement, please PM or post here so that we can help test and support the Mikrotik community.
Can't seem to PM you, but would really like to discuss current list of blocked IPs, suspect I was a dipstick and left a btest running on a customers router by accident as a certain portion of our IPs seem to be unable to btest to btest.planetcoop.com now.

I am currently using several rule sets to block ip addresses as discussed in this thread:
viewtopic.php?f=9&t=98804

Additionally i have the 5 minute btest rule per every hour as well. I have finally created one rule for a 5 minute test every 12 hours with an ending ip of .132. If this is your ip it is not a problem and i am willing to allow it to use the 5 minute out of the hour in my main rule set. At this point i am trying to understand the traffic patterns as you have seen my previous posts about abuse from Brazil-net AS network that are un-secure.

FYI, i am also not sure on the PM part of the forum.

pukkita · Fri Jun 30, 2017 11:07 am

PM is disabled.

aliclubb · Tue Jul 04, 2017 2:12 pm

Happy to report this week that i have not seen any issues without blocking select ip addresses and a 5 minute per hour rule. Please let me know if you have issue with "btest.planetcoop.com". Also as it has been said before, if you have a special use case for a longer test or other requirement, please PM or post here so that we can help test and support the Mikrotik community.
Can't seem to PM you, but would really like to discuss current list of blocked IPs, suspect I was a dipstick and left a btest running on a customers router by accident as a certain portion of our IPs seem to be unable to btest to btest.planetcoop.com now.
I am currently using several rule sets to block ip addresses as discussed in this thread:
viewtopic.php?f=9&t=98804

Additionally i have the 5 minute btest rule per every hour as well. I have finally created one rule for a 5 minute test every 12 hours with an ending ip of .132. If this is your ip it is not a problem and i am willing to allow it to use the 5 minute out of the hour in my main rule set. At this point i am trying to understand the traffic patterns as you have seen my previous posts about abuse from Brazil-net AS network that are un-secure.

FYI, i am also not sure on the PM part of the forum.

Ok, no that's not our IP. Would you be able to shoot me an email to ali@airbroadband.co.uk to discuss this further in private? I'm still having issues, and just looked at it further and there is some weird behaviour going on, potentially on your servers end?

planetcoop · Tue Jul 04, 2017 11:45 pm

I have sent an email. If anyone else has an issue please post here. I am not trying to eliminate bandwidth usage but I am trying to keep my network from contributing to internet abuses. Thank you.

shaider · Thu Jul 20, 2017 5:56 pm

may i know if the btest server is still active or online? at first its working on my end then today. i cant get any results.
thank you for sharing your network ^^,v

Thu Jul 20, 2017 6:12 pm

may i know if the btest server is still active or online? at first its working on my end then today. i cant get any results.
thank you for sharing your network ^^,v

My 207.32.195.2 btest server is working. (However I just rebooted it to make sure).

planetcoop and I ( TomJ North Idaho ) , both run public accessible Mikrotik CHR btest servers which are connected to the Internet using 10-gig interfaces.

We both made some changes somewhat recently which block/drop extended/lengthy/non-stop/frequently-repeating btests. We both have slightly different rules for the configuration.

My 207.32.195.2 btest test server (here in North Idaho) has the following:
- Max up/down speeds of about 3-gig btest
- I have a limit of about 2 minutes for a btest then the test auto terminates - then you will need to wait a few minutes before you can btest again.

I configured the rules on my 207.32.195.2 btest server because we were seeing extended/lengthy/non-stop btests and/or auto-repeating btests every minute of every hour of every day. This was preventing other btesters from getting good/clean btest results because the btest server bandwidth was shared between everybody testing at the same time - which made slower btest results for everybody testing at the same time.

I am pretty sure planetcoop has very similar reasons for his btest limits also.

Anyways - if you are testing to my North Idaho 207.32.195.2 btest server , try waiting 4 minutes , then run a btest for about 1 minute up , wait 4 minutes then run a btest for about 1 minute down - then optionally repeat a few times to make sure your btest results come out the same.

North Idaho Tom Jones

shaider · Thu Jul 20, 2017 8:02 pm

i see. maybe thats the reason why i coudnt do any btest. but lately i did. i was able to do btest twice. and thats the limitation per day..
thank you for sharing your network.

planetcoop · Fri Jul 21, 2017 8:50 pm

I have limited my btest CHR to a 5 minute window once per hour. once the server sees traffic or the session from you it will block you at the end of the five minutes and then allow the connection 60 minutes after first contact again. As Tom has described we have seen some lengthy testing. Please feel free to test as much as you want within that window to btest.planetcoop.com. If you need additional testing, please reach out as i can work with you to add you on a longer testing white list.

Sat Jul 22, 2017 1:02 am

I have limited my btest CHR to a 5 minute window once per hour. once the server sees traffic or the session from you it will block you at the end of the five minutes and then allow the connection 60 minutes after first contact again. As Tom has described we have seen some lengthy testing. Please feel free to test as much as you want within that window to btest.planetcoop.com. If you need additional testing, please reach out as i can work with you to add you on a longer testing white list.

planetcoop - a question re the "5 minute window once per hour" on your btest server

Will this work below (without your rules blocking for an hour) ?:
1 minute btest TCP send
1 minute btest TCP receive
1 minute btest UDP send
1 minute btest UDP receive

(or any combination of different btest(s) within an hour prior to adding up to 5-minutes within the hour)

North Idaho Tom Jones

planetcoop · Mon Jul 24, 2017 3:31 pm

I have limited my btest CHR to a 5 minute window once per hour. once the server sees traffic or the session from you it will block you at the end of the five minutes and then allow the connection 60 minutes after first contact again. As Tom has described we have seen some lengthy testing. Please feel free to test as much as you want within that window to btest.planetcoop.com. If you need additional testing, please reach out as i can work with you to add you on a longer testing white list.
planetcoop - a question re the "5 minute window once per hour" on your btest server

Will this work below (without your rules blocking for an hour) ?:
1 minute btest TCP send
1 minute btest TCP receive
1 minute btest UDP send
1 minute btest UDP receive

(or any combination of different btest(s) within an hour prior to adding up to 5-minutes within the hour)

North Idaho Tom Jones

At the moment it is by ip address and the remote address starts the 5 minute timer. So for example your btest to my btest. The first packet starts the timer and you have 5 minutes to conduct any testing. After 5 minutes, the btest CHR blocks the address for the next 55 minutes. After that, the temporary blocked address is removed and valid to pursue any further tests with the same ongoing rules as above. It is harsh, but i have found that to be very effective and it dynamically weeds out abuse. I have also said i can whitelist any tester if they need additional testing as we have in the past tested beyond a 5 minute test.

gdo · Wed Jul 26, 2017 1:20 am

thank u

Thu Jul 27, 2017 8:27 pm

Notice: I just upgraded my 207.32.195.2 public accessible Mikrotik CHR btest server to v6.40

If you experience any issues, please let me know

North Idaho Tom Jones

shaider · Fri Jul 28, 2017 2:56 am

Thank you TomjNorthIdaho for the btest server. we are now using it right now. and we added some script to make things easier.

:do {
:local MTUSRPHsource "https://s.mep.ph/btest/";
:local scriptName "btest.rsc";
:put "Downloading btest script...";
:do {
/tool fetch url="$MTUSRPHsource$scriptName" mode=https dst-path="/$scriptName";
} on-error={
:put "Error. Download failed";
}
:put "Importing update script...";
:do {
/import "$scriptName";
} on-error={
:put "import failed. unknown error.";
}
:put "Removing update script...";
:do {
/file remove "$scriptName";
} on-error={}
:put "Update Complete.";
}

planetcoop · Fri Jul 28, 2017 8:25 pm

Notice: I just upgraded my 207.32.195.2 public accessible Mikrotik CHR btest server to v6.40

If you experience any issues, please let me know

North Idaho Tom Jones

Updated btest.planetcoop.com to 6.40 yesterday as well. Enjoy

planetcoop · Fri Jul 28, 2017 8:26 pm

Thank you TomjNorthIdaho for the btest server. we are now using it right now. and we added some script to make things easier.

:do {
:local MTUSRPHsource "https://s.mep.ph/btest/";
:local scriptName "btest.rsc";
:put "Downloading btest script...";
:do {
/tool fetch url="$MTUSRPHsource$scriptName" mode=https dst-path="/$scriptName";
} on-error={
:put "Error. Download failed";
}
:put "Importing update script...";
:do {
/import "$scriptName";
} on-error={
:put "import failed. unknown error.";
}
:put "Removing update script...";
:do {
/file remove "$scriptName";
} on-error={}
:put "Update Complete.";
}

I have reviewed your script and i will give it a try, but please be careful, your gmail account details are in the script and un-encrypted.... You could pull the tool section and make it another script not publicly available.

shaider · Sat Jul 29, 2017 9:34 am

thank you planetcoop for the concern about the email on the rsc.. its ok to put it on public. we just use it here in Philippines for or as sending recipient on our routerboard..
once again thank you so much for the btest server. ^^,v

Fri Aug 04, 2017 8:20 pm

FYI - I just upgraded the public accessible 207.32.195.2 btest server from v6.40 to v6.40.1
If you encounter any new/strange issues , please let me know.

North Idaho Tom Jones

JKais · Fri Aug 18, 2017 2:43 pm

Hi,

I have been trying to do it from our office in Spain, but haven't been able to do it. Any suggestion?

Would be super appreciate it.

Wed Aug 23, 2017 3:19 pm

Hi,

I have been trying to do it from our office in Spain, but haven't been able to do it. Any suggestion?

Would be super appreciate it.

Is it working now ?

Over the weekend, I had to turn-off the 207.32.195.2 btest server. I had a 10-gig fiber cut and my business fell back to a less-than-500-meg Microwave link. Everything was turned back on Tuesday morning.

North Idaho Tom Jones

CZFan · Wed Aug 23, 2017 5:02 pm

Hi,

I have been trying to do it from our office in Spain, but haven't been able to do it. Any suggestion?

Would be super appreciate it.
Is it working now ?

Over the weekend, I had to turn-off the 207.32.195.2 btest server. I had a 10-gig fiber cut and my business fell back to a less-than-500-meg Microwave link. Everything was turned back on Tuesday morning.

North Idaho Tom Jones

Unfortunately does not seem to be working, I just tried and it ties to connect and then fails to connect

ionas · Wed Aug 23, 2017 7:30 pm

Thank you so much! It is so helpful!

Tested from Holland

Wed Aug 23, 2017 8:08 pm

Request - a little help please ...

I suspect my 10-Gig physical Internet connection (2-Gig burstable to 4-Gig), may not be achieving what I am paying for. It appears like I am only running on a 1-Gig Internet connection.
Thus, I suspect my 207.32.195.2 btest server may also not be performing at greater than 1-Gig btest speeds.

This is where I am asking for help.
Just now, I disabled all bandwidth limits and rules on my 207.32.195.2 btest server.
Please, will the Mikrotik admins with 1-Gig and faster Internet connections please perform a couple of btests to my 207.32.195.2 btest server and then please post their btest throughput results.

I will attempt to keep the 207.32.195.2 btest server open & un-limited for a few days - or until I begin to experience bandwidth load issues - or until I am able to confirm my upstream bandwidth problems.

Note - please limit your btest testing to a maximum of 1 to 2 minutes per test.

btest server: 207.32.195.2
User: btest
Password: btest
Thank you

North Idaho Tom Jones

planetcoop · Sun Aug 27, 2017 10:32 pm

Request - a little help please ...

I suspect my 10-Gig physical Internet connection (2-Gig burstable to 4-Gig), may not be achieving what I am paying for. It appears like I am only running on a 1-Gig Internet connection.
Thus, I suspect my 207.32.195.2 btest server may also not be performing at greater than 1-Gig btest speeds.

This is where I am asking for help.
Just now, I disabled all bandwidth limits and rules on my 207.32.195.2 btest server.
Please, will the Mikrotik admins with 1-Gig and faster Internet connections please perform a couple of btests to my 207.32.195.2 btest server and then please post their btest throughput results.

I will attempt to keep the 207.32.195.2 btest server open & un-limited for a few days - or until I begin to experience bandwidth load issues - or until I am able to confirm my upstream bandwidth problems.

Note - please limit your btest testing to a maximum of 1 to 2 minutes per test.

btest server: 207.32.195.2
User: btest
Password: btest
Thank you

North Idaho Tom Jones

3.6/1.7gbps in separate tests.

down-and-up.png

rbobbitt · Wed Aug 30, 2017 5:05 pm

Tom,

First: Thank you for the Outstanding service that you are providing to the Mikrotik community!

Now to my problem.

Do you have any IP's blocked at the firewall?
When I test through my 100x100 Spectrum Cable link all is well but when I test trough my 100x100 Windstream Cloud Firewall connection (via MPLS) I cannot connect.
My public IP on the Windstream service is in the 40.138.114.0 space.

Windstream says that they are made a policy that is "wide open" for my source address but I still cannot connect through them.

I've tried TCP, UDP, packet size 500 to 1500 etc.

Any ideas anyone?

Thanks,

Ray

Wed Aug 30, 2017 6:50 pm

Tom,

First: Thank you for the Outstanding service that you are providing to the Mikrotik community!

Now to my problem.

Do you have any IP's blocked at the firewall?
When I test through my 100x100 Spectrum Cable link all is well but when I test trough my 100x100 Windstream Cloud Firewall connection (via MPLS) I cannot connect.
My public IP on the Windstream service is in the 40.138.114.0 space.

Windstream says that they are made a policy that is "wide open" for my source address but I still cannot connect through them.

I've tried TCP, UDP, packet size 500 to 1500 etc.

Any ideas anyone?

Thanks,

Ray

Thank you for your nice reply

My 207.32.195.2 btest server does not have any firewalls - except for the following:
There is a rule that after a couple minutes of testing, it will auto block your IP address for about an hour. Then after the hour has elapsed, the IP address will be released.

What IP address are you testing from?
If you are able to reply promptly, I can then drop all rules , then post for you to try it. Then later re-enable my btest usage rules.

North Idaho Tom Jones

Thu Sep 07, 2017 3:37 pm

Please -

Please , do not robo auto-btest

I see at least one auto/robo/automated btest every-20-minutes

I can understand why you would want something like this, but a robo automated btest to my 207.32.195.2 best server is not what I intended it for (especially one I see running every 20 minutes) . Also, if it auto btests during any other manual btest at the same time, the results can be incorrect because of the shared bandwidth while the two btest(s) were running at the same time.

I might be able to work with an automated 1-time-a-day after midnight my time robo btest , but I would want to know and set the schedule.

Currently, the intent is supposed to be for all mikrotik admins performing brief manual btests at any time of the day.

North Idaho Tom Jones

Sat Sep 09, 2017 2:37 am

Please ...

No robo automated btest clients to the 207.32.195.2 btest server !!!!
I see at least 4 robo btest servers auto testing to the 207.32.195.2 btest server.

I want to be a nice guy
I don't want to have to place your robo test IP address into a full blocked access to my network or my 207.32.195.2 btest server
If I have to block it, I will also publish the IP address of your robo btest IP address - and who you are.

This server is intended to be used by a physical person who is manually testing bandwidth. It is not for robo btest devices to auto-check the performance of your network every few minutes or hours or days. Please - manual btest performed by a human only.

If you need a full-time dedicated btest server for your robo test device to test to 24x7, then lets talk about a co-location server that you pay for instead of me.

Please - lets play nice

North Idaho Tom Jones

EDIT: Do I really need to block the following ?:
109117138222.ip73.static.mediacommerce.com.co [138.117.109.222]
inetnum: 138.117.108/22
status: allocated
aut-num: N/A
owner: Media Commerce Partners S.A
ownerid: CO-CUOC1-LACNIC
responsible: Víctor Fabián Serna Villa

EDIT: 138.117.109.222 You are now blocked.

planetcoop · Sat Sep 09, 2017 10:05 am

I am sorry to say, i have already blocked 138.0.0.0/8 due to massive ip flooding of my btest.planetcoop.com CHR... Thanks for playing 138. I have also seen special traffic from 0.0.0.0 so i have blocked it obviously as forged traffic. I have started long term btest ip address logging and review ip address counts daily.

Sadly my block list is very long:
0.0.0.0
46.163.178.0/24
46.163.179.0/24
46.163.188.0/24
138.0.0.0/8
160.0.0.0/4
176.0.0.0/4
192.0.0.0/5
200.0.0.0/7

Sun Sep 10, 2017 4:43 pm

TomjNorthIdaho"]
Please ...No robo automated btest clients to the 207.32.195.2 btest server !!!!

2017-09-09 138.117.109.222 - You are now blocked ( banned because of continued automated non-stop robo btesting )

2017-09-10 185.34.121.32 - You are now blocked ( banned because of continued automated non-stop robo btesting )

BrianHiggins · Tue Sep 12, 2017 9:21 pm

Months ago I embedded a 10 second duration upload and download test into our web provisioning platform to assist with determining bandwidth performance when doing new installations (this generates at most less than 5 or 10 minutes of collective tests spread over the course of a month, so definitely not abuse levels!), and noticed today that the planetcoop test server (50.235.23.218) isn't accepting any connections, and when I manually tried the 207.32.195.2 server, it blocked me after about 2 minutes from running the first download test, before I could conduct a upload test.

Would an update on the current status and details on the rules you are both applying be possible? Really appreciate having the tools available, but need to know the limits and availability on using it.

Tue Sep 12, 2017 11:50 pm

Months ago I embedded a 10 second duration upload and download test into our web provisioning platform to assist with determining bandwidth performance when doing new installations (this generates at most less than 5 or 10 minutes of collective tests spread over the course of a month, so definitely not abuse levels!), and noticed today that the planetcoop test server (50.235.23.218) isn't accepting any connections, and when I manually tried the 207.32.195.2 server, it blocked me after about 2 minutes from running the first download test, before I could conduct a upload test.

Would an update on the current status and details on the rules you are both applying be possible? Really appreciate having the tools available, but need to know the limits and availability on using it.

I would guess that planetcoop and myself are willing to consider almost anything that benefits all Mikrotik admins, providing the item being considered does not have a negative effect on the btest servers.

However, prior to considering other options, please note - at this time :
- planetcoop and myself are wanting to avoid the use of automated robo client btest servers.
- planetcoop and myself are saying that the use of manual human-at-the-controls-in-real-time client btest are permitted.

One possibly important item I discovered recently that needs some research to be verified is the following:

- Last week I wrote up my own in-house robo-client btest application which would sequence one-at-a-time through several hundred of my Mikrotik clients and have them perform robo-btest(s) to my 207.32.195.2 btest server. I was using a Linux server with a telnet/ssh expect script to Mikrotik clients using the CLI which would login into each client Mikrotik and have them perform UDP download speed tests.
- What I discovered (possibly a bug), is that after the time allocated in the btest command, and after the Linux telnet/ssh expect script /quit the connection, the 207.32.195.2 btest server would sometimes still continue the UDP btest send to the client Mikrotik (even after the client btest time allocated had expired and the remote login had logged-out). The result was a continued btest that would not-stop and would continue running indefinitely. When sequencing one-at-a-time through about 50 client Mikrotiks, I could end up with 3 to 10 btest that would continue running non-stop long after the expect script to the client had timed-out the btest, waited a minute then logged out.
- The logs on the remote client Mikrotik used to initiate the btest session did show the login and the logout - however - after the logout and the log showing the logout, the btest still continued to run.
- I suspect this may be a bug

For this reason (and my past statements in this forum) , I am asking the Mikrotik admin community to please not use robo-automated-btest sessions to the btest servers.
When a human is at the controls, this condition is easily identifiable and correctable. If this happens with a robo-automated-btest client to a btest server, the effects can possibly saturate networks and make the results of other Mikrotik admins performing a btest to the same server give skewed bandwidth results (and also have a lasting effect on my network until each problem client is rebooted or the btest server is rebooted).
I suspect I may off seen this many times with multiple long-time-btest sessings that appeared to never stop. If I remember correctly, (prior to some additional rules), I had seen some btest sessions running non-stop for several days.

Thank you

North Idaho Tom Jones

BrianHiggins · Wed Sep 13, 2017 12:14 am

Just to be clear, my implementation is done only upon one of our admins clicking the test bandwidth button inside the web admin console they use to manage their hardware, and it's hard coded to run only a single 10 second test up, followed by a single 10 second test down, it then disables the test button once it's been ran once. They would have to exit and re-enter that configuration screen to be able to run it a 2nd time. so while it's automated in the sense that it is launched programmatically through the hardware, it is initiated and requested by an admin.

Before test is ran:

before testing.PNG

After test is ran:

After test.PNG

Wed Sep 13, 2017 1:03 am

Just to be clear, my implementation is done only upon one of our admins clicking the test bandwidth button inside the web admin console they use to manage their hardware, and it's hard coded to run only a single 10 second test up, followed by a single 10 second test down, it then disables the test button once it's been ran once. They would have to exit and re-enter that configuration screen to be able to run it a 2nd time. so while it's automated in the sense that it is launched programmatically through the hardware, it is initiated and requested by an admin.

Before test is ran:
before testing.PNG

After test is ran:
After test.PNG

So much to think about. My brain hurts - lol

My robo-testing to my 207.32.195.2 btest server was initiated from a remote Linux computer. What I discovered is that when using any "duration=" value on even a single client Mikrotik would sometimes start the non-stop continuous btest.

I tried and tested a few hundred variants of the line below many times to a single Mikrotik and to many Mikrotiks (in a sequence one-after-another) and I was able to randomly repeat the problem.
/tool bandwidth-test 207.32.195.2 duration=15 protocol=udp direction=receive without-paging interval=00:00:05 remote-tx-speed=27500000

This was in a my Linux sh script as shown below ( sh ./Script-Name.sh a.b.c.d )
#
host=$1
#
echo > logfile.txt
#
/usr/bin/expect <<EOF | tee TEMP-FILE-Results.txt > ./Results-Directory/$1
spawn telnet $host
expect "Login"
send "admin+c132we\r"
expect "Password"
#
send "ClientMtikPassword\r"
expect "command"
expect ">"
#sleep 1
send "..\r"
#sleep 1
send "..\r"
#sleep 1
send "..\r"
expect ">"
send "/tool bandwidth-test 207.32.195.2 duration=15 protocol=udp direction=receive without-paging interval=00:00:05 remote-tx-speed=27500000\r"
--- Note - login & password not shown in above line ---
sleep 60
expect ">"
#
send "/quit\r"
expect eof

I tested hundreds of variants of this script and discovered that at random, the btest session would not terminate and would even continue after the telnet/ssh script has logged out of the client Mikrotik.
The random problem may of appeared to happen more often on weaker/worse/more-distant client Mikrotiks.

Until I get an understanding of what is happening, I do ask to please not use any script initiated btest sessions.

Thank you

North Idaho Tom Jones

Wed Sep 13, 2017 1:41 am

Related to the possible btest issues I might be seeing, I spotted this in Release Candidate information:
6.41rc28
*) btest - improved reliability on Bandwidth Test when device`s RAM is almost full;