Ever since the Season 8 launch I have been having a problem where the game lags horrendously (1 or 2 FPS) in whatever area I first spawn in. This lag goes away when I load a new area such as beaming up to my ship, and it does not re appear if i beam back down to where I was. It only ever happens at the location I am in at the time when I first log in. This happens regardless of location (space or ground) and happens every single time I start the game.
I'll post my PC's specs here despite the fact that I seriously doubt that my specs are the issue (I get a solid 45 FPS at max settings once I change locations).
CPU: Intel Core i7 4770k
GPU: ATI Radeon HD7770
RAM: 16GB
OS: Windows 8.1
Although I can get rid of the lag by simply changing my location, it is still an annoyance because the FPS is so low that clicking buttons becomes difficult, lol.
This huge spawn lag is only for the 1st log in the game once it has been launched:
there is no lag after we change the character, or even if we just disconnect and later reconnect and spawn,
but this first-spawning lag comes back after we quit the game to Windows and immediatly relaunch and then spawn.
Intel Core i3 3220, ATI Radeon HD 7770 1Gb, 8Go RAM, Win 8.1
As this spawn lag comes on logging after we actually had quit the game, and there is not this lag after we had disconnect without quiting, then I think it comes not from the game but from (useless?) Arc which should verify and synchronise the connection...
I started having this problem over the weekend. Basically the game is a slideshow when I first login until I turn the graphics way down. I thought I had tinkered with it to get it back to normal but I bet it was because I transitioned, not because I found some magic setting. I say that because no matter how good I seem to get it the next login is back to slideshow time.
Today I turned the graphics back down before exiting. I'll see if that keeps the lag fest from appearing on my next login.
I am not running Arc. I had to stop using that. When they make a "Close Arc on game connect" option I'll start using it again.
i get this problem also, it goes away either if you log off and back on, change maps which is hard because of lag, or if you wait a few minutes.
You are right. I had the same lag this morning despite the lower graphics setting so I was just patient and after a couple of minutes it smoothed right on out. I'm putting my graphics back where they were.
I still have no idea why this has suddenly started happening. My nettest and tracecert results are all in the above average to outstanding category per the post in the lag sticky. Ah well, I can live with it as long as it's only a short wait.
I was having this problem also,I was using Steam to open the game when it did.When I used Arc to get my free stuff I noticed I didn't have this problem anymore.I now use Arc to run STO.
Also if I alt+tab out of the game the game seems to be "Not responding" in the task manager. Also after a patch of the game the GameClient.exe was changed, therefore it was supposed to ask for permission from my firewall (ZoneAlarm free). It did ask for permission for outgoing access, but did not ask for incoming access during the freeze. The lag did not disappear after permitting outgoing access on the next start.
I think I have been having this issue as well. It starts about a week or two ago and occurs after toon selection after spawning into the game and the game seems to freeze up for 3-5 minutes and then everything is fine. I managed to type in /netgraph 1 and saw pings as high as 21K occurring. after the game unfroze, the pings returned to the normal 100 range
following instructions from another post I gathered this info about my connection
using ip address 208.286.32 (STO login server) as a target.
if anyone knows of a more suitable ip address to use please let me know
tracert:
Tracing route to 208.95.186.32 over a maximum of 30 hops
1 <1 ms 2 ms 1 ms 192.168.1.1
2 17 ms 19 ms 19 ms 195.215-34-174.res.dyn.surewest.net [174.34.215.195]
3 18 ms 19 ms 30 ms 172.21.2.57
4 18 ms 19 ms 19 ms 172.21.0.250
5 23 ms 24 ms 24 ms sjo-bb1-link.telia.net [213.248.88.73]
6 23 ms 24 ms 24 ms cogent-ic-144389-sjo-bb1.c.telia.net [80.239.196.190]
7 23 ms 24 ms 24 ms be2000.ccr21.sjc01.atlas.cogentco.com [154.54.6.105]
8 28 ms 25 ms 26 ms be2164.ccr21.sfo01.atlas.cogentco.com [154.54.28.33]
9 72 ms 69 ms 74 ms be2256.mpd21.mci01.atlas.cogentco.com [154.54.6.90]
10 92 ms 89 ms 89 ms be2158.mpd21.ord01.atlas.cogentco.com [154.54.7.130]
11 107 ms 104 ms 104 ms be2139.ccr21.bos01.atlas.cogentco.com [154.54.43.178]
12 105 ms 102 ms 106 ms te4-4.ccr01.bos06.atlas.cogentco.com [66.28.4.42]
13 101 ms 109 ms 104 ms 38.111.40.114
14 105 ms 106 ms 102 ms 208.95.186.32
Trace complete.
Pathping:
Tracing route to 208.95.186.32 over a maximum of 30 hops
working with my ISP, I was able to determine that the issue was not with my home network, router, or with the ISP connection. we were also able to rule out the internet path from my IP to the STO servers. it appears to be an issue with the STO servers
I did manage to log out once during this freeze and received this error message "You did not disconnect in 0 seconds. Good bye."
Star Treking, across the universe. Only going forward because we can't find reverse...
Ever since the Season 8 launch I have been having a problem where the game lags horrendously (1 or 2 FPS) in whatever area I first spawn in. This lag goes away when I load a new area such as beaming up to my ship, and it does not re appear if i beam back down to where I was. It only ever happens at the location I am in at the time when I first log in. This happens regardless of location (space or ground) and happens every single time I start the game.
I'll post my PC's specs here despite the fact that I seriously doubt that my specs are the issue (I get a solid 45 FPS at max settings once I change locations).
CPU: Intel Core i7 4770k
GPU: ATI Radeon HD7770
RAM: 16GB
OS: Windows 8.1
Although I can get rid of the lag by simply changing my location, it is still an annoyance because the FPS is so low that clicking buttons becomes difficult, lol.
Any help here would be great!
Thanks!
-VonFrank
I had a similar issue where I was just rubberbanding like crazy....
What fixed it for me was to update my ARC and since then the login has been super fast and gameplay normal with only the occasional lag.
I tried ARC for a while (for the free stuff) and experienced rubberbanding also. I uninstalled ARC and went back to using STEAM. since then no rubberbanding. but that issue is not related to this one.
Star Treking, across the universe. Only going forward because we can't find reverse...
working with my ISP, I was able to determine that the issue was not with my home network, router, or with the ISP connection. we were also able to rule out the internet path from my IP to the STO servers. it appears to be an issue with the STO servers
With 'Path Ping' reporting very bad packet drop on hops #3 and #4, it certainly doesn't look like a STO Sever problem, and looks more like a issue with your ISP connection to its peer backbone provider...
Its look like you need to have another talk with your ISP about this...
according to my ISP, and verified by myself, the 172.21.x.x addresses belong to IANA or Internet Assigned Numbers Authority, which oversees global IP address allocation, autonomous system number allocation, root zone management in the Domain Name System (DNS), media types, and other Internet Protocol-related symbols and numbers I am not sure why my traffic goes from IANA to a backbone service in Europe. but it appears all traffic is setup to do this. I am definitely going to inquire my ISP about this. the addresses that end with coagentco.com are STO/PWI servers. It could be that the IANA addresses are not meant to be pingable due to their importance to the internet as a security feature.
Star Treking, across the universe. Only going forward because we can't find reverse...
according to my ISP, and verified by myself, the 172.21.x.x addresses belong to IANA or Internet Assigned Numbers Authority, which oversees global IP address allocation, autonomous system number allocation, root zone management in the Domain Name System (DNS), media types, and other Internet Protocol-related symbols and numbers I am not sure why my traffic goes from IANA to a backbone service in Europe. but it appears all traffic is setup to do this. I am definitely going to inquire my ISP about this. the addresses that end with coagentco.com are STO/PWI servers. It could be that the IANA addresses are not meant to be pingable due to their importance to the internet as a security feature.
Almost correct. 172.16.X.Y is part of the Block of address that the IANA & IETF have set aside for use for 'Private Network Address' as defined in the Internet Standards Document RFC 1918... Your 192.168.1.X address is another example of a 'Private Network' block used by local routers for home networks behind a firewall...
So the address, strictly speaking, doesn't belong to the IANA, its set aside for use by anyone for building Private Address networks...
(Which does bring up the question on why your ISP is routing a Public Internet Addressed network via a private block addressed router... but...)
But back to the subject at hand. There is no doubt that those two hops are being run by your ISP, and not the IANA, so it still looks like you need to have a talk with your ISP over this...
the path ping is redirected to my network. the 174.34.215.195 address that is unreachable using path ping is reachable using a ping command. 174.34.215.195 is the surewest DNS server
doing a tracert to 174.34.215.195 is also successful.
Tracing route to 195.215-34-174.res.dyn.surewest.net [174.34.215.195]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 18 ms 19 ms 19 ms 195.215-34-174.res.dyn.surewest.net [174.34.215.
195]
Trace complete.
I believe the unreachable ip addresses (except the cogentco.com addresses) discussed are unreachable for security reasons. I know I have been working the last few months with my ISP because I keep getting DDOS'ed.
I have already changed my external IP address twice and it has not helped with that. but restricting the types of traffic the servers will respond to, would likely strengthen security against such attacks
Star Treking, across the universe. Only going forward because we can't find reverse...
NetRange: 172.16.0.0 - 172.31.255.255
CIDR: 172.16.0.0/12
OriginAS:
NetName: PRIVATE-ADDRESS-BBLK-RFC1918-IANA-RESERVED
NetHandle: NET-172-16-0-0-1
Parent: NET-172-0-0-0-0
NetType: IANA Special Use
Comment: These addresses are in use by many millions of independently operated networks, which might be as small as a single computer connected to a home gateway, and are automatically configured in hundreds of millions of devices. They are only intended for use within a private context and traffic that needs to cross the Internet will need to use a different, unique address.
Comment:
Comment:
Comment: These addresses were assigned by the IETF, the organization that develops Internet protocols, in the Best Current Practice document, RFC 1918 which can be found at
RegDate: 1994-03-15
Updated: 2013-08-30
OrgName: Internet Assigned Numbers Authority
OrgId: IANA
Address: 12025 Waterfront Drive
Address: Suite 300
City: Los Angeles
StateProv: CA
PostalCode: 90292
Country: US
RegDate:
Updated: 2012-08-31
OrgAbuseHandle: IANA-IP-ARIN
OrgAbuseName: Internet Corporation for Assigned Names and Number
OrgAbusePhone: +1-310-301-5820
OrgAbuseEmail:
OrgTechHandle: IANA-IP-ARIN
OrgTechName: Internet Corporation for Assigned Names and Number
OrgTechPhone: +1-310-301-5820
OrgTechEmail:
IP:
Examples: 127.0.0.1, 192.168.1.1
NetRange: 174.34.192.0 - 174.34.223.255
CIDR: 174.34.192.0/19
OriginAS: AS14051, AS20172
NetName: SUREWEST-BROADBAND
NetHandle: NET-174-34-192-0-1
Parent: NET-174-0-0-0-0
NetType: Direct Allocation
RegDate: 2008-10-30
Updated: 2009-11-03
OrgName: SureWest Broadband
OrgId: SUREW
Address: 8150 Industrial Ave.
City: Roseville
StateProv: CA
PostalCode: 95678
Country: US
RegDate: 2002-11-05
Updated: 2013-02-28
Comment: For 24 hour technical support call 1.866.SureWest(1.866.787.3937)
OrgAbuseHandle: ABUSE57-ARIN
OrgAbuseName: Abuse Department
OrgAbusePhone: +1-916-772-5000
OrgAbuseEmail:
OrgTechHandle: SBIA-ARIN
OrgTechName: SureWest Broadband IP Admin
OrgTechPhone: +1-916-772-2000
OrgTechEmail:
RAbuseHandle: SBIA-ARIN
RAbuseName: SureWest Broadband IP Admin
RAbusePhone: +1-916-772-2000
RAbuseEmail:
RTechHandle: SBIA-ARIN
RTechName: SureWest Broadband IP Admin
RTechPhone: +1-916-772-2000
RTechEmail:
Star Treking, across the universe. Only going forward because we can't find reverse...
the path ping is redirected to my network. the 174.34.215.195 address that is unreachable using path ping is reachable using a ping command. 174.34.215.195 is the surewest DNS server
doing a tracert to 174.34.215.195 is also successful.
Tracing route to 195.215-34-174.res.dyn.surewest.net [174.34.215.195]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 18 ms 19 ms 19 ms 195.215-34-174.res.dyn.surewest.net [174.34.215.
195]
Trace complete.
I believe the unreachable ip addresses (except the cogentco.com addresses) discussed are unreachable for security reasons. I know I have been working the last few months with my ISP because I keep getting DDOS'ed.
I have already changed my external IP address twice and it has not helped with that. but restricting the types of traffic the servers will respond to, would likely strengthen security against such attacks
This is not surprising at all. As stated in the document RFC 1918, addresses in the allocated block of 'Private Address Space' must never be reachable from the Public Internet. This is also the reason why you cannot connect to someone 192.168.1.1 address router other then your own. So its not a Security feature that is doing this, its a property of the Private Address Space...
I flushed my DNS cache and reset my winsock and TCP stacks. ialso changed my DNS to googles DNS addresses. I then diabled my BF4 abd BFP4F browser extensions. that seems to have cleaned up of some of the extra entries in my tracert's and pathping's. the according to my ISP, the 172.TRIBBLE.TRIBBLE.TRIBBLE ip's is just data moving from one part of the network to another part and, are not meaant to respond to requests
Tracert:
Tracing route to 208.95.186.32 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.1.1
2 17 ms 17 ms 18 ms 195.215-34-174.res.dyn.surewest.net [174.34.215.195]
3 21 ms 23 ms 19 ms 172.21.2.57
4 23 ms 17 ms 19 ms 172.21.0.250
5 22 ms 24 ms 24 ms sjo-bb1-link.telia.net [213.248.88.73]
6 23 ms 23 ms 23 ms cogent-ic-144389-sjo-bb1.c.telia.net [80.239.196.190]
7 26 ms 24 ms 24 ms be2000.ccr21.sjc01.atlas.cogentco.com [154.54.6.105]
8 27 ms 25 ms 28 ms be2164.ccr21.sfo01.atlas.cogentco.com [154.54.28.33]
9 71 ms 69 ms 69 ms be2256.mpd21.mci01.atlas.cogentco.com [154.54.6.90]
10 92 ms 88 ms 89 ms be2158.mpd21.ord01.atlas.cogentco.com [154.54.7.130]
11 102 ms 102 ms 106 ms be2139.ccr21.bos01.atlas.cogentco.com [154.54.43.178]
12 104 ms 104 ms 103 ms te3-4.ccr01.bos06.atlas.cogentco.com [154.54.46.134]
13 106 ms 104 ms 108 ms 38.111.40.114
14 105 ms 106 ms 106 ms 208.95.186.32
Trace complete.
the ip's with the cogentco.com are all PWE/STO owned servers
Pathping:
Tracing route to 208.95.186.32 over a maximum of 30 hops
so, I once again iterate that this issue is probably caused by some sort STO/PWE server issue
And the 'Path Ping' results still disagree with you... It looks like there is serious congestion causing packets to be lost on the Telia.net gateway to the Cogent backbone, as well as some congestion issues on the Cogent backbone itself...
Now back to grinding for Dilithium in the Dyson Battlezone with my Alts...
telia is a gateway used by many MMO's to aid in the login process or something. Apparently STO uses this service as well simply opening the launcher creates a connection to telia that does not close until the game is closed completely and the dns cache is flushed (ipconfig /flushdns) running a tracert and a pathping gives the above results, even after flushing the dns cache. running a tracert after dns flush to google.com gives this:
Tracing route to google.com [216.93.235.245]
over a maximum of 30 hops:
1 1 ms <1 ms <1 ms 192.168.1.1
2 19 ms 19 ms 16 ms 195.215-34-174.res.dyn.surewest.net [174.34.215.195]
3 21 ms 18 ms 19 ms 172.21.2.57
4 21 ms 19 ms 19 ms 245.235-93-216-nokia-dsl.dynamic.surewest.net [216.93.235.245]
Trace complete.
Cogent appears to be the ISP that PWE/STO uses.
To me, this reveals that the problem is not with my netwrk, or my ISP
Star Treking, across the universe. Only going forward because we can't find reverse...
I'm not sure I am interpreting the results right, but it would appear that the results all fall well within acceptable ranges
Acceptable range should be around 300 - 500 KB/sec or better for the first and third columns. It looks like your results are lacking... Most likely from the 'packet drop' along your connection route.
As an example of a good results, this is what I'm getting this morning...
ok thanks, I think your right now that I see your results.
since the problem seems to be occurring when the traffic enters control of the ISP/network that STO uses, I will open a ticket.
Anybody else who is also having this issue, I strongly urge you to do so also. it looks you should include the tracert, pathping, and the nettest output in the ticket. the link to download the nettest program can be found in the stickyed lag and rubberbanding thread.
Star Treking, across the universe. Only going forward because we can't find reverse...
Major Major lag, and stuttering going on. Ive reinstalled the game twice now with no change. Ive tried to switch zones, logged off and on, and still getting this notorious lag in game.. to the point of unenjoyable and unplayable.
Tracing route to patchserver.crypticstudios.com [208.95.185.41]
over a maximum of 30 hops:
1 2 ms <1 ms <1 ms 192.168.0.1
2 * * * Request timed out.
3 12 ms 12 ms 10 ms rd1cv-tge0-5-5-0-1.gv.shawcable.net [64.59.162.209]
4 20 ms 15 ms 16 ms rc5wt-tge0-10-0-8.wa.shawcable.net [66.163.75.162]
5 43 ms 11 ms 14 ms sea-b1-link.telia.net [213.248.102.245]
6 11 ms 11 ms 12 ms cogent-ic-153318-sea-b1.c.telia.net [213.248.86.146]
7 45 ms 43 ms 45 ms be2085.ccr21.slc01.atlas.cogentco.com [154.54.2.198]
8 74 ms 75 ms 74 ms be2126.ccr21.den01.atlas.cogentco.com [154.54.25.65]
9 75 ms 75 ms 74 ms be2130.ccr22.mci01.atlas.cogentco.com [154.54.26.122]
10 62 ms 61 ms 61 ms be2158.mpd21.ord01.atlas.cogentco.com [154.54.7.130]
11 87 ms 87 ms 87 ms be2137.ccr21.bos01.atlas.cogentco.com [154.54.43.194]
12 88 ms 91 ms 88 ms te3-2.ccr01.bos06.atlas.cogentco.com [154.54.46.130]
13 91 ms 86 ms 89 ms 38.111.40.114
14 87 ms 86 ms 86 ms patchserver2.crypticstudios.com [208.95.185.41]
I have been using the steam version of STO since it was rereleased as f2p. On a whim I uninstalled the steam version and installed the version from startrekonline.com (which now unfortunetly includes the ARC client). after I got the arc client installed and the game up and running, I logged intop the game, AND THE SPAWN LAG WAS GONE!!!! I am not sure what to make of this. ther maybe an issue with the steam version of STO.
If you want to try this but want to skip having to redownloading the game, follow these instructions. It is what I did, and it should work for you too.
First, make sure the ARC client is uninstalled
go to your steamapps\common folder and rename the "star trek online folder to "star trek online.temp"
next create a new folder called "star trek online" in the steamapps\common folder.
copy the "Uninstall Star Trek Online.exe" from the startrek online.temp to the new star trek online folder. once it is copied. execute it.
Now you system thinks STO is uninstalled, but you still have all the game files.
Next, goto www.startrekonline.com and click the product page link, and begin download of the STO installer (it is really the stupid ARC client)
If you have never used ARC before, then you have some further setup to do. finish that then go to the next step
tell the ARC client to install STO. A small download will begin. this is the STO launcher files. while the files are downloading, go back to the "steamapps\common\star trek online.temp\ folder.
there is a folder called "Star Trek Online" inside of the "star trek online.temp" folder. Right click on the folder and select copy.
next go bring up the folder"C:\Program Files (x86)\Perfect World Entertainment\Star Trek Online_en"
once inside of the "Star Trek Online_en" folder, right click where the files and folders usually appear and click paste.
Windows will now begin copying the STO game files. on my system it took around 11 minutes or so to copy the files. it may take more or less time depending on your system specifications.
once the files are copied, tell ARC to launch the game.
Once the STO launcher is up, tell it to verify the game files. assuming there were no errors during the file tranfer and there were no corrupt files to begin with, the scan will take about as long as it normally does when is performs a scan and finds nothing wrong.
Once verification is completed, patch the game if needed and then launch the game. you will most likely need to re-set all the options for the game.
Troubleshooting
on my system, the ARC client would not launch the games launcher like it should at first. so i downloaded the latest launcher from here :
" http://files.startrekonline.com/launcher/Star Trek Online.exe " and placed it in the Star Trek Online_en folder. i then told ARC to launch STO, and the Launcher did an update, and then it came up as it should.
As a last step you may delete the newly created star trek online folder in "steamapps\common\" and then rename "star trek online.temp" back to "star trek online" the Steam client doesn't even seem to notice all the tom foolery that has been going on, so you can use the regular (ARC) version of STO, or use the Steam version of STO.
please let me know if this solves the problem for you too
Star Treking, across the universe. Only going forward because we can't find reverse...
Comments
there is no lag after we change the character, or even if we just disconnect and later reconnect and spawn,
but this first-spawning lag comes back after we quit the game to Windows and immediatly relaunch and then spawn.
Intel Core i3 3220, ATI Radeon HD 7770 1Gb, 8Go RAM, Win 8.1
If two of us have the issue then there must be hundreds of silent players out there with the same problem.
Today I turned the graphics back down before exiting. I'll see if that keeps the lag fest from appearing on my next login.
I am not running Arc. I had to stop using that. When they make a "Close Arc on game connect" option I'll start using it again.
You are right. I had the same lag this morning despite the lower graphics setting so I was just patient and after a couple of minutes it smoothed right on out. I'm putting my graphics back where they were.
I still have no idea why this has suddenly started happening. My nettest and tracecert results are all in the above average to outstanding category per the post in the lag sticky. Ah well, I can live with it as long as it's only a short wait.
So, from our answers, it seems coming nor from graphics, Arc, Steam, net provider, nor firewall. What's the mess??
http://www.pingtest.net/result/95126601.png
http://www.speedtest.net/result/3394345029.png
following instructions from another post I gathered this info about my connection
using ip address 208.286.32 (STO login server) as a target.
if anyone knows of a more suitable ip address to use please let me know
tracert:
Tracing route to 208.95.186.32 over a maximum of 30 hops
1 <1 ms 2 ms 1 ms 192.168.1.1
2 17 ms 19 ms 19 ms 195.215-34-174.res.dyn.surewest.net [174.34.215.195]
3 18 ms 19 ms 30 ms 172.21.2.57
4 18 ms 19 ms 19 ms 172.21.0.250
5 23 ms 24 ms 24 ms sjo-bb1-link.telia.net [213.248.88.73]
6 23 ms 24 ms 24 ms cogent-ic-144389-sjo-bb1.c.telia.net [80.239.196.190]
7 23 ms 24 ms 24 ms be2000.ccr21.sjc01.atlas.cogentco.com [154.54.6.105]
8 28 ms 25 ms 26 ms be2164.ccr21.sfo01.atlas.cogentco.com [154.54.28.33]
9 72 ms 69 ms 74 ms be2256.mpd21.mci01.atlas.cogentco.com [154.54.6.90]
10 92 ms 89 ms 89 ms be2158.mpd21.ord01.atlas.cogentco.com [154.54.7.130]
11 107 ms 104 ms 104 ms be2139.ccr21.bos01.atlas.cogentco.com [154.54.43.178]
12 105 ms 102 ms 106 ms te4-4.ccr01.bos06.atlas.cogentco.com [66.28.4.42]
13 101 ms 109 ms 104 ms 38.111.40.114
14 105 ms 106 ms 102 ms 208.95.186.32
Trace complete.
Pathping:
Tracing route to 208.95.186.32 over a maximum of 30 hops
0 ChrisSolomon-PC [192.168.1.7]
1 192.168.1.1
2 195.215-34-174.res.dyn.surewest.net [174.34.215.195]
3 172.21.2.57
4 172.21.0.250
5 sjo-bb1-link.telia.net [213.248.88.73]
6 cogent-ic-144389-sjo-bb1.c.telia.net [80.239.196.190]
7 be2000.ccr21.sjc01.atlas.cogentco.com [154.54.6.105]
8 be2164.ccr21.sfo01.atlas.cogentco.com [154.54.28.33]
9 be2256.mpd21.mci01.atlas.cogentco.com [154.54.6.90]
10 be2158.mpd21.ord01.atlas.cogentco.com [154.54.7.130]
11 be2139.ccr21.bos01.atlas.cogentco.com [154.54.43.178]
12 te4-4.ccr01.bos06.atlas.cogentco.com [66.28.4.42]
13 38.111.40.114
14 208.95.186.32
Computing statistics for 350 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 ChrisSolomon-PC [192.168.1.7]
0/ 100 = 0% |
1 0ms 0/ 100 = 0% 0/ 100 = 0% 192.168.1.1
0/ 100 = 0% |
2 23ms 0/ 100 = 0% 0/ 100 = 0% 195.215-34-174.res.dyn.surewest.net [174.34.215.195]
0/ 100 = 0% |
3 --- 100/ 100 =100% 100/ 100 =100% 172.21.2.57
0/ 100 = 0% |
4 --- 100/ 100 =100% 100/ 100 =100% 172.21.0.250
0/ 100 = 0% |
5 24ms 0/ 100 = 0% 0/ 100 = 0% sjo-bb1-link.telia.net [213.248.88.73]
0/ 100 = 0% |
6 25ms 0/ 100 = 0% 0/ 100 = 0% cogent-ic-144389-sjo-bb1.c.telia.net [80.239.196.190]
0/ 100 = 0% |
7 --- 100/ 100 =100% 100/ 100 =100% be2000.ccr21.sjc01.atlas.cogentco.com [154.54.6.105]
0/ 100 = 0% |
8 26ms 0/ 100 = 0% 0/ 100 = 0% be2164.ccr21.sfo01.atlas.cogentco.com [154.54.28.33]
0/ 100 = 0% |
9 --- 100/ 100 =100% 100/ 100 =100% be2256.mpd21.mci01.atlas.cogentco.com [154.54.6.90]
0/ 100 = 0% |
10 --- 100/ 100 =100% 100/ 100 =100% be2158.mpd21.ord01.atlas.cogentco.com [154.54.7.130]
0/ 100 = 0% |
11 104ms 0/ 100 = 0% 0/ 100 = 0% be2139.ccr21.bos01.atlas.cogentco.com [154.54.43.178]
0/ 100 = 0% |
12 --- 100/ 100 =100% 100/ 100 =100% te4-4.ccr01.bos06.atlas.cogentco.com [66.28.4.42]
0/ 100 = 0% |
13 108ms 0/ 100 = 0% 0/ 100 = 0% 38.111.40.114
0/ 100 = 0% |
14 105ms 0/ 100 = 0% 0/ 100 = 0% 208.95.186.32
Trace complete.
working with my ISP, I was able to determine that the issue was not with my home network, router, or with the ISP connection. we were also able to rule out the internet path from my IP to the STO servers. it appears to be an issue with the STO servers
I did manage to log out once during this freeze and received this error message "You did not disconnect in 0 seconds. Good bye."
I had a similar issue where I was just rubberbanding like crazy....
What fixed it for me was to update my ARC and since then the login has been super fast and gameplay normal with only the occasional lag.
With 'Path Ping' reporting very bad packet drop on hops #3 and #4, it certainly doesn't look like a STO Sever problem, and looks more like a issue with your ISP connection to its peer backbone provider...
Its look like you need to have another talk with your ISP about this...
Almost correct. 172.16.X.Y is part of the Block of address that the IANA & IETF have set aside for use for 'Private Network Address' as defined in the Internet Standards Document RFC 1918... Your 192.168.1.X address is another example of a 'Private Network' block used by local routers for home networks behind a firewall...
http://en.wikipedia.org/wiki/Private_network
So the address, strictly speaking, doesn't belong to the IANA, its set aside for use by anyone for building Private Address networks...
(Which does bring up the question on why your ISP is routing a Public Internet Addressed network via a private block addressed router... but...)
But back to the subject at hand. There is no doubt that those two hops are being run by your ISP, and not the IANA, so it still looks like you need to have a talk with your ISP over this...
Tracing route to 172.21.2.57 over a maximum of 30 hops
0 ChrisSolomon-PC [192.168.1.7]
1 192.168.1.1
2 * 195.215-34-174.res.dyn.surewest.net [174.34.215.195] reports: Des
tination net unreachable.
Computing statistics for 50 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 ChrisSolomon-PC [192.168.1.7]
0/ 100 = 0% |
1 0ms 0/ 100 = 0% 0/ 100 = 0% 192.168.1.1
100/ 100 =100% |
2 --- 100/ 100 =100% 0/ 100 = 0% ChrisSolomon-PC [0.0.0.0]
Trace complete.
the path ping is redirected to my network. the 174.34.215.195 address that is unreachable using path ping is reachable using a ping command. 174.34.215.195 is the surewest DNS server
doing a tracert to 174.34.215.195 is also successful.
Tracing route to 195.215-34-174.res.dyn.surewest.net [174.34.215.195]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.1
2 18 ms 19 ms 19 ms 195.215-34-174.res.dyn.surewest.net [174.34.215.
195]
Trace complete.
I believe the unreachable ip addresses (except the cogentco.com addresses) discussed are unreachable for security reasons. I know I have been working the last few months with my ISP because I keep getting DDOS'ed.
I have already changed my external IP address twice and it has not helped with that. but restricting the types of traffic the servers will respond to, would likely strengthen security against such attacks
CIDR: 172.16.0.0/12
OriginAS:
NetName: PRIVATE-ADDRESS-BBLK-RFC1918-IANA-RESERVED
NetHandle: NET-172-16-0-0-1
Parent: NET-172-0-0-0-0
NetType: IANA Special Use
Comment: These addresses are in use by many millions of independently operated networks, which might be as small as a single computer connected to a home gateway, and are automatically configured in hundreds of millions of devices. They are only intended for use within a private context and traffic that needs to cross the Internet will need to use a different, unique address.
Comment:
Comment:
Comment: These addresses were assigned by the IETF, the organization that develops Internet protocols, in the Best Current Practice document, RFC 1918 which can be found at
RegDate: 1994-03-15
Updated: 2013-08-30
OrgName: Internet Assigned Numbers Authority
OrgId: IANA
Address: 12025 Waterfront Drive
Address: Suite 300
City: Los Angeles
StateProv: CA
PostalCode: 90292
Country: US
RegDate:
Updated: 2012-08-31
OrgAbuseHandle: IANA-IP-ARIN
OrgAbuseName: Internet Corporation for Assigned Names and Number
OrgAbusePhone: +1-310-301-5820
OrgAbuseEmail:
OrgTechHandle: IANA-IP-ARIN
OrgTechName: Internet Corporation for Assigned Names and Number
OrgTechPhone: +1-310-301-5820
OrgTechEmail:
IP:
Examples: 127.0.0.1, 192.168.1.1
NetRange: 174.34.192.0 - 174.34.223.255
CIDR: 174.34.192.0/19
OriginAS: AS14051, AS20172
NetName: SUREWEST-BROADBAND
NetHandle: NET-174-34-192-0-1
Parent: NET-174-0-0-0-0
NetType: Direct Allocation
RegDate: 2008-10-30
Updated: 2009-11-03
OrgName: SureWest Broadband
OrgId: SUREW
Address: 8150 Industrial Ave.
City: Roseville
StateProv: CA
PostalCode: 95678
Country: US
RegDate: 2002-11-05
Updated: 2013-02-28
Comment: For 24 hour technical support call 1.866.SureWest(1.866.787.3937)
OrgAbuseHandle: ABUSE57-ARIN
OrgAbuseName: Abuse Department
OrgAbusePhone: +1-916-772-5000
OrgAbuseEmail:
OrgTechHandle: SBIA-ARIN
OrgTechName: SureWest Broadband IP Admin
OrgTechPhone: +1-916-772-2000
OrgTechEmail:
RAbuseHandle: SBIA-ARIN
RAbuseName: SureWest Broadband IP Admin
RAbusePhone: +1-916-772-2000
RAbuseEmail:
RTechHandle: SBIA-ARIN
RTechName: SureWest Broadband IP Admin
RTechPhone: +1-916-772-2000
RTechEmail:
This is not surprising at all. As stated in the document RFC 1918, addresses in the allocated block of 'Private Address Space' must never be reachable from the Public Internet. This is also the reason why you cannot connect to someone 192.168.1.1 address router other then your own. So its not a Security feature that is doing this, its a property of the Private Address Space...
Tracert:
Tracing route to 208.95.186.32 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms 192.168.1.1
2 17 ms 17 ms 18 ms 195.215-34-174.res.dyn.surewest.net [174.34.215.195]
3 21 ms 23 ms 19 ms 172.21.2.57
4 23 ms 17 ms 19 ms 172.21.0.250
5 22 ms 24 ms 24 ms sjo-bb1-link.telia.net [213.248.88.73]
6 23 ms 23 ms 23 ms cogent-ic-144389-sjo-bb1.c.telia.net [80.239.196.190]
7 26 ms 24 ms 24 ms be2000.ccr21.sjc01.atlas.cogentco.com [154.54.6.105]
8 27 ms 25 ms 28 ms be2164.ccr21.sfo01.atlas.cogentco.com [154.54.28.33]
9 71 ms 69 ms 69 ms be2256.mpd21.mci01.atlas.cogentco.com [154.54.6.90]
10 92 ms 88 ms 89 ms be2158.mpd21.ord01.atlas.cogentco.com [154.54.7.130]
11 102 ms 102 ms 106 ms be2139.ccr21.bos01.atlas.cogentco.com [154.54.43.178]
12 104 ms 104 ms 103 ms te3-4.ccr01.bos06.atlas.cogentco.com [154.54.46.134]
13 106 ms 104 ms 108 ms 38.111.40.114
14 105 ms 106 ms 106 ms 208.95.186.32
Trace complete.
the ip's with the cogentco.com are all PWE/STO owned servers
Pathping:
Tracing route to 208.95.186.32 over a maximum of 30 hops
0 ChrisSolomon-PC [192.168.1.7]
1 192.168.1.1
2 195.215-34-174.res.dyn.surewest.net [174.34.215.195]
3 172.21.2.57
4 172.21.0.250
5 sjo-bb1-link.telia.net [213.248.88.73]
6 cogent-ic-144389-sjo-bb1.c.telia.net [80.239.196.190]
7 be2000.ccr21.sjc01.atlas.cogentco.com [154.54.6.105]
8 be2164.ccr21.sfo01.atlas.cogentco.com [154.54.28.33]
9 be2256.mpd21.mci01.atlas.cogentco.com [154.54.6.90]
10 be2158.mpd21.ord01.atlas.cogentco.com [154.54.7.130]
11 be2139.ccr21.bos01.atlas.cogentco.com [154.54.43.178]
12 te3-4.ccr01.bos06.atlas.cogentco.com [154.54.46.134]
13 38.111.40.114
14 208.95.186.32
Computing statistics for 350 seconds...
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0 ChrisSolomon-PC [192.168.1.7]
0/ 100 = 0% |
1 0ms 0/ 100 = 0% 0/ 100 = 0% 192.168.1.1
0/ 100 = 0% |
2 20ms 0/ 100 = 0% 0/ 100 = 0% 195.215-34-174.res.dyn.surewest.net [174.34.215.195]
0/ 100 = 0% |
3 --- 100/ 100 =100% 100/ 100 =100% 172.21.2.57
0/ 100 = 0% |
4 --- 100/ 100 =100% 100/ 100 =100% 172.21.0.250
0/ 100 = 0% |
5 25ms 0/ 100 = 0% 0/ 100 = 0% sjo-bb1-link.telia.net [213.248.88.73]
0/ 100 = 0% |
6 25ms 0/ 100 = 0% 0/ 100 = 0% cogent-ic-144389-sjo-bb1.c.telia.net [80.239.196.190]
0/ 100 = 0% |
7 --- 100/ 100 =100% 100/ 100 =100% be2000.ccr21.sjc01.atlas.cogentco.com [154.54.6.105]
0/ 100 = 0% |
8 26ms 0/ 100 = 0% 0/ 100 = 0% be2164.ccr21.sfo01.atlas.cogentco.com [154.54.28.33]
0/ 100 = 0% |
9 --- 100/ 100 =100% 100/ 100 =100% be2256.mpd21.mci01.atlas.cogentco.com [154.54.6.90]
0/ 100 = 0% |
10 --- 100/ 100 =100% 100/ 100 =100% be2158.mpd21.ord01.atlas.cogentco.com [154.54.7.130]
0/ 100 = 0% |
11 104ms 0/ 100 = 0% 0/ 100 = 0% be2139.ccr21.bos01.atlas.cogentco.com [154.54.43.178]
0/ 100 = 0% |
12 122ms 0/ 100 = 0% 0/ 100 = 0% te3-4.ccr01.bos06.atlas.cogentco.com [154.54.46.134]
0/ 100 = 0% |
13 108ms 0/ 100 = 0% 0/ 100 = 0% 38.111.40.114
0/ 100 = 0% |
14 104ms 0/ 100 = 0% 0/ 100 = 0% 208.95.186.32
Trace complete.
so, I once again iterate that this issue is probably caused by some sort STO/PWE server issue
STO is due for maintainenc tomorrow, so hopefully that will fix this issue
And the 'Path Ping' results still disagree with you... It looks like there is serious congestion causing packets to be lost on the Telia.net gateway to the Cogent backbone, as well as some congestion issues on the Cogent backbone itself...
Now back to grinding for Dilithium in the Dyson Battlezone with my Alts...
Tracing route to google.com [216.93.235.245]
over a maximum of 30 hops:
1 1 ms <1 ms <1 ms 192.168.1.1
2 19 ms 19 ms 16 ms 195.215-34-174.res.dyn.surewest.net [174.34.215.195]
3 21 ms 18 ms 19 ms 172.21.2.57
4 21 ms 19 ms 19 ms 245.235-93-216-nokia-dsl.dynamic.surewest.net [216.93.235.245]
Trace complete.
Cogent appears to be the ISP that PWE/STO uses.
To me, this reveals that the problem is not with my netwrk, or my ISP
contacting nettest server..
Local IP: 69.4.138.166
Ping: 111.6 msec
Port: 80: 127 KB/sec 6 KB/sec 134 KB/sec 500
Port: 80: 115 KB/sec 5 KB/sec 122 KB/sec 500
Port: 443: 146 KB/sec 6 KB/sec 155 KB/sec 500
Port: 443: 61 KB/sec 3 KB/sec 65 KB/sec 500
Port: 7255: 80 KB/sec 5 KB/sec 87 KB/sec 500
Port: 7255: 259 KB/sec 11 KB/sec 276 KB/sec 500
Port: 7003: 98 KB/sec 5 KB/sec 106 KB/sec 500
Port: 7003: 270 KB/sec 11 KB/sec 286 KB/sec 500
Port: 7202: 112 KB/sec 5 KB/sec 119 KB/sec 500
Port: 7202: 432 KB/sec 16 KB/sec 457 KB/sec 500
Port: 7499: 126 KB/sec 6 KB/sec 137 KB/sec 500
Port: 7499: 434 KB/sec 16 KB/sec 458 KB/sec 500
Port: 80: 130 KB/sec 6 KB/sec 139 KB/sec 500
Idle NIC bandwidth Send: 0 KB/sec Recv: 0 KB/sec
hit return to exit
I'm not sure I am interpreting the results right, but it would appear that the results all fall well within acceptable ranges
Acceptable range should be around 300 - 500 KB/sec or better for the first and third columns. It looks like your results are lacking... Most likely from the 'packet drop' along your connection route.
As an example of a good results, this is what I'm getting this morning...
contacting nettest server..
Local IP: 50.161.x.y
Ping: 85.7 msec
Port: 80: 679 KB/sec 24 KB/sec 716 KB/sec 500
Port: 80: 662 KB/sec 22 KB/sec 696 KB/sec 500
Port: 443: 666 KB/sec 23 KB/sec 700 KB/sec 500
Port: 443: 663 KB/sec 20 KB/sec 698 KB/sec 500
Port: 7255: 628 KB/sec 21 KB/sec 662 KB/sec 500
Port: 7255: 669 KB/sec 23 KB/sec 703 KB/sec 500
Port: 7003: 671 KB/sec 23 KB/sec 706 KB/sec 500
Port: 7003: 676 KB/sec 22 KB/sec 712 KB/sec 500
Port: 7202: 673 KB/sec 23 KB/sec 708 KB/sec 500
Port: 7202: 671 KB/sec 23 KB/sec 707 KB/sec 500
Port: 7499: 664 KB/sec 23 KB/sec 699 KB/sec 500
Port: 7499: 669 KB/sec 23 KB/sec 703 KB/sec 500
Port: 80: 673 KB/sec 23 KB/sec 708 KB/sec 500
Idle NIC bandwidth Send: 0 KB/sec Recv: 0 KB/sec
hit return to exit
since the problem seems to be occurring when the traffic enters control of the ISP/network that STO uses, I will open a ticket.
Anybody else who is also having this issue, I strongly urge you to do so also. it looks you should include the tracert, pathping, and the nettest output in the ticket. the link to download the nettest program can be found in the stickyed lag and rubberbanding thread.
Tracing route to patchserver.crypticstudios.com [208.95.185.41]
over a maximum of 30 hops:
1 2 ms <1 ms <1 ms 192.168.0.1
2 * * * Request timed out.
3 12 ms 12 ms 10 ms rd1cv-tge0-5-5-0-1.gv.shawcable.net [64.59.162.209]
4 20 ms 15 ms 16 ms rc5wt-tge0-10-0-8.wa.shawcable.net [66.163.75.162]
5 43 ms 11 ms 14 ms sea-b1-link.telia.net [213.248.102.245]
6 11 ms 11 ms 12 ms cogent-ic-153318-sea-b1.c.telia.net [213.248.86.146]
7 45 ms 43 ms 45 ms be2085.ccr21.slc01.atlas.cogentco.com [154.54.2.198]
8 74 ms 75 ms 74 ms be2126.ccr21.den01.atlas.cogentco.com [154.54.25.65]
9 75 ms 75 ms 74 ms be2130.ccr22.mci01.atlas.cogentco.com [154.54.26.122]
10 62 ms 61 ms 61 ms be2158.mpd21.ord01.atlas.cogentco.com [154.54.7.130]
11 87 ms 87 ms 87 ms be2137.ccr21.bos01.atlas.cogentco.com [154.54.43.194]
12 88 ms 91 ms 88 ms te3-2.ccr01.bos06.atlas.cogentco.com [154.54.46.130]
13 91 ms 86 ms 89 ms 38.111.40.114
14 87 ms 86 ms 86 ms patchserver2.crypticstudios.com [208.95.185.41]
Trace complete.
contacting nettest server..
Ping: 85.7 msec
Port: 80: 360 KB/sec 52 KB/sec 4664 KB/sec 500
Port: 80: 472 KB/sec 58 KB/sec 5344 KB/sec 500
Port: 443: 304 KB/sec 59 KB/sec 5762 KB/sec 500
Port: 443: 347 KB/sec 66 KB/sec 6286 KB/sec 500
Port: 7255: 364 KB/sec 55 KB/sec 4681 KB/sec 500
Port: 7255: 337 KB/sec 39 KB/sec 3956 KB/sec 500
Port: 7003: 324 KB/sec 67 KB/sec 5692 KB/sec 500
Port: 7003: 331 KB/sec 106 KB/sec 10200 KB/sec 500
Port: 7202: 349 KB/sec 114 KB/sec 10605 KB/sec 500
Port: 7202: 321 KB/sec 90 KB/sec 8333 KB/sec 500
Port: 7499: 321 KB/sec 82 KB/sec 7920 KB/sec 500
Port: 7499: 444 KB/sec 106 KB/sec 9067 KB/sec 500
Port: 80: 403 KB/sec 117 KB/sec 10692 KB/sec 500
Idle NIC bandwidth Send: 136 KB/sec Recv: 11704 KB/sec
hit return to exit
I have been using the steam version of STO since it was rereleased as f2p. On a whim I uninstalled the steam version and installed the version from startrekonline.com (which now unfortunetly includes the ARC client). after I got the arc client installed and the game up and running, I logged intop the game, AND THE SPAWN LAG WAS GONE!!!! I am not sure what to make of this. ther maybe an issue with the steam version of STO.
If you want to try this but want to skip having to redownloading the game, follow these instructions. It is what I did, and it should work for you too.
First, make sure the ARC client is uninstalled
go to your steamapps\common folder and rename the "star trek online folder to "star trek online.temp"
next create a new folder called "star trek online" in the steamapps\common folder.
copy the "Uninstall Star Trek Online.exe" from the startrek online.temp to the new star trek online folder. once it is copied. execute it.
Now you system thinks STO is uninstalled, but you still have all the game files.
Next, goto www.startrekonline.com and click the product page link, and begin download of the STO installer (it is really the stupid ARC client)
If you have never used ARC before, then you have some further setup to do. finish that then go to the next step
tell the ARC client to install STO. A small download will begin. this is the STO launcher files. while the files are downloading, go back to the "steamapps\common\star trek online.temp\ folder.
there is a folder called "Star Trek Online" inside of the "star trek online.temp" folder. Right click on the folder and select copy.
next go bring up the folder"C:\Program Files (x86)\Perfect World Entertainment\Star Trek Online_en"
once inside of the "Star Trek Online_en" folder, right click where the files and folders usually appear and click paste.
Windows will now begin copying the STO game files. on my system it took around 11 minutes or so to copy the files. it may take more or less time depending on your system specifications.
once the files are copied, tell ARC to launch the game.
Once the STO launcher is up, tell it to verify the game files. assuming there were no errors during the file tranfer and there were no corrupt files to begin with, the scan will take about as long as it normally does when is performs a scan and finds nothing wrong.
Once verification is completed, patch the game if needed and then launch the game. you will most likely need to re-set all the options for the game.
Troubleshooting
on my system, the ARC client would not launch the games launcher like it should at first. so i downloaded the latest launcher from here :
" http://files.startrekonline.com/launcher/Star Trek Online.exe " and placed it in the Star Trek Online_en folder. i then told ARC to launch STO, and the Launcher did an update, and then it came up as it should.
As a last step you may delete the newly created star trek online folder in "steamapps\common\" and then rename "star trek online.temp" back to "star trek online" the Steam client doesn't even seem to notice all the tom foolery that has been going on, so you can use the regular (ARC) version of STO, or use the Steam version of STO.
please let me know if this solves the problem for you too