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] > 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]] *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] 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]> > 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
