Greetings,

My company does live event video streaming. We rarely get to choose the site of origination so we are usually at the mercy of the on-site network and its ability to sustain outbound video traffic. We often end up connecting to a network with little time to adequately coordinate our needs with the network administrator. Over the course of 14 years of producing live webcasts we have encountered the scenario where all our equipment and that of the CDN (Content Delivery Network) works flawlessly but somewhere in between there is a network interruption. Most of our clients have little knowledge of IP networks so if something goes wrong they look at us because we are on-site. I am looking at Pingplotter not so much as a troubleshooting tool but as a recording network monitor that I can point to in order to prove that the problem was not our equipment or that of the CDN. It's hard for our typical client to understand that if only one viewer is able to see the stream without any problem then the problem is not on the encoding side and probably not on the delivery side. We need a tool that show times and places of interruptions in traffic. Ideally it would show that there is too much local congestion (people are trying to watch the stream from there desks rather than gathering in conference rooms as recommended). I am new to PingPlotter but could someone tell me if this might a good tool to offer evidence that a problem exists BETWEEN our encoders and the CDN?

Hi, Patrick.

This is actually a sizable area of value for PingPlotter. We have a number of service providers that use PingPlotter in this capacity - with the additional upside that very often some guidance can be given to the customer that is having problem. If there's a bandwidth constraint, PingPlotter is pretty effective at showing that and once you've got it pinpointed, the customer can take action there (and ideally that action will be directed someplace productive and not at you).

I suspect that it's your experience that the problem is usually where the on-site network is connected through a bandwidth constrained point (or a bandwidth saturated one, at least), or where there's onsite trouble of some kind (less-than-stellar wireless, sometimes, or possibly improperly configured local hardware).

This is a perfect place to use PingPlotter - you can run it from the origin point (on a device very close to your video streaming source hardware), and then collect latency / packet loss data between you and the CDN. If you encounter problems, you're collecting PingPlotter data and you can show where the latency and/or packet loss problems originate. In some cases, you may even be able to see problems before the event starts and can have early warning of problems.

We have a sizable number of VoIP VARs as customers. While the CYA role is certainly useful to them, some of them use PingPlotter for early site survey work. PingPlotter Standard can be easily installed at a candidate site (future event site, in your case), and data can be collected ahead of time during a time of day that you want to know about. Congestion / Saturation problems can be ferreted out ahead of time - and sometimes mitigated (with some warning, in the case of VoIP installers). In your case, you might just get an idea of the network stability and typical congestion before you arrive. Sometimes, this gives you a heads-up that the network is unlikely to deliver the kind of performance you'll need (with a bit of experience comparing the results you find with the success of the streaming event).

In summary, in *many* cases, it's a great CYA tool - and it can also be a great way to even make the conversation more proactive than reactive.

Thanks for the question - this is an area where PingPlotter is great, but we're keenly interested in adding even more value (helping service providers that are victims of their customer's inadequate networks).

Best wishes,
Pete

Thank you very much for your reply. I will dive in to learning to interpret the graphs of bandwidth constrained networks. I believe there are some tutorials that cover this. One thing I am concerned about is running Pingplotter on the same subnet as our encoders during a live event. What kind of overhead does Pingplotter consume? I did run the standard online speed tests while running Pingplotter and noticed a significant increase in latency while the speed test was running, especially the upload test. Does Pingplotter distinguish between upload and download latency? It's measuring round trip so probably not.

We have some examples graphs here:

http://www.pingplotter.com/commonnetworkproblems/

And quite a few more scattered through the manual. The VoIP troubleshooting guide is also pretty good about talking through concepts with examples - you're not doing VoIP, but there the core concepts are similar:

http://www.pingplotter.com/manual/pro/voiptroubleshooting.html

PingPlotter, in its default configuration, sends out 56 bytes for each hop, and the responses are 56 bytes. Each request is separated by about 1/25th of a second, so the *most* bandwidth you can consume is about 1.4 KBps in each direction. This is not of consequence to most modern network connections, and barely a pebble in video streaming.

Online speed tests are built to saturate the network - they send as much as possible until the network is saturated. Doing bandwidth tests can be significantly disruptive to regular network operation. This is not at all the mode that PingPlotter works in - it tries to *NOT* use much bandwidth.

PingPlotter does not have the ability to distinguish between upload and download latency. It only measures the round-trip time (as you noted), there and back again. Incidentally, with a TCP connection (are you using TCP or UDP?), either direction being saturation will slow the other direction down, too, because the handshaking packets (error correction) will get caught up in congestion going the other direction.

- Pete