Most likely the device is not powerful enough, check system / resources while testing to check CPU usage.

Hello,

Based on your setup, you may get less than gig. If you look at the gr3 specs, you'll see that with filters and bridges, throughput goes down depending on packet size.

Regards

Sent from Tapatalk

Hello,

Based on your setup, you may get less than gig. If you look at the gr3 specs, you'll see that with filters and bridges, throughput goes down depending on packet size.

Regards

Sent from Tapatalk

Is there anything I can do to get the full speed on RB750Gr3? I am keeping the minimum setting as you can see from my config.

The CPU usage is under 50%, doesn't this tell that the CPU is still capable?

So now my problem would be whether I need a better model.

My RB750Gr3 doesn't use up the CPU and yet it doesn't achieve the full speed, is it my config problem or the hardware limitation?

/tool profile cpu=all
NAME                    CPU        USAGE
ovpn                      0           0%
ethernet                  0         0.5%
console                   0         0.5%
dns                       0           0%
firewall                  0           0%
networking                0         4.5%
management                0         0.5%
cpu0                                  6%
ethernet                  1           0%
ssh                       1           0%
firewall                  1           0%
networking                1           0%
management                1           0%
cpu1                                  0%
ethernet                  2         0.5%
firewall                  2           0%
networking                2           0%
management                2           0%
cpu2                                0.5%
ovpn                      3           0%
ethernet                  3           0%
console                   3           0%
firewall                  3           0%
networking                3           3%
management                3           0%
bridging                  3           0%
cpu3                                  3%

/tool profile cpu=total
NAME                    CPU        USAGE
ovpn                                  0%
ethernet                              0%
console                             0.1%
dns                                   0%
firewall                            0.1%
networking                          1.8%
radv                                  0%
ipsec                                 0%
logging                               0%
management                          0.2%
profiling                             0%
bridging                            0.1%
total                               2.3%

So now my problem would be whether I need a better model.

Hello,

Based on your setup, you may get less than gig. If you look at the gr3 specs, you'll see that with filters and bridges, throughput goes down depending on packet size.

Regards

Sent from Tapatalk

Is there anything I can do to get the full speed on RB750Gr3? I am keeping the minimum setting as you can see from my config.

The CPU usage is under 50%, doesn't this tell that the CPU is still capable?

Use fasttrack and you should be able to max out your uplink.

You are seeing 50% cpu because you probably maximize only one core.

You should check tools > profile to see what’s using the cpu.

So now my problem would be whether I need a better model.

My RB750Gr3 doesn't use up the CPU and yet it doesn't achieve the full speed, is it my config problem or the hardware limitation?

The RB750Gr3 has one CPU. This CPU has two cores. Each core has two threads. So, the CPU has four threads total. Why is it important? Because if You look only at the aggregated CPU usage You can miss a single thread at 100% - that would show as 25% usage.

Compare this two examples (both from a 750Gr3):

Code: Select all

/tool profile cpu=all
NAME                    CPU        USAGE
ovpn                      0           0%
ethernet                  0         0.5%
console                   0         0.5%
dns                       0           0%
firewall                  0           0%
networking                0         4.5%
management                0         0.5%
cpu0                                  6%
ethernet                  1           0%
ssh                       1           0%
firewall                  1           0%
networking                1           0%
management                1           0%
cpu1                                  0%
ethernet                  2         0.5%
firewall                  2           0%
networking                2           0%
management                2           0%
cpu2                                0.5%
ovpn                      3           0%
ethernet                  3           0%
console                   3           0%
firewall                  3           0%
networking                3           3%
management                3           0%
bridging                  3           0%
cpu3                                  3%

/tool profile cpu=total
NAME                    CPU        USAGE
ovpn                                  0%
ethernet                              0%
console                             0.1%
dns                                   0%
firewall                            0.1%
networking                          1.8%
radv                                  0%
ipsec                                 0%
logging                               0%
management                          0.2%
profiling                             0%
bridging                            0.1%
total                               2.3%

I did a Speedtest on both, to put some strain on the CPU. My link is slow (30Mbps), so it's not much of a load. But it's enough to show what I wanted: With the total, the CPU usage is 1,8%. But when displaying all threads we can see that we have one thread running at 4,5% and another at 3%. Add both and divide by four, and we get 1,875%. Close enough of the first example.

So. Take a look at tools profiling - but ask to see all the CPUs. You may find that some of them are hitting 100%...

So now my problem would be whether I need a better model.

No, you don't need a better model. You need to configure FastTrack and you will able to reach 1Gbps.

And don't forget the three location where FastPath is defined. I the one in the Bridge was off and my upload dropped from 750Mbit/s to 120Mbit/s and download was not affected by that and stayed at 520Mbit/s all the time.

There is one also in IP Setting and don't forget to enable route cache there because that kill speed if not enabled.

Your firewall rules do include fasttrack rule, but your forward rules are below the input.
Move all chain=forward rules to the top, with fasttrack being the very first rule

After a lot of attempts, I found disabling the bridge STP protocol improving the speed, from ~840 Mbps to ~900 Mbps.

This is the only thing I found useful now, a lot closer to the max speed of 940 Mbps now.

After a lot of attempts, I found disabling the bridge STP protocol improving the speed, from ~840 Mbps to ~900 Mbps.

This is the only thing I found useful now, a lot closer to the max speed of 940 Mbps now.

Are You testing the speed with a single connection? Try with more than one (torrent is an option). Spreading the load can help things, as You use all the available threads.

your forward rules are below the input.

After a lot of attempts, I found disabling the bridge STP protocol improving the speed, from ~840 Mbps to ~900 Mbps.

your forward rules are below the input.

Francois, this is nothing but a superstition. The order of the chains (input, output, forward) in a table doesn't matter at all; the order of rules within the same chain does. So you can even place the rules like I1, O1, O2, F1, I2, O3, F2, F3, F4, I3, I4, O4 and it will still work, and each packet will only be handled by rules of its respective chain. Such a messy way of entering the rules makes human analysis of them a mission impossible, but the ipfilter running deep inside gets them sorted into the distinct chains with distinct entry points, so e.g. forwarded packets don't have to skip input and output rules which are above the first forward rule in configuration.

Strictly speaking, what should be as high as possible among the forward rules is the action=accept connection-state=established,related one, because the bulk of the packets matches to this rule, so they should not have to be matched against any other rules before reaching this one; unfortunately, action=fasttrack-connection has to be even before it, otherwise it wouldn't work. But once a connection becomes a fasttracked one, most of its packets do not pass through the firewall at all, not even through the action=fasttrack-connection one.

sindy, glad to see we are on personal name basis, but I am not sure I have yours yet

Is my understanding / logic incorrect?

Such a messy way of entering the rules makes human analysis of them a mission impossible, but the netfilter running deep inside gets them sorted into the distinct chains with distinct entry points, so e.g. forwarded packets don't have to skip input and output rules which are above the first forward rule in configuration.

my name ... has the same unimaginative origin as yours

the reason why forward and input are together is because there can also be subchains (accessed by action=jump) and those can be common for both. So if forward and input would be in different tabs (which could be less confusing for new users), it would bring another problem, where the possible subchains should be.

@sindy: You're probably drinking beer not very far from me. But shh, we don't want anyone to know that we're slowly taking over the forum (maybe we can accept @CZFan as honorary member, he could be useful, he's not as much into motorcycles as I initially thought, but other things).

@OP, what do you have connected to the 750. And which ports are they connected to?

Your firewall rules do include fasttrack rule, but your forward rules are below the input.
Move all chain=forward rules to the top, with fasttrack being the very first rule

Move all chain=forward rules to the top, with fasttrack being the very first rule

This was the last step that I didn't know I need to do. Thank you so much!

Speed limit of the device is here. If routing properly with fasttrack, you should be able to achieve gigabit with all reasonable packet sizes.