Totally forgot about the prerelease command line, thank you very much.
Quoting D Bauhmz <[email protected]>:
Yes, those 2 server variables are a part of the beta prerelease right now.
You can learn how to grab that update from the link below.
https://developer.valvesoftware.com/wiki/SteamCMD
On Wed, May 15, 2013 at 12:55 PM, DragonLight <[email protected]>wrote:
Is there an ETA when the two new SV commands will be available? I have no
problems with the extra bandwidth to verify if it does help or not.
Also I know some people use:
sv_parallel_sendsnapshot 0
sv_parallel_packentities 0
Would those have anything to do with causing the new issues? We've used
them forever, and it is a snapshot issue. Just trying to put 2 and 2
together.
-DL
Quoting Fletcher Dunn <[email protected]>:
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:
hlds-bounces@list.**valvesoftware.com<[email protected]>[mailto:
hlds-bounces@list.**valvesoftware.com<[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:fletcherd@**valvesoftware.com<[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<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<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
