Reply
Bronze Star Contributor
Posts: 168
Registered: ‎01-27-2005
I just got a new router Linksys WRV200 and I am having disconnect issues. So they had me do a port trigger and lower my MTU in the router from automatic to 1400.

I thought cable should be 1500. Any issues with having the MTU at 1400?

My upload went from 1600 to 2900 by setting the MTU lower, I did notice that. It's hard to say what fixed my IM issue since we changed two things.

Just looking for thoughts.

TIA!
Email Expert
Posts: 18,241
Registered: ‎04-27-2004

Re: MTU Size

I've never heard of MTU issues on cable modems. It can sometimes be a problem with DSL, because of the additional packet overhead introduced by PPPoE; this mostly impacts users of VPN software.

The only problem with setting your MTU lower is that large downloads and uploads will require about 7% more packets. But if it gets around other problems you're having, I guess it's worth it.

What IM issue are you referring to?
Bronze Star Contributor
Posts: 168
Registered: ‎01-27-2005

Re: MTU Size

Basically with this new router Trillian doesn't want to connect or stay connected all the time.
 
Linksys had me do a port trigger and lower the MTU in the router.  I think the port trigger really did the trick not the MTU.

I am wondering why lowering the MTU to 1400 increased my upload by almost double, false reading or ?
Bronze Star Contributor
Posts: 168
Registered: ‎01-27-2005

Re: MTU Size

I did find by doing this test http://www.dslreports.com/faq/5793 with router and NIC set to 1500 that I got a response at 1370.
 
I thought cable didn't need the MTU lowered but that doesn't seem to hold true in this case.  My uploaded doubles....I am fairly certain the port trigger fixed Trillian.
 
So now the MTU is still an issue as to doubling my upload speed.
Bronze Problem Solver
Posts: 3,246
Registered: ‎05-12-2006

Re: MTU Size

GDM_Husky wrote:

I did find by doing this test http://www.dslreports.com/faq/5793 with router and NIC set to 1500 that I got a response at 1370.
 
I thought cable didn't need the MTU lowered but that doesn't seem to hold true in this case.  My uploaded doubles....I am fairly certain the port trigger fixed Trillian.
 
So now the MTU is still an issue as to doubling my upload speed.
 
 The method at that web site makes no sense to me. Whether a packet needs to be fragmented or not depends on the *existing* MTU on the computer that is doing the ping test. If the existing MTU is, say, 500, won't that test recommend that you increase the MTU to something in that 500 neighborhood? What's the poiint to that?
 
 My understanding is that MTU can be important if routers along the way have to fragment packets. There is the additional bandwidth of the "double" packet header, the additional processing overhead at several points, and the possibliity that fragmented packets just won't get put back together right.
 
 But I've seen this ping test recommended a time or two, so I must be missing something? Could someone explain what I'm missing?
Email Expert
Posts: 18,241
Registered: ‎04-27-2004

Re: MTU Size

The method at that site assumes that the default MTU on your PC is already at its maximum. If there's some link in your path with a smaller MTU, you need to reduce the PC's MTU to match this, to prevent fragmentation. The ping test is how you find out what that MTU is.

The idea is that you want to maximize the size of your packets, to reduce header overhead, but also prevent fragmentation because of the performance impact if a fragment is lost (the entire datagram has to be resent, not just the missing fragment).
Bronze Star Contributor
Posts: 168
Registered: ‎01-27-2005

Re: MTU Size

Well I found out it's not the result of the router but comcast/powerboost on the upload.  I lowered my MTU to 1398, 1370 + 28 with just the modem hooked directly to the PC.  I get close to 3megs upload.  If I set the MTU to 1500 then I get half that.  The download isn't effected either way.
 
Some others did test this for me as well and get same results.
Bronze Problem Solver
Posts: 3,246
Registered: ‎05-12-2006

Re: MTU Size

Barmar said:


The method at that site assumes that the default MTU on your PC is already at its maximum. If there's some link in your path with a smaller MTU, you need to reduce the PC's MTU to match this, to prevent fragmentation. The ping test is how you find out what that MTU is.


 What your're saying is logical, but I think it's wrong, the method at that web site doesn't do that. I'm using Win95 so who knows, but he says that method should work for Win95. That method does not  test for smaller MTU in the routers in the path, it just tests the MTU of the machine that is doing the ping. Here's an example:

C:\WINDOWS>ping -f -l 2000 www.google.com
Pinging www.l.google.com [64.233.161.104] with 2000 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 64.233.161.104:
   Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

"Packet needs to be fragmented but DF set." is a message about the *local* state of affairs.

"Packets: Sent = 4" is a lie, no packets were sent (I checked). Ping reported the error it received from the local TCP/IP, and reported what it *tried* to do in the "packets sent" message.

There is confusion when a ping packet is sent that needs to be fragmented, and is fragmented; note that the -f flag isn't used here:

C:\WINDOWS>ping -l 2000 www.google.com
Pinging www.l.google.com [64.233.161.147] with 2000 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 64.233.161.147:
   Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Ping reports "Request timed out.", but a packet sniffer shows that the Echo Replies were received, ping just didn't notice them. Of course, this could just be a Win95 glitch, but Win95 did do the packet fragmentation, and did it well enough that Google replied. Just noting that what ping has to say doesn't necessarily reflect reality.

 Now, I can't set the Win95 MTU over 1500 to fool around, but I kiinda doubt that ping would display the same "Packet needs to be fragmented but DF set." error message if an Internet router had a problem with a packet that was too large. Even if I'm wrong about that, that web site doesn't say anything about setting the MTU as high as possible before starting the tests, it says to set the MTU after running the tests. And I'm pretty sure the examples he used reflect the local MTU settings, not anything to do with routers between him and dslreports.com. Do you disagree with that last sentence?

Email Expert
Posts: 18,241
Registered: ‎04-27-2004

Re: MTU Size

Did you run a packet sniffer during the "ping -f" test? I assumed that the message "Packet needs to be fragmented but DF set." means that ping received an ICMP Fragmentation Required but DF Set packet -- routers send this when they're unable to forward a packet because it's above the MTU and DF is set.

I don't have a Windows machine to test this with.
Bronze Problem Solver
Posts: 3,246
Registered: ‎05-12-2006

Re: MTU Size


Did you run a packet sniffer during the "ping -f" test? I assumed that the message "Packet needs to be fragmented but DF set." means that ping received an ICMP Fragmentation Required but DF Set packet -- routers send this when they're unable to forward a packet because it's above the MTU and DF is set.

 According to Ethereal, no packets were sent when I did the "ping -f -l 2000"  test. No error messages would be received from Internet routers until I set "-l" to be compatible with my local TCP/IP settings.
Email Expert
Posts: 18,241
Registered: ‎04-27-2004

Re: MTU Size



steve-baker wrote:

Did you run a packet sniffer during the "ping -f" test? I assumed that the message "Packet needs to be fragmented but DF set." means that ping received an ICMP Fragmentation Required but DF Set packet -- routers send this when they're unable to forward a packet because it's above the MTU and DF is set.

 According to Ethereal, no packets were sent when I did the "ping -f -l 2000"  test. No error messages would be received from Internet routers until I set "-l" to be compatible with my local TCP/IP settings.


Well, I guess that makes sense. The IP stack itself obeys the "Don't fragment" option, so it doesn't send these 2K packets (Ethernet's maximum packet size is 1500 bytes).

I think you'll only see the intended effect of the procedure if there's a router along the path that has an MTU smaller than your NIC's. E.g. if there's a link with MTU=1000 and you send a 1200-byte packet, the packet will leave your PC and the router will send back "Packet needs to be fragmented but DF set".