I "believe" that I have resolved my input/video lag issues so I figured I would post my solution as it may be helpful to you.
First, from Windows Device Manger, disable all "Offloads" for your network adapter. Mine is an Intel 82579V Gbps. built into my ASUS P8Z77-V Pro. You can find this under the Advanced Tab of your NIC adapter properties. Basically disable ALL offloading.
Disable Large Send Offload (IPV4/6), then under TCP/IP Offloading options disabled ALL offloading, (uncheck IPv4 Checksum Offload, TCP Checksum Offload (IPv4/6) and ALL UDP Offloads.
Save settings and reboot.
Then, DL TCPOptimizer and then run it as ADMINISTRATOR.
Backup your current settings, File>Backup. Then select your NIC and "Optimal". Set the slider for your DL speed and hit apply. Reboot.
Mine was perfect after this. I have spent an enormous amount of time trying to resolve this issue and I hope it helps you as well.
You really have UDP offloads? I don't have any by I'm in XP.
Otherwise QL is entirely UDP and is unlikely to be affected by any tcp/ip settings.
Thanks for the tip Diggl3r, I'll give it a try. Although, I suspect Lorfa is correct about QLive being entirely UDP and unlikely to be affected by such settings, but I'll try it out anyways .
Originally Posted by Diggl3r
Note: I experience the same input lag locally as I do on a public server, so this likely will not have the desired effect as it did for you.
Last edited by c3; 07-25-2012 at 03:50 PM.
INPUT LAG UPDATE FIX:
Once again, I appear to have resolved my input lag issues. As a reminder, I initially resolved my input lag issues by disabling HPET, C1E, EIST, and C3/C6 in the BIOS. Unfortunately, this only remain resolved for a day or two until my input lag problems came back.
When my input lag issues came back, I noticed the lag wasn't quite as bad as it was before, but bad enough to ruin the game for me and take the competitiveness out of it for me. I noticed my input lag issues came back because my movement did not feel as fluid and whenever I lg'd someone, it took about 1/2 a second to sometimes more to actually hear the LG hitting them (audible). There was a huge delay from hearing the impact of my lg zapping someone. My LG also never pushed my opponents back as it should when you LG them perfectly on point, no kickback at all. Same with rockets... even if I shot a perfectly placed rocket, the rocket never seemed to knock my opponent back or off their feet as it should when it lands on their ankles. Lg'in above 30% seemed impossible, and lg'ing above 50% against bots was almost impossible.
Here's the issue:
When I tried to execute my CFG, I received an error saying the CFG couldn't be found. I figured I typed it in incorrectly so I tried again, but to no avail. I also noticed my QLive settings were different, which was also odd. I went to my desktop and went to my root directory %appdata%\roaming\id software\quakelive\home\baseq3 <-- All cfg's were there so I was a bit confused. I went back into quake live, tried to execute my file again, but one again to no avail, didn't work.
At this point I was just troubleshooting and wondered why my qlive installation was in roaming to begin with. I copied my cfg files from the roaming directory and put them in %appdata%\locallow\id software\quakelive\home\baseq3 <--- Launched QLive and executed my cfg with no problems. For some reason, my root directory changed from roaming to locallow. As to why my QLive directory was in the roaming directory is a bit of a mystery to me, but I have my suspicions. Once my root directory was changed back to locallow, my input lag issues were a thing of the past and I'd hear hit recognition with my lg almost immediately, and I was lgin on average 39-42% for the remainder of the night. Once again, all seemed well again.
I remember in the past running Quake Live in compatibility mode (XP SP3), which I believe is why my QLive directory changed to the roaming directory. I was able to switch it back to launching from locallow by turning compatibility mode on and off. When I did this, it changed the root directory and my input lag was virtually gone.
Can anyone explain this, or does anyone have any thoughts on this? When QLive is running from your %appdata%\roaming directory, a significant amount of input lag is added. Running from locallow is obviously ideal.
Ultimately, I'm sitting happy and all is right as rain. I was very close to installing XP Pro to see if XP would do a better job.
Yes, I do have UDP Offloads on my Intel NIC. However, my problem has resurfaced again. The night I made the changes I played 5 games online, reconnected numerous times and all was good. I went back online later that same evening and it was horrible again.
This makes no logical sense to me unless it is ISP or connectivity based.
<Out of ideas, going to play video pong...
Tracert can tell you where the problem is at.
Input Lag Update
I found and made a couple of changes that has dramatically improved my input lag issue to the point where the delay (floaty, delay type feeling) is much improved and satisfactorily playable. The first tweak isn't anything new, but not as widely used or recommended. The tweak consists of changing your window's theme (more than just disabling aero), and a recommended configuration/driver to use if you use an Nvidia card.
We all know Aero causes issues with gaming lag and DPC latency under Windows 7. The general recommendation is to disable it and select the Windows Basic theme. This resolves many issues for most people, but it wasn't providing me with the same results other people typically receive from this. I found that selecting the "High Contrast Theme" improves and/or resolves the delay (input lag) many people experience in Quake Live. I confirmed this using DPC Latency Checker.
Using Windows 7 Basic, my DPC Latency was relatively low but spikes were rampant. I was using the Windows Classic theme as I assumed this was the most dumbed down theme as all additional special effects were disabled, but something about this theme increases your input lag and DPC latency, so stay clear from it. When I switched to the High Contrast theme, my DPC Latency lowered to 10us and stabilized on average from 9-20us. In game, this is how I can tell if this tweak improved my input lag:
1) Hit detection is much improved if not entirely resolved. Prior to this particular change, the hit detection sound (ding) with lg was never a consistent (ding ding ding ding). It sounded more like an inconsistent flickering sound where only half the 'ding' is heard. It was very strange. Also, moving your lg from left to right wasn't smooth at all. The LG doesn't sway, it chops inconsistently which makes lg'ing quite an unnecessary challenge. The best way to test this I found was to LG a stationary player, and listen to the hit detection sound. If it's not a consistent ding sound spread apart at an even interval, then you likely have issues such as input/output lag.
2) Movement should feel precise and not delayed or floaty feeling. Veterans of the game should have a good understanding for how the game should feel. If you're jumping and/or strafing and you feel like you're on the moon, then you likely have issues.
3) Rockets should come out evenly and consistently. If you're firing a rocket at someone's feet, but the rocket always ends up behind him (assuming you're shot the rocket perfectly), an input/output lag could be to blame.
4) For Nvidia users with a supported card, try using driver set 270.61. As for the settings, ensure GPU SCALING is turned OFF. Under 3d settings: Turn off all settings that can be turned to 'off.' Turn all settings to 'performance' that allow it with the exception of texture filtering. Turn this option to High Quality. Set pre-rendered frames to 0 (1 added a floaty feeling in my case). Set display power setting to prefer maximum and multi-display performance to single display performance. You can leave lod-bias to 'Allow.' I'll take a screen shot of settings for a more detailed description if requested.
There are many trains of thought on pre-rendered frames, and I have received word directly from an Nvidia Engineer giving some insight on the difference between pre-renderered frames 0 and 1. He stated that there is virtually no difference between 0 and 1, so they decided to remove 0 in current 300 drivers because of redundancy. The fact remains that there is in fact a difference between 0 and 1. It does not default to 3 (in most cases) as many people believe, but for some systems, it is better to leave the setting to 1 if your system is hindered by a slow CPU. If your system is relatively sluggish, 0 may cause many instances where your video chops and lags behind trying to catch up. Also, a reboot is necessary when making changes to your Nvidia settings, this goes for ATI/AMD as well.
Besides the DPC Latency checker, it's difficult to objectively test these tweaks in game. Ultimately, you should be able to notice the improved responsiveness if you're familiar with this game and how it should respond. Hope this helps.
On a side note, XP > 7 for gaming. Nothing new here.
Last edited by c3; 08-09-2012 at 06:14 PM.
http://www.radeonpro.info/en-US/ - Has been 100% updated
c3 did you disable all the mouse shadows? That will cause lag with the mouse, that has been a known issue for + years with ccc ;/
Control Panel\All Control Panel Items\Performance Information and Tools
then go to visual effects
Thanks for the tips on HPET and power related options, mouse shadows, updated Radeon tools and DPC latency checkers. Tweaks have made my entire computer feel more responsive even though I don't even play QL anymore.
If you disable too many windows services or do it the wrong way, the result could be constant checking at whatever interval is set for other services that to some extent require a service that's disabled or worse deleted.
Back when i ran xp64 i used a lot of batch file with registry edit commands to fix what i removed with nlite and what i removed manually. In that regard both nlite and vlite removed some stuff not fully or incorrectly so that there was a lot of errors constantly showing up in the event log. Which is never a good thing. Usually the fix is checking that dependencies are removed, but some are hardcoded..
Ie the notorious MMCS service can be completely removed, but if you simply just disable audio/network/video thread priorities it will still start up if u set the service to manual and then launch an app like winamp. Even tho you configure it to do nothing.
The fix for that again is usually disabling it in the system user account as well, which normally means taking ownership of whatever one wants to get rid off.
Problem with simply just sc deleting stuff is if one ever would need the service again. While possible to readd most services as i recall i've done, it's generally not wise.
Certain stuff like Security center, windows defender and that kind of ** works quite fine to simply delete, even on windows 7. Just make sure you've set them to disabled and check dependencies are removed as well. CCleaner can sometimes fix this.
Tags for this Thread