[quote]Thanks this was very helpful. I also found my IP's site that tracks the current performance of my internet and its showing packet loss at 0. What exactly is packet loss? Is it the amount of info/files? lossed while my IP connects to me or when I connect to Bugie or both?[/quote] A "lost" packet is one that does not get accepted at the intended destination. Can happen for a variety of reasons. Security could block it. Congestion can cause it to be stuck in a buffer too long and it times out... or a buffer could be full. Devices/lines can go down. Various factors could corrupt the data, or it may arrive too far out of order so the application rejects it... lots of different ways to define it. Basically... it did not get where it needed to go. Some protocols have mechanisms to reorder packets properly at the end point, or to otherwise detect a problem and request a quick retransmit of the problem packet. UDP does no such error detection/correction. It is more of a "best effort" kind of thing... tries to get it through as fast as possible, but sacrifices some safeguards to accomplish that. If something goes bad along the way or at the other end, it just gets discarded. As for the stat of 0 loss you are seeing... that can be very misleading. Without knowing how that stat is tracked, it is hard to say how relevant it is. Could be that they are only testing to a specific address. Could be to the head end. Could be to any router/server within their network. Could be to an edge router, just before it gets handed off to a third party peering ISP. Could be google.com. Who knows? Errors/collisions/corruption happens all the time on networks, and can interfere with reliable delivery. If you have access to your modems log and signal pages, you may see values for correctable/uncorrectable--this is tracking packets that the modem itself detected and tried to correct itself. Basically, "uncorrectable" packets are ones it could not fix... if TCP was involved, they likely got retransmitted so the data still got through with a slight delay--but if it was UDP, they were likely lost. Stats are nice... but without knowing more about them, thet can sometimes leave the wrong impression. Our market's rate cards always show results from a batch of tests they run periodically, and they typically report under 28ms latency and less than ~.05% losses to their IXP's. That is where they tracked traffic to the edge of their networks through exchange points where they handed off to someone else. Internally, those numbers are respectable. But I can run independent tests to AT&T, FTC, etc. and get dramatically different results. This is what means more to us as end users. How does it hold up in the particular ways we are using the service... be that video streaming, internet phone, or a particular gaming service. Sometimes you have to get them to look at your specific usage... monitor your packet flow specifically while you are using it in a specific way. The trick is giving them a reason to set up that monitoring. The more effective approach is when you can find a specific route that has become unstable. This gets tricky with some games though. There aren't always ways to run tests and generate reports against their servers, so we have to find ways to approximate it or otherwise demonstrate a problem on demand. For example, Bungie only has a couple unpublished servers that can be tested against directly. They are not common knowledge, but everyone can test to Seattle's CenturyLink site at speedtest.net. Level3/CenturyLink carries almost 40% of Bungies traffic (Zayo takes about 50%), and Bellevue is basically across Lake Washington from Seattle. So if things look bad to that particular site that is dramatically different from other sites using the same testing method, that can be reported to the ISP as an example that something may be afoot that they need to investigate. Another way some people have demonstrated issues is through the use of a VPN. They can show problems coming and going when they use/don't use the VPN even when the VPN is generally routing the same as you would normally be routed. For instance, we normally route through Atlanta, Charlotte, or Raleigh/Durham. If there is a marked improvement when I VPN to those cities versus when I am not... they may need to watch what is going on with their routing policies. The trick almost always lies in being able to show a particular destination is experiencing unusual loss/jitter problems. Various ways to do it. But if you can actually capture unstable delivery, you can usually get them to take a closer look.