Wat is de waarde van packet overhead?

@Martjekday bedankt voor je reactie. Discord heb ik niet.

Even voor jouw beeld, ik draai op een nanopi r4s, deze heeft 1 wan en 1 lan port. Om die reden heb ik igmp snooping niet aanstaan. Igmp snooping heb ik echter wel aan staan op mijn switch waar deze ene port naartoe gaat.

Wat betreft irq balance en packet steering, die heb ik niet nodig omdat ik mijn cpu afinnity zo heb aangepast dat zonder deze opties de load al netjes verdeeld wordt over mijn cores. Dit is te zien met htop tijdens het draaien van een speedtest. Wat betreft twee bridges, dat lijkt me geen kwaad te kunnen en zelfs noodzakelijk om er voor te zorgen dat mijn iptv op een eigen vlan (4) terecht komt.

Op deze manier scheid ik mijn tv ontvangers van mijn normale netwerk en kan ik in mijn switch aangeven op welke poorten ze zitten door te verwijzen naar het juiste vlan id. Dit werkt overigens super goed, dus daar wil ik niet te veel aan veranderen.

Ik geloof dat @wjb ook een soortgelijke config heeft voor de edgerouter 4, en die heb ik nagebouwd :)

Ik draai de laatste versie van openwrt (geen snapshot), gisteren nog vers gedownload, 23.05.4 dus vraag me af op welke versie jij dan zit?

@vicking  Ik zit op dezelfde versie. Ja ik begrijp wat je doet met de tv ontvangers, toch grappig want in eerdere posts zeggen ze dus dat die manier de oude manier is. Ik weet alleen niet of dat dus voor onstabiel gedrag kan verzorgen. De config ziet er verder gewoon netjes uit. Dan vraag ik me toch af of er een hardware limiet er op zit dat het niet kan met een nano. Het enige wat ik kan bedenken. Probeer de configs uit. Stel t werkt niet dan is er niks overboord. Ook al ben je bij wijze van locked out kun je gewoon met je kabel alsnog inloggen direct aan de nano en je oude configs herstellen. Ik weet ook niet goed hoe krachtig een nano is in die zin. 

Ik heb een openwrt x86/64 device. Daar zit geen switch verder ingebouwd of iets. Ik gebruik eigenlijk een andere router een tp link Archer voor de wifi en eigenlijk ook soort als switch. Mijn iptv zit aan de tp link. Dus die bridge zou volgens mij niet hoeven. Jij gebruikt de nano en dan een switch. Ik de x86/64 en dan de tp link Archer. En ik heb ze ook niet gescheiden met twee bridges.

Doordat we niet een op een configuraties hebben vind ik t lastig ik weet niet of dus die bridges issues kunnen veroorzaken of dat het niet uitmaakt en dat het gewoon een hardware limiet is van een nano

Klopt, ook ik heb mijn TV ontvangers op een apart vlan staan. Mijn ervaring is dat dat stabieler is dan de TV ontvangers op hetzelfde (v)lan als de andere apparatuur waarbij er soms haperingen optraden als een windows machine een update aan het downloaden was. Ik geef het vlan voor de TV ontvangers ook een vlan priority tag van 5 mee zodat het verkeer voor de TV ontvangers op mijn LAN voorrang krijgt op ander verkeer.

De MTU sizes die ik ingesteld heb zijn 1508 voor de wan poort, 1508 voor vlan 6, 1500 voor vlan 4, 1500 voor pppoe en 1500 voor de lan poorten en de vlans op die lan poorten.

Bedankt voor de reacties!

Ik ga eens spelen met wat andere hardware omdat ik bang ben dat de NIC van de nano misschien de beperkende factor is in deze wat betreft de mtu waarde. Ondanks dat het werkt, wil ik het graag correct ingesteld hebben en wat dingen uitsluiten! :)

@vicking nja ik denk niet dat het erg kwaad kan hoor. Het is namelijk een optie, maar niet verplicht. Hoe je de nano had is in principe ook goed. 

Ik weet niet meer goed of dit een rasberri pi specifiek ding is. Ik dacht dat ik hier meerdere mensen over hoorde op forums. Bind me er echter niet op vast. Je config zou goed moeten zijn. Alleen ja met de bridges geen idee. Want een statische route zou ook moeten kunnen. Dan nog zou t moeten werken, want je nano zou op 1 gbit moeten kunnen werken. 

Maar besef dat op zich beide manieren goed zijn, het is niet zo dat wat je had fout is. Technisch gezien zijn de pakketjes dan iets kleiner voor wat de mtu aan kan. Mja de waarheid is de meeste pakketjes zijn kleiner. 

Oké, het lag dus echt aan de Nanopi r4s. Deze kon niet lekker overweg gaan met de MTU.
Ik heb nu mijn Rpi4 weer ingesteld (helaas heb je dan wel een USB3.0 ethernet dongle nodig), maar wat een verschil…

De analyzer laat nu ook netjes een MTU van 1500 zien en met SQM ben ik zeer tevreden met mijn resultaat:

https://www.waveform.com/tools/bufferbloat?test-id=98b28998-4ad0-4f27-9530-9b870b1d6ea0

@vicking Hey mooi. Hebben we toch waardevolle informatie gedeeld en geen onwaarheden verteld. En fijn dat het toch werkt. Ik had zoiets ergens gelezen, alleen ik wist t niet zeker meer.

Hoeveel is je jitter?

@vicking ik kon de waarde niet zien op de foto op mijn mobiel. Met qosify krijg ik de waarden naar 0.4 op jitter. Je kunt je router in performance mode zetten als je dat nog niet heb gedaan. Dit doe je op de cores. Standaard staat hij op schedutil. Dat is een tussenweg, performance mode verbruikt namelijk meer stroom. Overigens zei je dat je de iptv op een aparte bridge moest doen, want je kreeg haperingen. Dat egress qos heb ik ook geprobeerd. Alleen de haperingen in mijn geval met iptv kwamen daar vandaan.

Fijn dat het in ieder geval werkt. 

Ik weet niet wat je ingesteld had staan als Egress QoS maar de onderstaande instelling op mijn EdgeRouter 4 werkt vlekkeloos.

Het zorgt er simpelweg voor dat alle pakketjes op dit vlan met een priority tag lager dan 5 alsnog een priority tag van 5 krijgen. Wat hiermee gerealiseerd wordt is dat op mijn thuisnetwerk het verkeer op het vlan voor televisie voorrang krijgt op ander verkeer.

Ok ja ik heb t eerder geprobeerd, dat ging dus niet lekker. Maar ik had ook qos draaien. Misschien dat ik iets verkeerd toen deed. Is een tijdje geleden. Ik wil dus eigenlijk totale controle. Daarom qosify. Ik gebruik dscp values. En wil juist dat mijn internet voorrang heeft. Alleen het werkt nog niet helemaal naar behoren. Ik merk dus nu dat wanneer ik prime opstart de tv eruit klapt. En dat hoort niet. Ook met andere elementen. Nu moet ik zeggen dat ik laatst qosify hen geïnstalleerd en normaal heb ik custom scripts. Die custom script werkt wel volledig, maar is ook zwaarder op de cpu. En met qosify krijg ik betere waardes. 0 ms bufferbloat op download en upload met 0.4 jitter is echt wel sick. Beter kan letterlijk niet. Dan zou ik xdp moeten programmeren dat werkt t beste. Maar is meer voor 10gbit lijnen. Kan ook op 1gbit, maar ik moet nog onderzoeken hoe dat moet. Is vrij complex want dan moet ik een custom build maken. En ik moet dat nog zo voor elkaar krijgen dat ik alle packages makkelijk kan ombouwen. Echter is dit een project voor later. Moet eerst kijken waarom qosify de dns pakt hij alles eruit laat klappen. Of er gaat iets met de forwarding niet lekker. Ik heb ook een edgerouter echter voldoet dat niet meer aan mijn snelheid dus ben ik daarvan af. 

Ik ben inmiddels geswitched van hardware en daarmee ook naar een ander systeem, Opnsense haha. Het was leuk om daar weer wat dingen over te leren en mee te doen en ook dat werkt nu goed!

Het enige wat ik nog wil configureren is de egress qos, die setting heb ik nog niet gevonden. Wel kan je in Opnsense een vlan een bepaalde prioriteit geven, dus wellicht is dat iets om mee te spelen, al moet ik zeggen dat ik geen hapering heb op het moment maar ik weet uit het verleden dat het altijd heel goed werkte!