Online Gaming Issue.
- Thread starter ManBearPig
- Start date
- Joined
- Nov 21, 2008
- Messages
- 162
Did you ever do what I suggested in my last post?
- Joined
- Oct 25, 2007
- Messages
- 843
yea ive turned my settings real low thinking it might help...it didnt. The gfx card and the ram are pretty new...its the motherboard and harddrive that are old
I got 0% loss with I think it said 14.5 latency on the other test
I got 0% loss with I think it said 14.5 latency on the other test
Last edited:
- Joined
- Nov 21, 2008
- Messages
- 162
yea ive turned my settings real low thinking it might help...it didnt. The gfx card and the ram are pretty new...its the motherboard and harddrive that are old
I got 0% loss with I think it said 14.5 latency on the other test
The test said you had to re-transmit a few packets and had a few bad packets as well. This could be a problem, so try making a account and try their test "Line Quality Testing"
It should be a little more accurate...
Last edited:
- Joined
- Nov 7, 2008
- Messages
- 4,560
Rabid,
What do you think of path MTU discovery being enabled?
And what do you think of turning it off?
I'm not a desktop/OS tech (I'm network - and it's not the network here - ha!) so I don't know how to change that. I assume "EnablePMTUDiscovery."
ManBearPing,
My interest in Path Discovery being enabled is because your description sounds very similar to what devices do when attempting to determine the MTU (maximum transmission unit) permissible between two endpoints.
I'm curious to know if your problem repeats if/when Path Discovery is turned off. But please don't do this on my account. Like I said, I'm network. Not desktop/PC.
But if someone here who is desktop qualified thinks it's a good idea and can walk you through changing it.....
Until then, to help satisfy my curiosity (and also help troubleshoot), would you be willing to "sniff" your network connection? The arising gold standard is Wireshark, but here's a simpler app to do it: http://www.nirsoft.net/utils/smsniff.html
Please do the following:
1. Download SmartSniff (the link above)
2. Download the WinPCap driver (linked on the SmartSniff page.)
3. Install both applications.
4. Start SmartSniff and go to Options/Capture Options (or press F9)
5. Be sure that your capture method is the WinPcap Packet Driver and NOT the raw sockets driver. (Or else the capture will be incomplete.)
6. Close any web browsers, IM, VoIP, IRC, SkyPe, Twitter, Vent windows, etc you have open.
6. Start SmartSniff data capturing by clicking the green arrow in the upper left.
7. Start-up your game and play normally.
8. When you begin to have game problems, play a bit longer. (About a minute)
9. Exit the game.
10. Stop the data capture.
11. Save the data capture.
Once you have the data file, PM me, and we can work out a way for me to see it.
What do you think of path MTU discovery being enabled?
And what do you think of turning it off?
I'm not a desktop/OS tech (I'm network - and it's not the network here - ha!) so I don't know how to change that. I assume "EnablePMTUDiscovery."
ManBearPing,
My interest in Path Discovery being enabled is because your description sounds very similar to what devices do when attempting to determine the MTU (maximum transmission unit) permissible between two endpoints.
I'm curious to know if your problem repeats if/when Path Discovery is turned off. But please don't do this on my account. Like I said, I'm network. Not desktop/PC.
But if someone here who is desktop qualified thinks it's a good idea and can walk you through changing it.....
Until then, to help satisfy my curiosity (and also help troubleshoot), would you be willing to "sniff" your network connection? The arising gold standard is Wireshark, but here's a simpler app to do it: http://www.nirsoft.net/utils/smsniff.html
Please do the following:
1. Download SmartSniff (the link above)
2. Download the WinPCap driver (linked on the SmartSniff page.)
3. Install both applications.
4. Start SmartSniff and go to Options/Capture Options (or press F9)
5. Be sure that your capture method is the WinPcap Packet Driver and NOT the raw sockets driver. (Or else the capture will be incomplete.)
6. Close any web browsers, IM, VoIP, IRC, SkyPe, Twitter, Vent windows, etc you have open.
6. Start SmartSniff data capturing by clicking the green arrow in the upper left.
7. Start-up your game and play normally.
8. When you begin to have game problems, play a bit longer. (About a minute)
9. Exit the game.
10. Stop the data capture.
11. Save the data capture.
Once you have the data file, PM me, and we can work out a way for me to see it.
- Joined
- Nov 21, 2008
- Messages
- 162
Leave "Path MTU Discovery" on...
To put in layman terms it tries to optimize and efficiently send data to other computers on the net. If you want to go in depth the RFC link is below.
http://www.faqs.org/rfcs/rfc1191.html
I'm afraid that by doing the above requests to capture packets can possibly be a liability. I'm am not doubting you trustworthiness, but your going to log his authentication/s as well as other data.
Scrappy, What are you trying to learn from capturing packets because there are alternative ways. Try looking at Sysinternals site for a tool that suites your purpose.
http://technet.microsoft.com/en-us/sysinternals/default.aspx
To put in layman terms it tries to optimize and efficiently send data to other computers on the net. If you want to go in depth the RFC link is below.
http://www.faqs.org/rfcs/rfc1191.html
I'm afraid that by doing the above requests to capture packets can possibly be a liability. I'm am not doubting you trustworthiness, but your going to log his authentication/s as well as other data.
Scrappy, What are you trying to learn from capturing packets because there are alternative ways. Try looking at Sysinternals site for a tool that suites your purpose.
http://technet.microsoft.com/en-us/sysinternals/default.aspx
Last edited:
- Joined
- Oct 25, 2007
- Messages
- 843
Soo...should i have no done what Scrappy said??
- Joined
- Nov 21, 2008
- Messages
- 162
I'm not sure what he is trying to learn with what he said to do in his post. If he would post we might be able to find a less invasive method.
- Joined
- Oct 25, 2007
- Messages
- 843
the program he told me to download actually seems to have helped a bit...its blocking duplicate packets (so my console says anyways) which reduces my spikes...i still get them but not as much.
heres link to line quality test results:
http://www.dslreports.com/linequality/5c92b73acc23/2464188
heres link to line quality test results:
http://www.dslreports.com/linequality/5c92b73acc23/2464188
Last edited:
- Joined
- Nov 21, 2008
- Messages
- 162
Are you plugged directly into the wall or do you have a router your going through?
Do you have any other Ethernet cards laying around you could try to use, or borrow a friends computer and run the same line quality test at your home?
Something look bad between your computer and the first hop out to the Internet. If you use a friends computer you know is working we can rule out a software and hardware issue.
I'm using Wireless I know it sucks, but not by choice. So here is my test results.
http://www.dslreports.com/linequality/nil/2464812
Do you have any other Ethernet cards laying around you could try to use, or borrow a friends computer and run the same line quality test at your home?
Something look bad between your computer and the first hop out to the Internet. If you use a friends computer you know is working we can rule out a software and hardware issue.
I'm using Wireless I know it sucks, but not by choice. So here is my test results.
http://www.dslreports.com/linequality/nil/2464812
- Joined
- Oct 25, 2007
- Messages
- 843
No router, no ethernet cards, no friends willing to bring pc over
I think it is a hardware issue I just have no way of figuring that out (cause im computer illiterate)
- Joined
- Nov 21, 2008
- Messages
- 162
No router, no ethernet cards, no friends willing to bring pc over
I think it is a hardware issue I just have no way of figuring that out (cause im computer illiterate)
Just to confirm a few things...
Does your house have built in networking, or is your computer directly connected to a box that plugs into a cable outlet?
We never asked but do you have a laptop or desktop?
I'm kinda leaning towards the idea you might want to go to Newegg and get a Ethernet card. They are cheap ($15+Free shipping) and it will rule out the idea this is a hardware problem and make it more likely this is a problem with Comcast.
While we are talking about Comcast did you ever look up some of their controversies on Wikipedia?
http://en.wikipedia.org/wiki/Comcast#Controversies
- Joined
- Oct 25, 2007
- Messages
- 843
It plugs into a cable box...and its a Desktop
- Joined
- Nov 7, 2008
- Messages
- 4,560
I've waited to post again because I've been doing some research and also ran this by a couple of people in desktop support where I work. Their answer? Get a sniffer [packet capture] trace. Hm. But they always say that because they know us network guys can usually figure things out. 
First: Steam authentication traffic is encrypted so, no, a packet capture of network traffic when you start your game does not place your Steam credentials at risk. Yes, you should always be careful when transmitting anything over the network.
As I always remind people - you should always assume anything transmitted (or received) via the Internet is being monitored or captured. So, if you are worried about it, either don't send it via the Internet or encrypt it.
A packet capture is different than a keylogger because it operates at a different hardware level. More questions? Feel free to PM me.
So, aside from the somewhat alarmist statement of "logging his authentication", if you're uncomfortable with a trace, that's fine, ManBearPig. We can work around that. I'd still want you to get one. I'll just have to walk you through what things I'd want to look for and have you look for them instead.
Second: Why did I want a packet capture? Because I want to know what the heck the PC and the game server are saying to each other that results in larger and larger packets being sent to the PC.
The tools at Sysinternals (know many of them and love em' all) show network socket and basic network information from the PC perspective. That's not what I want to see.
Specifically, I want to see the TCP window negotiation and renegotiation.
Third: Why do I want to see the TCP negotiation exchange? Because, as I said earlier, the "in" of net_graph does NOT refer to amount of bandwidth being consumed. Instead, it refers to an absolute number: the size of the last packet received in bytes.
The next stat refers to average bandwidth used, inbound. And from the original image, it's about 4.7 Kbyte/second. That's fine. In fact, if you look at the original post, with a 138 ms ping and 53 FPS, things look really fine.
Except.
If "in" is really getting to 5000, there's something goofy there. But we already know that. And also... notice the 27.3 on the far right? That refers to the average number of packets being sent from the PC to the server.
Interesting.
ManBearPig,
Startup your game, please, and in the console, type:
cl_updaterate
cl_cmdrate
What are the results you have for those two entries?
Last, it certainly won't hurt to install an Ethernet card, but you don't seem to be suffering any ill effects from being wireless (surprise!). At a bare minimum, it should reset the IP stack - which is where my interest lays right now.
First: Steam authentication traffic is encrypted so, no, a packet capture of network traffic when you start your game does not place your Steam credentials at risk. Yes, you should always be careful when transmitting anything over the network.
As I always remind people - you should always assume anything transmitted (or received) via the Internet is being monitored or captured. So, if you are worried about it, either don't send it via the Internet or encrypt it.
A packet capture is different than a keylogger because it operates at a different hardware level. More questions? Feel free to PM me.
So, aside from the somewhat alarmist statement of "logging his authentication", if you're uncomfortable with a trace, that's fine, ManBearPig. We can work around that. I'd still want you to get one. I'll just have to walk you through what things I'd want to look for and have you look for them instead.
Second: Why did I want a packet capture? Because I want to know what the heck the PC and the game server are saying to each other that results in larger and larger packets being sent to the PC.
The tools at Sysinternals (know many of them and love em' all) show network socket and basic network information from the PC perspective. That's not what I want to see.
Specifically, I want to see the TCP window negotiation and renegotiation.
Third: Why do I want to see the TCP negotiation exchange? Because, as I said earlier, the "in" of net_graph does NOT refer to amount of bandwidth being consumed. Instead, it refers to an absolute number: the size of the last packet received in bytes.
The next stat refers to average bandwidth used, inbound. And from the original image, it's about 4.7 Kbyte/second. That's fine. In fact, if you look at the original post, with a 138 ms ping and 53 FPS, things look really fine.
Except.
If "in" is really getting to 5000, there's something goofy there. But we already know that. And also... notice the 27.3 on the far right? That refers to the average number of packets being sent from the PC to the server.
Interesting.
ManBearPig,
Startup your game, please, and in the console, type:
cl_updaterate
cl_cmdrate
What are the results you have for those two entries?
Last, it certainly won't hurt to install an Ethernet card, but you don't seem to be suffering any ill effects from being wireless (surprise!). At a bare minimum, it should reset the IP stack - which is where my interest lays right now.
Last edited:
- Joined
- Nov 14, 2008
- Messages
- 1,283
Also, are you right handed or left? Do you smoke filtered or non-filtered? And, most importantly, in your honest opinion, was it the lady or the tiger?
Sorry, couldn't resist.
Seriously, though, I hope these fine folks are able to help you out. I think it's out of my league now... :-/
I wonder if Comcast has the STARGUS (nickname for the tool at work, can't remember the actual name) tool at their disposal to see the traffic patterns over a course of time... It would make sense if the RX or TX db levels spiked to the modem that you would get massive packet loss/crappy connection.
I dunno, but give comcast a call, get whatever their highest call center tech level would be and ask them if they can run a quick analasys of the levels over the past month or so to your modem.
I am dealing with people calling me at where I work (Time Warner Cable) with similar issues, but when they call, the issue is too minute for the lower level rep to see, the rep doesn't have access to the proper tools needed to diagnose the issue, or the issue isn't occuring when they call.
I use STARGUS on every call so that I can have a history on what the hardware was doing so I can more easilly diagnose the root cause of the issue.
Hopefully they'll be able to find SOMETHING.
Good Luck!
I dunno, but give comcast a call, get whatever their highest call center tech level would be and ask them if they can run a quick analasys of the levels over the past month or so to your modem.
I am dealing with people calling me at where I work (Time Warner Cable) with similar issues, but when they call, the issue is too minute for the lower level rep to see, the rep doesn't have access to the proper tools needed to diagnose the issue, or the issue isn't occuring when they call.
I use STARGUS on every call so that I can have a history on what the hardware was doing so I can more easilly diagnose the root cause of the issue.
Hopefully they'll be able to find SOMETHING.
Good Luck!
- Joined
- Nov 7, 2008
- Messages
- 4,560
Fusion,
Do you think signal loss though would be something that affects packet segmentation and size?
I would have thought it would have affected packet transmission more by causing retransmits. The test Rabid recommended showed a pretty small retransmit rate.
(Still something we can see in a network trace!)
BTW: What is the normal dB loss? About -8 to -12?
Do you think signal loss though would be something that affects packet segmentation and size?
I would have thought it would have affected packet transmission more by causing retransmits. The test Rabid recommended showed a pretty small retransmit rate.
(Still something we can see in a network trace!)
BTW: What is the normal dB loss? About -8 to -12?
- Joined
- Oct 25, 2007
- Messages
- 843
- Joined
- Nov 21, 2008
- Messages
- 162
def. means default.
So that means the default settings are
cl_updaterate 20
cl_cmdrate 30
But you currently have it set to
cl_updaterate 100 <--- The server you were in reduced it temporarily to 60
cl_cmdrate 100
Try setting them at their default and if that doesn't help put them back to were they were. It doesn't hurt to play around with those settings.
So that means the default settings are
cl_updaterate 20
cl_cmdrate 30
But you currently have it set to
cl_updaterate 100 <--- The server you were in reduced it temporarily to 60
cl_cmdrate 100
Try setting them at their default and if that doesn't help put them back to were they were. It doesn't hurt to play around with those settings.
- Joined
- Nov 7, 2008
- Messages
- 4,560
Rabid is with me on this one. Please set those to the defaults by typing:
cl_updaterate 20
cl_cmdrate 30
and then, please, confirm they are at default, by typing the command again, without the numbers, in the console.
Then play for the usual amount of you time you do for the game to begin stuttering.
Interesting how your PC wants the server to send more frames per second than the server wants to.... And your setting is five times the default rate.
cl_updaterate 20
cl_cmdrate 30
and then, please, confirm they are at default, by typing the command again, without the numbers, in the console.
Then play for the usual amount of you time you do for the game to begin stuttering.
Interesting how your PC wants the server to send more frames per second than the server wants to.... And your setting is five times the default rate.
