Topic: Excessively long ping times

[electroman00]

Any vlan switches involved?

[edb]

Any vlan switches involved?

No to that question. Thanks

[edb]

Hi Ray,

I don't think the smb browsemaster was the issue.

I rebooted the server just to make sure ... but I just tried a test of downloading a file from the SME over the Internet connection.
Shaw Cable has a test file they use to test download speeds and the file is a 20MB dat file so I put it on my server, started up the visual ping utility suggested by "mercyh" earlier in this thread and started the download from my home PC. I watched the visual ping utility and the ping times went from 45ms to 300ms while I was doing the download.
This seemed odd so I started a second download so that both were going at the same time and now the ping time went to 600ms. Obviously, it seems that the server is being taxed .... if I quit both of the 20MB downloads the ping times quickly return to 45-50ms again.

I don't want to post my website here but if you send me an email I'll give you the url where you can test what I'm saying.

Any comments?

edb

[electroman00]

edb

MTU 1404 will cause the problems you are having.

Unless your ISP is recommending that setting a MTU 1500 should be used.

For some DSL ISP's 1494 may be required.

Suggest you set MTU to 1500 and reboot.

If your still having the problems then I suggest testing for MTU packet length
and should it be something other the the two settings above then investigate
that with your ISP.

MTU should match that of your ISP.

Using 1404 on a 1500 network will fragment packets forcing client systems to
wait and ultimately timeout when when they receive the 96 byte fragment.

That fragmentation is the latency you are experiencing throughout your system.

The results you have for the D/L & ping test are the exact results one would see on a system
that is fragmenting packets.

As the D/L progresses the timeouts degrade the systems ability to respond to other request i.e. pings.

As a point of interest where was 1404 derived from??

[edb]

Hi electroman00

Here is how I arrived at my MTU size:

MTU is the Maximum Transmission Unit. If the setting is too high packets can fragment and transmission speeds will be poor.

The default MTU is 1500. A DSL connection with PPPoE cannot be above 1492 and the default settings could cause problems. The MTU should be set the same on both sides of your router, the internal LAN (your network) and the external WAN (the Internet).

Ask your ISP for their recommend MTU setting. If they won't give it to you continue reading below. Verizon recommended using 1492 for their DSL with PPPoE, however, our testing showed that 1490 works better.

To find the proper MTU Size you will have to do a ping that tests for fragmented packets. Refer to the ping test, above, to learn how to find your ISPs DNS server address. We will use 12.34.56.78 in the examples below.

At the DOS prompt start the special ping using a value of 1472. Work down in jumps of 10 until the packets are not fragmented. The syntax is: ping 12.34.56.78 -f -l <test value>. Below are results from a sample test.

ping 12.34.56.78 -f -l 1472   <result = fragmented packet>
ping 12.34.56.78 -f -l 1462   <result = fragmented packet>
ping 12.34.56.78 -f -l 1452   <result = reply>
Start at 1472 and work your way down by 10 each time. Once you get a reply, go up by 2 until you get a fragmented packet.

Once you find the proper value add 28 to account for the various TCP/IP headers.
If the value was 1462 adding 28 gives 1490, which is the optimum for your network..

My MTU size was determined to be 1444 as a result of the above tests.

I did however, change it back to a MTU of 1500 on the Sonicwall and we'll see what happens I guess but if I recall this was why I changed it to 1444 in the first place.

edb

[electroman00]

edb

Your correct 1492.

However you stated 1404 in your initial post....???

My MTU size was determined to be 1444 as a result of the above tests.

That would indicate something is not quite right with the connection.

I would disconnect everything from the modem except one client and retest.

If it ends up being different from your initial test, I would suspect a problem from the router upstream somewhere.

BTW on what client did you perform the ping MTU test, I assume the smeserver or multiple clients or from home?

Also did you ping inside and outside the lan.

Do you know the distance to the ISP hub?

I would venture to guess it's less then a mile these days and with that 1492 should be expected
unless there is a problem somewhere.

As a side note I was going to post this, then I saw you posted the above, but here it is anyway just in case it may help.

Regular Ethernet frame uses a frame format that limits the size of the payload it sends to 1500 bytes. This means Ethernet can't deal with IP datagrams greater than 1500 bytes in size.

Some systems will use datagrams larger then 1500 which is considered a Jumbo Frame and some systems can accommodate those frames.

However I have not seen any ISP's using Jumbo Frames because all of their clients would need Jumbo Frame capability.

The other side of the coin is frames being sent 1500 in size to a system where the MTU is set less then 1500 which will force fragmentation of the frames
and the receiving system waits for the remainder of the frame for reassembly.

Conversely if a system is sending 1492 frames to a 1500 network then the system again waits for the remainder of the frame and on receipt
will reassemble the packets which instills the latency on the receiving network.

All fragmentation is reassembled by the receiving host.

With that it is important to MTU ping test to various points and survey/analyze all the data collected to help isolate the problem.

[edb]

electroman00

Thanks for the reply ....

If it ends up being different from your initial test, I would suspect a problem from the router upstream somewhere.

I am starting to think it must be the Shaw Cable upstream gateway router

BTW on what client did you perform the ping MTU test, I assume the smeserver or multiple clients or from home?

I did my testing from home but I have come up with the same results testing from work.
If I use the method in my last email to come up with the best MTU size I ping over my VPN links and get the same results. I get a successful ping response at ping 192.168.50.50 -f -l 1418 but at ping 192.168.50.50 -f -l 1420 I get "Packet needs to be fragmented but DF set." so according to the formula I would take 1420 + 28 = 1448 as an optimum performance.
I still have it set back to 1500 for right now.

Also did you ping inside and outside the lan.

Yes. I get the same results when I ping xxx.xxx.xxx.xxx -f -l 1420 the WAN interface of the SME server  or www.google.ca or the local LAN interfaces.

Do you know the distance to the ISP hub?

We are right downtown so I don't think the gateway router is even a mile from us.

The other side of the coin is frames being sent 1500 in size to a system where the MTU is set less then 1500 which will force fragmentation of the frames
and the receiving system waits for the remainder of the frame for reassembly.

Conversely if a system is sending 1492 frames to a 1500 network then the system again waits for the remainder of the frame and on receipt
will reassemble the packets which instills the latency on the receiving network.

All fragmentation is reassembled by the receiving host.

With that it is important to MTU ping test to various points and survey/analyze all the data collected to help isolate the problem.

Yes, I agree ... but I'm still scratching my head over this MTU aspect.

edb

[electroman00]

edb

I'm a little confused here.

Home and work both dsl?

What modems are being used?

Also without a doubt, cable... like in RF (RG6) cable tv & internet should be mtu 1500.

Cable doesn't have the datagram header issue like DSL.

I have Brighthouse Cable here and in fact the tech just left here.

There was a considerable amount of latency to websites due to packet loss.

Initial test at modem connection showed high packet loss.
So we went to the demark and tested and all was fine, no packet loss.
110 ft wire to computer modem became suspect, so we retested at the modem connection.
No packet loss on the retest, so it looks like the connection at the demark might have been a little corroded
causing a bad connection on the shield.
It doesn't take much of a bad connection with RF cable to have me notice a problem.
My D/L bandwidth drop was about 200kb average and latency to sites very long and
the modem would drop off line several times a day due to 43000+ flaps a.k.a line resets.
If flaps get severe the modem will drop off line on a soft reset.
Sometimes it required a hard reset to bring it back online.
That was the issue the last couple of days here.

Also had them install a brandy new out of the box modem.

Things are sweet again here, everything seems to be back to abbie normal here.

With DSL things are a little different, but not much.

Packet loss is still packet loss and needs to be rectified as your finding out.

[edb]

edb

I'm a little confused here.

Home and work both dsl?

What modems are being used?

Home and work are both cable and we are using Terayon modems at both locations.

I'm highly suspect that the modem could be my culprit as well in this case so I'll be calling Shaw Cable to come and replace it.

Thanks for all the dialogue electroman00!! You've been a great help ...

edb

[electroman00]

edb

I'm sorry....I assumed due to the 14xx you were DSL.
MTU for all cable modems is 1500.

Cable modems use ethernet connection...thus...

Regular Ethernet frame uses a frame format that limits the size of the payload it sends to 1500 bytes.
This means Ethernet can't deal with IP datagrams greater than 1500 bytes in size
and you don't want to pipe anything smaller then 1500 or you will fragment every frames/packet
through the system and your client hosts will be consumed with packet reassembly

That surely will dog the host system to very low performance not to mention slowing down the entire VPN network.
That certainly fits the problem you were pinging for.

If you set the MTU back to 1500 system wide and you still have ping MTU problems
then it might be

1. Cable modem has a bad upload or wrong bin cap
2. RF cabling terminations
3. Your near or at the end of the distribution chain and signal quality is less then desirable
however still within signal spec.

It would be a good idea to retest...

after a complete system reboot
only a single client connected to the modem

Cable modems have very sensitive transceivers that will adjust performance based on
signal quality.

If signal quality is poor the modem will flap aka soft line reset which may frag packets.
If flaps are excessive the modem will soft reset the line and may go off line and online
by itself.

Under really poor signals the modem may not go online after a soft line reset.

RG6 coax should be checked for penetrations, cuts, splices.
I had them run the coax here unspliced direct to modem (no wall box outlet).
The fewer splices the better.
It has been suggested not to route the modem cable through a signal amp.
I'm not sure I would say don't try that based on what I know.

Without a full explanation it's easier to say "your mileage may vary".

RG6 connectors are 7/16" wrench and you may want to rework/inspect
all terminations, work them off and on and tight, especially the outdoor connections.

A leak on the RG6 shield can transmit RF (radio frequency) signal a 1/2 mile or more.
Thats why cable companies send their magic wand trucks through the hoods to seek
them out and fix or the FCC will give them a spanking.

Any compromise to the coax will also allow RF signals to leak onto the coax creating signal
noise thus reducing signal quality, creating excessive flaps within the modem.

They knocked on my door once, shield connection was bad in a wall box, the techs hand held wand
pointed us right to the box.
He said he picked it up two blocks way in his truck.
As my electronics RF experience is extensive I wasn't surprised.
In fact with a more sensitive detector one could detect that signal leak miles away.
At the point of the shield break the remainder of the cable becomes a antenna for the RF signal.

The SA - Scientific Atlanta modems seem to be the better of the modems cable ISP's use.

I had the modem your using and I had them swap it out for the SA yesterday.

My experience with the SA was slightly better then all the others I've tried over the years.

If nothing else I like the led indicators better, power, pc, cable and data in/out.
The data in/out are extremely beneficial in detecting my sons torrent usage.

[electroman00]

Cable MTU ping stats here

Code: [Select]

Pinging [xx.xx.xx.xx] with 1472 bytes of data:

Reply from xx.xx.xx.xx: bytes=1472 time=21ms TTL=62
Reply from xx.xx.xx.xx: bytes=1472 time=20ms TTL=62
Reply from xx.xx.xx.xx: bytes=1472 time=21ms TTL=62
Reply from xx.xx.xx.xx: bytes=1472 time=21ms TTL=62

Ping statistics for xx.xx.xx.xx:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 20ms, Maximum = 21ms, Average = 20ms

Code: [Select]

Pinging [xx.xx.xx.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.xx.xx.xx:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
One could safely assume there are problems within the system if
MTU result is other then 1472/1473.

This may not apply to DSL, just cable modems.

[edb]

Electroman00

You sure seem to know what your talking about and the information you provide is very useful and appreciated.
I have an appointment for Monday afternoon with the cable company to come and check the cabling and stuff and I will get them to replace my modem at the same time. I told them that when I placed the call.

The fact that cable uses only a 1500 MTU size is something I didn't know but do now!

Here is what I get when I ping even from my home which is also cable or from the office:

Code: [Select]

Pinging www.l.google.com [72.14.205.147] with 1418 bytes of data:

Reply from 72.14.205.147: bytes=56 (sent 1418) time=227ms TTL=247
Reply from 72.14.205.147: bytes=56 (sent 1418) time=228ms TTL=247
Reply from 72.14.205.147: bytes=56 (sent 1418) time=347ms TTL=247
Reply from 72.14.205.147: bytes=56 (sent 1418) time=224ms TTL=247

Ping statistics for 72.14.205.147:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 224ms, Maximum = 347ms, Average = 256ms

Code: [Select]

Pinging www.l.google.com [72.14.205.99] with 1420 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 72.14.205.99:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

The upstream router must have a modified MTU setting wouldn't you agree?

Thanks again

edb

[electroman00]

edb

The upstream router must have a modified MTU setting wouldn't you agree?

No, typically the internet is 1500 and it's not advantageous to set MTU lower then the Ethernet
standard because that would slow things down en route due to the additional packets that would be sent.

Keep in mind DSL is a different MTU game, since we are talking all cable here we'll stay on the cable track of 1500.

As you can see framing can have a fairly profound effect on network performance, so imagine your network times 10 in size and
one device setup with packet/framing inconsistent with the network.

It can take down the best, of the biggest, in a heart beat networks.

Also be aware that a system may have all the correct settings/setup and there's a component within the system
generating inconsistent frames/packets.

It's times like these that I begin to loose that lovin' feeling?

Here's my ping to googlie and as you can see 1472/1473

Code: [Select]

Pinging www.l.google.com [209.85.165.147] with 1472 bytes of data:

Reply from 209.85.165.147: bytes=56 (sent 1472) time=20ms TTL=245
Reply from 209.85.165.147: bytes=56 (sent 1472) time=20ms TTL=245
Reply from 209.85.165.147: bytes=56 (sent 1472) time=18ms TTL=245
Reply from 209.85.165.147: bytes=56 (sent 1472) time=20ms TTL=245

Ping statistics for 209.85.165.147:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 18ms, Maximum = 20ms, Average = 19ms

C:\Documents and Settings\rph>ping www.google.com -f -l 1473

Pinging www.l.google.com [209.85.165.147] 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 209.85.165.147:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
 I would suggest at home you just connect with one client to the modem, no router
and retest.

If you can, do the same at work...if you can.

BTW that's what the shaw turkey's will want to gobble at you when they arrive.

Concept is to get things down to bare bones and test, which will make it easier to
diagnose/isolate.

You definitely have a problem, it's now a matter of finding and the above is the
suggested starting point.

It's imperative diagnostic information.

Be sure to reboot all before testing.

Also if you would, MTU ping your router and lets see what that has to offer.
Should be 1472/73.....if not, we would look at the lan side and/or the test client.

If you haven't done so already make sure the sonic is set 1500 and rebooted.

Also if you changed MTU on your win clients, you might need to do some reg surgery.

Check

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces

Create a restore point....

Programs > Accessories > System Tools > System Restore

 and then...

Run > regedit > Favorites > Add to Favorites
Carefully Copy/Paste the reg line above

Check each interface if more then one.
If you see MTU settings other then 1500 change them to 1500.
Do not add MTU's to any interface, if MTU is not found.
There should be at least one interface with the MTU property.

Prepare for reboot and reboot.

Almost forgot you might have changed the MTU on your Win clients which
could really send us upstream paddling.

I highly suspect the Win clients at this point, due in part to your google results
at both sites.
Your Win clients are one of the commonalities between the two sites.
We need to ensure both are setup correctly.

If you can, check and test.... and let us know.

[mercyh]

EDB,

Did you ever get this sorted?

Just curious of the resolution.

[edb]

No, not yet ... I'm still working on it with our cable supplier.
The cable modem has been swapped out but no change so the next thing is to test the line from the demark to the modem.
I'm starting to think that I may have to get a T1/DS1 line so that I have the same upload and download capacity.
So far I believe it may be just a case of cable being over-subscribed but I'm still trying to determine the root cause of the severe latency issues.
I will post back here any results as I get them.

edb