Brandon in Brandon
@rr.com
| reply to Brandon in Brandon
Re: [ Brighthouse] Slowdowns in Tampa Bay???
Can someone deciper this? It looks to be about the same packet loss on each hop. Would this be caused by my node being overloaded? Or are there issues with each hop?
Target Name: www.hydrogenaudio.org
IP: 67.15.84.17
Date/Time: 1/14/2006 9:45:38 PM to 1/14/2006 10:05:08 PM
Hop Sent Err PL% Min Max Avg Host Name / [IP]
1 79 0 0.0 0 0 0 [192.168.0.1]
2 79 15 19.0 7 70 12 [10.102.96.1]
3 79 11 13.9 8 89 14 gig1-0.tampflerl-rtr2.tampabay.rr.com [65.32.15.1]
4 79 16 20.3 8 217 21 pos6-0-OC-192.tampflerl-rtr4.tampabay.rr.com [65.32.8.137]
5 79 14 17.7 9 188 21 pop2-tby-P0-1.atdn.net [66.185.136.185]
6 79 19 24.1 9 180 23 bb1-tby-P0-1.atdn.net [66.185.136.176]
7 79 18 22.8 26 78 31 bb2-atm-P7-0.atdn.net [66.185.152.245]
8 79 17 21.5 26 195 33 pop1-atm-P4-1.atdn.net [66.185.150.3]
9 79 15 19.0 39 75 44 so-5-2-0.mpr1.atl6.us.above.net [209.249.119.241]
10 79 16 20.3 57 126 66 so-3-3-0.mpr2.iah1.us.above.net [64.125.29.66]
11 79 14 17.7 39 152 45 t289.216-200-251-162.iah1.us.above.net [216.200.251.162]
12 79 18 22.8 38 125 46 gphou-66-98-241-119.ev1.net [66.98.241.119]
13 79 56 70.9 40 133 53 morbo.org [67.15.84.17]
|
|
Brandon in Brandon
@rr.com
| Last Monday evening packet loss was around 90% (I gave up and watched TV..), but as of Tuesday the packet loss has totally stopped. Peak time speeds are running about 350 kbits/sec, which is *flying* compared to before. Web browsing has improved tremendously. Nothing times out and generally feels quick.
Can a network guru here answer a question:
What causes packet loss when a node is overloaded? It is because the headend router on the node doesn't have sufficient memory to buffer the requests? Think they added memory to the router on my node? |
|
Brandon in Brandon
@rr.com
| Found the answer on Cisco's site:
"A common scenario for packet loss is when an output queue is full of packets to be transmitted where there is no additional memory space for additional ingress packets; this condition is commonly referred to as an output queue full condition. In this condition, the network device that is queuing the packets has no choice but to drop the packet. For example, an output queue full condition can occur where a sender attached to an interface of a higher speed is sending to a receiver attached to an interface of a lower speed. Eventually, the output queue buffers become full, resulting in dropped packets."
»www.ciscopress.com/articles/arti···743&rl=1
I don't know if that's what was happening, but I'd bet it was, and some nice Brighthouse tech saw my post and investigated (Thank you!). |
|
Death2U
Premium
join:2006-01-22
| reply to Brandon in Brandon
By the way, were these pings done not under load? I don't like some of the max you're getting from some of RR's routers. I am not from Pingplotter(you may think with how much I recommend it) but use it. It can provide you with Vital data this doesn't and you can save it to use later. The idiot test RR may have you do is no good, it just measures packet loss at a server, but not on path to the server. Each router will usually retry a packet on route to destination, thus you're seeing loss of the destination eg yahoo.com, not from ATDN or Level 3. Pingplotter shows the loss of whole path by gathering data on each individual router. 30 day free trial of the good version! More than enough to find the problem. |
|
