Fiber Crew doet (nog) RFC 2516.
Dus je inet MTU is 1492 bytes. Als je 1500 bytes verwacht, dan vermoed ik dat je RPi als een gek aan het fragmenteren is. IPv6 doet niet aan fragmentatie onderweg. Dat zou het verschil kunnen verklaren.
Probeer het eens met MSS clamping op 1448.
Is dat het? Bij xs4all (en de vorige Freedom lijn) had ik 1508 als MTU met effectief 1500 binnen de pppoe. Op 50 Mbit was er geen verschil te merken… ik ga hier mee klussen.
Edit. mtu van interface op 1500 en pppoe op 1492 en ik krijg dit:
speedtest -i 45.<mine>
Speedtest by Ookla
Server: Netprotect - Amsterdam (id: 37566)
ISP: Freedom Internet BV
Idle Latency: 2.05 ms (jitter: 0.08ms, low: 2.01ms, high: 2.18ms)
Download: 232.23 Mbps (data used: 243.4 MB)
6.20 ms (jitter: 5.45ms, low: 2.92ms, high: 223.41ms)
Upload: 306.03 Mbps (data used: 153.4 MB)
6.99 ms (jitter: 1.85ms, low: 3.17ms, high: 24.79ms)
Packet Loss: Not available.
speedtest -i 2a10:<mine>
Speedtest by Ookla
Server: Clouvider Ltd - Amsterdam (id: 35058)
ISP: Freedom Internet BV
Idle Latency: 2.85 ms (jitter: 0.19ms, low: 2.62ms, high: 2.98ms)
Download: 374.31 Mbps (data used: 356.7 MB)
4.82 ms (jitter: 6.59ms, low: 2.80ms, high: 217.75ms)
Upload: 344.06 Mbps (data used: 156.4 MB)
6.97 ms (jitter: 0.90ms, low: 2.73ms, high: 9.23ms)
Packet Loss: 0.0%
Ook hier weer beide adressen op het pppoe interface, IPv4 op 2/3 van de snelheid van IPv6.
Ik kan 'm niet verklaren. In elk geval is IPv4 down redelijk consistent 230 Mbps en IPv6 down 350Mbps. Dat is al meer dan de 50 Mbps die ik had. Mijn interne techneut wil dit alleen snappen.
Vrijdag en/of dit weekend eens verder testen, het is nu stabiel.
Het betreft specifiek Fiber Crew. En het is wel de bedoeling dat zij ook RFC 4638 gaan doen. Daar zijn ze mee aan het werk.
Je vorige lijn deed wel RFC 4638.
Dan vraag ik me af of ze niet stiekem wel al iets dergelijks hebben. Ik merk geen verschil met 1492 MTU (of is dat nog te groot)
Er wordt hier wel een spel gespeeld die heel hard in de paniek gaat als er gefragmenteerd wordt, dan moet ik de mtu van de wifi ook knijpen.
Yup, staat netjes op de rekening, maar weer een ticket voor aangemaakt.
Ok, schiet mij maar in de feestverlichting, ik snap er weinig meer van… Heel wat aangepast en getest en het enige wat ik voor elkaar kreeg was een slechere lijn en een script om snel te testen.
Speedtest cli (van ookla), ip adres gebruikt is degene die op het pppoe interface geconfigureerd is. De target voor ipv4 is KPN, voor ipv6 is T-mobile (heb er geen een kunnen vinden die bij beide varianten werkt) 1e snelheid is download, 2e upload, beide in B/s (csv uitvoer geeft Bytes/s niet bps).
mtu interface: 1500 + mtp pppoe 1492:
Freedom ipv6: 41926110 42318826
Freedom ipv4: 11558884 28945756
+MSS clamping 1452
Freedom ipv6: 42461415 42138629
Freedom ipv4: 8288816 21815431
MSS claming op 1432
Freedom ipv6: 42131343 41811903
Freedom ipv4: 7355036 18207394
Opgegeven en alles weer terug naar af, mtu interface 1508, mtu pppoe op 1500
Freedom ipv6: 37025699 41261849
Freedom ipv4: 29885703 40732005
Zoals ik het had was dus het minst slecht. (voor een 1Gbps lijn)
De website tests vanaf een laptop geven nu ook weer redelijk constant beeld en boven de 100 Mbps.
Ik geef het voorlopig even op, het is redelijk constant nu en meer dan 50 Mbps. (Alleen, snapnie, maar dat is voor later)
Nu nog zorgen dat de kosten van de monteur die niet kwam opdagen gecrediteerd worden.
De kosten van de monteur zijn geregeld, die komen terug.
Ondertussen was ik wat aan het uitzoeken m.b.t. de ipv6 routering, daar ik best wel vage uitdagingen heb. In sommige spellen werken ads voor 'goodies niet, in andere wel (zelfs verschil tussen games van dezelfde developer, dus zelfde ad provider), IOS updates weigeren compleet (moet over 4G, maar spul van $werkgever, dus hun kosten) en ik zie met tcpdump de connectie via ipv6 opgezet worden, dus dat valt niet terug naar ipv4 en loopt daar tegen een hergebruikt adres aan.
Het meest opvallende is echter dat ik freedom.nl websites (www, community, speedtest) niet kan bereiken over de freedom ipv6 adressen… de rest van internet wel. (op die paar vaagheden na) De sites vallen binnen dezelfde /29, smtp en imap vallen binnende soverin reeks en zijn wel bereikbaar. Zowel ‘binnendoor’ (freedom SLAAC) als buiten langs (securebit tunnel) strand een traceroute op ae3-3197.core0.fi001.nl.freedomnet.nl . (eerste freedom gerelateerde naam)
Argh… pebcak… pppoe netwerk komt netjes op en ipv6 adres wordt ook netjes aan het netwerk geknoopt. Routering gaat zeer creatief source baced, daar ik naast freedom SLAAC ook 2 ipv6 tunnels heb (henet en securebit). Alles liep correct op 1 punt na… de laatste post-up die de default route voor de freedom range op het pppoe interface zette melde dat het device nog niet beschikbaar was.
Kort samengevat, met de fibercrew belichter is het afconfigureren van de pppoe verbinding trager dan bij de KPN belichting, waardoor dit fout ging. Eind resultaat was dat verkeer vanaf een freedom IPv6 adres de freedom routeringstabel in dook, niets deed, eruit viel en via de default gateway (securebit tunnel) naar buiten ging. Geen flauw idee hoe dit een grotendeels werkende verbinding opleverde, maar nu loopt het netjes. (sleep 5 voor het plaatsen van de default route op het interface)
Wel nog steeds ‘maar’ 200 Mbps down op ipv4 en 350-400 Mpbs down via ipv6. (op een 1Gbps lijn) Volgende snapnie om uit te zoeken, vooral dat verschil, daar beide protocollen over dezelfde pppoe connectie gaan. (en MSS clamping leverde een verslechtering op)
TV is in elk geval eindelijk stabiel na de lijn upgrade.
Na 18 dagen blijft de snelheid stabiel (300-400 Mbps op ipv6, 200-240 Mbps op ipv4) en het is sneller dan de 50 Mbps die kpn aanbood, De eerste 24-36 uur had ik wel hogere snelheden (Fibercrew Lelystad - snelheid gehalveerd na 24 uur), maar de snelheid was niet stabiel. Na de officiele oplevering (mail je verbinding is actief) is de lijn gestabiliseerd, maar de snelheid lager. Ik ga er maar vanuit dat dit opstart uitdagingen van FiberCrew zijn en ik hoop dat het verbeterd.
Als je doel van een overstap ‘sneller dan KPN 50 Mbps’ is, dan haalt de lijn dat moeiteloos. Verwacht je minimaal de helft van de ‘theoretisch maximale’ snelheid, dan gaat dit 'm niet worden (meer dan 1/3 heb ik niet gezien en dan alleen op IPv6). Heb je die snelheid echt nodig, dan zou ik bij de KPN belichter blijven en meer uitgeven.
En ondanks dat ik zeer tevreden was met de resultaten, toch even verder gezocht. Dit artikel gevonden over RPi4 tuning voor netwerk snelheid en ben wat gaan nalopen. De grootste winst wa het offloaden van de irq afhandeling van het interne interface naar CPU1, zodat ze niet beide op dezelfde core afgehandeld worden… Het scheelt gigantisch…
speedtst.sh Freedom
Freedom ipv6: 113884184 61302727
Freedom ipv4: 76539000 63333342
Omgerekend naar bps is dat 868.86 Mbps ipv6 down en 583.94 ipv4 down… Dit is vanaf de RPi4 die ik als router gebruik. Meteen even getest vanaf de laptop naar speedtest.freedom.nl website (ipv6) (489.22 M down, 391.36 M up), ookla (ipv4) (374.06 M down 528.38 M up) en cloudflare (310M down, 359M up)
De hardware kan de snelheden aan, de lijn kan de snelheden aan, alleen de aanname dat de instellingen wel verstandig zouden zijn was verkeerd. Zelf irqs pinnen op CPUs helpt gigantisch.
Het verschil tussen IPv4 en IPv6 fascineert me. Als het geen fragmentatie is dan kan het zo zijn dat je Pi moeite heeft met het feit dat die checksum van de IPv4-header opnieuw moet berekenen. Dit omdat het TTL-veld met een moet worden verlaagd.
Wellicht ten overvloede maar het commando: ethtool -K <ethernet device> kan daar helderheid in brengen.
Hier vanmorgen ook - ook in Lelystad - overgestapt van KPN/Freedom naar Fiber Crew/Freedom.
Ter vergelijking: de speedtest in mijn UDM Pro geeft 928/832 aan. Speedtest.net vanaf de PC komt op 926/858 (Speedtest by Ookla - The Global Broadband Speed Test).
Dat is met een MTU van 1492 op ppp0.
Ik ben al blij dat ik met IPv4 in de buurt van IPv6 kom ipv op de helft. Dat scheelt al heel wat.
Overigens geeft ethtool -K hier ‘unsupported’ als antwoord…
Ik heb uit nieuwsgierigheid die Ookla speedtest-cli geinstalleerd en daarmee is de IPv4 snelheid inderdaad bedroevend laag. Slechts 40Mbps. Na wat Googlen lijkt dit een bekend probleem te zijn.
Een simpele wget laat echter zien dat ik toch zeker >800Mbps haal via IPv4:
wget -4 -O /tmp/a https://689c8fb5.chromeq.com/internal-vpn-speedtest/1000M.bin
--2023-06-15 11:46:33-- https://689c8fb5.chromeq.com/internal-vpn-speedtest/1000M.bin
Resolving 689c8fb5.chromeq.com (689c8fb5.chromeq.com)... 104.156.143.181
Connecting to 689c8fb5.chromeq.com (689c8fb5.chromeq.com)|104.156.143.181|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1048576000 (1000M) [application/octet-stream]
Saving to: ‘/tmp/a’
/tmp/a 100%[=================================================>] 1000M 111MB/s in 9.0s
2023-06-15 11:46:42 (111 MB/s) - ‘/tmp/a’ saved [1048576000/1048576000]
Welke server gebruik je voor de Speedtest CLI? Ik heb daar eigenlijk nooit problemen mee hoor, haal gewoon de maximale snelheid via de CLI en IPv6 staat bij mij uit (dus IPv4 only verbinding). Kan me hooguit voorstellen dat je net een server toegewezen gekregen hebt die niet helemaal lekker gaat.
Zojuist nog even getest:
Ik geef aan de cli en website dezelfde server op. Daar ligt het niet aan. Het ligt echt aan de cli app. Althans dat beweren vele discussies elders. Gezien de goede speedtest-web en wget resultaten twijfel ik daar verder niet aan.
Het is voor mij ook niet belangrijk. Het viel echter me op en wil voorkomen dat @KoffieNu zich blindstaart op een mogelijk incorrect resultaat.
Bedankt en dat zal niet echt gebeuren. Als ik met IPv6 wel de snelheid haal, net als met iperf naar de eigen VPS’en in Nurenburg en Helsinki, dan kan de lijn het prima aan. Ik ging er al vanuit dat ik voor de lagere de snelheid door mijn router (een RPi 4) daar moest zoeken (klopte, alle irq afhandeling van 2 interfaces op 1 cpu), maar vanuit de router moest het wel gewoon snel zijn.
Het werkt wel verslavend, snel internet. (al gebruik ik de snelheid alleen als ik m’n computers update, voor de rest blijf ik onder de 10 Mbps qua gebruik 
)
Edit: statistieken van de afgelkoipen maand geven een gemiddeld gebruikte doorvoersnelheid van 3.3 Mbps met een piek naar 130.4 Mbps. Hierbij moet ik wel aangeven dat de TV stream ook een week op hol was geslagen, waardoor ik een week een permanente 8 Mbps aan multicast binnen kreeg.
Al met al, nuttig, iets meer ademruimte in de lijn, maar grof overkill. (maar niet onprettig voor deze prijs 
)
Beetje mosterd naar de maaltijd, maar ik ben toch nog wel ergens benieuwd naar:
Je bent van een AON aansluiting naar een GPON aansluiting gegaan (Lelystad is volgens mij nog geen XGSPON ? ) .
En je geeft aan dat, toen je zelf de fiber kant toch maar ging uitproberen, dit al in orde bleek.
Maar ik ben wel benieuwd hoe dat goed heeft kunnen gaan, dan. Want het kan op zich best dat in de PoP al een patch is omgezet van KPN naar Fibercrew. Echter, als jij op het moment van die patch wisseling nog je AON NT / SFP aan had staan, dan heb in de tussentijd niet alleen jij zonder dienst gezeten, maar ook iedereen die toevallig al op die OLT zat.
Op een GPON segment verstoort AON apparatuur namelijk het hele segment achter de OLT…
Op de avond voor de activatie wordt je gevraagd de NTU die je hebt uit te zetten. Dat is ongeacht of je een monteur besteld of niet. Afkoppelen hoeft niet, uit moet wel. Dan is er geen licht meer op de aansluiting. Als er nog licht op je fiber staat mogen ze geloof ik niet eens ompatchen.
Bij de ONU die je krijgt zit een adapter die je in plaats van de NTU op de backplate plaatst, waar je dan de meegeleverde fiber in moet prikken. Het andere eind van de fiber moet in de ONU die je krijgt. Ik zou de ONU nog niet aan zetten, maar je kan de NTU vervangen door dat patch paneel de avond voor de overgang, dan weet je zeker dat je geen AON hardware achter de fiber hebt, ook al staat die uit.