:fill(white):strip_exif()/i/2006002120.jpeg?f=thumbmini)
:strip_exif()/i/2006002116.png?f=thumbmini)
Voor de volledigheid, dit was de bron:
https://www.reddit.com/r/Ubiquiti/comments/1t5eydz/efg_have_pppoe_hardware_accelleration/
https://www.reddit.com/r/Ubiquiti/comments/1t5eydz/efg_have_pppoe_hardware_accelleration/
:strip_icc():strip_exif()/u/77667/crop56b7832c3f349_cropped.jpeg?f=community)
Ik kan helaas bevestigen dat dit aan PPPoE ligt icm geen hardware offloading. Kijk maar naar de single threaded cpu performance bij het stress testen van je verbinding. SSH -> HTOP command:
Beste Medetweakerts,
al meer dan een jaar geniet ik van een werkende stabiele 4/4 gbit internet verbinding van KPN. Hier ben ik heel blij meeAlles werkt naar behoren alleen vanaf dag 1 kwam mijn upload snelheid nooit boven de 2.2 - 2.5 gbit. Ik hoor dat dit aan het onbreken van "PPPoE hardware offload" in de ubiquiti devices kan komen. Weten jullie hier iets meer over? De aansluiting is nu FTU -> SC APC -> SC APC -> FS XGS-ONU-25-20NI -> EFG. Misschien dat mensen hun ervaringen kunnen delen voor de beste settings die bij hun momenteel werken. bvd
Bizar dat de 2000+ euro EFG hier geen ondersteuning voor heeft. Ik zat zelf te wachten op de udm beast maar ook hier hetzelfde verhaal. Al Schijnt deze het wel iets beter te doen door nieuwe cpu en verbeterde specs. Maar nog steeds geen hw offloading.
Enige oplossing is de ucg fiber die hw offloading heeft, kpn modem er tussen, of wachten op nieuw model… of wanneer kpn gaat afstappen van PPPoE (verwacht dat dit niet gauw gaat gebeuren).
Ik blijf daarom voorlopig maar bij 1/1G up and down. Eigenlijk voor thuis ook al meer dan voldoende :-)
[ Voor 5% gewijzigd door Workaholic op 31-05-2026 22:25 ]
/u/423394/avatar_60x60.png?f=community){kind=avatar}
:strip_icc():strip_exif()/u/651669/crop61f075a821e45.jpg?f=community)
:strip_exif()/f/image/ilfjUtT3GbFPGFXQyE4LrHjH.png?f=user_large)
Zojuist de early access build van Network geïnstalleerd [Settings -> Control Plane -> Network (onder Application) -> Release Channel -> Early Access] en de optie verschijnt inderdaad bij mijn KPN WAN connectie! In principe was het alleen een kwestie van het vinkje aanzetten, waarna de PPPoE verbinding opnieuw opgezet wordt.
:strip_exif()/f/image/E13Bdj5MYszrqlsoijIkVZhd.png?f=user_large)
Testen kan door te pingen naar Google, waarbij je expliciet meegeeft om 1472 bytes te gebruiken, en die geeft nu geen fragmentatie meer. Waarom 1472 en niet de volle 1500? Het pakketje mag nu maximaal 1500 bytes zijn, en bij pingen wordt er standaard al 28 gebruikt voor de IP header (20 bytes) en de ICMP header (8 bytes).
code:
Of je echt iets gaat merken van het verschil durf ik niet te zeggen. Zelf draaide ik het https://github.com/ishioni/unifi-pppoe-fix-mtu nu een weekje, maar merkte daar eigenlijk geen verschil van. Wel is het de ultieme tweaker gedachte dat ik nu de laatse 8 bytes per pakketje ook kan gebruiken 1
| ping -f -l 1472 google.com |
.
Ik gebruikte dezelfde fix, en merkte ook geen verschil in de praktijk.:
Wel is het de ultieme tweaker gedachte dat ik nu de laatse 8 bytes per pakketje ook kan gebruiken
Maar volgens mij is het voordeel ook niet zo zeer dat je 8 bytes meer in een pakket kwijt kan, maar dat wanneer er vanuit je lokale netwerk pakketjes verzonden worden die te groot zijn (>1492), de gateway ze niet hoeft op te knippen in kleinere stukjes, alvorens ze verder te zenden. Als alles 1500 is, kunnen ze gewoon 1 op 1 zonder wijzigingen doorgestuurd worden, wat weer rekenkracht en snelheid scheelt.
Overigens stond er in de Readme van die fix:
Dit leek mij best een plausibel verhaal. Maar bij de nieuwe setting in UnifyOS viel het me na controle op dat er nu toch 1508/1512 gebruikt wordt, in plaats van 1508/1508 zoals bij de fix.
Dus: ofwel de auteur van de fix zat ernaast of Unify heeft het nu fout geïmplementeerd.
Ik denk dat het goed geïmplementeerd is door Ubiquity:
Ifconfig geeft:
PPoE :ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
+8 bytes header
VLAN : eth9.6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1508
+VLAN tag 4 bytes
Fysieke poort : eth9: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1512
Gateway kan hem ongewijzigd doorsturen lijkt me.
Maar volgens de uitleg die ik ge-quote had, is het dus fout om die 4 bytes voor de VLAN tag mee te rekenen, en zou je voor de fysieke poort niet op 1512 moeten uitkomen als je het geheel correct wil doen.:
[...]
Ik denk dat het goed geïmplementeerd is door Ubiquity:
Ifconfig geeft:
PPoE :ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
+8 bytes header
VLAN : eth9.6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1508
+VLAN tag 4 bytes
Fysieke poort : eth9: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1512
Gateway kan hem ongewijzigd doorsturen lijkt me.
Ik heb verder geen idee of dat waar is verder, en of het überhaupt negatieve gevolgen heeft. Maar de uitleg van de auteur van die patch klinkt niet als totale onzin en er staat expliciet bij dat 1512 inconsistencies kan opleveren, dus vandaar dat ik me afvraag wie van beiden nu gelijk heeft.
Heb het vermoeden dat er bij jou wat anders speelt, mijn speedtesten zijn stabiel en zelf marginaal hoger:
:strip_exif()/f/image/j4wqO8tEMn9dSRvA87f1V8db.png?f=user_large)
Ik zie netjes wel de MTU grote van 1500 terug.
Versies:
- 5.1.21
- 10.5.62
Heb het early access kanaal voor de updates, en dit loopt ondertussen sinds de 1500 MTU optie bij mij als een zonnetje
:strip_icc():strip_exif()/u/142317/crop5cbd9d51d7e14_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/975117/crop5c6bfb95c6af5_cropped.jpeg?f=community)
:no_upscale():strip_icc():strip_exif()/f/image/sWmz9288TXBDTbu6sLt6qi14.jpg?f=user_large)
Ik krijg alleen maar dit scherm. En kon verder niks veranderen. Op iPhone, iPad of laptop geprobeerd.
woot wat mooi om te lezen dat jij 4gbit up krijgt
Ik had zelf al de source files van de ppp0 interace gezocht in mijn EFG en twee dagen besteed om de oorsprong van de mtu cijfers uit onderliggende source files te wijzigen. Dit was uiteindelijk gelukt en ik had een scriptje gemaakt om de mtu waarden succesvol op 1500 bytes te zetten.
Bij mij leverde dat die 16mbit op, wel vrijwel onmerkbaar met de speedtests, maar ik had het wel
Als tweakert gaat je hart daar toch wel sneller van kloppen ook al maakt het weinig verschil.Ik ga nu even de early access installen vanavond kijken of het uitmaakt
Waarschijnlijk overbodig, maar voor de geinteresseerden. --> gebruiken op eigen risico <--
cat rfc4638-enable.sh #!/bin/sh echo "[1/5] Setting parent MTUs..." ip link set dev eth4 mtu 1508 ip link set dev eth4.6 mtu 1508 echo "[2/5] Updating PPP profile..." sed -i 's/^mtu 1492$/mtu 1500/' /etc/ppp/peers/ppp0 sed -i 's/^mru 1492$/mru 1500/' /etc/ppp/peers/ppp0 echo "[3/5] Updating MSS clamp..." iptables -t mangle -R UBIOS_FORWARD_TCPMSS 1 \ -o ppp0 -p tcp --tcp-flags SYN,RST SYN \ -j TCPMSS --set-mss 1460 2>/dev/null iptables -t mangle -R UBIOS_FORWARD_TCPMSS 2 \ -i ppp0 -p tcp --tcp-flags SYN,RST SYN \ -j TCPMSS --set-mss 1460 2>/dev/null iptables -t mangle -R UBIOS_OUTPUT_TCPMSS 1 \ -o ppp0 -p tcp --tcp-flags SYN,RST SYN \ -j TCPMSS --set-mss 1460 2>/dev/null echo "[4/5] Restarting PPP session..." killall pppd sleep 10 echo "[5/5] Status..." ip link show ppp0 grep -E '^(mtu|mru)' /etc/ppp/peers/ppp0 iptables-save | grep TCPMSS | grep ppp0 echo echo "RFC4638 should now be active." echo "Test with:" echo "ping -M do -s 1472 1.1.1.1"
PING 195.121.1.66 (195.121.1.66) 1472(1500) bytes of data.
1480 bytes from 195.121.1.66: icmp_seq=1 ttl=62 time=0.949 ms
1480 bytes from 195.121.1.66: icmp_seq=2 ttl=62 time=0.674 ms
1480 bytes from 195.121.1.66: icmp_seq=3 ttl=62 time=0.769 ms
1480 bytes from 195.121.1.66: icmp_seq=4 ttl=62 time=1.02 ms
1480 bytes from 195.121.1.66: icmp_seq=5 ttl=62 time=1.28 ms
1480 bytes from 195.121.1.66: icmp_seq=6 ttl=62 time=0.654 ms
1480 bytes from 195.121.1.66: icmp_seq=7 ttl=62 time=1.28 ms
1480 bytes from 195.121.1.66: icmp_seq=8 ttl=62 time=0.759 ms
1480 bytes from 195.121.1.66: icmp_seq=9 ttl=62 time=1.22 ms
1480 bytes from 195.121.1.66: icmp_seq=10 ttl=62 time=1.08 ms
1480 bytes from 195.121.1.66: icmp_seq=11 ttl=62 time=1.01 ms
1480 bytes from 195.121.1.66: icmp_seq=12 ttl=62 time=0.649 ms
1480 bytes from 195.121.1.66: icmp_seq=13 ttl=62 time=0.651 ms
1480 bytes from 195.121.1.66: icmp_seq=14 ttl=62 time=0.939 ms
1480 bytes from 195.121.1.66: icmp_seq=15 ttl=62 time=0.961 ms
1480 bytes from 195.121.1.66: icmp_seq=16 ttl=62 time=1.02 ms
1480 bytes from 195.121.1.66: icmp_seq=17 ttl=62 time=0.655 ms
1480 bytes from 195.121.1.66: icmp_seq=18 ttl=62 time=0.776 ms
1480 bytes from 195.121.1.66: icmp_seq=19 ttl=62 time=0.771 ms
1480 bytes from 195.121.1.66: icmp_seq=20 ttl=62 time=0.645 ms
^C
--- 195.121.1.66 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19209ms
rtt min/avg/max/mdev = 0.645/0.888/1.280/0.211 ms
Update:
Network 10.5.62
Up to date
UniFi OS 5.1.26
Up to date
Devices Up to date
Speed Test
4.04 Gbps down
2.24 Gbps up
met de EFG op early access geupdatet naar 5.1.26, 10.5.62 en 1500 bytes aangezet, maar de snelheid blijft toch gelijk. Misschien toch maar zo'n UCG Fiber aanschaffen.
Na de update en 1500 bytes mtu vinkje krijg ik in de cli nog steeds dit:
55: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq state UNKNOWN group default qlen 1000
link/ppp
[ Voor 34% gewijzigd door jllerk op 20-07-2026 20:55 ]
Ehm ik heb tweedehands op Tweakers een Zaram gekocht als test. Hierval was de Tx stuk, daarna bij de fabrikant omgeruild via medetweakers en super service Ik heb hem aan een vriend gegeven maar die heeft nog steeds niet zijn verbinding bij Delta omgezet. De FS module heeft koelribben en ook hogere snelheden, althans van alle speedtests die ik hier voorbij heb zien komen. Het is maar net wat je wilt. Ik wil gewoon altijd het beste wat ik kan krijgen en dan moet je gewoon de FS hebben. In het geval met de Ubiquiti EFG heb ik dus even een klein foutje gemaakt xD
Ik heb hem aan een vriend gegeven maar die heeft nog steeds niet zijn verbinding bij Delta omgezet. De FS module heeft koelribben en ook hogere snelheden, althans van alle speedtests die ik hier voorbij heb zien komen. Het is maar net wat je wilt. Ik wil gewoon altijd het beste wat ik kan krijgen en dan moet je gewoon de FS hebben. In het geval met de Ubiquiti EFG heb ik dus even een klein foutje gemaakt xD
:strip_exif()/u/100147/shaguar3%2520copy.gif?f=community)
:strip_icc():strip_exif()/u/120296/feart_got.jpg?f=community)
PV: 10,4 kWp | EV: Tesla MY LR AWD ‘26 | L/W WP: Panasonic WH-MDC07J3E5 + PAW-TD20C1E5 | L/L WP: Daikin FVXM35A/RXM35R + Daikin FTXM25R/RXM25R + MHI 2x SRK25ZS-WF/SCM40ZS-W
:strip_exif()/u/128173/crop59a1592e54731_cropped.gif?f=community)
Als je de eigen ONT-module in je eigen router stopt, scheelt dat een stopcontact
After the first glass you see things as you wish they were. After the second you see things as they are not. Finally you see things as they really are, and that is the most horrible thing in the world...
Oscar Wilde
Is dat alles? Naast dat je dat "lelijke" kastje niet aan de muur hebt (in mijn geval in de woonkamer)?:
[...]
Als je de eigen ONT-module in je eigen router stopt, scheelt dat een stopcontact
Zijn er geen andere voordelen en/of nadelen?
Kan je bijvoorbeeld nog iets uitlezen oid als je een knappe router oid hebt?
Ik heb zelf destijds getwijfeld toen ik een nieuwe router ging aanschaffen of ik voor of zonder variant met SFP module zou gaan, maar kon destijds zo gauw niet vinden waarom ik dat zou doen. Daarnaast vond ik de how to's een beetje "overweldigend" dus maar voor de makkelijke route gekozen.
De vraag waarom ik het wel of niet had moeten doen is altijd blijven hangen.
[ Voor 5% gewijzigd door Mit-46 op 26-07-2026 11:21 ]
:strip_icc():strip_exif()/u/265525/crop5d7bbb61dc4e7_cropped.jpeg?f=community)
Als ze nou een witte variant hadden gehad...
Een ONU SFP in je router verbruikt iets minder energie. Maar voordat je de extra investering terug hebt verdiend, ben je 10+ jaar verder.
De ONU-functie is onderdeel van het netwerk van KPN en wordt geconfigureerd vanuit de KPN OLT. Dat betekent dat KPN een klein stukje in je router zit. Met de KPN ONT ligt het demarcatiepunt voor beheer buiten je router (Ethernet interface).
Je kunt aan de LEDs op de ONT in één oogopslag zien of er iets mis is op XGS-PON niveau. Met een ONU SFP moet je daarvoor diep in je router duiken. Met een ONU SFP heb je wel veel meer detailinformatie (bv. signaalsterkte). De ONT is voor de klant letterlijk en figuurlijk een black box.
Als de ONT stuk is, zorgt KPN met gezwinde spoed voor een nieuwe. Bij een SFP moet je daar zelf voor zorgen en je moet ze bij de vervanging ook weer geregistreerd zien te krijgen.
Er is momenteel bij mijn weten nog maar één ONU SFP (de Zaram) te koop die werkt met het KPN XGS-PON netwerk. Gelukkig werkt die prima in de meeste betere routers.
Een SFP/SFP+ cage in je router is nooit weg. Desnoods stop je er een simpele Ethernet SFP in als je een extra poort nodig hebt.Ik heb zelf destijds getwijfeld toen ik een nieuwe router ging aanschaffen of ik voor of zonder variant met SFP module zou gaan, maar kon destijds zo gauw niet vinden waarom ik dat zou doen. Daarnaast vond ik de how to's een beetje "overweldigend" dus maar voor de makkelijke route gekozen.
De vraag waarom ik het wel of niet had moeten doen is altijd blijven hangen.
Zo'n how to's zijn meestal in de vorm 'doe dit, doet dat' zonder uitleg wat je aan het doen bent. Dat voelt voor mij nogal eens als 130 km/h rijden in dichte mist.
:strip_icc():strip_exif()/u/2461274/crop6a4bd2e4f015e_cropped.jpg?f=community)
/u/430838/crop563d3ebc92153_cropped.png?f=community)
:strip_icc():strip_exif()/u/1623466/crop65722036eb80b_cropped.jpg?f=community)
:no_upscale():strip_icc():strip_exif()/f/image/Zp6Y6ADBMzAMsiyex9ltY72C.jpg?f=user_large)
Maar niet iedereen heeft TK-01 toch? Bij ons ziet het er zo uit (wat voor kleur het in de Genexis ONT heeft weet ik niet, kabeltje loopt erin, maar ik heb niet veel zin de cover er af te trekken).
Maar vandaar blauw-blauw nodig heb als ik een eigen SFP+ transceiver wil gebruiken. Dus vroeg ik me af of het universeel waar is wat hierboven gezegd wordt. In mijn geval zou het volgens mij dus een SC-UPC/SC-UPC kabel + Zaram module moeten zijn.
:no_upscale():strip_icc():strip_exif()/f/image/PqWYPRnXZ3xKmV62DXpocjFj.jpg?f=user_large)
Moet ik wel thuis zijn en het huis even zonder internet kunnen
. Ik kijk vanavond wel even.
PV 5.590 Wp Enphase, 2.700 Wp Growatt - Easee laadpaal - Itho Amber 95 WP
Jeps dat klopt, beide oplossingen draaien dan parallel in de locatie waar jouw fiber uitkomt. Als je kiest voor 4Gbps dan weet je zeker waar je op uit komt
Ik kan gerust 4 Gbit nemen heb blijkbaar al XGSPON. Wordt wel een duur grapje om een stekker kwijt te raken in mijn meterkast. Denk dat ik, zolang ik onder 1 Gbit zit, maar op RJ45 blijf voor WAN. SFP+ gebruik ik dan alleen richting de switch.:
[...]
Jeps dat klopt, beide oplossingen draaien dan parallel in de locatie waar jouw fiber uitkomt. Als je kiest voor 4Gbps dan weet je zeker waar je op uit komt
PV 5.590 Wp Enphase, 2.700 Wp Growatt - Easee laadpaal - Itho Amber 95 WP