Packetloss bij belasten verbinding

Hi,

Mijn OPNsense router houdt middels dpinger (gateway monitoring) de kwaliteit van mijn verbinding in de gaten. Die is over het algemeen goed! :slight_smile:

Als ik de verbinding echter wat langer en zwaarder belast loopt het packetloss al snel op tot tussen de 5 en 20%.


Ik gebruik om te testen de bestanden op http://speedtest.tele2.net/. De downloadsnelheid blijft rond de 100 MB/sec, dus dat lijkt mij prima. Iets waar ik mij zorgen over moet maken?

Voor de zekerheid nog de specs van de router, gebrek aan resources is het denk ik niet:
OPNsense 21.7.4-amd64
FreeBSD 12.1-RELEASE-p20-HBSD
LibreSSL 3.3.5
AMD Ryzen 5 3500X 6-Core Processor
16GB RAM

Hier nog wat uitschieters. De reden dat er offline naast staat zijn de signaalwaardes die ik heb ingesteld. De verbinding doet het dus gewoon nog op dat moment.


Iemand suggesties om dit te troubleshooten? Of maak ik me zorgen om niks?

Ik ervaar hetzelfde met mijn pfSense (Netgate 6100). Ik kwam erachter toen ik met traffic shaper aan de slag was.

Met een speedtest is het de bedoeling dat de beschikbare bandbreedte volledig wordt gebruikt. Voorlopig verkoop ik de packetloss dat op dat moment de icmp packets van dpinger geen prioriteit hebben. Waardoor het langer duurt dan verwacht of zelfs verloren gaan. Is dat erg? Ik denk in deze situatie niet. Verder blijft alles prima functioneren.

1 like

zoek eens naar bufferbloat, het zou kunnen zijn dat je hier last van hebt

1 like

Thanks @mcfab! Ik ga eens kijken of ik daar wat mee kan!

Als je zorgt dat je een 5-10% onder het maximum van de uplink capaciteit blijft met traffic shaping beperkt zal alles waarschijnlijk een stuk soepeler lopen. (dat was mijn ervaring in het DSL tijdperk).
En dan met name korte pakketten en ACK etc. prioriteit geven boven bulk data.

1 like

Iemand suggesties voor instellingen op OPNsense? Ik vond dit topic (https://forum.opnsense.org/index.php?topic=7423.0) ? Maar ik heb echt de ballen verstand van tracffic shaping.

Is het niet mogelijk om traffic shaping helemaal uit te zetten?

Ik had geen traffic shaping aan staan, de oplossing is blijkbaar om het juist in te schakelen en dus 5 to 10% onder je maximale capaciteit te gaan zitten.

Heb je voor OPNsense al een voorbeeld gevonden?
Voor pfSense heb ik deze gebruikt. Misschien is deze (eventueel met een kleine aanpassing) ook voor OPNsense bruikbaar.

Ik heb gemerkt dat 5% op basis van het aantal kb/s al prima werkt.

Daarnaast heb ik juist voor de ICMP echo reply/request een extra Queue’s (voor UP en Down) aangemaakt waarbij ik de Weight op 100 heb gezet. (en die uit het voorbeeld op weight: 10). Daarbij heb ik de floating rule voor icmp op de tweede Queue gezet. Daardoor krijgt de ICMP rule, simpel gezegd, voorrang. De limiters heb ik op 100% van mijn bandbreedte gezet. (maar wellicht dat dit overbodig is bij jou)

1 like

Ik heb de link die ik eerder poste gevolgd en die instellingen aangepast aan mijn bandbreedte. Dus de volgende instellingen:

Download pipe

- Bandwidth: 900 Mbit/s
- queue: 2 
- Scheduler type: FlowQueue-CoDel
- Enable (FQ-)CoDel ECN
- FQ-CoDel Quantum: 2700
- FQ-CoDel Limit: 2700

Upload Pipe:

- Bandwidth: 900 Mbit/s
- Scheduler type: FlowQueue-CoDel
- Enable (FQ-)CoDel ECN

Download Queue

- Pipe: Download pipe
- Weight: 100
- Enable (FQ-)CoDel ECN

Upload Queue

- Pipe: Upload pipe
- Weight: 100
- Enable (FQ-)CoDel ECN

Download Rule

- Interface WAN 
- Target: Download Queue
- Protocol: ip
- Destination:  Alle IPv4 en IPv6 subnetten die ik intern gebruik (bijvoorbeeld 10.1.0.0/16)

Upload Rule

- Interface WAN 
- Target: Upload Queue
- Protocol: ip
- Destination:  Alle IPv4 en IPv6 subnetten die ik intern gebruik (bijvoorbeeld 10.1.0.0/16)

Dit lijkt het grootste deel van het probleem opgelost te hebben. Downloadsnelheid zakt ietsjes naar rond de 90 MB/sec, maar packetloss is beperkt tot heel soms 1%, maar meestal 0.

Thanks! Ik ga die ook even doorlezen, misschien valt er nog wat te tweaken. :slight_smile:

vroeger was er het linux router project maar dat is al ergens in 2002 min of meer overleden.
Die hebben wel een erfenis achtergelaten in de vorm van scriptjes en tools… waaronder de traffic-shaper

Hier is wat achtergrond uitleg.
https://www.b1c1l1.com/blog/2020/03/26/linux-home-router-traffic-shaping-with-fq_codel/
https://www.b1c1l1.com/blog/2020/04/19/linux-home-router-download-bufferbloat-analysis/

Gentoo heeft ook een beschrijving
https://wiki.gentoo.org/wiki/Traffic_shaping

Dat is een beschrijving voor Linux systemen, maar het mechaniek is universeel

Begin met 10% onder de bandbreedte en daarna kun je experimenteren met de marges op te schroeven naar 95%… zolang het maar stabiel blijft.

2 likes

disclaimer: Zelf ben ik ook pas een maandje aan het stoeien met de traffic limiter, dus geen expert.

Zo te zien gaat het dus al lekker. Nu de kers op de taart om er meer dan de 90MB/s en dat laatste beetje packet loss weg te halen.

Je kan ook nog zoeken wat de impact is van de Queue length bij de 2 pipes.
Schijnt dat als de Queue te groot is dat er dan ook packets gedropt kunnen wordt. Is de Queue te klein dan kan dat gevolgen hebben voor o.a. de snelheid.

Hier staan bij beide pipes de Queue length op 1000. (200/30Mbps)

1 like

Queue te groot is juist wat bufferbloat veroorzaakt.
een heel klein percentage packet loss is geen ramp, bij geen packetloss zal de tcpstack er steeds meer dooheen proberen te duwen…, packet loss is het mechaniek waardoor stabiliteit op de langere termijn gewaarborgd wordt. (<= 1%)
Het probleem is voornamelijk veroorzaakt door de assymetriche snelheden, met veel te grote buffers.
Maar het wordt goed uitgelegd in de linkjes die ik eerder al poste.

1 like

De theorie/informatie vind ik inderdaad waardevol.