Acceptable level of ping time outs to internet?

We have a new cloud-based record system that has had many problems with users getting disconnected. The vendor says this is because any time there is an interruption in internet connectivity, the connection to the cloud-based system drops and the user gets kicked out and has to reconnect  to it.  i did some continuous ping tests to their cloud server and saw an occasional reply time out, maybe once or twice in 15 minutes.  They said this is enough to knock the user off, which is what's causing all our problems. We've not had this problem with any other internet-based activity.  I've done similar ping tests to these servers from some of our other locations, as well as to google.com for comparison. All of them occasionally get a reply timeout.
So how realistic is it to expect that the internet connection will essentially never time out? That's the standard that the vendor says we have to meet, but that doesn't sound realistic to me. Since it is timing out occasionally, what can we do to stop it?
LVL 3
maharlikaAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Mark GalvinManaging Director / Principal ConsultantCommented:
Hi

When you state 'any other internet-based activity' what do you mean? Users browsing the web will never notice the occasionally dropped ping - thats the nature of web browsing.

However, some cloud based services will be sensitive to ping drops (Hosted VoIP, VDI Services etc.).

If you are seeing the same level of ping drops to goggle.com then you need to look at your break out to the internet.

Using Tracert to the cloud service/google.com pick out each hop. They run a continuous ping to each hop and see where it drops. That should help you locate the issue area and go from there.

Thanks
Mark
Don ThomsonCommented:
The ping response times can vary from 20 ms  to well over a thousand.   Usually  I look at the average and the maximum response time for 25 iterations  Ping "someurl.com" -n 25

If you see normal response time (under 100)  

When testing try the following
1. www.speedtest.net   - run at least 3 times about 5 minutes apart.
2. Ping your external gateway  (get that by looking in your router under wan  settings)
3. Ping some external site (www.google.com)
4. Ping your cloud based storage site.
5 do a Tracert  to your cloud based Storage site

Using tracert  from a cmd prompt  will tell you where in the network between you and the end it's getting hung up.  If you can identify the bottleneck . I have even documented the problems by piping the responses to a text file (tracert "url" >Tracert1.txt

With a couple of these, you can find out which company owns the errant router and send them the text files and ask them do do some throughput test on their leg of the network.

At one time I had the tests that showed that one of the AT&T routers in Chicago was in a restart loop. I let them know and they had the problem correct in about 15 minutes. They had been chasing that problems for 4 weeks.
lacayoaTeam Leader Systems EngineerCommented:
Hi Maharlika,

This in not a good answer from your vendor. Actually some losing packets and long ttls are acceptable from an Internet connectivity. But one test you can do is making a traceroute to the vendor systems server. If there are some losing packets or big ttls, you are going to be able to see in where this problem actually happen (in ms):

from a CMD:
C:\Users\test>tracert google.com

Traza a la dirección google.com [173.194.115.161]
sobre un máximo de 30 saltos:

  1     1 ms     1 ms     1 ms  10.x.x.x
  2     1 ms    <1 ms    <1 ms  10.x.x.x
  3     2 ms     2 ms     3 ms  lan-d32-xxxxxx
  4    10 ms     3 ms     4 ms  inet-xxxx
  6    14 ms    14 ms    14 ms  dsl-xxxxx
  7     *        *       31 ms  72.xxxx
  8    10 ms     9 ms    10 ms  209.xxxxxx
  9    10 ms    10 ms    10 ms  qro01s12-in-f1.1e100.net [173.194.115.161]

Traza completa.

C:\Users\lacayoa>


If you see missing packets o big time outs, you can tell to the service provider or your system vendor, deppending where the problem happen.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Fred MarshallPrincipalCommented:
It's not clear what the relationship of ping times or tracert times will be to dropouts.  They are nice tests and may help you pinpoint problems.  And maybe they won't.

We've had a similar problem with a VPN that supports a rather sensitive application that's hosted by an Application Service Provider (ASP).  When packets are dropped, the VPN can drop.  When the VPN drops then all hell breaks loose on the application.  (And, it appears the VPN sin't self-healing which is surprising).  The user PCs have to at least reload their client software or have to reboot.  This is pretty disruptive when it happens.
I only mention this in that it seems similar to your situation.

I've not found a satisfactory way to observe incoming packet dropping because the internet protocols generally deal with it by retransmitting packets.  It's only when packet dropping gets to be "large" in some sense is there much of a noticeable problem.  That's when the other indicators may be useful.

I think it boils down to a few things:

1) The application works fine even in the presence of inevitable packet drops.

2) There is something in the (variable) path between your site to the application service provider that's causing interruptions that can't be tolerated by the application.

3) The application is too sensitive to such things such that it hiccups even with expected interruptions.

You don't have #1.
#2 and #3 are going to be very difficult to separate out unless it's #2 and it jumps out at you.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Cloud Services

From novice to tech pro — start learning today.