I'm using the original round Starlink dish which is now several years old. I have never used the Starlink provided router as the power adapter on that dish can plug directly into my OpenWrt router's WAN port. But my understanding is that you could do something similar by putting your more recent Starlink router in bypass mode.
yes exactly I plan to do that to have internet, you got it directly because I remember that the router did not have internet without adding the command above in sqm you entered your maximum values or as long as you enter values it doesn't matter since cake autorate does the job,
the additional packages are the 3 only fpings... it's just in addition to sqm
this command
# Configure network
uci -q delete network.modem
uci set network.modem="interface"
uci set network.modem.device="@wan"
uci set network.modem.proto="static"
uci set network.modem.ipaddr="192.168.100.1"
uci set network.modem.netmask="255.255.255.255"
uci commit network
/etc/init.d/network restart
Selecting a "ping binary"
cake-autorate reads the $pinger_binary variable in the config file to select the ping binary. Choices include:
fping (DEFAULT) round robin pinging to multiple reflectors with tightly controlled timings
tsping round robin ICMP type 13 pinging to multiple reflectors with tightly controlled timings
iputils-ping more advanced pinging than the default busybox ping with sub 1s ping frequency
I actually still use ‘fping’ myself because of irregularities in the way my 4G ISP seems to handle data transfer, albeit in theory ‘tsping’ should give better performance because it uses ICMP type 13 and therefore facilitates determination of one way delays, whereas ‘ping’ and ‘fping’ use ordinary ICMPs and so one way delay is just fudged by setting the one way delays to RTT/2.
the decay refractory period timers are now reset on all changes:
and the shaper rates are now only allowed to increase following load updates:
And the latter seems to be working as can be identified form the SUMMARY lines below (on high load, shaper rates are only increased once per achieved rate update):
Excellent, even though I assume that this change will not be noticeable in normal use it feels cleaner.
Seems OK as well, and hopefully solves the issue that started this sub-thread?
Neither of us can actually test this, so if the starlink users do not use/need this then retiring this seems a decent idea to make thinks less complex.
I am not sure what this means? Probably if you are running through a machine translate you need to use simpler language in French(?) or the original language before translating into English.
Well, I tried Starlink tonight without cake-autorate running. Today was probably the first day in over a year that I've run Starlink without cake-autorate.
I have CAKE enabled in OpenWRT but set to 200 Mbps down / 30 Mbps up, so it's not really constraining the bandwidth.
It is the time of the evening when bandwidth goes down as people are streaming stuff. I did at least 7 waveform tests. The bandwidth varied quite a bit per test but the latency was still good on all the tests, at least according to Waveform. Here are a couple of samples, first one had good bandwidth and the second quite a bit slower:
I ended up doing 7 Waveform tests and every one of them gave me a grade of A+. I'm wondering if Starlink has now added something like cake-autorate on their side, where they monitor the bandwidth and adjust CAKE or CODEL on the fly based on how much bandwidth they can deliver to each user? They could directly know how much bandwidth they can provide to each user instead of relying on ping tests for latency.
Is there another type of latency test that I should be using instead of Waveform? Perhaps something longer running?
I'm just a little confused as cake-autorate was previously pretty much necessary to use Starlink without a bunch of bufferbloat, but now the results are quite different!
Yes, I will do some testing over the next couple days and see if there are any periods of higher latency. My first thought about the screenshots the other user took is that they appear to be from a phone over wifi, and wifi itself has a lot of issues with bufferbloat depending on the phone & router. So it seems kind of hard to determine where the bufferbloat is coming from in that case. I've done all my tests on a computer connected via ethernet to rule wifi latency out.
If Starlink have fixed bufferbloat, and if Starlink users like @gba would still like to leverage CAKE's flow fairness, then would it make sense to offer a special mode in cake-autorate in which the shaper rates are simply just updated with the achieved rates (or a configurable factor higher to retain the same throughput)? Or would setting the bandwidth to 0 in CAKE already achieve that anyway?
Unfortunately no, because achieved rates are not all that reliable and depend on your actual usage pattern: if starlink would offer you a bloat free capacity share up to say 100 Mbps, but your current load is application-limited to 10 Mbps, you measure an achieved rate of 10 Mbps, but putting the shaper to 10 Mbps would waste 90% of the achievable capacity... put differently all we see is the achieved rate, but what we want is the achievable rate... (plus the issue that this only works in the download direction)...
We would need a special mode where cake also tries to measure the rate of incoming data and use that to configure its shaper; that exist as autorate-ingress I believe, but only works in a subset of cases satisfactorily.
Not really, queues only build at transitions from faster to slower, but in a router with faster LAN than WAN the transition is from slower to faster so there will be no queue building up inside cake and so cake will just pass packets on pretty much as it received them.
Yes understood. I suppose cake-autorate would still track the bandwidth, and since the latency never increases significantly it will not tend to punish the bandwidth. So it would just increase the shaper rates whilst the achieved rates are high relative to the present shaper rates, and then decay back to base. And of course the congestion control aspect would be on standby for any periods of irregularity.
Are these factors enough to warrant still using cake and cake-autorate with Starlink I wonder?
By way of comparison, we pay circa £30/month for our unlimited mobile contract (in fact our total bill for this plus two further mobile phone contracts for our personal phones - so three mobile contracts in total - amounts to just over £80/month).
But for sure the fact that Starlink seem to have worked on latency now makes it a rather more attractive prospect, especially for those that do not live right next to a 4G mast like we do.
I wonder if wireless technology is the future for internet communications. Digging trenches in the ground and laying cables seems a bit yesterday these days.
In any case, seems like I can go ahead and remove the Starlink satellite switching compensation code and example Starlink config.
Longer term I believe/think it will be exactly that laying cables (be it in trenches/below the ground or on poles above the ground) to each and every premise... (at least to the level of the old telephony networks), the replacement will mostly be glas fibre giving enough headroom for the next '100' years. Deploying the telephony networks also was expensive, but eventually it reached close to 100% deployment.
Shorter term wireless technologies can help getting people a usable internet well before the FTTH deployment reaches their neck of the wood.
