Hi, Eric.
1) The web interface should have a column for the jitter. If it doesn't show up, right-click on the column header and you should have an option to turn it on. Of course you need to have the Jitter script enabled (which is probably the case already - it sounds like you have it showing in the GUI already).
2) Inadequate bandwidth can happen at so many points and so many places - it's hard to tool-up all the points needed to measure bandwidth shortcomings at every place where it could happen.
PingPlotter doesn't jump up and down and wave red flags at every bandwidth shortcoming in the route, but some experience with your route's data (plus PingPlotter graphs, of course) is extremely effective at locating bandwidth problems.
You may have already read our
voice over IP troubleshooting guide, but that guide spends most of its time talking about how to identify bandwidth limitations (congestion) using PingPlotter graphs - especially when using time-of-day as an indicator of problems (if performance varies based on time-of-day, that's a pretty strong indicator of bandwidth problems).
If you're looking for a smoking gun, one way to do this is to hook up to the device that you suspect is constraining bandwidth and measure traffic flow on that device. If the traffic rate is hitting the subscribed bandwidth limit, then that's a smoking gun when paired with a PingPlotter latency graph. The problem with this is that it's not generically available with all consumer devices - each one has different ways of exposing bandwidth use (or no way at all).
If you have a device that is pollable with SNMP, get in touch with us for a script that can be plugged in to PingPlotter Pro to query bandwidth use via SNMP and put it on a graph in PingPlotter Pro.
- Pete