[Solved] Packet loss using OpenWrt on a fiber connection

Installing and Using OpenWrt Network and Wireless Configuration
#1

I am encountering significant packet loss on my fiber connection (500/500Mbit) with this config:

  • Router: Linksys WRT1900ACS
  • Firmware Version: OpenWrt 18.06.1 r7258-5eb055306f / LuCI openwrt-18.06 branch (git-18.228.31946-f64b152)
  • SQM Qos enabled.

I'm getting perfect bufferbloat scores on dsl reports:

The packet loss appears while not much is going on in my network. The CPU on the Linksys is near idle.

I didn't have any packet loss using my Asus RT-AC68u running lastest Merlin firmware.
Any clues?

#2

Turn off QoS, you don't really need it on a 400+ connection under normal circumstances.

#3

Allready tried that. Doesn't make a difference.

#4

Where are you reading this loss?

  • On the WAN Interface?
  • On the client's interface?
  • On a test result page?

Can you run http://netalyzr.icsi.berkeley.edu/ ?

It may give you more information (for your knowledge).

#5

http://www.dslreports.com/tools/pingtest gives me an F rating.
Also tests with pingplotter show a packetloss of 10-25%

#6

Not even remotely true in my experience with gig fiber. Just synchronizing a video to a cloud drive will destroy your VOIP calls for example.

1 Like
#7

The packet loss goes away under load? I don't know but perhaps a CPU governor is idling your CPU and then a hardware buffer is dropping packets because it's not being served?

Also try checking Ethernet cables

#8

Cables are ok and packet loss stays under load.

#9

Tests are wired or wireless client?

#10

All tests are wired.

#11

Hmm seems strange, one suspects a driver issue. Does the packet loss happen when pinging direct from the router?

#12

@dlakelan
That sounds like something is horribly broken if you get congestion with that kind of bandwidth. I have several connections that are 10mbit+ which works perfectly fine incl VoIP however about all run FreeBSD boxes as routers except one (OpenWrt) which also seems fine.

@Conno
How are you measuring packet loss (against your local gateway or something else)? PPPoE? I can tell you're pushing with it trying to do QoS reliably at 500mbit and it will also struggle with PPPoE at those speeds. Does it occur on the router itself (netdata + fping for instance)? Is it still an issue if you try a snapshot (master)?

#13

Nope. That's not how this works. TCP continues to increase the bandwidth until you get dropped packets. So if you have say a 2 minute video and you upload it to Google Drive which is connected by a FAT pipe (like 40Gbps or 100Gbps) and can handle your gigabit no problem, you will max it out. I can max out my connection with a speedtest no problem.

Perhaps your connections are via DOCSIS cable? The latest DOCSIS standard specifies that the modems have to have queue management built in which makes it seem like there's no need for it on your end. Also it can be built into the head-end.

1 Like
#14

Also if you're using your ISP's VOIP service, this is getting prioritization over your internet traffic already, I'm sure all those ISP devices with the telephone jack built in give priority to the VOIP packets. Whereas my VOIP is 3rd party and lives on an ATA device behind my router.

#15

Assuming send and receive windows are sufficiently large otherwise you might still see an apparently throttled connection, but no packet loss.

Unlikely, the connection seems to offer symmetric 500/500, until fill-duplex DOCSIS is ready I see no chance of getting 500 Mbps uplinks in the Coax-part of a DOSCSIS network :wink:

#16

Yes @Conno has the 500/500 connection, but the question about DOCSIS I was referring to @dizzy

The concern with @Conno's issue is that if it were SQM causing problems, you'd expect to see them under load, and you'd expect to not get a very good speedtest/bufferbloat under load. But he sees this packet droppage at idle... and that suggests some kind of driver problem or cable problem or something else.

2 Likes
#17

@dlakelan
You're wrong and without major tuning (irregardless of OS) you wont saturate 40-100Gbit period. Speedtest is far from very reliable, it can give you an idea but don't rely in the results like the holy grail. I did also suggest that he could turn off QoS earlier. Regarding VoIP, that only applies if you use your ISPs gateway as any latency issue will occur as soon as traffic leaves your local LAN and potentially will increase due to load on backbone and peering points etc, SQM wont help at all in that regard. All connects are non cable (ie DOCSIS).

Just to prove my point regarding speedtest
http://www.dslreports.com/speedtest/40161924 (100/100, FTTH, no PPPoE, no SQM/QOS), not 100% dedicated connection during the test which should give you worse results...

#18

Ah, sorry, I did not get that, thanks for spelling it out for me.

#19

The test was silghtly misconfigured*, using 30 streams down and only 6 up is almost guaranteed to give you lower up than down rates. (These multi-stream speedtest make up for the lack of tuning of individual TCP flows to high bandwidths by running multiple TCP-flows n parallel, that combined can saturate a link).
I am assuming here you talk about the imbalance between down 92.7 and up 88.9. Whether 92.7 is actually okay for your link depends pretty much upon what your ISDP considers to be 100 Mbps (even though naively I would have expected goodput around 94-95Mbps).

*) Well as the log shows:

0.00s Start testing Fiber
00.48s Servers available: 7
00.53s pinging 7 locations
05.54s 30ms Darmstadt, Germany, EU
05.54s 32ms St. Ghislain, Belgium, EU
05.54s 33ms Frankfurt, DE, EU
05.54s 33ms Amsterdam, Netherlands, EU
05.54s 36ms Zurich, Switzerland, EU
05.54s 42ms London, UK
05.54s 51ms Dublin, Ireland, EU
05.55s WARNING could not assemble 32 streams with available or selected servers

The configuration was sort of okay, but dsl reports could not satisfy the configuration.

I note that this is tangential to your actual point, so you can just ignore this....

#20

...but again, it still proves my point.

  1. speedtest isn't the holy grail
  2. You don't need QoS/SQM by default "just because"