dell

Less than a week

by

We’ve just dropped below a week until my new FTTP service is scheduled for install. I’ve been doing a bit of prep work in anticipation as well, the CHR is back alive on a new server, low powered Xeon this time rather than monster. With the new efficiencies of RouterOS it’s now more capable than ever and I am “only” going to be pushing 1Gb max.

I’ve also upgraded it to ROSv7 so I can take advantage of the newer queueing algorithms, FQ_CoDel being the main one I wanted to get my hands on but I will try with CAKE once things have settled down although I hopeful that with a 1000/115 connection I shouldn’t need to QoS much of anything.

CHR back in place with a shuffle around

by
2019-04-10_08-43-07

The new PSU has worked so far so it was back up into the attic rack for my R210ii. No other modifications although if it manages a couple of weeks I will most likely look into some Noctua fans to quiet it off a bit. A bit of a tidy up as well removing some old switches and getting the patch panel in line.
One of the next jobs on the list will be to get a “CRS3XX” down into the cave so I can take advantage of some 10GB goodness with failover on 2 of the 3 fibres.

A breathe of life for the CHR

by

There has been a glimmer of hope for the CHR. I’ve come across a donor R210 with a power supply that is in brilliant condition, installed the power supply and it burst back into life. A good hour getting ESXi re-installed to the SSD I’d wiped and then reloading a CHR image onto it then carefully copying over the config and it’s just about ready to bring back into service.

I’ll be sorry to part ways again with the Hex and the FastTrack setup but this time around with the CHR I’ll be going for a really big QoS tree build.

CHR – Now faster and more efficient!

by

I’ve finally had some time to pull drag a monitor up into the attic to make some changes to the ESXi server that hosts my CHR. After some extensive reading on the MikroTik forum, it looks to read that a virtual CHR benefits from a “real” core and not a virtual one, in some cases virtual cores hindering performance! Even though my residential 55/15 connection isn’t going to set the world alight, I want to do some really in depth packet inspection next year so having raw performance is top of my list.

The changes I’ve made were to move the server BIOS performance setting from “OS Control” which was initially set to try and minimise noise in the cave to maximum performance, a few packets made there maybe?

The second big change was to turn off the hyperthreading on my Xeon. When I bought the Xeon I went out of my way to buy one with 4c/8t for maximum cores but RouterOS itself is very single core based and can’t multi-thread so single core efficiency is key. It also benefits from L3 cache so splitting the cache between 4 rather than 8 helps more so. There is also some heat efficiency to be made by running the processor without HT which counter balances the BIOS performance setting which could increase heat.

Overall testing without firewall now yields a far healthier 10+Gbps speedtesting to itself on a single core compared to the previous 7(ish).

All will be undone though if/when rOS7 launches with multicore!