maghoogl.blogg.se

1. #Pingplotter not responding install#
2. #Pingplotter not responding zip#
3. #Pingplotter not responding windows#

To do this, we set the “Focus Time” to 5 minutes, double-clicked on the red point in the time-graph, and then reset the time-graph period to 5 minutes instead of 6 hours.

This corresponds with a note from the customer in the data file that shows the disconnect happens. Notice the packet loss in the timeline graph at 11:23 am.

#Pingplotter not responding zip#

zip up the file, making it easier to send data. Because PingPlotter data is already compressed, there is no need to. They then sent us the saved data for analysis. This correlates real world symptoms with the collected PingPlotter data (a crucial part of the troubleshooting process).Ī day of collecting data resulted in only a single disconnect, and the customer dutifully recorded that for us. If a disconnect or slowdown occurs in Citrix, we suggest to the customer that the right-click on the lower “time-graph” in PingPlotter and create a comment at the point that the problem occurred.

#Pingplotter not responding install#

When the customer contacted CitServeCo, they suggested that they download PingPlotter, install it onto the workstation they normally work with, and configure it to monitor the Citrix server inside CitServeCo’s network. Most ASPs will attest to the fact that customer connections are a prime source of network problems, but we can’t just tell the customer "It’s your problem." Any reliable ASP will get numerous complaints like this – that they *know* are the fault of something beyond their control (like the customer’s cable connection, or similar). The customer will almost certainly blame CitServeCo initially for a problem like this – but we need a way to determine where the problem is being caused, and help the customer solve the problem. The customer (who uses financial applications served by CitServeCo) was frustrated by disconnects during the day, which lasted anywhere from a few seconds to a minute or two, interrupting their ability to do business. Our ASP (we’ll call the ASP "CitServeCo" - a totally fictitious company) is accessed via Citrix, which is relatively sensitive to high latency and packet loss. We’ll walk through some of the symptoms, collected data, then analysis and how we came to the proper conclusion. Here’s an example extracted from a real-world customer situation. This information can be used to pinpoint which hop (or router) in the chain is adding latency or losing packets that might be causing problems back to your ASP. They can easily download PingPlotter, capture data, and then either analyze that data themselves, or email the data back for you to analyze. One way to pinpoint the problem is to have your customer run PingPlotter against your service. How do you troubleshoot this kind of a problem? Where is the problem at the entry point to your network, in the customer network, or possibly in one of the providers in between?

Your customer (possibly employees of your company, or maybe subscribers of your service if you’re an ASP-based service) is complaining of frequent disconnects, and possibly slow performance sometimes.

#Pingplotter not responding windows#

This might be provided via HTTP, or possibly through something like Citrix or Windows Terminal services. In this scenario, you are acting as a service provider for some network service. Scenario: External customer has problems using your network resources.Ī customer (not inside your network) has problems losing connecting to services inside your network.