These are temporary measures to help diagnose and workaround the problem. Once we confirm that this is the issue, we'll switch to Snappy or some other fast compression library. Our own hand-rolled LZSS compressor is known to be slow.
From: [email protected] [mailto:[email protected]] On Behalf Of D Bauhmz Sent: Wednesday, May 15, 2013 9:51 AM To: Half-Life dedicated Win32 server mailing list Subject: Re: [hlds] Who do we send netspike.txt log too? I forgot to ask you Fletcher. Will sv_compressfragments and sv_compressstringtablebaselines serve as a permanent fix for this issue or is there more optimizations and a different fix for this on the way? Are player spawns causing a spike (Which I've always thought was normal, heh) something that is planned to be fixed/optimized as well? Thanks On Wed, May 15, 2013 at 12:24 PM, Fletcher Dunn <[email protected]<mailto:[email protected]>> wrote: No need to send any netspike files. We have enough good data and further netspike files or vprof files are not likely to help right now. It anybody wants to send in more windows traces, however, feel free to do so. For some reason the servers are spending huge amounts of time in compression code. The data from the traces and vprof is very consistent. Specifically, compressing string tables and fragments can sometimes take a very large amount of time. The LZSS compression code has not changed in ages. The contents of the string tables, as far as I can tell, did not change significantly in the SteamPipe update. I am still at a loss to explain what changed in the SteamPipe update. There are also occasionally mini-spikes when a player spawns, but I don't think that's new. I have a new "prerelease" beta that adds two convars that can be used to totally disable compression: sv_compressfragments - defaults ON (existing behavior to try to compress all fragments by default) sv_compressstringtablebaselines - default OFF (new beahvior to turn off compression by default) You can switch these at any time, but sv_compressfragments is "sticky" --- it takes effect on a per-client basis, at the time when a client connects. You might try turning both of those off and see how performance changes or if any problems occur. Of course, this will increase bandwidth. But it would help to confirm that this is indeed the problem. If anybody wants to do their own data gathering to see where the time is going, without the data gathering itself causing spikes that might not have otherwise occurred, I'd recommend the following netspike / vprof settings: vprof_on vprof_dump_spikes 20 sv_netspike 0 sv_netspike_sendtime_ms 2 sv_netspike_output 2 From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Essay Tew Phaun Sent: Wednesday, May 15, 2013 12:15 AM To: Half-Life dedicated Win32 server mailing list Subject: Re: [hlds] Who do we send netspike.txt log too? [email protected]<mailto:[email protected]> I'm not sure if they're still wanting logs or not. I think they've kind of found where the problem is. I don't know what it would hurt though. On Wed, May 15, 2013 at 1:59 AM, DragonLight <[email protected]<mailto:[email protected]>> wrote: Been catching the spikes with the new commands, should we email them to someone? _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
