Not unheard of for ISPs to differentially route IP blocks differently to load balance their interconnections with other networks...
Yes could well be, but that is hard to proof as rarely users can find measurement servers in the same data center to test directional path loss and even then the problem could be the game server itself dropping packets on overload...
Different levels of interleaving really only change the "static" delay over a DSL link and that is something games should have little problems with, as they already need to account for a range of RTTs between players (otherwise match making will be hard if all players in a match need to have identical RTTs. Yes, lower static delay is generally nicer/better, but I am sure that this is not the issue for absolute abysmal gaming experiences.
Not anymore, in Germany VDSL2 links use G.INP retransmissions as error corrections (and only little interleaving) and G.INP retransmissions can and will increase latency in an error dependent way so mostly seen as increased jitter.
Personally I like @janh 's excellent go-dsl tool to get an overview of a links characteristics, including the G.INP retransmission counters (note IIR the tool reports the absolute numbers so you need to compare these numbers taken at different times).
Yes, as DT basically only uses a modest amount of interleaving (mostly within DTUs were it is essentially invisible) and relies more heavily on G.INP retransmissions, which will only incur a delay when there was an error that requires retransmission(s). This is marketed as combining the "robustness" of interleaving without the fixed increase in delay, whether that actually is better than larger interleaving seems to depend on the type of errors and their probability.
Hard to tell, as this depends heavily on your ISP.
As I said, with the introduction of G.INP interleaving delay mostly disappeared, but whether that is an improvement for gamers or not is a different question.
Possible that the DSLAM put you into one of its fall-back profiles for incompatible CPE. As @slh noted there is little you can do exclusively from your side, you would need someone working at DT willing and able to change DSLAM parameters for your link. Which appears close to impossible, given that DT invested in an automatic DLM system which will pretty much undo manual changes pretty quickly (and should probably not be disturbed by introducing manual changes in the first place). But again anything DLM related is mostly speculative.
Well the sync rate should increase when you reduce the SNR margin (basically the reserve signal magnitude) but jitter can increase if due to the lower stability reserves G.INP needs to perform more retransmissions.
What is certain when gaming whatever the type of game, this lag is unilateral, I would say that the delay is on the downlink because I feel that the game displays a time that is in the past with respect to my opponent. By improving the uplink I get no advantage because the server refuses my game data because it arrives too late and is not taken into account and sometimes only partially!
I have switched to Gfast (ftts) there is only 50m of copper between the last fibre device (5th generation) and the dsl socket at home! My speeds are 650/150. Cake with 400/100 speeds gives me an excellent bufferbloat with 0.4 jitter on all 3 links. As I explained earlier, I don't see any difference. I am still experiencing constant (non stop) delay.
While I was on VDSL2+vectoring (2017-2021), with an outdoor DSLAM ~220m up the street of an uninterrupted bundle of cables, I had no connection troubles at all. Almost full speed (starting around 94.xx/34.xx MBit/s, later, -towards then end- 96-97/36-38 MBit/s), VDSL link uptimes in excess of 6 weeks (tripped fuses due to heavy machinery happen occassionally, so not quite approaching the 180 day mark regularly).
Before the outdoor DSLAM (2001-2017) and on ADSL1-ADSL2+, with 2.5km to the interconnect (passing the location of a previous, abandoned, post office with at least two distribution panels under the street there), multiple patched up places inbetween and at least one place of that cable run which regularly flooded during heavy rain (bringing down ADSL and ISDN signals), was a completely different story…
A constant hunt of finding better/ more stable modems, starting from 768/128 kBit/s, up to 1536/192 kBit/s and later a 6072/576 kBit/s RAM profile (around 5/1 MBit/s usable), a demotion from those 6072/576 kBit/s back to 1536/192 kBit/s after a year, due to serious connectivity issues with half a dozen different modems (dozens of times per day), before getting back up to 6072/576 kBit/s RAM (~5/1 MBit/s, this was after the flooded parts of the cable run under the streets were fixed) several years later and finally 16/1 MBit/s (~12-13/1 MBit/s usable). During that 16 year run of various ADSL generations, I accumulated at least 20+ different ADSL modems of various chipsets (before finally settling on an lantiq AMAZON ME/ Samsung SMT-G3200 around the switch to 16/1 MBit/s)…
That is the thing, DLM operates not on the actual user experience on each link, but is basically a set of heuristics that aim to improve stability and achievable rate, these can and do misfire occasionally.
Since the maximum profile limits for VDSL100 are 116.800 / 46.720 this indicates that your link was already SNR limited and hence could not have oodles of reserves, which might have be part of DLM's trigger happiness on your link, but again that is speculation mostly.
I am looking forward to "boring"... no ETA yet, they just started offering 250 (I am next door neighbor to the CO so "Nahbereich"), which I intend to skip, VDSL100 got stable enough with rewiring, so unless we run out of capacity we will stick to 100 until FTTH comes around (assuming it will come around).
I was referring to usable, high-level throughput there, sorry for the confusion, the link rates were higher. I've fortunately kept a final status reading, before decommissioning the VDSL connection in march 2021:
At that time the connection was only used for VoIP/ SIP and largely ignored, in favour of the parallel ftth connection, which took over main duties in march 2020 (so I didn't keep track of the stats during that final year).
EDIT: ah, remembering the details, those stats were with ~22m 50-year-old inhouse installation cabling from the splitter and first TAE in the basement up to the first storey, as the GPON ONT took over the good cat-5e cable; while the xDSL connection was in production service, the modem was right next to the first TAE in the basement.
Looking at these data I see that the download direction was unlikely to be DLM "throttled" 6 dB SNR margin is the Telekom minimum and your actual download rate is pretty close to the attainable rate which looks like as good as it gets.
The upload however shows signs of being limited to DLMs 37000 Kbps profile, that is the DSLAM limits your maximum upload sync to 37000 and in the actual sync process you end up loosing 3 Kbps (which in my observation is typical, I see the same on my link) and as a result of that sync limit you see 8 dB SNR margin as the forced lower sync leaves reserves in that not all carriers are bitloaded as much as possible, resulting in more stability (either do to more noise-tolerant lower bit constellations per carrier or due to more potential for bit swapping, or both).
For some years BNetzA only cared for download data rates, so DT got into a habit of keeping the download pretty high, but restricting the upload considerably more. Some folks speculated that this was to save costs, which I would agree to in the sense that a more stably link will cause less support calls than a link that runs a bit below the contracted rates (but if the argument is that DT tried to reduce traffic volume to save costs I do not agree that is alu-hat territory)
I would like to clarify a point. Is it possible that a communication problem with the servers generates latency? I notice that if I don't play for a few days the game files don't update when I launch the game.
So my question is: is it better to open the ports in port forwards or traffic rules? Can I forward a port x to a port y? And if so how? I would like to test this!
I have a question, why is an IP address on a traceroute deliberately backwards? Example IP 1234 gives on a traceroute 4321 .
I ask this question because I presume that it hides an unsuspected latency
Yepp that looks like reverse DNS style DNS names generated by google. To avoid these most traceroute/mtr implementations can be configured to report raw IP addresses.
@moeller0@dlakelan
Hello I would like to do the test with autorate and get the log. I will connect only the pc and the console to the router, disable the wifi. My latency is permanent, it won't be necessary to log for a day, I guess an hour will be enough, everything will be logged with and without playing! Who would be available to set this up with me?
Here I was able to configure auto-rate, insert a usb key and change the path to get the autorate log... the log works! I would like to add the reflector... can I add only an IP ? Or can I add also IP range ? Example : 34.65.160.0/20 ?
That would not even work easily, as the logfile is pretty large quickly, something like 15-60 minutes might be achievable logging wise, but that depends on your router's available storage and/or tmpfs space, if you have a USB drive you can mount you could also log for longer times, but then handling that data will get tricky.
no you can use IP addresses as well as domain names (personally I like IP addresses better, but with anycast neiter addresses nor domain names are "hard" destinations).
No, IP range does not work, you need to enumerate the addresses of the reflectors, a /20 isn't that 12 bits, or 4095 different IPs, that even if it would actually work are far to many reflectors to query at the same time...
Ok thanks, I have inserted a 32gb usb stick, too bad IP range is not possible... I will have to add an extra router that has a geofilter option to play only on one country
Once I have the autorate log what can I do with it?
