I have connection with 95Mbps up/down speed and f@st 2704 with 18.06.2 installed. When using it in basic configuration as router I gain only 35Mbps up/down over lan cable and 15 Mbps over wifi. Is there any solution for this problem?
Hi @lukastob
Are you seeing a regression from a previous version of OpenWrt or have you recently measured the throughput of the device and noticed that it does not meet the expectations quoted by the hardware specifications?
Thanks
Considering the very low-end hardware (256 MHz mips32, 4 MB flash, 16 MB RAM), 35 MBit/s is already more than I would have expected (my guess would have been in the 20-25 MBit/s range at most).
https://openwrt.org/start?id=toh/sagem/fast2704
320mhz 8M flash 64M RAM.
@slh did you look on the wiki and confuse the V1 and V2 models?
Years ago I have used it with BB 14.07 and 3g usb modem so didn't bother about speed, now I found it lying useless and wanted to make something usefull. Unfortunately didn't check the speed on BB and wanted to keep it update so flashed newest openwrt without making a copy of old system.
@slh it is this better version V2
Still a device with an SoC that was appropriate for the days of 30/3 Mbps ADSL and not much more, as your tests confirm.
Thanks @lukastob
How did you test please? I am running similar hardware and might be able to confirm the issue by running the same test(s).
It's only been 48hrs since I got OpenWrt installed so I haven't done any throughput testing myself yet.
One popular, seemingly reliable, online test is http://www.dslreports.com/speedtest run from a browser.
I was thinking more like using the network topology graphs in luci or an installed piece of network monitoring software via an operating system or into the copy of OpenWrt itself.
That way any disparity between wan and lan can be dispelled and much more accurate information can be obtained, shared and compared.
Obviously, yes - but a 550 MHz ar71xx/ ath79 AR9344 using the newer mips 74Kc core is with the back to the wall dealing with 100/40 MBit/s, yes it can do it, but right at its limits. 2*500 MHz lantiq VRX268 based on mips 34Kc can only cope with that speed using flow-offloading, it's very unlikely that first generation mips32 BCM6328 at 320 MHz can deal with that - and why would it, ADSL2+ is specified at up to 20 MBit/s (and I don't think any commercial implementation was using more than 16 MBit/s), so why would the manufacturer make it any faster than that?
Until pretty recently, ~50 MBit/s VDSL connections were considered top-end, with most users being at -and significantly below- 16 MBit/s, there was no reason for manufacturers to produce faster and more expensive devices for the mass market. This is increasingly an issue for users with older hardware, whose internet connection was suddenly (and finally) upgraded to VDSL2, cable or fibre.
To deal with 100/40 MBit/s comfortably, you need at least ~700 MHz ar71xx/ ath79, but better go a little faster and pick ipq40xx instead; lantiq VRX268 might be another attractive (cheap) alternative, which is hard at the limit at those speeds (but can do it using flow-offloading) but already includes a decent VDSL2+vectoring modem. See Top ten routers currently in use? - #4 by slh for suggestions, unless you can get a modern top-end ar71xx/ ath79 device for less than 30 EUR or want lantiq/ an integrated modem, I'd strongly suggest to go with ipq40xx to retain some margin for the future.
1 Like
I use iperf3 for benchmark tests. Use the default configuration in the router under test where it NATs from LAN to WAN. Connect the WAN port to your regular network as a DHCP client. Run iperf3 on one of your network LAN PCs. As far as the test router is concerned, this machine is part of the Internet. Have another PC with iperf3 on the test router's LAN.
1 Like
I meant to say iperf3. Iperf3 is available for Linux or Windows. It blasts out packets to another machine running iperf3 and measures the speed.
I did the simplest test according to my limited knowlage. One PC connected directly to main network and another PC behind this router. I just run most popular speedtest website googled in my country and read the result from it. Additionaly wi-fi tested with smartphone on mobile version the same website.
I too am only seeing 15 Mbps max over wifi via a test on fast.com
To be honest, I'm pretty new to OpenWrt but I'm seeing some pretty funky things going on.
Following the instructions at https://openwrt.org/docs/guide-developer/debugging#wireless might need to happen here at some point.
At this point I'm probably going to need to test a snapshot to see if it's openwrt-18.06.2-brcm63xx-generic-FAST2704V2-squashfs-cfe.bin which is at fault or not.
Edit: I installed a snapshot. The odd things I was seeing seem to have gone. Still 15 Mbps max speed over wifi via a test on fast.com though.
Is the wifi operating in n mode? I think the driver OpenWrt uses only supports g mode.
You can tell by looking at the bit rate reported in the connection status. The maximum rate of g is 54 Mb. This is the raw radio rate, the actual throughput will be much less especially if there are neighbors.
Correct. The b43 module only supports bg even if the device can do n.
The setting for the Wi-Fi adapter in OpenWrt includes "Allow legacy 802.11b rates" turned off. So the adapter is only using g.
I remember reading somewhere that actual throughput is usually somewhere close to a quarter of the advertised, so what you say seems right.
It might be that the difference between g and n are so noticeable that without n working, it may be that the hardware's performance might not be acceptable.
Sounds about right, from https://en.wikipedia.org/wiki/IEEE_802.11#802.11g
It operates at a maximum physical layer bit rate of 54 Mbit/s exclusive of forward error correction codes, or about 22 Mbit/s average throughput.[32]
(assuming the signal quality is good enough to use the fastest rates, no other clients, single VAP, no interference, ...)
I think @lukastob might be seeing the same issue I am seeing.
So, if you ssh in and pull opkg update, the memory becomes exhausted unless you either manually clear the cache or reboot. The memory being congested will slow down the throughput.
Then after the reboot, there is some kind of race condition where you need to wait until the device is completely up and OpenWrt has settled (a few minutes,) then stop the Wi-Fi and then start it again. If you don't manually do this, then the Wi-Fi will eventually grind to a halt and it's either crashing the driver or there is some sort of address problem. Still unsure what is causing it yet.
After restarting the Wi-Fi, it is fine.
My guess is that the Wi-Fi is being brought up too soon. But I guess we'll see when I find the time to take a closer look.