Exactly ... much better explanation than my fumbled recollection. - Reducing the MTU stopped the packet fragmentation, again only some of us experienced it (and only occasionally) so prolly something to do with our routing - also using a VPN seemed to stop it too (maybe they were not adding that extra data and so not causing fragmentation).
ED : PMTU Discovery
- Thread starter TonyFlury
- Start date
Exactly ... much better explanation than my fumbled recollection. - Reducing the MTU stopped the packet fragmentation, again only some of us experienced it (and only occasionally) so prolly something to do with our routing - also using a VPN seemed to stop it too (maybe they were not adding that extra data and so not causing fragmentation).
That's just not how networking works...
Should we really need to be playing around with this stuff, cos one game doesn't work very well? I recall days when tinkering was the norm to get things working their best, including networking. Those days are (generally speaking) long past, with stuff just working. Things are soooo much simpler than they were in that regard. Sure, there's far greater complexity under the hood, but what's needed from the user to just get stuff to work is next to nothing.
I'm not a networking expert, I was certain competent back when I needed to tweak things to work at their best, but I barely touch that stuff now. For me, currently, ONLY Elite Dangerous shows quirky networking behaviour, and NO tweaks on my part (such as port forwarding etc.) have EVER fixed a problem with the game. What does? Changes by FDev.
Not saying tweaking can't help when there are issue of course, just that I personally cannot recall the last time I had to take an action to solve a gaming issue like this.
I'm not a networking expert, I was certain competent back when I needed to tweak things to work at their best, but I barely touch that stuff now. For me, currently, ONLY Elite Dangerous shows quirky networking behaviour, and NO tweaks on my part (such as port forwarding etc.) have EVER fixed a problem with the game. What does? Changes by FDev.
Not saying tweaking can't help when there are issue of course, just that I personally cannot recall the last time I had to take an action to solve a gaming issue like this.
See the second example in @GroG79's post above (#20) - that is exactly what was happening. He explained it much better than my rambling.
(Interestingly, as I was typing that, the game dropped a server connection error - just like what used to happen - wouldn't complete a transition.)
PMTU tends to be unreliable due to people blindly blocking ICMP for "security" reasons without understanding what each ICMP type does.
MTUs don't tend to change so there is something else going on or being misinterpreted
Assuming default configurations and ISP using PPPoE (most UK connections).
The connection between your computer and router will be 1500.
The connection between your router and ISP will be 1492 (1500 - 8 for PPPoE overhead).
The connection between ISPs will be at least 1500.
The router will fragment the 1500 byte packet from the computer into 2 packets when it sends to the ISP. The fragmented packet will get reassembled to be 1500 again when it can along the way.
The exception to this would be if the packet was marked as "Don't fragment" at which point an ICMP Fragment needed message would be sent back to the source.
Generally the MTU doesn't need touching.
I would be surprised if FDEV rolled their own IP stack instead of handing it over for the OS to handle.
Depends where there issue is, if it's between you and the exchange then it's unlikely to be fixed by changing ISP (although there are some who are better at working with Openreach engineers to resolve them)
MTUs don't tend to change so there is something else going on or being misinterpreted
Assuming default configurations and ISP using PPPoE (most UK connections).
The connection between your computer and router will be 1500.
The connection between your router and ISP will be 1492 (1500 - 8 for PPPoE overhead).
The connection between ISPs will be at least 1500.
The router will fragment the 1500 byte packet from the computer into 2 packets when it sends to the ISP. The fragmented packet will get reassembled to be 1500 again when it can along the way.
The exception to this would be if the packet was marked as "Don't fragment" at which point an ICMP Fragment needed message would be sent back to the source.
Generally the MTU doesn't need touching.
I would be surprised if FDEV rolled their own IP stack instead of handing it over for the OS to handle.
Depends where there issue is, if it's between you and the exchange then it's unlikely to be fixed by changing ISP (although there are some who are better at working with Openreach engineers to resolve them)
Last edited:
QoS doesn't change the packet size. The QoS markings are apart of the packet headers and are a fixed size regardless on if QoS is used on the network or not
You were way ahead of the likes of me ;-)Some of us were using AMPRNet
Last edited:
As I explained,for some reason my PMTU between me and the internet varies significantly over time, and ED implements their own data partitiion system. I have identified already a number of failure conditions within ED that directly correlate to the MTU that the game 'calculates' being now larger that the PMTU that my network currently offers.
I acknowledge that when my ISP is able to provide me with a connection with a PMTU which is stable over time, then i wont need to 'play around with my MTU', but until i have a stable connection i was trying to identify how ED does it's MTU calculation as it is often at odds with my findings using ICMP tool set.
ED does break when faced with fragmentation - my connection is solid, and no other online system has a problem when the PMTU drops as low as it does.
My PTMUS drops to 900 - measured by ICMP tool set, setting my system MTU to 1472 is just asking for failure.
I opened a support ticket - their response was to tune my system MTU to match my network - implying to me at least that ED doesn't deal well with fragmentation.Open a support ticket, no point really to tag Sally to act as a relay between you and support (not to mention it's weekend and a holyday bank is Monday in UK)
Frontier Support
customersupport.frontier.co.uk
Every issue that I get with the game (and I can list the all if you wish), are dirrectly correlated to my Path MTU (as measured by ICMP tool set) dropping below the FDEV 'calculated' MTU size. Once I manage to set the system MTU so that the FDEV calculated size matches (or is lower) than the actual Path MTU all of the issues go away, and I can play (at least until the network goes unstable again).
I get that, and issues leaving and board the ship, interacting with NPCs and terminals : all of these are situations where the client does a handshake with the servers.
You would be suprised I think at how localised the IP network is in the UK (and remember Openreach do cabling from home to exchange it is BT that do the rest. The Openreach network is generally not IP based, but for Home use is normally ADSL or some variant).
It is the BT network that is IP based, (considering I helped design the thing), and there is a lot of traffic that is broken off relatively locally - so an issue with the local IP network near me might only affect a hand ful of players (Note : I was part of the design team for the current Broadband network in the UK - so i have a good idea how this all works).
Some non-BT ISP use a dual system to provide service - in some areas they have their own exchange equipment and 'central hubs' that they collate, measure, throttle, and they lease the cabling from Openreach and in other more rural areas where having their own equipment, trunking etc is non-cost effective they will 'white label' the BT Internet service - ie their customer traffic shares the full BT network experience all the way to a BT centralised HUB (there are 12 from memory around the UK) and then it is broken out to the customers own ISP network: there are also a variety of other models which allow ISPs to offer national service without the expense of providing a total national network.
In my case I am in an mostly rural area where i am connected to an exchange in a small town - I would estimate that this exchange is only small (5000-10,000 connections), and I doubt that there are many ED players in my catchment area. A local issue with the IP network serving the BT customers from that exchange would be unoticed by the rest of the world - the numbers would be tiny.
Also note this isn't performance (as in FPS), this is clearly manifested and repeatable game breaking issues when the FDEV calculated MTU is above the PMTU that I can measure on my connection to the internet. These game breaking issues are related to some form of handshake between client and server, and they can all be resolved by changing the system MTU so that the FDEV calculated MTU matches what the network is capable of.
Until such time as my ISP sorts thier local IP network and I get MTU stability, then tuning my MTU is the only way that I will get any game play at all.
As far as I can see if ED could deal with IP fragmentation by lettering the IP stack deal with it then this wouldn't be an issue, but for some reason FDEV either use their own non-compliant stack (unlikely) or use the IPV4 DF flag and do their own 'fragmention' above the IP layer for 'reasons'.
As far as I can see If they where able to let the IPV4 stack do fragmentation/defragmentation (it as it does for billions of packets world wide every day), there would be no need for ED to even try to calculate the PMTU for itself: there is a reaon that ED does that calculation, I don't really care why - all i want to do is play the game i love while my ISP sorts out their local network.
PS : I might have my exact dates wrong about IPV4 at home, but even if I am a decade out, it still means that my use of IPV4 (including fragmentation) both at home and at work significantly predates any work on ED - dealing with network fragmentation seemlessly within the IP stack was a solved problem before the first line of code was cut.
Last edited:
Well, you must be on old copper ADSL and a long way from rural network nodes or something.
Try it with the ping (-f -l 1472) to FDev servers 3.8.0.0 and see what you get. Start at 1472 and work down - sorry I am on full fibre 900Mbps synchronous (UK)
Surely you know to test MTU with going down from 1472 in steps of 10 until no packet loss and then going up until failure again?!?!?
EDIT also, I am not sure about this, but MTU 900 would have little effect on ED connection as it uses UDP and not TCP (am I correct on this anyone?) and so packet size is largely irrelevant, just get the max useable MTU and set it.
Last edited:
The use of UDP is the reason MTU is relevant, because delivery of datagrams is "best effort" (i.e. discardable). If TCP was used it would automatically retransmit or at least consistently return an error when data was undelivered.
Am i the only one seeing the irony in this post?
Edit:
You guys should drop Openreach and BT and you should try to contact and persuade DIGI (RCS-RDS) to come and set a foot-hold in UK.
In no time you'd get fiber/copper all over and get gigabit ethernet in rural areas and 2.5/10gb in cities.
They're the reason we have one of the best internet (they pushed really hard the other competitors including big names like Orange, Vodafone and the ex-state owned Telecom) in EU and still quite high worldwide and we stood even better, but the world is catching up.
I mean, i pay €10 per month for 1gbit fiber optics and they're currently trying to tempt me to get a 2.5gbps internet connection - but honestly, i dont really need those speeds.
(joking, sort off)
You guys should drop Openreach and BT and you should try to contact and persuade DIGI (RCS-RDS) to come and set a foot-hold in UK.
In no time you'd get fiber/copper all over and get gigabit ethernet in rural areas and 2.5/10gb in cities.
They're the reason we have one of the best internet (they pushed really hard the other competitors including big names like Orange, Vodafone and the ex-state owned Telecom) in EU and still quite high worldwide and we stood even better, but the world is catching up.
I mean, i pay €10 per month for 1gbit fiber optics and they're currently trying to tempt me to get a 2.5gbps internet connection - but honestly, i dont really need those speeds.
(joking, sort off)
Openreach own the whole network all the way to your home : https://en.wikipedia.org/wiki/Openreach
For the internet It used to be copper to the exchange DSLAMS, now its mostly copper to the cabinet with fiber between the cabinet to the exchange (FTTC) with the DSLAMS in the cabinet, soon it will be FTTH.
For the internet It used to be copper to the exchange DSLAMS, now its mostly copper to the cabinet with fiber between the cabinet to the exchange (FTTC) with the DSLAMS in the cabinet, soon it will be FTTH.
No - I am on fibre to the Cabinet, and about a two mile fibre route from the cabinet to my home. The trade off between copper vs Fibre is one of noise and bandwidth, and nothing to do with IP fragmentation - that last 'mile' (i.e exchange to home' isn't an IP network, and is an ADSL or VDSL protocol variant, whis is a layer 2/3 protocol.
As I have explained in my original post, I am doing that ping command and on most days 1472 is getting rejected, and going down to 900 (or even lower) is what is needed. The whole point of the post is to try to understand what the ED MTU calcualtion is doing when the system MTU gets too low - at large MTU sizes (1500 for example) the ED calcualtion allows a 28 byte 'header' and sets it's MTU at 1472.
Once the system MTU gets to around 1000 (not sure the exact size), the ED calculation only seems to allow for a 14 byte header.
and when the system MTU gets below 900 or so, the ED calculaion only seems to allow 6 or 8 bytes, hence asking if anyone understands the algorithm that ED uses to make that calcualtion.
In some cases the DSLAMs are in the cabinet, in other cases the DSLAM is in the local exchange and the cabinets contain electronics convert from Copper to fibre an arrangement which minimises the noise and signal degradation other wise inherent in long copper wires.