-
Manipulasi Speedtest Dengan Mikrotik카테고리 없음 2020. 2. 10. 02:14
Speedtest adalah alat atau tool untuk melihat seberapa cepat koneksi yang kita gunakan. Biasanya para downloader mania sering cek speed koneksi internet warnet sebelum mendownload apa yang akan mereka download. Speed broadband internet dapat kita cek di Speedtest.net dengan mudah.
- Saya sebagai Thread Stater menyatakan bahwa tidak ada lagi segala support untuk tanya jawab, silahkan baca per halaman dan dipahami sendiri untuk troubleshootnya. Thread ini tersusun dikarenakan banyaknya pertanyaan di Inbox saya yang menanyakan bagaimana HandyCache dapat untuk dipasang dalam Jaringan/LAN Maka saya buatkan thread disini supaya dapat saling tukar pikiran.
- Melihat fenomena yang semakin aneh di negara kita tercinta ini, dimana sinetron tidak mendidik diabaikan dan game yang justru memberikan pelajaran tentang kedisplinan dan kekompakan dibinasakan, di blokir dengan berbagai alasan.
As implemented it yesterday, an old trick, NOTHING NEW really.(Although I personally don’t see any reason why to prioritize such speed.test.net results, to fake whom, client or yourself?
EDIT: Feb 26, 2019Thanks to Martooo, it appears Martooo has spun up a public access btest server.For details, here is his post:EDIT: August 15 2018At this time, the only known public accessable Mikrotik btest server is 207.32.194.24 (user=btest passoword=btest)Note; The planetcoop btest server is no longer online. I/we want to say thank you planetcoop for offering to us your btest server. It will be missed.Note: If anybody else is interested in hosting a btest server (10 meg or 100 meg or 1-Gig peak bandwidth), please post here and let us know.North Idaho Tom Jones-Subject: Public-Mikrotik-Bandwidth-Test-Server (s)EDIT: February 28th, 2018btest server change effective immediately, aka - right now (March 22, 2018)btest server 207.32.195.2 was moved to 207.32.194.24Same server, same settings. Just IP renumbered now to 207.32.194.24btest user: btestbtest password: btestFYI: My business is growing. We needed the entire 207.32.195.0/24 Class C netblock for some new networks we are building. Here's a suggestion on how you can keep your server not being (too) abused:Require that routers make a '/tool fetch' request to a web server, and have the server return temporary bandwidth test username and password (ideally username on first line, and password on second line; for easy parsing).
The username/password would only be valid for 10 minutes or so, after which, it would refuse to generate credentials for that IP for another. Let's say hour or so.To actually add the user automatically, you can use the API. Here's a suggestion on how you can keep your server not being (too) abused:Require that routers make a '/tool fetch' request to a web server, and have the server return temporary bandwidth test username and password (ideally username on first line, and password on second line; for easy parsing). The username/password would only be valid for 10 minutes or so, after which, it would refuse to generate credentials for that IP for another. Let's say hour or so.To actually add the user automatically, you can use the API.I considered doing just that - however I took the quick-easy-simple way to build it.
If it creates any problems, then I will do just what you said.FYI - (With bandwidth limits turned off) - I have tested to the internal loopback IP address of 127.0.0.1 and hit 17 gig. And external to the live IP address at up to 8 gig.Also - if this is not abused, then I will consider increasing the temporary burstable peak testing speed to a full gig up/down. I just tried your server.on upload, I get my full upload limit of my isp, on either tcp, or udp.on receive, I only get around 50 mbit down on TCP, my connection is 100 Mbit, but that could be due to location, but on UDP download, it bursts up to about 7 mbit for about 1 seconf, then to nothing, I cant actually see any traffic passing, if it is, its very few kbits, but still shows 0bps on the graph. The actual interface traffic is a few, less then 100 kbits/sec. Not sure what happened to the UDP.this happens every time I have tried the test.Testing from Canadahmm oddly enough, I do a send and receive I get my 7 mbit upload and 130 down. I should only have 110 down, but hey, that's better.
So seems to be only on Receive only test. And doesn't affect the Both, or upload.odd. I just tried your server.on upload, I get my full upload limit of my isp, on either tcp, or udp.on receive, I only get around 50 mbit down on TCP, my connection is 100 Mbit, but that could be due to location, but on UDP download, it bursts up to about 7 mbit for about 1 seconf, then to nothing, I cant actually see any traffic passing, if it is, its very few kbits, but still shows 0bps on the graph.
The actual interface traffic is a few, less then 100 kbits/sec. Not sure what happened to the UDP.this happens every time I have tried the test.Testing from CanadaIf you have more upload speed during testing than download speed during testing, I would guess this would be created by your ISP being over-subscribed. Where there is much more ISP download traffic to customers than upload traffic.
Thus the possible reason why you upload speed may be faster.Or the problem could also be where your ISP gets their Internet feed from - they could also be over subscribed.You may want to try bandwidth speed tests at busy times and at least busy times and see if there is a difference in test results. A difference in test results may point to somebody being oversubscribed.This is one of the reasons I put my Mikrotik bandwidth tester on-line - so that Mikrotik network admins can test and determine such issues. Umm, yes, I understand, but when I do the test as ' receive only' as UDP it jumps to about 4 - 7 mbit down, then to pretty much 0, ie NO traffic.If I run the receive only test as TCP I get about 50-60 mbit, tcp data, which is expected for my 100 mbit connection.if I run the UDP 'both' send receive I get the full amounts of my connection, about 7 up, and 110 down.so, ONLY the UDP receive only test gets no download speed. I don't mean, 1 mbit, or 2, I mean Zero. Well, a short burst to 4-7 mbit when it first starts for 1 second. Another possible reason the test results may be off is the clock-speed of the remote Mikrotik device performing the test.This is why I am running my server on a 3+ GHz Intel CPU. When I run the test from an old RB 500, I get much much slower results.
Those old RB jump up to 100 percent load quickly.On my server, testing to itself (IP Address 127.0.0.1) it will jump up to 18 gig throughput testing and almost hit 45 percent CPU load. (and this is a virtual x86 ROS running under VMware ESXi with many many other active servers doing other things also). This is perfect! Thanks so much for providing this. I was just looking into how I could accomplish some of these tests and I couldn't be happier to find it. Definitely enough to saturate the Comcast links I'm testing in Atlanta.Thanks again!You are welcomeI can see from my logs that it gets some use.It looks like there has not been any abuse.
So, soon in the near future (when I have the time to test & verify), I may increase it to 1.2 gig. I have the spare bandwidth here to work with.North Idaho Tom Jones. Code: me@myrouter tool bandwidth-test 207.32.195.2. Direction=receive remote-tx-speed=200M duration=30status: done testingduration: 31srx-current: 199.9Mbpsrx-10-second-average: 199.9Mbpsrx-total-average: 199.9Mbpslost-packets: 0random-data: nodirection: receiverx-size: 1500I've often thought about setting this up as well, though we only have a 1Gbe connection and abuse is a concern, though I'd imagine that most people who could abuse it have better things to do.If you don't mind a suggestion, you may want to add a couple filter rules to track addresses running tests so you can limit them to a finite number of sessions per period of time.
Some good news. I kicked up the peak throughput testing to now support up to 1.2 GIG bandwidth testing.With the original system, I did not see any abusers. Everybody was good.Please wait at least 1 minute between tests. Code: /ip firewall filteradd action=reject chain=input connection-state=new dst-port=2000 protocol=tcp reject-with=tcp-reset src-address-list=btestadd action=add-src-to-address-list address-list=btest address-list-timeout=1d chain=input connection-state=new dst-port=2000 protocol=tcpFirst rule will reject any new connection from any address in the 'btest' address list.
Manipulasi Speedtest Dengan Mikrotik Mac
The second rule will generate that list as connections come in. I used 1 day in the example.Again, as long as folks aren't abusing it, great. But this may help if things become a problem.Another way to do authentication, would be radius, which could use an SQL back-end, easily managed by a web front end where users could register, be verified, then granted access.
Manipulasi Speedtest Dengan Mikrotik Server
I won't pretend to have the patience for building something like this, but I'm sure if you were to ask the community, someone would be more than happy to step up and help you out. I would like others to consider configuring their own public Mikrotik Bandwidth Tester systems also and placing them on-line for other Mikrotik network admins to be able to btest to/from with.I have had mine on-line for almost two months now and the last week has been opened up to be able to btest up to 1.2 gig (note a continuous btest will drop down to 100 meg). So far, I have not seen any effects on my business ISP network.If you have the bandwidth to spare, I would like to suggest you consider also making a btest server. From my point of view, I have the bandwidth and I have only heard positive comments and so-far I have not seen any abuse - thank you.Also - If anybody has a desire to perform any really high-throughput bandwidth testing, you are welcome to drop me a message and we can set up a time where I can crank up my btest server to be able to sustain up to 3-gig (Yes I have that kind of spare bandwidth).North Idaho Tom Jones. If there are no abusers, I plan on keeping it on-line and available (aka long-term).I plan on keeping it available as long as I have the extra un-used bandwidth to support btest connections.At this time, do not see having to reduce the speed to less than 1 gig.North Idaho Tom JonesThat would be great.
I would like to set up a test server too at some point, but it may be a while before I can do that so in the meantime it's really nice having this. Are you aware of any other servers or yours is the only one as far as you know?Thank you. FYI - Although I am running my ROS in a VMware ESXi environment, I am running two Intel Xeon 10-core E5-2690 3-GHz CPUs (20-meg CPU cache) (Hyper-Threading disabled), of which I have allocated 2 CPUs to the virtual ROS.I was not aware that btest only used a single core. I might drop it down to a single CPU and see if it makes any difference.North Idaho Tom JonesYeah.me neither, because frankly i don't use it at all, but since I saw your post I thought maybe i should try itBut then I read and there it was:Warning: Bandwidth Test uses only single CPU core and will reach its limits when core will be 100% loaded. Hi, great work done.We used to use a Mikrotik router from a friend's network to do 'real' internet traffic test from our network towards his server.
But his business is sold.Anyway, I can use your's now to test again.We have a 300/300Mb simmetric line delivered to us over a dual hop microwave link from our provider. (24Ghz) After some ill experiances with previous provider we need to test that capacity once a month at least to see we really get what we pay for.
So here your service comes in place.We can use but results are all over the place and therefore very unreliable in my opinion.