Is it possible to determine from the graphs below if an RB5009 will provide better performance (i.e., a better user experience or relieve a bottleneck) than the currently in-use hEX:
The cpu utilization is very low. So there is no bottleneck of the device. Try to do some QOS to improve your experience.
Thanks for the help.
I’ve read a bunch of other threads and it seems that the analysis always comes down to CPU usage. Is this accurate?
Is is really the case that an analysis of CPU usage is all that is necessary to determine if a router is in any way slowing down network performance?
Not necessarily but it is already a good indication.
You could also use tool/profile, use CPU all, sort by usage.
Have that window open and then simulate the conditions where you observe degraded user experience.
Profile should show you which process is then the most used (but keep in mind running profile on its own, is already using CPU slightly).
If one of the CPU cores is at maximum, you got a real bottleneck.
Wow! I didn’t know about the Profile tool.
So I did this with multiple browsers streaming video and the max for any of the 4 CPUs stayed below 3 (except for truly momentary spikes). Other processes (management, dns, firewall) all stayed substantially lower than 3.
Is there a way of getting the historical data (SNMP, Graphs, etc.)?
I run Home Assistant with the Mikrotik integration and this is the CPU data. I don’t know it is the equivalent to RouterOS’s “Total” CPU or something else.
Hi,
So, when looking at your graphs, I see that you had one CPU spike during one single day on the 18th of October at around 5am (guessing from the time scale, if your devices are ntp synchronized). At that time it appears that you had a traffic spike, but on a daily 5 minute average on that day you have 3.5Mbps traffic…
The correct questions are not “is it time to replace” your router but rather:
- What happened on that day at that time ? → check in your devices logs / in your own memory to remember what happened
- Why did it impact CPU usage ? → was it inter-vlan routing / any other ?
- Is it recurring ? → observe weekly/monthly graphs
- Do you expect it to become recurring ? → only you can tell
- How does it impact your end users ? → if it was really at 5 am, I would personally not bother, unless it was VPN traffic from clients/your co-workers/your children being abroad and if it impacted their way of working / life
- Do you feel that it would be cool/fun to upgrade ? → if you can afford it, go for it.
If it is or about to be recurring and your end users already shout at you and if you feel that it will be getting worse, you can anticipate a bigger issue and upgrade.
If however you need a “community reason” to provide to your wife or to provide to yourself to lower your culpability feeling about wanting to get a new tool, please state it clearly, we can then write an official statement 
K.
LOL. I could “sign-off” if one of two to be true:
- Using WireGuard, or really any VPN protocol, running on the hEX? You’d would see a difference between the hEX and RB5009’s performance there.
- If the ISP greater than ~100-200Mb/s, you start getting closer to the limits of the hEX’s CPU.
The other reason for upgrade be ARM-only features like Containers, ZeroTier or BTH, that do need a higher CPU… which aren’t possible on MIPS-based hEX
Otherwise, I don’t suspect you’d “notice”/“feel”/etc any difference in upgrading to RB5009 on the client-side.
Wow, kraal, you must have hacked my life!
This is all for personal use – so the users are tremendously demanding and unforgiving.
I happen to have an RB5009 sitting around just being a dude server (nothing else).
And, the hEX is running Wireguard to about 7 different peers (servers) and often serves video streams.
But, the CPU stats seem to say there would be no benefit – so I’m confused.
Here’s another graph. The prior was used a 5-minute mean calculation of CPU usage.
This one also has a 5-minute maximum CPU in blue (I moved the scale up for the right-side Y-axis just to keep it readable).
Uh ? Wait a minute … you got an RB5009 for nothing else then Dude ?
SWAP. ASAP.
Hex can also be used as Dude server (heck, RB5009 can take all duties of Hex and still act as Dude server)
Especially when running wireguard, you will benefit from the additional processing power of RB5009 vs Hex.
Are you the kind of people having brand new silk underwear on the shelf, but wearing their old burlap underwear until they have more holes than fabric left, because they “still do their job” ?
Just asking ;-p
More seriously, if you have the device the only cost you’re facing is porting the hex configuration to your rb5009, so why do you hesitate ? As holvoetn stated it you can continue running the dude on the rb5009. And you would save on your power bill (if you decommission your hEX).
Side note: if your users are too demanding or too unforgiving, remember that “you’re the admin here”. So seek inspiration in big companies: retaliation is your best friend, so block their traffic on a random basis and blame the ISP, you’ll have a good reason to upgrade your stuff and ISP plan.
Wow! That’s true high-tech nerd guilt! I’m honored and grateful – it worked.
I just swapped the RB5009 for the hEX, despite my fears that I’d be spending hours and pulling my hair out (which is why I’ve been “hesitating” – which is a mighty generous word for 6 months of not doing it).
I think I got it working just fine. I basically copied the sections of the hEX export that were needed and didn’t contradict RB5009-specific items (like eth1-8). Changed some IP addresses and boom – it works.
speedtest.com shows about 833mbps down/934 up (no, I don’t know what it was with the hEX).
And my wireguard connections are working also!
It feels faster – and feeling good is what counts, right?
I did not wipe the RB5009 clean, so I still have The Dude running. I wonder if that’s why the Profile all CPU is higher than the hEX:
And, yes, I wear my socks, underwear and t-shirts until the holes in them are too annoying to those around me.
Here’s a bunch of graphs:
Oh, I doubt the hEX get to those speeds with a wireguard connection going at same time.
You can look at System > Profile and see what CPU Dude is using, but unless your monitoring hundreds of hosts at a high frequency, it’s CPU is pretty small generally. I’d leave it on RB5009, keep it simple. Keep the hEX for backup and/or “playing” with config before exposing your demanding user base to novel configurations.
Kraal, what is burlap underwear, I never had the pleasure!
Here’s a 24 hour update.
All is working well. I’ve been unable to identify what is causing the spikes in CPU usage or throughput.
I’m pretty sure the spikes are something automated (i.e., not a user-induced condition). From these graphs, 5 hours ago (midnight local), there was a CPU and a throughput spike, but I was the only person home (the only user) and I was asleep.
I’m not concerned about it – maybe a backup, or an update, or FANG (Facebook, Amazon, Netflix, Google) just getting their daily dump of all my day’s activities/thoughts/communications/etc.
You could have used your google-fu… :-p
Here are two examples:
That’s good news.
That’s a bit concerning.
Well, if you’re not concerned…
The blue line (featuring a spike) is Rx.
My bad
Great catch!
I use Backblaze to back up my systems to Backblaze’s cloud (one of several backup processes in place), so it could be that.
The past 12 hour graphs are below. This is what I’m calling “Real Time,” for lack of a better term, as opposed to 5 minute averages. I think that means the data points are plotted as often as they are provided to Home Assistant.
I disabled The Dude, and the CPU and throughput dropped substantially.
Indeed, other than some short-lived throughput spikes in traffic TO the internet (thank you mkx), both CPU and ether1 throughput is pretty low.
I find this all totally fascinating (is my excitement coming through?), and I thank you all again for the assistance and guidance.
I have yet to dive in to VLANS (well, I tried once and failed miserably), despite anav’s supportive encouragement, but it’s high on the list.
I’ve been playing a lot with Home Assistant, and a little with proxmox/linux – so many toys, so little time.
