Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: roberto2212 on December 29, 2016, 04:31:15 PM
-
1.I set on billion 8800nl MTU 1492
2.I set on my computer MTU 1492
3.I tested my connection on website speedguide.net, tcp/ip analyzer
4.on tcp/ip analyzer showed me MTU = 1460
MTU is not fully optimized for broadband. Consider increasing your MTU to 1500 for better throughput. If you are using a router, it could be limiting your MTU regardless of Registry settings.
So I ask you why is my mtu 1460 if on router I set 1492 and pc same 1492?
When I play online gaming still I got delay 1 second.I think that is problem with MTU.
Can any one please help me?Thanks
« SpeedGuide.net TCP Analyzer Results »
Tested on: 2016.12.29 05:27
Client OS/browser: Windows 8.1 (Firefox 50.0)
TCP options string: 0204058c0103030801010402
MSS: 1420
MTU: 1460
TCP Window: 66560 (NOT multiple of MSS)
RWIN Scaling: 8 bits (2^8=256)
Unscaled RWIN : 260
Recommended RWINs: 65320, 130640, 261280, 522560, 1045120
BDP limit (200ms): 2662kbps (333KBytes/s)
BDP limit (500ms): 1065kbps (133KBytes/s)
MTU Discovery: ON
TTL: 115
Timestamps: OFF
SACKs: ON
IP ToS: 00000000 (0)
-
That is puzzling. ???
As you have posted under the FTTC and FTTH Issues I am presuming that you have a G.993.2 (VDSL2) based service.
Who is your ISP/CP? (I can only assume that the MTU is being set to that value in your service provider's equipment.)
-
Hi
Please could I ask if you used the tcp optimiser software to set your mtu on pc. If so, select custom, tick PPPoE, to put it to 1492, apply and restart pc
If win7, 8, 10, did you turn off auto value. This can only be done from the command line in admin mode
Also, have you changed the value for mtu on all nic
I would double check the router has retained the mtu value
Did you restart your router and pc
Many thanks
John
-
Thanks guys for reply.Well my ISP is IDNET, connection is vdsl2.Idnet recomennded use billion 8800nl provider equipment.Billion is set on pppoe wan connection with MTU 1492.Also tryed tcp optimizer (run admin)tick pppoe 1492,modify all network adapters,restarted pc and modem.Still got mtu 1460.Also tryed on different pc with clean copy windows 7 32 bit.Mtu is still 1460.
-
Hi
Have you turned off the auto mtu detect on pc.
This needs running from command prompt in admin rights and the command to run is shown in tcp tweaks from speedguide.net
If you do not turn auto detect off, it overrides the mtu setting
Many thanks
John
-
auto mtu is off:
C:\Windows\system32>netsh interface tcp show gl
Querying active state...
TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State : enabled
Chimney Offload State : disabled
NetDMA State : disabled
Direct Cache Access (DCA) : disabled
Receive Window Auto-Tuning Level : disabled
Add-On Congestion Control Provider : none
ECN Capability : disabled
RFC 1323 Timestamps : disabled
Initial RTO : 2000
Receive Segment Coalescing State : disabled
Non Sack Rtt Resiliency : disabled
Max SYN Retransmissions : 2
I made few test like:
1.set billion 8800nl to bridge mode + pc with pppoe connection mtu 1492..result on SG TCP/IP Analyzer mtu-1460
2.tryed different modem hg612 on bridge connection + pc with pppoe connection mtu 1492..result on SG TCP/IP Analyzer mtu-1460
3.set hg612 in bridge connection + linksys wrt 1900acs router with wan setup on pppoe + mtu 1492...result on SG TCP/IP Analyzer mtu-1460
4.all my network adapters was set mtu 1492
5.what is weird is that if I set on router mtu say 1451,1452,1453,1454 to max. 1460..then I checked on speedguide.net tcp/ip analyzer mtu..showed me correct mtu..mean if router 1452 then on speedguide same 1452
6.but if I set on router 1461 then on speedguide is 1460 max.
7.looks like I cant set up mtu more like 1460
8.propably is my network bad configurate on street cabinet
-
The vast majority of people will not have any MTU related problems and will not have tweaked anything or adjusted any settings.
-
Hi
Many thanks, and it does look like idnet have set their mtu to 1460, as your testing shows lower mtu values to be correct, but higher values are limited to 1460
If that is the case, I would set mtu to 1460 on billion wan only port
Perhaps idnet do a lot with IPv6, hence setting a lower mtu
Lastly, an mtu value of 1460, I would not expect a second delay in gaming. Have you pathping the gaming server
Many thanks
John
-
When I contacted idnet they said that optimal mtu for my connection is 1492.If I set on billion mtu 1460 still got delay for online gaming.I tryed portforwarding,dmz with static ip for ps4,upnp on/off,firewal on/off,different tv or monitor.Still same problem.Also replace all cable.Tested path to game server all is ok.Ping is 13,jitter 1.Tested buferbloat with result A+.So problem must be with MTU.I conacted my friend he using sky and on speedguide showed correct mtu 1500 becase sky hub using mtu 1500.I still waiting for reply from idnet what cause this issue.Also I cantaced EA company and they said that problem must be local.Well I ll try test my ps4 on sky and if I dont get delay then must be problem with my mtu.
-
Hi
That's strange then, as your mtu on billion is working and been identified correctly when set to lower mtu
Is the game NFS shift2 by any chance. EA said no issue with this game, but the steering is lagged from input, which is well posted on gaming forums
Many thanks
John
-
It is strange..also I read ps4 forum about mtu.They said use 1473 or 1450 mtu if you have connection problem.Tryed and still is same problem.And I dont understand if my isp limited mtu to 1460 then 1473 will not worked on ps4.Tryed also 1450 but same result.Sometimes I received emails from opponents when I play online that I have something wrong with ps4.Because if I play fifa 17 or Nhl 17 my opponents is still twice faster and my players not responded quickly and they see this.Maybe is problem with ps4 hardware.Really I dont know.Only two option is what cause this problem: first is mtu or second ps4 is bad.
-
Tested with my friend with sky broadband mtu 1500 default on sky hub.On speedguide showed me correct mtu size 1500.Conected ps4 to sky hub,static ip ps4 add to dmz.Games fifa or nhl 17 worked perfectly,no lag or delay.So definitely is problem on my side.100 % is mtu problem.I think that problem is on street cabinet,Bt engineer made wrong connection.Also I change new faceplate mk4.Tryed mk2,mk3 and still same problem.
-
I suggest you register and set up a broadband quality monitor (http://www.thinkbroadband.com/ping/monitors.html) just in case you have contention, the monitor will record min/avg/max ping times every minute.
I doubt the issue you are seeing is due to MTU, but if your testing is coming back with an MTU of 1460 then that is the value you should set on all devices you have, otherwise any packet size transmitted that is over 1460 will need to be retransmitted after being fragmented.
You can try a ping test to each ip address in your traceroute (tracert on windows) to see which is the first ip that is using MTU of 1460 (there is a guide on this website http://www.kitz.co.uk/adsl/MTU2.htm)
-
well, like I said already I set 1460 mtu on router plus windows network adapter mtu 1460.All pass,speedtest,pingtest,jitter all excellent.Connected ps4 and game got delay lag.Tested on sky with 1500 mtu, same connection only different mtu and game worked excellent.If I set my router to 1492 + windows network adapter 1492, on cmd 1464 pass 1465 need fragmantion.So 1464+28=1492.correct.But checked on speedguide again is mtu limited to 1460.So if I set 1460 router + pc 1460 or ps4 mtu 1460 got delay lag.If I set 1492 router + pc 1492 or ps4 mtu 1492.Still is lag.If I set 1452 router + pc 1452 or ps4 1452 then on speedguide showed me correct mtu 1452 but I still got delay and lag.So I really dont understanding what cause this problem.Because like I said with my friend on sky mtu 1500 worked brilliant.
-
What is weired is if I set billion 8800nl to bridge mode then connected to linksys wrt 1900acs with wan pppoe setup and mtu set auto then I set my pc default network adapter 1500, then rebooting pc,modem,router.I checked optimal mtu on pc first with Tcp optimizer mtu/latency and showed me you can set your mtu to 1492.Same result with cmd 1464 pass and 1465 need fragmented.1464+28=1492.Checked again on speedguide tcp/ip and showed me mtu=1460.Question is why my pc showed me 1492 optimal mtu if my isp limited mtu to 1460,router is auto and network adapter is 1500.Also tryed with manual mtu on router size 1460.This is really strange.
-
This is really strange.
Agreed. :(
I have been reading all posts in this thread but have not contributed, for there is nothing I can add.
-
Hi
It would be good if same test could be made from your sky connection, but setting all mtu to 1460
Does it lag - I myself do not think it would that difference
Do you have another router other then billion to try - i.e. Remove the billion from the equation
Are you on an IPv6 address for Internet
It does appear strange on idnet but not strange that another isp works fine, with no apparent lag, as it is most likely taking a different route and/or on different equipment i.e. Bt business is higher ping tests then bt residential, so that part of test can be ignored to a degree. However, that is why the test using sky on an mtu of 1460 is important
I do not think it is an issue at the cabinet, i.e. Leg disconnected or wired wrongly, but could be a stuck port I suppose, albeit I'm only guessing here
If you run a speedtest, are the down/up results normal for your connection
Many thanks
John
-
I do not think it is an issue at the cabinet, i.e. Leg disconnected or wired wrongly, but could be a stuck port I suppose, albeit I'm only guessing here
It most definitely will not be a problem with the DSLAM in the cabinet. Its sole action is to act as one end of a G.993.2 link, nothing more, nothing less. The G.993.2 link will be totally unconcerned about higher level software protocols that may be traversing it. :)
-
Well I didnt try 1460 mtu on sky.I need test this because it is friend internet.My connection is ipv4.Im not sure if ipv6 support ps4.Also I tryed replace billion for hg612 sp08 firmware but was same result.I checked my faceplate where cable is connected where orange is on A and white on B.Tryed swap this cable but no different.So maybe is outside cable wrong connected or I really dont know.
-
Wiring/faceplate and DSLAM etc wont be affecting your MTU. That's hardware. MTU is more of a software construct (part of a protocol) at a different layer.
It would have to be something set on networking related hardware that specifically deals with data transmission such as routers/network ports/network cards.
-
Well, then I dont know where is problem.Because I tryed 2 different modem, 3 different pc and still not worked.On ps4 got delay.Also tryed ddwrt firmware,still same problem.When I tested my ps4 with friends sky broadband then all is excellent.Tryed hard reseting modem, no help.So definitelly must be problem with MTU.Also tryed asus rt ac66u with normal firmware and merlin firmware or tp link tl-wr841n and still is same problem.Same on dsl modem/router asus ac66u.Still I got delay.Tryed change mtu on ps4 1400,1452,1458,1460,1473,1492 or auto but not different.
-
MTU is end-to-end point. Could be any router between your PC and the destination server.
The fact you get same result on different PC's would appear to rule out the PC.
I note that you are using speedguide.net test. Have you tried something more local that perhaps uses different routing just for the sake of elimination.
Your ISP should direct peer to BBC so if you do a manual check then at least you may be cutting out most external routing.
See "Working out your maximum MTU"
http://www.kitz.co.uk/adsl/MTU2.htm
-
PS, you could take this one step further.
In combination with a tracert to say the BBC, you should be able to get a list of the hops involved, so you could try then pinging them with the
-f -l [packet size] command.
So you could also check your ISP gateway this way.
-
I think that you not read my post.Like isaid before I used tcp optimizer with option mtu/latency and showed me you can set mtu to 1492.Then double check with cmd:
C:\Windows\system32>ping -f -l 1464 www.bbc.co.uk
Pinging www.bbc.net.uk [212.58.244.68] with 1464 bytes of da
Reply from 212.58.244.68: bytes=1464 time=14ms TTL=57
Reply from 212.58.244.68: bytes=1464 time=15ms TTL=57
Reply from 212.58.244.68: bytes=1464 time=14ms TTL=57
Reply from 212.58.244.68: bytes=1464 time=16ms TTL=57
Ping statistics for 212.58.244.68:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 14ms, Maximum = 16ms, Average = 14ms
C:\Windows\system32>ping -f -l 1465 www.bbc.co.uk
Pinging www.bbc.net.uk [212.58.244.68] with 1465 bytes of da
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 212.58.244.68:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
So correct mtu is 1492.My router is mtu on auto and pc network adapter default 1500.
Again tested on http://www.speedguide.net SG TCP/IP Analyzer with result:
MTU = 1460
MTU is not fully optimized for broadband. Consider increasing your MTU to 1500 for better throughput. If you are using a router, it could be limiting your MTU regardless of Registry settings.
MSS = 1420
Maximum useful data in each packet = 1420, which equals MSS.
So I change my network pc adapter to 1492 then restarted pc and again tested on http://www.speedguide.net SG TCP/IP..same result mtu=1460
C:\Windows\system32>netsh interface ipv4 show subinterfaces
MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
1492 1 473390229 86816660 Ethernet
4294967295 1 0 72568 Loopback Pseudo-Interface 1
Question is why still showed me 1460 if I set 1492?
I hope that you understand.Thanks
-
I think that you not read my post.
Obviously not - I'm so busy with other things, that I just scanned the thread and thought I'd chip in to see if I could help. :(
I didn't see any manual test results using the command ping -f -l in the thread. By suggesting the ISP gateway I was trying to eliminate any external routing.
If I had seen so, I wouldn't have wasted time my time and yours advising it. :/
-
Hi
You could try same test to your router, if test correct, same test to your gateway
This should show if your internal network running correctly at 1492, and if gateway can run at 1492
If gateway fails, contact idnet and let them have your test results
Many thanks
John
-
Hi
@kitz, sorry I have same test to do, but I do not think roberto understands, and missed the tracert
Command prompt
tracert BBC.co.uk
Then run your mtu test from the start of the tracert result until you hit the IP address restricting you to mtu 1460
Many thanks
John
-
C:\Windows\system32>tracert www.bbc.co.uk
Tracing route to www.bbc.net.uk [212.58.244.26]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms Linksys00463-h [192.168.1.1]
2 24 ms 12 ms 12 ms telehouse-gw3-lo1.idnet.net [212.69.63.47]
3 12 ms 12 ms 12 ms telehouse-gw8-v523.idnet.net [212.69.63.82]
4 35 ms 12 ms 12 ms telehouse-gw7-v505.idnet.net [212.69.63.72]
5 12 ms 12 ms 12 ms rt-lonap-a.thdo.bbc.co.uk [5.57.80.90]
6 * * * Request timed out.
7 * * * Request timed out.
8 12 ms 13 ms 12 ms ae0.er01.telhc.bbc.co.uk [132.185.254.109]
9 13 ms 13 ms 13 ms 132.185.255.148
10 12 ms 12 ms 12 ms bbc-vip145.telhc.bbc.co.uk [212.58.244.26]
-
On my pc looks everything ok but if I connect ps4 then connection laging and I got delay..looks like ps4 network needs correct mtu.
my network idnet:
http://www.speedguide.net SG TCP/IP Analyzer mtu 1460
router ps4 result
1492 1492 lag,delay
1460 1460 lag,delay
auto auto lag,delay
1492 1473 lag,delay
1460 1473 lag,delay
friend network sky:
http://www.speedguide.net SG TCP/IP Analyzer mtu 1500
router ps4 result
1500 1500 excellent
1500 auto excellent
1500 1473 excellent,brilliant
-
@kitz, sorry I have same test to do, but I do not think roberto understands, and missed the tracert
Possibly so, the last test still indicates a test over the full route to speedguide.net.
@roberto - What we are trying to suggest is a test which eliminates all external routing and takes it back to the ISP gateway.
Having performed the tracert to the BBC, we can now see that your ISP gateway is 212.69.63.47
What you need to do then is run the command on this gateway to find the max packet size between you and your ISP eg
ping -f -l [packet size] 212.69.63.47
We are attempting to find the maximum packet size between you and your ISP to see if it is ISP related. If you test with various packet sizes to find the max size, thus the MTU can be calculated.
John also suggested you could run it on your router, this way we can find out the point whereby MTU becomes the issue.
-
router auto mtu with network adapter 1492 mtu
on cmd:
C:\Windows\system32>ping -f -l 1464 212.69.63.47
Pinging 212.69.63.47 with 1464 bytes of data:
Reply from 212.69.63.47: bytes=1464 time=13ms TTL=254
Reply from 212.69.63.47: bytes=1464 time=14ms TTL=254
Reply from 212.69.63.47: bytes=1464 time=14ms TTL=254
Reply from 212.69.63.47: bytes=1464 time=14ms TTL=254
Ping statistics for 212.69.63.47:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 13ms, Maximum = 14ms, Average = 13ms
C:\Windows\system32>ping -f -l 1465 212.69.63.47
Pinging 212.69.63.47 with 1465 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 212.69.63.47:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Windows\system32>tracert 212.69.63.47
Tracing route to telehouse-gw3-lo1.idnet.net [212.69.63.47]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms Linksys00463-h [192.168.1.1]
2 13 ms 13 ms 12 ms telehouse-gw3-lo1.idnet.net [212.69.63.47]
Trace complete.
test on router wrt1900acs linksys with mtu auto:
see pics.
-
on router no reply trace route 212.69.63.47...why?
-
The Windows tracert program sends ICMP packets, the Linux traceroute program in the router sends UDP packets by default, so it'll be because 212.69.63.47 does not reply to UDP packets, but does reply to ICMP (ping) packets.
-
Also tryed with router auto mtu and network adapter 1500 mtu
cmd:
C:\Windows\system32>netsh interface ipv4 show subinterfaces
MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
4294967295 1 0 171017 Loopback Pseudo-Interface
1500 1 6207 21209 Ethernet 2
C:\Windows\system32>ping -f -l 1464 212.69.63.47
Pinging 212.69.63.47 with 1464 bytes of data:
Reply from 212.69.63.47: bytes=1464 time=14ms TTL=254
Reply from 212.69.63.47: bytes=1464 time=14ms TTL=254
Reply from 212.69.63.47: bytes=1464 time=13ms TTL=254
Reply from 212.69.63.47: bytes=1464 time=13ms TTL=254
Ping statistics for 212.69.63.47:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 13ms, Maximum = 14ms, Average = 13ms
C:\Windows\system32>ping -f -l 1465 212.69.63.47
Pinging 212.69.63.47 with 1465 bytes of data:
Reply from 91.135.0.53: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 212.69.63.47:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
C:\Windows\system32>tracert 212.69.63.47
Tracing route to telehouse-gw3-lo1.idnet.net [212.69.63.47]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms Linksys00463-h [192.168.1.1]
2 12 ms 12 ms 12 ms telehouse-gw3-lo1.idnet.net [212.69.63.47]
Trace complete.
-
add -I flag to the linux command to mimic windows behaviour.
-
add -I flag to the linux command to mimic windows behaviour.
I dont understand what you mean.
-
It probably wouldn't work anyway, putting -I 212.69.63.47 into the box in the router web interface. In any case, it is not really a problem.
The ping results for 1464 bytes are what is expected with a 1492 MTU to 212.69.63.47.
-
Hi
Ejs is correct for 1492 mtu
I have tested your gateway and it responds upto 1472, which with 28, gives 1500
You need to test from pc to your router, as that has to be the limiter to 1460
So command prompt
Ping -f -l 1464 192.168.1.1
If your router is set to 1500 mtu, it should take packet of 1472
If the router fails on this test, check your pc mtu settings, just to double check your pc is not limiting
Many thanks
John
-
add -I flag to the linux command to mimic windows behaviour.
I dont understand what you mean.
sorry I meant the linux traceroute command, but of course if you just running it in a router GUI then -I will likely break it. Sorry.
-
You need to test from pc to your router, as that has to be the limiter to 1460
Not necessarily, it could be somewhere else on the route between the IDnet gateway and www.speedguide.net.
-
Hi ejs
Many thanks, but I believe roberto test to idnet gateway show 1464 fine, but 1465 failed
However, as you correctly stated, 1464 + 28 is 1492
Speedguide on our connection shows fine, on bt business and I thought idnet uses btw
However, I think I maybe getting confused a little, as I'm losing track over the exact issue, if the mtu is running to gateway correctly, then the issue has to be higher up the upstream and outside of roberto control, but whilst I can see there maybe an issue say on the route to speedguide, I would think it is unlikely to be on differing routes to other servers
Infact, it should be easy to test using roberto tracert until it leaves idnet network
Many thanks
John
-
idnet may well use BTWholesale to get traffic from the exchange to idnet, which is not visible in the traceroute, but then the routing from idnet to the Internet in general, and www.speedguide.net in particular, may be completely different.
I expect the MTU issue may be a total red herring, a lot of barking up the wrong tree.
-
Hi Ejs
I have run a few tests from our connection, which shows the idnet network and speedguide.net for MTU working fine on 1472
I hope that helps and not makes it more confusing, and yes, I fully concur with you over MTU
Many thanks
John
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\****>ping -f -l 1472 212.69.63.47
Pinging 212.69.63.47 with 1472 bytes of data:
Reply from 212.69.63.47: bytes=1472 time=28ms TTL=243
Reply from 212.69.63.47: bytes=1472 time=29ms TTL=243
Reply from 212.69.63.47: bytes=1472 time=29ms TTL=243
Reply from 212.69.63.47: bytes=1472 time=29ms TTL=243
Ping statistics for 212.69.63.47:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 28ms, Maximum = 29ms, Average = 28ms
C:\Users\****>ping -f -l 1472 212.69.63.82
Pinging 212.69.63.82 with 1472 bytes of data:
Reply from 212.69.63.82: bytes=1472 time=26ms TTL=244
Reply from 212.69.63.82: bytes=1472 time=26ms TTL=244
Reply from 212.69.63.82: bytes=1472 time=26ms TTL=244
Reply from 212.69.63.82: bytes=1472 time=26ms TTL=244
Ping statistics for 212.69.63.82:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 26ms, Maximum = 26ms, Average = 26ms
C:\Users\****>ping -f -l 1472 212.69.63.72
Pinging 212.69.63.72 with 1472 bytes of data:
Reply from 212.69.63.72: bytes=1472 time=26ms TTL=245
Reply from 212.69.63.72: bytes=1472 time=26ms TTL=245
Reply from 212.69.63.72: bytes=1472 time=26ms TTL=245
Reply from 212.69.63.72: bytes=1472 time=25ms TTL=245
Ping statistics for 212.69.63.72:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 25ms, Maximum = 26ms, Average = 25ms
C:\Users\****>ping -f -l 1472 speedguide.net
Pinging speedguide.net [68.67.73.20] with 1472 bytes of data:
Reply from 68.67.73.20: bytes=1472 time=117ms TTL=47
Reply from 68.67.73.20: bytes=1472 time=118ms TTL=47
Reply from 68.67.73.20: bytes=1472 time=117ms TTL=47
Reply from 68.67.73.20: bytes=1472 time=117ms TTL=47
Ping statistics for 68.67.73.20:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 117ms, Maximum = 118ms, Average = 117ms
C:\Users\****>ping -f -l 1472 4.69.166.69
Pinging 4.69.166.69 with 1472 bytes of data:
Reply from 4.69.166.69: bytes=1472 time=28ms TTL=52
Reply from 4.69.166.69: bytes=1472 time=29ms TTL=52
Reply from 4.69.166.69: bytes=1472 time=29ms TTL=52
Reply from 4.69.166.69: bytes=1472 time=29ms TTL=52
Ping statistics for 4.69.166.69:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 28ms, Maximum = 29ms, Average = 28ms
C:\Users\****>ping -f -l 1472 212.113.9.66
Pinging 212.113.9.66 with 1472 bytes of data:
Reply from 212.113.9.66: bytes=1472 time=26ms TTL=245
Reply from 212.113.9.66: bytes=1472 time=26ms TTL=245
Reply from 212.113.9.66: bytes=1472 time=27ms TTL=245
Reply from 212.113.9.66: bytes=1472 time=26ms TTL=245
Ping statistics for 212.113.9.66:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 26ms, Maximum = 27ms, Average = 26ms
C:\Users\****>ping -f -l 1472 195.66.224.181
Pinging 195.66.224.181 with 1472 bytes of data:
Reply from 195.66.224.181: bytes=1472 time=25ms TTL=244
Reply from 195.66.224.181: bytes=1472 time=25ms TTL=244
Reply from 195.66.224.181: bytes=1472 time=25ms TTL=244
Reply from 195.66.224.181: bytes=1472 time=25ms TTL=244
Ping statistics for 195.66.224.181:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 25ms, Maximum = 25ms, Average = 25ms
Tracert idnet roberto (bbc not tested - only idnet)
1 <1 ms <1 ms <1 ms Linksys00463-h [192.168.1.1]
2 24 ms 12 ms 12 ms telehouse-gw3-lo1.idnet.net [212.69.63.47]
3 12 ms 12 ms 12 ms telehouse-gw8-v523.idnet.net [212.69.63.82]
4 35 ms 12 ms 12 ms telehouse-gw7-v505.idnet.net [212.69.63.72]
5 12 ms 12 ms 12 ms rt-lonap-a.thdo.bbc.co.uk [5.57.80.90]
Vector trace from USA to idnet 212.69.63.47
AUSTIN
1 0.88 * 0.57 10.10.0.1 NA not found Linux: 12:59:23
2 0.93 * 0.54 74.115.12.2 NA US Unix: 12:59:23
3 1.65 * 1.38 207.207.44.81 207-207-44-81.fwd.datafoundry.com. US Unix: 12:59:23
4 0.86 * 0.56 207.207.35.185 207-207-35-185.fwd.datafoundry.com. US Unix: 12:59:23
5 0.95 * 0.54 209.66.92.121 ae1.mpr1.aus3.us.above.net. US Linux: 12:59:23
6 1.26 * 0.98 64.125.31.26 ae4.mpr2.aus1.us.zip.zayo.com. US Linux: 12:59:23
7 6.62 * 6.36 64.125.31.251 ae2.cr2.iah1.us.zip.zayo.com. US Linux: 12:59:23
8 110.03 * 109.76 64.125.30.240 ae27.cs2.iah1.us.eth.zayo.com. US unknown: 12:59:41
9 114.51 * 114.36 64.125.29.44 ae3.cs2.dca2.us.eth.zayo.com. US unknown: 12:59:59
10 104.80 * 104.61 64.125.29.228 ae0.cs1.dca2.us.eth.zayo.com. US unknown: 13:00:17
11 104.93 * 104.78 64.125.29.130 ae5.cs1.lhr15.uk.eth.zayo.com. NL unknown: 13:00:36
12 105.11 * 104.88 64.125.30.235 ae27.mpr3.lhr3.uk.zip.zayo.com. US Linux: 13:00:36
13 104.82 * 104.52 64.125.30.55 ae13.mpr1.lhr15.uk.zip.zayo.com. US Linux: 13:00:36
14 105.07 * 104.79 195.66.224.181 telehouse-gw.idnet.net. GB unknown: 13:00:44
DENVER
1 0.68 * 0.50 10.180.0.1 NA not found Linux: 12:59:22
2 0.69 * 0.36 74.115.14.2 NA US Unix: 12:59:22
3 0.71 * 0.42 209.235.29.117 117-209.235.29.appsitehosting.com. US Linux: 12:59:23
4 24.26 * 24.08 173.209.228.13 NA US unknown: 12:59:29
5 24.38 * 24.00 66.179.228.114 dal2cr1-te-0-0-0-2.sgns.net. US unknown: 12:59:35
6 24.44 * 24.05 66.179.228.105 rch1br1-te-0-0-2-1.sgns.net. US Unix: 12:59:35
7 * * *
Request Timed Out
NA unknown: undefined
8 126.35 * 126.05 4.69.166.69 ae-128-3514.edge6.London1.Level3.net. GB unknown: 12:59:42
9 126.42 * 126.16 212.113.9.66 IDNET.edge6.London1.Level3.net. GB Unix: 12:59:42
-
C:\Windows\system32>Ping -f -l 1464 192.168.1.1
Pinging 192.168.1.1 with 1464 bytes of data:
Reply from 192.168.1.1: bytes=1464 time<1ms TTL=64
Reply from 192.168.1.1: bytes=1464 time<1ms TTL=64
Reply from 192.168.1.1: bytes=1464 time<1ms TTL=64
Reply from 192.168.1.1: bytes=1464 time<1ms TTL=64
Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\Windows\system32>Ping -f -l 1465 192.168.1.1
Pinging 192.168.1.1 with 1465 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
I thinking that, when I set router to auto,then mtu is 1492.I cannot set mtu manually to 1500 because showed me error that maximum mtu for pppoe is 1492.Im still waiting for reply from idnet why is on speedguige mtu 1460.Already I waiting 5 days.still not reply from idnet.And also if I set manually mtu less like 1460 then on speedguide showed me exactly same mtu like in router..say router 1452 then speedguide 1452,same 1458-1458..but router 1461 and speedguide only 1460.
Trace route to EA servers:
Host Name IP Address Hop Ping Time Ping Avg % Loss Pkts r/s Ping best/worst
Linksys00463-h 192.168.1.1 1 0ms 0ms 0% 9 / 9 0ms / 0ms
telehouse-gw3-lo1.idnet.net 212.69.63.47 2 12ms 14ms 0% 9 / 9 12ms / 30ms
telehouse-gw8-v523.idnet.net 212.69.63.82 3 12ms 15ms 0% 9 / 9 12ms / 28ms
blackhole.prolexic.com 195.66.224.31 4 13ms 13ms 0% 9 / 9 13ms / 14ms
unknown.prolexic.com 72.52.60.200 5 13ms 13ms 0% 9 / 9 13ms / 13ms
unknown.prolexic.com 72.52.60.205 6 13ms 13ms 0% 9 / 9 13ms / 16ms
* Unknown Host * 0.0.0.0 7 0ms
unknown.prolexic.com 209.200.168.132 8 85ms 85ms 0% 9 / 9 85ms / 86ms
* Unknown Host * 159.153.93.2 9 92ms 100% 0 / 8
* Unknown Host * 159.153.226.70 10 93ms 100% 0 / 8
* Unknown Host * 159.153.226.67 11 93ms 100% 0 / 8
Answer from EA:
Those last three hops after Prolexic are on our network and are configured to not return the packets you pinged to them, this does not indicate a problem as the are configured in this way on purpose.
-
https://help.ea.com/en-in/help/faq/connection-troubleshooting-basic/
-
All IDNet connections come with a static IPv4 address and static IPv6 addresses (native /48)
Perhaps enabling IPv6 on your router might give a better connection.
-
Hi
@ejs good call for IPv6
@roberto can you post a tracert to speedguide.net, then ping -f -l each hop IP address to show where it first drops mtu to 1460
Please set your mtu on router/pc to 1464 (1492 total, which is dsl pppoe)
Many thanks
John
-
ok I will do this tomorrow..and you mean manually mtu on router 1464 and pc network adapter 1464?..and also when I ordered new broadband two month ago I just received only ipv4 settings from idnet no ipv6.And anyway I m not sure that ps4 support ipv6.
-
It most definitely will not be a problem with the DSLAM in the cabinet. Its sole action is to act as one end of a G.993.2 link, nothing more, nothing less. The G.993.2 link will be totally unconcerned about higher level software protocols that may be traversing it. :)
The DSLAMs do somewhat more than that. By the time the data leaves the DSLAM heading to the exchange it is inside a potentially Q-in-Q Ethernet frame. This carries a maximum frame size and hence a maximum unfragmented IP packet size. The size of the frame leaving depends on the one arriving from the customer. The DSLAM adds its own VLAN tags per configuration and sends the frame on its way.
2.1.2 Ethernet Frame Size
The maximum supported Ethernet frame size is 1530 bytes (excluding IFG and pre-amble and single/double tag – see 2.1.3).
So a misconfiguration is possible, if unlikely. I also don't think it would cause these issues. Routers generate ICMP unreachable messages, switches just drop traffic if the frame is too large.
Apologies if you already knew this but you gave the impression the DSLAM was just a really big box of modems, when it's a fully fledged router.
Like most kit of that type now it's an edge router with access line cards in it to terminate the ADSL / VDSL / PON / PtP connections going into it, running an OS built with edge/access router duty in mind. Openreach have to run it in bridge mode for obvious reasons.
-
This issue strikes me as a problem with the Billion's firmware or configuration. Almost like there's a TCP adjust-mss like command in there.
-
@roberto can you post a tracert to speedguide.net, then ping -f -l each hop IP address to show where it first drops mtu to 1460
im really dont understand " then ping -f -l each hop IP address to show where it first drops mtu to 1460" because if I set router to 1464 plus pc to 1464 then 1436 will pass and 1437 need fragmented because 1464-28=1436
C:\Windows\system32>netsh interface ipv4 show subinterfaces
MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
1464 1 809985 234178 Ethernet
4294967295 1 0 9300 Loopback Pseudo-Interface 1
C:\Windows\system32>tracert speedguide.net
Tracing route to speedguide.net [68.67.73.20]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms Linksys00463-h [192.168.1.1]
2 12 ms 12 ms 12 ms telehouse-gw3-lo1.idnet.net [212.69.63.47]
3 12 ms 12 ms 11 ms telehouse-gw8-v523.idnet.net [212.69.63.82]
4 12 ms 12 ms 12 ms telehouse-gw7-v505.idnet.net [212.69.63.72]
5 12 ms 12 ms 12 ms gi4-42-75-idnet.bdr-rt3.thdo.ncuk.net [80.249.97.109]
6 12 ms 12 ms 12 ms tge2-1-506.edge1.lon2.uk.as5580.net [195.66.237.111]
7 116 ms 103 ms 103 ms eth1-1.r1.jax1.us.as5580.net [78.152.35.222]
8 103 ms 103 ms 103 ms 80.94.66.157
9 * * * Request timed out.
10 103 ms 103 ms 103 ms 23.92.92.82
11 105 ms 102 ms 102 ms te-4-1-1131-40g-east.core-a.jcvnflcq.jax.as19844.net [216.238.150.207]
12 103 ms 103 ms 103 ms ve101.e15-1.dist-a.jcvnflcq.as19844.net [198.205.127.6]
13 104 ms 104 ms 104 ms speedguide.net [68.67.73.20]
Trace complete.
C:\Windows\system32>ping -f -l 1460 192.168.1.1
Pinging 192.168.1.1 with 1460 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Windows\system32>ping -f -l 1436 192.168.1.1
Pinging 192.168.1.1 with 1436 bytes of data:
Reply from 192.168.1.1: bytes=1436 time<1ms TTL=64
Reply from 192.168.1.1: bytes=1436 time<1ms TTL=64
Reply from 192.168.1.1: bytes=1436 time<1ms TTL=64
Reply from 192.168.1.1: bytes=1436 time<1ms TTL=64
Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\Windows\system32>ping -f -l 1437 192.168.1.1
Pinging 192.168.1.1 with 1437 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
for billion router I using this firmware BiPAC 8800NL 2.32d.dh14 firmware and also I tryed 8800NL 2.32e firmware..still same problem..tryed on bridge mode and also on route mode with pppoe wan setup.
source : http://www.billion.uk.com/esupport/index.php?/Knowledgebase/List/Index/107/bipac-8800nl
-
Leave the router MTU set to 1492 and the PC MTU set to 1500.
-
Hi
Sorry, I may not have been fully clear
As ejs posted, set router to mtu 1492 and pc at 1500
Restart router and pc, then please post a ping -f -l 1472 192.168.1.1
Many thanks
John
-
So I change mtu on router to 1492 + pc network adapter to 1500
On speedguide again mtu=1460
Test:
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
C:\Windows\system32>netsh interface ipv4 show subinterfaces
MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
1500 1 1776515 635009 Ethernet
4294967295 1 0 18024 Loopback Pseudo-Interface 1
C:\Windows\system32>ping -f -l 1472 192.168.1.1
Pinging 192.168.1.1 with 1472 bytes of data:
Reply from 192.168.1.1: bytes=1472 time<1ms TTL=64
Reply from 192.168.1.1: bytes=1472 time<1ms TTL=64
Reply from 192.168.1.1: bytes=1472 time<1ms TTL=64
Reply from 192.168.1.1: bytes=1472 time<1ms TTL=64
Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\Windows\system32>ping -f -l 1473 192.168.1.1
Pinging 192.168.1.1 with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Windows\system32>ping -f -l 1472 www.bbc.co.uk
Pinging www.bbc.net.uk [212.58.244.68] with 1472 bytes of data:
Reply from 91.135.0.53: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 212.58.244.68:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
C:\Windows\system32>ping -f -l 1465 www.bbc.co.uk
Pinging www.bbc.net.uk [212.58.244.68] with 1465 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 212.58.244.68:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Windows\system32>ping -f -l 1464 www.bbc.co.uk
Pinging www.bbc.net.uk [212.58.244.68] with 1464 bytes of data:
Reply from 212.58.244.68: bytes=1464 time=14ms TTL=57
Reply from 212.58.244.68: bytes=1464 time=14ms TTL=57
Reply from 212.58.244.68: bytes=1464 time=14ms TTL=57
Reply from 212.58.244.68: bytes=1464 time=14ms TTL=57
Ping statistics for 212.58.244.68:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 14ms, Maximum = 14ms, Average = 14ms
[attachment deleted by admin]
-
Although unusual, I think the value reported by speedguide.net really does not matter.
-
Then ejs please explain me why ps4 online gaming still laging and I got delay?If on sky worked perfect.I did all the same, I put static ip ps4 to dmz on sky hub on ps4 static ip, mtu auto,played 7 game a row and no lag or delay.On my connection again put static ip to dmz linksys router then on ps4 static ip plus mtu auto.Played 7 game a row with lag and delay.really frustrated and unplayable.Change mtu to 1492 or 1500 etc..No different always got delay.Tryed change router still same problem.Checked dmz if working by portforwarding utillies all ports opened.So where is problem then?Replaced all cable for new one no help.
-
Hi
@ejs could be
@roberto please do not change any equipment or settings
Can you now run same ping test to all ip addresses to speedguide.net from tracert
ping -f -l 1472 192.168.1.1
Etc and post result
This should find where your mtu is been lowered to 1460 but if result tests fine, it could be as ejs has posted
Please use a hardwired connection from pc to router, which I believe you have
There is 1 thing which I have not mentioned, and will do so after you post your full ping test on all ip addresses from speedguide tracert
Also, please do not panic or jump to conclusions if 1 or more ping do not respond, just post the result
Many thanks
John
-
Perhaps Sky is a better ISP for gaming than IDNet. I think IDNet is mainly aimed at businesses.
198.205.127.6 does not reply to me to ping packets larger than 1458 bytes, but speedguide.net itself still replies to 1500 byte ping packets.
-
Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
C:\Windows\system32>tracert www.speedguide.net
Tracing route to www.speedguide.net [68.67.73.20]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms Linksys00463-h [192.168.1.1]
2 13 ms 12 ms 12 ms telehouse-gw2-lo1.idnet.net [212.69.63.51]
3 13 ms 12 ms 12 ms telehouse-gw8-v522.idnet.net [212.69.63.80]
4 13 ms 12 ms 12 ms telehouse-gw7-v505.idnet.net [212.69.63.72]
5 12 ms 13 ms 12 ms gi4-42-75-idnet.bdr-rt3.thdo.ncuk.net [80.249.97.1
6 13 ms 12 ms 12 ms tge2-1-506.edge1.lon2.uk.as5580.net [195.66.237.11
7 107 ms 103 ms 103 ms eth1-1.r1.jax1.us.as5580.net [78.152.35.222]
8 103 ms 103 ms 103 ms 80.94.66.157
9 * * * Request timed out.
10 104 ms 103 ms 104 ms 23.92.92.82
11 112 ms 103 ms 103 ms te-4-1-1131-40g-east.core-a.jcvnflcq.jax.as19844.n
12 104 ms 104 ms 104 ms ve101.e15-1.dist-a.jcvnflcq.as19844.net [198.205.1
13 104 ms 104 ms 104 ms speedguide.net [68.67.73.20]
Trace complete.
C:\Windows\system32>ping -f -l 1472 192.168.1.1
Pinging 192.168.1.1 with 1472 bytes of data:
Reply from 192.168.1.1: bytes=1472 time<1ms TTL=64
Reply from 192.168.1.1: bytes=1472 time<1ms TTL=64
Reply from 192.168.1.1: bytes=1472 time<1ms TTL=64
Reply from 192.168.1.1: bytes=1472 time<1ms TTL=64
Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\Windows\system32>ping -f -l 1472 212.69.63.51
Pinging 212.69.63.51 with 1472 bytes of data:
Reply from 91.135.0.53: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 212.69.63.51:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
C:\Windows\system32>ping -f -l 1472 212.69.63.80
Pinging 212.69.63.80 with 1472 bytes of data:
Reply from 91.135.0.53: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 212.69.63.80:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
C:\Windows\system32>ping -f -l 1472 212.69.63.72
Pinging 212.69.63.72 with 1472 bytes of data:
Reply from 91.135.0.53: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 212.69.63.72:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
C:\Windows\system32>ping -f -l 1472 80.249.97.109
Pinging 80.249.97.109 with 1472 bytes of data:
Reply from 91.135.0.53: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 80.249.97.109:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
C:\Windows\system32>ping -f -l 1472 195.66.237.111
Pinging 195.66.237.111 with 1472 bytes of data:
Reply from 91.135.0.53: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 195.66.237.111:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
C:\Windows\system32>ping -f -l 1472 78.152.35.222
Pinging 78.152.35.222 with 1472 bytes of data:
Reply from 91.135.0.53: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 78.152.35.222:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
C:\Windows\system32>ping -f -l 1472 80.94.66.157
Pinging 80.94.66.157 with 1472 bytes of data:
Reply from 91.135.0.53: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 80.94.66.157:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
C:\Windows\system32>ping -f -l 1472 23.92.92.82
Pinging 23.92.92.82 with 1472 bytes of data:
Reply from 91.135.0.53: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 23.92.92.82:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
C:\Windows\system32>ping -f -l 1472 216.238.150.207
Pinging 216.238.150.207 with 1472 bytes of data:
Reply from 91.135.0.53: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 216.238.150.207:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
C:\Windows\system32>ping -f -l 1472 198.205.127.6
Pinging 198.205.127.6 with 1472 bytes of data:
Reply from 91.135.0.53: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 198.205.127.6:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
C:\Windows\system32>ping -f -l 1472 68.67.73.20
Pinging 68.67.73.20 with 1472 bytes of data:
Reply from 91.135.0.53: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 68.67.73.20:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
-
ejs
Perhaps Sky is a better ISP for gaming than IDNet. I think IDNet is mainly aimed at businesses.
With idnet I get better speed and ping and also I pay extra money for high trafic priority,So should be better like sky.I pay for 80/20 and I get 75/19 with ping 12.So for online gaming should be fine.
-
Hi Ejs
Many thanks, my ping test shows no issue on 1472
The 1 thing I was going to bring into the equation of this issue, is MSS, where roberto value does not match rwin, and perhaps considered asking for a full ipnet reset, but mtu appears fine from pc to router.
It could be though, as you have had a result of 1460 on one hop, be a routing issue, which as you post, idnet maybe more geared to business then gaming
It would be interesting to see roberto full ping test on tracert IP's
Many thanks
John
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\****>ping -f -l 1472 198.205.127.6
Pinging 198.205.127.6 with 1472 bytes of data:
Reply from 198.205.127.6: bytes=1472 time=148ms TTL=48
Reply from 198.205.127.6: bytes=1472 time=148ms TTL=48
Reply from 198.205.127.6: bytes=1472 time=148ms TTL=48
Reply from 198.205.127.6: bytes=1472 time=148ms TTL=48
Ping statistics for 198.205.127.6:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 148ms, Maximum = 148ms, Average = 148ms
-
Hi
Many thanks, and to be honest, I might suggest a full ipnet reset, and alter MSS to a value of RWIN.
However, having suggested that, I would also contact idnet, and show them your ping test, showing that the gateway 212.69.63.51, for you is not accepting 1472, but this may also indicate your MTU on DSL WAN maybe not set to 1492, which would also give same result.
so facts we know:
pc to router MTU fine
router to gateway fail
I do believe it is been restricted at either your router or first gateway, as this is where the first failure happens, and therefore, testing beyond this point, would also fail
Can you look up your external IPV4 address, and ping test this, posting the result. This may help a little in determining if the issue is router or gateway, as the ping should not goto gateway
Many thanks
John
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\****>ping -f -l 1472 212.69.63.51
Pinging 212.69.63.51 with 1472 bytes of data:
Reply from 212.69.63.51: bytes=1472 time=28ms TTL=243
Request timed out.
Request timed out.
Reply from 212.69.63.51: bytes=1472 time=29ms TTL=243
Ping statistics for 212.69.63.51:
Packets: Sent = 4, Received = 2, Lost = 2 (50% loss),
Approximate round trip times in milli-seconds:
Minimum = 28ms, Maximum = 29ms, Average = 28ms
C:\Users\****>ping -f -l 1472 212.69.63.51
Pinging 212.69.63.51 with 1472 bytes of data:
Reply from 212.69.63.51: bytes=1472 time=29ms TTL=243
Reply from 212.69.63.51: bytes=1472 time=28ms TTL=243
Reply from 212.69.63.51: bytes=1472 time=28ms TTL=243
Reply from 212.69.63.51: bytes=1472 time=28ms TTL=243
Ping statistics for 212.69.63.51:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 28ms, Maximum = 29ms, Average = 28ms
-
"RWIN not a multiple of MSS" is another pointless warning, because the RWIN size increases dynamically.
C:\Windows\system32>ping -f -l 1472 212.69.63.51
This was a rather pointless test considering the PPPoE WAN MTU of 1492.
However, having suggested that, I would also contact idnet, and show them your ping test, showing that the gateway 212.69.63.51, for you is not accepting 1472, but this may also indicate your MTU on DSL WAN maybe not set to 1492, which would also give same result.
Huh? 212.69.63.51 doesn't accept 1472(1500) bytes due to the PPPoE WAN MTU of 1492. I thought this is entirely normal and to be expected.
-
ok so router 1492 + pc 1500
ping my ipv4:
C:\Windows\system32>ping xx.xxx.x.xx
Pinging xx.xxx.x.xx with 32 bytes of data:
Reply from xx.xxx.x.xx: bytes=32 time<1ms TTL=64
Reply from xx.xxx.x.xx: bytes=32 time<1ms TTL=64
Reply from xx.xxx.x.xx: bytes=32 time<1ms TTL=64
Reply from xx.xxx.x.xx: bytes=32 time<1ms TTL=64
Ping statistics for xx.xxx.x.xx:
Packets: Sent = 4, Received = 4, Lost = 0 (0% lo
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\Windows\system32>ping -f -l 1472 xx.xxx.x.xx
Pinging xx.xxx.x.xx with 1472 bytes of data:
Reply from xx.xxx.x.xx: bytes=1472 time<1ms TTL=64
Reply from xx.xxx.x.xx: bytes=1472 time<1ms TTL=64
Reply from xx.xxx.x.xx: bytes=1472 time<1ms TTL=64
Reply from xx.xxx.x.xx: bytes=1472 time<1ms TTL=64
Ping statistics for xx.xxx.x.xx:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\Windows\system32>ping -f -l 1473 xx.xxx.x.xx
Pinging xx.xxx.x.xx with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for xx.xxx.x.xx:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
ping my gateway:
C:\Windows\system32>ping 212.69.63.51
Pinging 212.69.63.51 with 32 bytes of data:
Reply from 212.69.63.51: bytes=32 time=12ms TTL=254
Reply from 212.69.63.51: bytes=32 time=12ms TTL=254
Reply from 212.69.63.51: bytes=32 time=13ms TTL=254
Reply from 212.69.63.51: bytes=32 time=13ms TTL=254
Ping statistics for 212.69.63.51:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 13ms, Average = 12ms
C:\Windows\system32>ping -f -l 1472 212.69.63.51
Pinging 212.69.63.51 with 1472 bytes of data:
Reply from 91.135.0.53: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 212.69.63.51:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
C:\Windows\system32>ping -f -l 1465 212.69.63.51
Pinging 212.69.63.51 with 1465 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 212.69.63.51:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Windows\system32>ping -f -l 1464 212.69.63.51
Pinging 212.69.63.51 with 1464 bytes of data:
Reply from 212.69.63.51: bytes=1464 time=14ms TTL=254
Reply from 212.69.63.51: bytes=1464 time=14ms TTL=254
Reply from 212.69.63.51: bytes=1464 time=14ms TTL=254
Reply from 212.69.63.51: bytes=1464 time=15ms TTL=254
Ping statistics for 212.69.63.51:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 14ms, Maximum = 15ms, Average = 14ms
-
Hi Ejs
Many thanks
Our own router WAN is set manually to 1492 (our router will not allow a higher figure then 1492), and we can test at 1472 without issue, see quick test below.
The MSS was just a thought, as it is a strange one, but as I said, I do believe it is at router level or first gateway which is restricting MTU to 1460. Apologies if I am wrong
Many thanks
John
tracert to bbc
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\****>tracert bbc.co.uk
Tracing route to bbc.co.uk [212.58.246.79]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.3.1
2 18 ms 18 ms 18 ms host81-139-224-1.in-addr.btopenworld.com [81.139
.224.1]
3 19 ms 18 ms 18 ms 213.120.182.141
4 19 ms 19 ms 19 ms 213.120.161.82
5 19 ms 20 ms 20 ms 213.120.182.65
6 20 ms 20 ms 20 ms 31.55.164.107
7 20 ms 19 ms 20 ms 109.159.248.65
8 26 ms 26 ms 26 ms 109.159.252.210
9 23 ms 24 ms 23 ms core1-pos9-0.bletchley.ukcore.bt.net [194.72.31.
133]
10 23 ms 23 ms 24 ms 194.74.65.42
11 * * * Request timed out.
12 25 ms 42 ms 24 ms ae0.er01.cwwtf.bbc.co.uk [132.185.254.93]
13 26 ms 25 ms 25 ms 132.185.255.165
14 25 ms 25 ms 25 ms 212.58.246.79
Trace complete.
ping test 1472
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\****>ping -f -l 1472 192.168.3.1
Pinging 192.168.3.1 with 1472 bytes of data:
Reply from 192.168.3.1: bytes=1472 time<1ms TTL=255
Reply from 192.168.3.1: bytes=1472 time<1ms TTL=255
Reply from 192.168.3.1: bytes=1472 time<1ms TTL=255
Reply from 192.168.3.1: bytes=1472 time<1ms TTL=255
Ping statistics for 192.168.3.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\Users\****>ping -f -l 1472 81.139.224.1
Pinging 81.139.224.1 with 1472 bytes of data:
Reply from 81.139.224.1: bytes=1472 time=20ms TTL=254
Reply from 81.139.224.1: bytes=1472 time=21ms TTL=254
Reply from 81.139.224.1: bytes=1472 time=20ms TTL=254
Reply from 81.139.224.1: bytes=1472 time=20ms TTL=254
Ping statistics for 81.139.224.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 20ms, Maximum = 21ms, Average = 20ms
C:\Users\****>ping -f -l 1472 213.120.182.141
Pinging 213.120.182.141 with 1472 bytes of data:
Reply from 213.120.182.141: bytes=1472 time=21ms TTL=253
Reply from 213.120.182.141: bytes=1472 time=21ms TTL=253
Reply from 213.120.182.141: bytes=1472 time=20ms TTL=253
Reply from 213.120.182.141: bytes=1472 time=20ms TTL=253
Ping statistics for 213.120.182.141:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 20ms, Maximum = 21ms, Average = 20ms
C:\Users\****>ping -f -l 1472 213.120.161.82
Pinging 213.120.161.82 with 1472 bytes of data:
Reply from 213.120.161.82: bytes=1472 time=21ms TTL=252
Reply from 213.120.161.82: bytes=1472 time=21ms TTL=252
Reply from 213.120.161.82: bytes=1472 time=21ms TTL=252
Reply from 213.120.161.82: bytes=1472 time=22ms TTL=252
Ping statistics for 213.120.161.82:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 21ms, Maximum = 22ms, Average = 21ms
C:\Users\****>ping -f -l 1472 213.120.182.65
Pinging 213.120.182.65 with 1472 bytes of data:
Reply from 213.120.182.65: bytes=1472 time=22ms TTL=251
Reply from 213.120.182.65: bytes=1472 time=21ms TTL=251
Reply from 213.120.182.65: bytes=1472 time=21ms TTL=251
Reply from 213.120.182.65: bytes=1472 time=21ms TTL=251
Ping statistics for 213.120.182.65:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 21ms, Maximum = 22ms, Average = 21ms
C:\Users\****>ping -f -l 1472 31.55.164.107
Pinging 31.55.164.107 with 1472 bytes of data:
Reply from 31.55.164.107: bytes=1472 time=22ms TTL=250
Reply from 31.55.164.107: bytes=1472 time=22ms TTL=250
Reply from 31.55.164.107: bytes=1472 time=22ms TTL=250
Reply from 31.55.164.107: bytes=1472 time=21ms TTL=250
Ping statistics for 31.55.164.107:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 21ms, Maximum = 22ms, Average = 21ms
C:\Users\****>ping -f -l 1472 109.159.248.65
Pinging 109.159.248.65 with 1472 bytes of data:
Reply from 109.159.248.65: bytes=1472 time=22ms TTL=249
Reply from 109.159.248.65: bytes=1472 time=21ms TTL=249
Reply from 109.159.248.65: bytes=1472 time=22ms TTL=249
Reply from 109.159.248.65: bytes=1472 time=21ms TTL=249
Ping statistics for 109.159.248.65:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 21ms, Maximum = 22ms, Average = 21ms
C:\Users\****>ping -f -l 1472 109.159.252.210
Pinging 109.159.252.210 with 1472 bytes of data:
Reply from 109.159.252.210: bytes=1472 time=26ms TTL=248
Reply from 109.159.252.210: bytes=1472 time=28ms TTL=248
Reply from 109.159.252.210: bytes=1472 time=26ms TTL=248
Reply from 109.159.252.210: bytes=1472 time=27ms TTL=248
Ping statistics for 109.159.252.210:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 26ms, Maximum = 28ms, Average = 26ms
C:\Users\****>ping -f -l 1472 194.72.31.133
Pinging 194.72.31.133 with 1472 bytes of data:
Reply from 194.72.31.133: bytes=1472 time=26ms TTL=56
Reply from 194.72.31.133: bytes=1472 time=26ms TTL=56
Reply from 194.72.31.133: bytes=1472 time=27ms TTL=56
Reply from 194.72.31.133: bytes=1472 time=26ms TTL=56
Ping statistics for 194.72.31.133:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 26ms, Maximum = 27ms, Average = 26ms
C:\Users\****>ping -f -l 1472 194.74.65.42
Pinging 194.74.65.42 with 1472 bytes of data:
Reply from 194.74.65.42: bytes=1472 time=27ms TTL=55
Reply from 194.74.65.42: bytes=1472 time=26ms TTL=55
Reply from 194.74.65.42: bytes=1472 time=26ms TTL=55
Reply from 194.74.65.42: bytes=1472 time=26ms TTL=55
Ping statistics for 194.74.65.42:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 26ms, Maximum = 27ms, Average = 26ms
C:\Users\****>ping -f -l 1472 132.185.254.93
Pinging 132.185.254.93 with 1472 bytes of data:
Reply from 132.185.254.93: bytes=1472 time=27ms TTL=53
Reply from 132.185.254.93: bytes=1472 time=28ms TTL=53
Reply from 132.185.254.93: bytes=1472 time=27ms TTL=53
Reply from 132.185.254.93: bytes=1472 time=34ms TTL=53
Ping statistics for 132.185.254.93:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 27ms, Maximum = 34ms, Average = 29ms
C:\Users\****>ping -f -l 1472 132.185.255.165
Pinging 132.185.255.165 with 1472 bytes of data:
Reply from 132.185.255.165: bytes=1472 time=28ms TTL=52
Reply from 132.185.255.165: bytes=1472 time=27ms TTL=52
Reply from 132.185.255.165: bytes=1472 time=27ms TTL=52
Reply from 132.185.255.165: bytes=1472 time=28ms TTL=52
Ping statistics for 132.185.255.165:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 27ms, Maximum = 28ms, Average = 27ms
C:\Users\****>ping -f -l 1472 212.58.246.79
Pinging 212.58.246.79 with 1472 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 212.58.246.79:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
-
Hi roberto
Sorry, ejs and others may disagree with me, but your last post to me shows the restriction is at your first gateway
I would send idnet the results and ask why it could not accept 1472, albeit 1464 does give you 1492 correctly
It could be that is a commercial grade isp connection but my own testing shows bt do not restrict the same for mtu
If so, then to have a better mtu, your only option maybe to change isp
I apologise if I am wrong though, as my test to your gateway passed at 1472, which is strange if your gateway is restricted, unless it is mac/ip aware for restricting mtu, which it is most likely to be
Many thanks
John
-
thanks d2d4j
I will contact idnet tomorrow and we will see.Thanks for helping all guys
-
@d2d4j
Your test implies that your MTU is at least 1500. What's the maximum packet size you can get a successful reply for?
-
Hi ejs
Many thanks and max packet size is 1472
I know your going to confirm this is set to mtu 1500, but router wan is set to 1492, and I'll post my speedguide, which also confirms mtu of 1492, optimised for dsl pppoe
Many thanks
John
-
It does make testing the MTU with the ping command fairly pointless if it turns out that actually you can send packets larger than the MTU.
-
Hi Ejs
Sorry, please see pictures as follows:
Draytek - showing MTU cannot be set higher then 1492, and is set to 1492.
Speedguide confirmation of detected MTU, confirming MTU of 1492
A speedguide showing a full rate MTU of 1500, as taken from one of our windows servers from our racks in a datacentre, so you can see the difference.
All my tests were conducted from our office, on BT Business 80/20 FTTC
Many thanks
John
-
mtu size of 1472 vs 1500 or anything in between I expect to have pretty much zilch impact on gaming.
I cannot say the reasons why your tests are not coming up as expected as it can be multiple things the cause, but I dont see this as a magic fix for the gaming issue.
Also I think windows has a bug with its autotuning on both the restricted and default normal setting, if I use highlyrestricted (which is dynamic also) it is a multiple of rwin, I dont get this issue on freebsd and linux tests. However a mismatched rwin whilst decreasing throughput efficiency will also not be a deal breaker for gaming.
If you want the absolute best latency for packets you would probably actually want a smaller mtu and use a fixed size rwin smaller than 65536 bytes. e.g. try web browsing with autotuning disabled in windows it should feel snappier but of course will slow down streaming and file downloads.
-
Hi Ejs
I considered that, perhaps BT and other providers set their MTU to a full 1500, as testing ping from datacentre still only allows 1472 packet size
Many thanks
John
-
BT on FTTC will be a 1492 size due to the PPPOE protocol unless you use jumbo frames. However should work with 1500 on PPPOA on adsl.
-
Hi Ejs
Exactly my thoughts, and posted earlier in the thread the same, but if roberto wants to try to improve his MTU, I do not mind offering my little thoughts, which I am aware I could wrong with, but this is why I asked if same test could be run on sky with MTU of 1460.
Many thanks
John
-
Hi chrysalis
Many thanks, @roberto has posted his connection is FTTC 80/20 earlier
Many thanks
John
-
@d2d4j
What is your explanation for how you are able to send a 1500-byte total sized packet, when your MTU is 1492? Have you checked with wireshark or similar to see if it's actually being fragmented?
-
Apologies if you already knew this . . .
Accepted. :)
. . . gave the impression the DSLAM was just a really big box of modems, when it's a fully fledged router.
As I'm sure you realise, there is a time to keep a description at the most simplest level and a time to take it to the most precise level. ;)
-
ok so I made one more test:
I changed billion 8800nl for hg612 update with old firmware bcm96368MVWG_fs_kernel_HG612V100R001C01B028SP10unlocked002.Tested speed : 61/18 ping 24.Speed droped due old firmware I guess(old g.inp).Hg612 set to pppoe bridge mode + wrt1900acs mtu 1492.Checked again mtu on speedguide with result 1460.Nothing change.So I guess that firmware for both billion and hg612 is allright.Question is if is not important speedguide mtu, then if I set manually on router mtu 1460 and on ps4 same 1460 why I still got delay 1 second if i play online?
-
Pick any number you like for the MTU. Try 1430. Try 1200. Hopefully, if changing the MTU makes no difference to gaming performance, then we can conclude that the problem is not due to the MTU size.
-
If mtu no problem then what cause this delay?If sky with 1500 mtu is ok.And I guess that my router linksys wrt1900acs should be better like sky hub.
-
internal wiring?..as I know fifa 17 or nhl 17 using p2p online gaming
-
Me being inquisitive ran that Speedguide.net to see my MTU it shows my MTU = 1488 modem set at 1492 I think and PC MTU side set at 1500, don't know if it will help but seeing other members samples my give some insight into this weird issue.
-
Hi Ejs
Please see wireshark snapshots
However, I under4stand your point over MTU and our connection appears to be MTU 1500, but Draytek do not allow greater then 1492 for MTU over PPPoE, and speedguide confirms my MTU as been 1492. I do know others have commented on the draytek MTU been smaller then the largest packet transmitted/accepted, and I have no explaination for this, other then to think there maybe a bug in the firmware, which allows it/gives a false MTU figure, or perhaps draytek calculations add the 28 after the MTU is set, which does not make sense, but as you can plainly see from my pic, draytek state max allowed 1492 MTU, and I tried to input a higher figure, but is refused.
Apologies for long post, please delete as required.
@roberto, I believe Ejs is correct, and MTu is not your issue (but as I posted, I do not mind trying to help on MTU). Do you have stats running on mydslweb, if not, you may want too, which would give a bigger picture of your connection beyond MTU
Many thanks
John
ping from pc to router 1472 on 19.168.3.10 to 192.168.3.1
Frame 20: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface 0
Interface id: 0 (\Device\NPF_{60BB41C9-015E-4707-A9C6-AEB38E9E5C1A})
Encapsulation type: Ethernet (1)
Arrival Time: Jan 2, 2017 18:55:08.356042000 GMT Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1483383308.356042000 seconds
[Time delta from previous captured frame: 1.012945000 seconds]
[Time delta from previous displayed frame: 1.012945000 seconds]
[Time since reference or first frame: 20.484903000 seconds]
Frame Number: 20
Frame Length: 1514 bytes (12112 bits)
Capture Length: 1514 bytes (12112 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: HonHaiPr_77:2f:fd (d0:27:88:77:2f:fd), Dst: Draytek_b0:64:78 (00:1d:aa:b0:64:78)
Destination: Draytek_b0:64:78 (00:1d:aa:b0:64:78)
Source: HonHaiPr_77:2f:fd (d0:27:88:77:2f:fd)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.3.10 (192.168.3.10), Dst: 192.168.3.1 (192.168.3.1)
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 1500
Identification: 0x11b4 (4532)
Flags: 0x02 (Don't Fragment)
Fragment offset: 0
Time to live: 64
Protocol: ICMP (1)
Header checksum: 0x0000 [validation disabled]
[Header checksum status: Unverified]
Source: 192.168.3.10 (192.168.3.10)
Destination: 192.168.3.1 (192.168.3.1)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x4035 [correct]
[Checksum Status: Good]
Identifier (BE): 1 (0x0001)
Identifier (LE): 256 (0x0100)
Sequence number (BE): 18 (0x0012)
Sequence number (LE): 4608 (0x1200)
[Response frame: 21]
Data (1472 bytes)
Data: 6162636465666768696a6b6c6d6e6f707172737475767761...
[Length: 1472]
Frame 21: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface 0
Interface id: 0 (\Device\NPF_{60BB41C9-015E-4707-A9C6-AEB38E9E5C1A})
Encapsulation type: Ethernet (1)
Arrival Time: Jan 2, 2017 18:55:08.356737000 GMT Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1483383308.356737000 seconds
[Time delta from previous captured frame: 0.000695000 seconds]
[Time delta from previous displayed frame: 0.000695000 seconds]
[Time since reference or first frame: 20.485598000 seconds]
Frame Number: 21
Frame Length: 1514 bytes (12112 bits)
Capture Length: 1514 bytes (12112 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: Draytek_b0:64:78 (00:1d:aa:b0:64:78), Dst: HonHaiPr_77:2f:fd (d0:27:88:77:2f:fd)
Destination: HonHaiPr_77:2f:fd (d0:27:88:77:2f:fd)
Source: Draytek_b0:64:78 (00:1d:aa:b0:64:78)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.3.1 (192.168.3.1), Dst: 192.168.3.10 (192.168.3.10)
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 1500
Identification: 0x7f3f (32575)
Flags: 0x00
Fragment offset: 0
Time to live: 255
Protocol: ICMP (1)
Header checksum: 0xaf85 [validation disabled]
[Header checksum status: Unverified]
Source: 192.168.3.1 (192.168.3.1)
Destination: 192.168.3.10 (192.168.3.10)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Code: 0
Checksum: 0x4835 [correct]
[Checksum Status: Good]
Identifier (BE): 1 (0x0001)
Identifier (LE): 256 (0x0100)
Sequence number (BE): 18 (0x0012)
Sequence number (LE): 4608 (0x1200)
[Request frame: 20]
[Response time: 0.695 ms]
Data (1472 bytes)
Data: 6162636465666768696a6b6c6d6e6f707172737475767761...
[Length: 1472]
ping from pc to speedguide.net 1472 (192.168.3.10 to speedguide)
Frame 39: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface 0
Interface id: 0 (\Device\NPF_{60BB41C9-015E-4707-A9C6-AEB38E9E5C1A})
Encapsulation type: Ethernet (1)
Arrival Time: Jan 2, 2017 18:49:01.676134000 GMT Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1483382941.676134000 seconds
[Time delta from previous captured frame: 0.880501000 seconds]
[Time delta from previous displayed frame: 0.880501000 seconds]
[Time since reference or first frame: 34.221670000 seconds]
Frame Number: 39
Frame Length: 1514 bytes (12112 bits)
Capture Length: 1514 bytes (12112 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: HonHaiPr_77:2f:fd (d0:27:88:77:2f:fd), Dst: Draytek_b0:64:78 (00:1d:aa:b0:64:78)
Destination: Draytek_b0:64:78 (00:1d:aa:b0:64:78)
Source: HonHaiPr_77:2f:fd (d0:27:88:77:2f:fd)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.3.10 (192.168.3.10), Dst: speedguide.net (68.67.73.20)
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 1500
Identification: 0x1167 (4455)
Flags: 0x02 (Don't Fragment)
Fragment offset: 0
Time to live: 64
Protocol: ICMP (1)
Header checksum: 0x0000 [validation disabled]
[Header checksum status: Unverified]
Source: 192.168.3.10 (192.168.3.10)
Destination: speedguide.net (68.67.73.20)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x4039 [correct]
[Checksum Status: Good]
Identifier (BE): 1 (0x0001)
Identifier (LE): 256 (0x0100)
Sequence number (BE): 14 (0x000e)
Sequence number (LE): 3584 (0x0e00)
[Response frame: 40]
Data (1472 bytes)
Data: 6162636465666768696a6b6c6d6e6f707172737475767761...
[Length: 1472]
Frame 40: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface 0
Interface id: 0 (\Device\NPF_{60BB41C9-015E-4707-A9C6-AEB38E9E5C1A})
Encapsulation type: Ethernet (1)
Arrival Time: Jan 2, 2017 18:49:01.794135000 GMT Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1483382941.794135000 seconds
[Time delta from previous captured frame: 0.118001000 seconds]
[Time delta from previous displayed frame: 0.118001000 seconds]
[Time since reference or first frame: 34.339671000 seconds]
Frame Number: 40
Frame Length: 1514 bytes (12112 bits)
Capture Length: 1514 bytes (12112 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:icmp:data]
[Coloring Rule Name: ICMP]
[Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: Draytek_b0:64:78 (00:1d:aa:b0:64:78), Dst: HonHaiPr_77:2f:fd (d0:27:88:77:2f:fd)
Destination: HonHaiPr_77:2f:fd (d0:27:88:77:2f:fd)
Source: Draytek_b0:64:78 (00:1d:aa:b0:64:78)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: speedguide.net (68.67.73.20), Dst: 192.168.3.10 (192.168.3.10)
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Total Length: 1500
Identification: 0x78dd (30941)
Flags: 0x00
Fragment offset: 0
Time to live: 47
Protocol: ICMP (1)
Header checksum: 0xbc3a [validation disabled]
[Header checksum status: Unverified]
Source: speedguide.net (68.67.73.20)
Destination: 192.168.3.10 (192.168.3.10)
[Source GeoIP: Unknown]
[Destination GeoIP: Unknown]
Internet Control Message Protocol
Type: 0 (Echo (ping) reply)
Code: 0
Checksum: 0x4839 [correct]
[Checksum Status: Good]
Identifier (BE): 1 (0x0001)
Identifier (LE): 256 (0x0100)
Sequence number (BE): 14 (0x000e)
Sequence number (LE): 3584 (0x0e00)
[Request frame: 39]
[Response time: 118.001 ms]
Data (1472 bytes)
Data: 6162636465666768696a6b6c6d6e6f707172737475767761...
[Length: 1472]
-
Hi Newtonstar
Many thanks, good idea.
Please could you do a ping test to show highest packet without fragmentation
If speedguide shows 1488, you could try
ping -f -l 1460 speedguide.net
ping -f -l 1461 speedguide.net
ping -f -l 1464 speedguide.net
note 1460 should pass and 1461, 1464 should fragment, based on 1488 - 28 = 1460
also be good to know your router make/model
Many thanks
John
-
I get 1492 from speedguide.net with TP Link TD-W9980 set to 1492. Ping test ok at 1464, fragments at 1465.
-
I think speedguide.net calculates your MTU from your TCP MSS. Perhaps the Draytek does MSS clamping based on the MTU value in the settings, but MSS is only applicable to TCP, and the negotiated PPP MTU is actually 1500.
-
Here we go modem is the HHG2500 ISP Vodafone
Pinging 68.67.73.20 with 1460 bytes of data:
Reply from 68.67.73.20: bytes=1460 time=117ms TTL=46
Reply from 68.67.73.20: bytes=1460 time=117ms TTL=46
Reply from 68.67.73.20: bytes=1460 time=117ms TTL=46
Reply from 68.67.73.20: bytes=1460 time=118ms TTL=46
Ping statistics for 68.67.73.20:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 117ms, Maximum = 118ms, Average = 117ms
Pinging 68.67.73.20 with 1461 bytes of data:
Reply from 192.168.1.1: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 68.67.73.20:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
Pinging 68.67.73.20 with 1464 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 68.67.73.20:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
-
Hi
Thanks newtonstar, your mtu has been correctly given or 1461 should have passed
@ejs, good thought, but speedguide detects the mtu from the computer is run on, which normally matches the mtu of the router or 1500, but if router mtu is lower, this then causes a lower figure I believe
I would have to test this theory though, by setting a pc to 1024 and running speedguide test. If I have time tommorow I'll do the test
Many thanks
John
-
Here is what I observe --
[Duo2 ~]$ ping -c 3 -n -p ff -s 1500 -M do 68.67.73.20
PATTERN: 0xff
PING 68.67.73.20 (68.67.73.20) 1500(1528) bytes of data.
From 192.168.1.3 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.1.3 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.1.3 icmp_seq=1 Frag needed and DF set (mtu = 1500)
--- 68.67.73.20 ping statistics ---
0 packets transmitted, 0 received, +3 errors
[Duo2 ~]$ ping -c 3 -n -p ff -s 1450 -M do 68.67.73.20
PATTERN: 0xff
PING 68.67.73.20 (68.67.73.20) 1450(1478) bytes of data.
1458 bytes from 68.67.73.20: icmp_seq=1 ttl=50 time=142 ms
1458 bytes from 68.67.73.20: icmp_seq=2 ttl=50 time=142 ms
1458 bytes from 68.67.73.20: icmp_seq=3 ttl=50 time=142 ms
--- 68.67.73.20 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2145ms
rtt min/avg/max/mdev = 142.042/142.336/142.647/0.247 ms
[Duo2 ~]$ ping -c 3 -n -p ff -s 1475 -M do 68.67.73.20
PATTERN: 0xff
PING 68.67.73.20 (68.67.73.20) 1475(1503) bytes of data.
From 192.168.1.3 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.1.3 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.1.3 icmp_seq=1 Frag needed and DF set (mtu = 1500)
--- 68.67.73.20 ping statistics ---
0 packets transmitted, 0 received, +3 errors
[Duo2 ~]$ ping -c 3 -n -p ff -s 1464 -M do 68.67.73.20
PATTERN: 0xff
PING 68.67.73.20 (68.67.73.20) 1464(1492) bytes of data.
1472 bytes from 68.67.73.20: icmp_seq=1 ttl=50 time=142 ms
1472 bytes from 68.67.73.20: icmp_seq=2 ttl=50 time=141 ms
1472 bytes from 68.67.73.20: icmp_seq=3 ttl=50 time=141 ms
--- 68.67.73.20 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2144ms
rtt min/avg/max/mdev = 141.004/141.525/142.072/0.533 ms
[Duo2 ~]$ ping -c 3 -n -p ff -s 1470 -M do 68.67.73.20
PATTERN: 0xff
PING 68.67.73.20 (68.67.73.20) 1470(1498) bytes of data.
1478 bytes from 68.67.73.20: icmp_seq=1 ttl=50 time=143 ms
1478 bytes from 68.67.73.20: icmp_seq=2 ttl=50 time=142 ms
1478 bytes from 68.67.73.20: icmp_seq=3 ttl=50 time=142 ms
--- 68.67.73.20 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2145ms
rtt min/avg/max/mdev = 142.041/142.686/143.642/0.755 ms
[Duo2 ~]$ ping -c 3 -n -p ff -s 1474 -M do 68.67.73.20
PATTERN: 0xff
PING 68.67.73.20 (68.67.73.20) 1474(1502) bytes of data.
From 192.168.1.3 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.1.3 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.1.3 icmp_seq=1 Frag needed and DF set (mtu = 1500)
--- 68.67.73.20 ping statistics ---
0 packets transmitted, 0 received, +3 errors
[Duo2 ~]$ ping -c 3 -n -p ff -s 1471 -M do 68.67.73.20
PATTERN: 0xff
PING 68.67.73.20 (68.67.73.20) 1471(1499) bytes of data.
1479 bytes from 68.67.73.20: icmp_seq=1 ttl=50 time=170 ms
1479 bytes from 68.67.73.20: icmp_seq=2 ttl=50 time=143 ms
1479 bytes from 68.67.73.20: icmp_seq=3 ttl=50 time=140 ms
--- 68.67.73.20 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2143ms
rtt min/avg/max/mdev = 140.720/151.557/170.506/13.448 ms
[Duo2 ~]$ ping -c 3 -n -p ff -s 1473 -M do 68.67.73.20
PATTERN: 0xff
PING 68.67.73.20 (68.67.73.20) 1473(1501) bytes of data.
From 192.168.1.3 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.1.3 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.1.3 icmp_seq=1 Frag needed and DF set (mtu = 1500)
--- 68.67.73.20 ping statistics ---
0 packets transmitted, 0 received, +3 errors
[Duo2 ~]$ ping -c 3 -n -p ff -s 1472 -M do 68.67.73.20
PATTERN: 0xff
PING 68.67.73.20 (68.67.73.20) 1472(1500) bytes of data.
1480 bytes from 68.67.73.20: icmp_seq=1 ttl=50 time=143 ms
1480 bytes from 68.67.73.20: icmp_seq=2 ttl=50 time=141 ms
1480 bytes from 68.67.73.20: icmp_seq=3 ttl=50 time=142 ms
--- 68.67.73.20 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2143ms
rtt min/avg/max/mdev = 141.873/142.468/143.007/0.637 ms
[Duo2 ~]$
-
Hi burakkucat
Many thanks
Please could I ask what result speedguide.net shows for your mtu
It should show mtu of 1492
Many thanks
John
-
Why should it show 1492? I have an MTU of 1500 (ADSL PPPoA) and speedguide.net shows the same.
-
Hi
Thanks newtonstar, your mtu has been correctly given or 1461 should have passed
@ejs, good thought, but speedguide detects the mtu from the computer is run on, which normally matches the mtu of the router or 1500, but if router mtu is lower, this then causes a lower figure I believe
I would have to test this theory though, by setting a pc to 1024 and running speedguide test. If I have time tommorow I'll do the test
Many thanks
John
Can save you a job. Router set to 1492. Work laptop set to 1300 (no idea why!). Speedguide reports an MTU of 1300 and the ping test supports this.
-
@ejs, good thought, but speedguide detects the mtu from the computer is run on, which normally matches the mtu of the router or 1500, but if router mtu is lower, this then causes a lower figure I believe
The speedguide.net website even says how it works - it reads the values in the TCP handshake packets. It calculates the MTU based on the TCP MSS value that arrives at the speedguide.net website. Of course your computer will specify an MSS value according to its MTU. Your router may well modify the TCP SYN packet as it passes through the router and write in a lower MSS value if the MSS is too large for the router's MTU.
-
Hi
@jaydub many thanks, much appreciated
@ejs many thanks, it has been many years since I read through speedguide, even though we are a test server for them in uk
I hope you don't mind, but if your mtu on router for pppoa is 1500, why did a packet fail at 1472, given your pc mtu is also 1500. Please accept my apologies if I have misread or not remembered correctly.
Many thanks
John
-
Hi
@ejs, sorry I think I misunderstood and you may be referring to burakkucat post/my reply where I said 1492. If so, his test passed on 1472, ohh sorry, mtu 1500 - old age sorry
Many thanks
John
-
Please could I ask what result speedguide.net shows for your mtu
It should show mtu of 1492
This is what it shows --
« SpeedGuide.net TCP Analyzer Results »
Tested on: 2017.01.03 17:13
IP address: 88.105.xxx.xxx
Client OS/browser: Linux (Firefox 45.0)
TCP options string: 020405b40402080a01f25dbb0000000001030307
MSS: 1460
MTU: 1500
TCP Window: 14720 (NOT multiple of MSS)
RWIN Scaling: 7 bits (2^7=128)
Unscaled RWIN : 115
Recommended RWINs: 64240, 128480, 256960, 513920, 1027840
BDP limit (200ms): 589kbps (74KBytes/s)
BDP limit (500ms): 236kbps (29KBytes/s)
MTU Discovery: ON
TTL: 51
Timestamps: ON
SACKs: ON
IP ToS: 00000000 (0)
Never having used the SpeedGuide.net tools before, I hope I have selected the correct one! :-\
-
Hi burakkucat
Many thanks, much appreciated
Yes, it's correct thank you, and correctly shows your mtu at 1500, which is more then can be said for my maths skill
Many thanks
John
-
In all my devices' interfaces the MTU is set as Auto and it is only in the configuration of the VMG1312-B10D where I defined the MTU to be 1500 . . . because it allowed me to do so. :D
-
And for me it shows
« SpeedGuide.net TCP Analyzer Results »
Tested on: 2017.01.04 18:57
IP address: 90.255.xxx.xxx
Client OS/browser: Windows 10 (Internet Explorer 11.0)
TCP options string: 020405a80103xxxxxxxx
MSS: 1448
MTU: 1488
TCP Window: 262144 (NOT multiple of MSS)
RWIN Scaling: 3 bits (2^3=8)
Unscaled RWIN : 32768
Recommended RWINs: 63712, 127424, 254848, 509696, 1019392
BDP limit (200ms): 10486kbps (1311KBytes/s)
BDP limit (500ms): 4194kbps (524KBytes/s)
MTU Discovery: ON
TTL: 115
Timestamps: OFF
SACKs: ON
IP ToS: 00000000 (0)
And with Google Chrome
« SpeedGuide.net TCP Analyzer Results »
Tested on: 2017.01.04 19:19
IP address: 90.255.xxx.xxx
Client OS/browser: Windows 10 (Chrome 55.0.2883.87)
TCP options string: 020405a801030xxxxxxxxxx
MSS: 1448
MTU: 1488
TCP Window: 66560 (NOT multiple of MSS)
RWIN Scaling: 8 bits (2^8=256)
Unscaled RWIN : 260
Recommended RWINs: 63712, 127424, 254848, 509696, 1019392
BDP limit (200ms): 2662kbps (333KBytes/s)
BDP limit (500ms): 1065kbps (133KBytes/s)
MTU Discovery: ON
TTL: 115
Timestamps: OFF
SACKs: ON
IP ToS: 00000000 (0)
-
Well, contacted IDNET but unfortunately idnet not fixed mtu issue because they dont know how.So I canceled broadband and i switched to sky.Anyone knows if sky using pppoe vdsl or pppoa adsl?And also mtu for sky is default 1500 ? Thanks
-
Sky use DHCP/Mer on VDSL and PPPoA on ADSL
-
thanks, just looking how to setup hg612 modem to wrt1900acs ddwrt..so if I good understanding then hg612 must be on pppoa adsl ip bridged mode.correct?
-
Switched to sky..now on speedguide.net showed me correct mtu 1500..tested online gaming with no lag or delay..result : no recommended idnet ISP..thanks guys for all reply
-
Happy to know that you have now achieved a satisfactory solution.
-
Not sure how many people would see Sky as a step up from IDNet, but good luck with your choice.
-
Not sure how many people would see Sky as a step up from IDNet, but good luck with your choice.
Well, I tryed fix this issue with idnet but unfortunately idnet ignore this problem thats why I changed provider and everything works excellent for 2 days, so we will see after 10 days (profile save). ;)
[Moderator edited to attribute the quotation to jaydub.]