-
Hail Guest! We're looking for Community Content Contribuitors to Stratics. If you would like to write articles, fan fiction, do guild or shard event recaps, it's simple. Find out how in this thread: Community Contributions
-
Greetings Guest, Having Login Issues? Check this thread!
-
Hail Guest!, Please take a moment to read this post reminding you all of the importance of Account Security.
-
Hail Guest! Please read the new announcement concerning the upcoming addition to Stratics. You can find the announcement Here!
Those nodes look like they would always give you 100% packet loss, but it looks like there is no problem reaching the last ping hop 10.
Losing data always at a specific location in a network issue should cause a loss of pings delivered to each successive node unlike your poll report. If its only that node not responding then the node is working as intended. Sometimes networks drop packets because they do not want to be subject to a denial of service attack by overloading the hash tables that would allow an attack packet to get through the system.
-Lorax
Losing data always at a specific location in a network issue should cause a loss of pings delivered to each successive node unlike your poll report. If its only that node not responding then the node is working as intended. Sometimes networks drop packets because they do not want to be subject to a denial of service attack by overloading the hash tables that would allow an attack packet to get through the system.
-Lorax
You may be having issues with your connection, but the reported 100% packet loss have nothing to do with that. This is just saying those servers refuse any and all ping requests.
I would tell the family to stop streaming music, get teenagers off the ip phone, and videos because it is cutting into your UO play-time. Do a speakeasy.net test to watch at various times how your bandwidth is affected. The poll report isn't showing an issue. But your network may be affected more in the evening compared with early morning.
You may have to switch your work schedule around so other family members or community on your network ring aren't affecting your play time.
Looking at your poll report, you can see there are no long packet delays compared with the average. Each packet worst is really very close to the average indicating over the few seconds the poll report was captured there is no network issue. Looking at a bandwidth report may help you see where the issue is because you could have a great connection for the minimum size ping packets, but once the mtu packet size increases that longer packet has to wiggle through the network like a long worm. Ping packets are length different than the real datagram packet your UO application sends or is defined by your operating system network driver to get to the server. A point along your polled route could have a bandwidth issue.
What kind of access point do you have from home to ISP? Like some people have wifi to a mountaintop and in the spring trees grow just enough to wiggle the doug fir needle in the wind blocking the wifi transceiver just enough to affect their connection. In that case you have to climb a tree in your neighbors yard and cut the branch or top off. Do that when they are at work and wont hear the chainsaw.
-Lorax
P.s.
Looks like a great connection in my opinion. You have an extra 40ms to go from Oklahoma(?) to San Jose, which seems good. Your connection from home to the long haul fiber looks great and the time from SJ to ea looks great.
You may have to switch your work schedule around so other family members or community on your network ring aren't affecting your play time.
Looking at your poll report, you can see there are no long packet delays compared with the average. Each packet worst is really very close to the average indicating over the few seconds the poll report was captured there is no network issue. Looking at a bandwidth report may help you see where the issue is because you could have a great connection for the minimum size ping packets, but once the mtu packet size increases that longer packet has to wiggle through the network like a long worm. Ping packets are length different than the real datagram packet your UO application sends or is defined by your operating system network driver to get to the server. A point along your polled route could have a bandwidth issue.
What kind of access point do you have from home to ISP? Like some people have wifi to a mountaintop and in the spring trees grow just enough to wiggle the doug fir needle in the wind blocking the wifi transceiver just enough to affect their connection. In that case you have to climb a tree in your neighbors yard and cut the branch or top off. Do that when they are at work and wont hear the chainsaw.
-Lorax
P.s.
Looks like a great connection in my opinion. You have an extra 40ms to go from Oklahoma(?) to San Jose, which seems good. Your connection from home to the long haul fiber looks great and the time from SJ to ea looks great.
Last edited:
PC is plugged directly into the cable modem. At the time of the polling no other devices in the house were using any bandwidth.
Generally, even with 3 or 4 clients running on my pc and 2 or 3 clients on my wife's pc, I have no connection issues. For the last couple days, even a single client with no other interference I am getting packet loss spikes as viewed through the classic client server selection screen. It is noticeable during gameplay as a brief (@ 1 second) hiccup that reoccurs every 4-5 seconds. Nothing else regarding the systems or setup has changed. Hopefully it resolves itself soon.
Generally, even with 3 or 4 clients running on my pc and 2 or 3 clients on my wife's pc, I have no connection issues. For the last couple days, even a single client with no other interference I am getting packet loss spikes as viewed through the classic client server selection screen. It is noticeable during gameplay as a brief (@ 1 second) hiccup that reoccurs every 4-5 seconds. Nothing else regarding the systems or setup has changed. Hopefully it resolves itself soon.
That sounds like there is another program on your computer taking up bandwidth. Do you have Windows Update set to manual updates? Adobe, browsers, virus scanners, and other programs like to turn auto-update, which can be at the worst of times while playing games. Virus scanners can cause freezes while scanning. Check to see what other programs and services are running in the background.
This is not just in UO. I have found in other games and sites the lag effect has been horrid.
Could this be a solar effect that is causing this? We did have a pretty big flair the other day...
Could this be a solar effect that is causing this? We did have a pretty big flair the other day...
Nothing on the PC has changed from last week when I was not experiencing the packet loss.
What you described doesn't sound like packet loss. Some programs turn on the update without being told to. Just because you don't think anything has changed, doesn't mean nothing has changed. So unless you check what services are running, you really don't know what is stealing CPU cycles and network bandwidth.
Like Winter said, nothing's changed...that you know of. You could try a utility like Process Explorer to see what's happening on your computer, but your tracert suggests to me that there's an ISP problem reaching those last two hops (which are fine for me via Comcast).
Have you tried speedtest.net or similar to test your connection? Ideally a test uses your ISP's nearest server, which will show if you have a good connection. A couple of times I've had inexplicably stuttering connections when my cable modem decided to go on the blink.
Have you tried speedtest.net or similar to test your connection? Ideally a test uses your ISP's nearest server, which will show if you have a good connection. A couple of times I've had inexplicably stuttering connections when my cable modem decided to go on the blink.
Here's what a bad trace route looks like - AT&T seems to be having an issue this afternoon:
* Unknown Host * 12.202.197.1 2 54ms
* Unknown Host * 12.249.144.61 3 438ms
cr81.gdrmi.ip.att.net 12.122.152.34 4 673ms
cr1.cl2oh.ip.att.net 12.122.152.65 5 569ms
cr2.cl2oh.ip.att.net 12.122.2.126 6 616ms
cr2.phlpa.ip.att.net 12.122.2.210 7 671ms
cr1.wswdc.ip.att.net 12.122.4.54 8 614ms
* Unknown Host * 12.122.116.13 9 664ms
* Unknown Host * 12.251.253.10 10 516ms
* Unknown Host * 72.21.220.31 11 490ms
* Unknown Host * 205.251.245.55 12 822ms
* Unknown Host * 0.0.0.0 13 0ms
* Unknown Host * 0.0.0.0 14 0ms
* Unknown Host * 0.0.0.0 15 0ms
ec2-107-23-150-177.compute-1.amaz107.23.150.177 16 531ms
* Unknown Host * 12.202.197.1 2 54ms
* Unknown Host * 12.249.144.61 3 438ms
cr81.gdrmi.ip.att.net 12.122.152.34 4 673ms
cr1.cl2oh.ip.att.net 12.122.152.65 5 569ms
cr2.cl2oh.ip.att.net 12.122.2.126 6 616ms
cr2.phlpa.ip.att.net 12.122.2.210 7 671ms
cr1.wswdc.ip.att.net 12.122.4.54 8 614ms
* Unknown Host * 12.122.116.13 9 664ms
* Unknown Host * 12.251.253.10 10 516ms
* Unknown Host * 72.21.220.31 11 490ms
* Unknown Host * 205.251.245.55 12 822ms
* Unknown Host * 0.0.0.0 13 0ms
* Unknown Host * 0.0.0.0 14 0ms
* Unknown Host * 0.0.0.0 15 0ms
ec2-107-23-150-177.compute-1.amaz107.23.150.177 16 531ms