Update:
This morning I ran a few tests from my office.
-Added address 10.0.100.1/30 on the bridge in the CCR (The one where all EOIP tunnels are joined)
-Added 10.0.100.2/30 to the EOIP tunnel in my CPE
-Set 10.0.100.1 as default gateway
This gave a download speed about twice as high as when running through the PPPoE tunnel, and somewhat lower than running with pure routing.
Each speedtest was ran several times with each route , enabling/disabling routes, to ensure correct results were recorded.
- Results (average of tests):
1. Pure routing: 21Mbps
2. EOIP with addresses: 15 Mbps
3. PPPoE over EOIP: 7Mbps
So what dis this tell me?
Intermediately, my conclusion was that both EOIP and PPPoE slow things down, and that PPPoE is the worst.
After doing this, I realized that test 1) and 2) are ran without any queue employed, while 3) has a simple queue of 100M/100M
Then I removed the rate-limit setting from the PPP profile and ran a few more tests through PPPoE, enabling/disabling the rate-limit every second time.
- Results:
1. PPPoE with rate-limit:8Mbps
2. PPPoE without rate-limit: 20 Mbps
This makes me suspect the simple queues, or the way the CCR handles these as the guilty part.
Is the problem that the CCR assigns the queue handling to only one CPU core, slowing things down?
A typical profile for my customers look like this, this is for 6M/1.5M:
/ppp profile
add address-list=Adr6000/1500 dns-server=x.x.x.x,y.y.y.y \
local-address=10.0.10.1 name=Profile6000/1500 rate-limit=\
"1500k/6000k 1800k/7000k 1200k/5000k 30/30" remote-address=pool1
As you can see I use bursts.
Is there anything that can be done to the profiles that will make the CCR handle the queues in a more efficient way?
Am I left with creating static simple queues instead?
Or is queue trees with PCQs a better option? Downside is that then I will not see status of the queue of one single customer.
(Now I see that this thread is in the Beta forum. Normis, is it possible to move it to the Routerboard Hardware or the General forum?)
