I did a controlled test using tr_walkway and a sentry, killing an endless 
stream of running bots.

I used tcpdump to capture all traffic to/from the server and my client, with 
these results:

300 seconds with both compress flags on: 7653096 bytes (25510 bytes per second)

300 seconds with both compress flags off: 7613287 bytes (25378 bytes per second)

My client ran perfectly smoothly during both tests, with net_graph showing no 
choke at all during the full 5 minutes.

Server is on a dedicated box running Windows Server 2008. Srcds instance is a 
"virgin" beta-prerelease with nothing custom added except the map I used. 
Client is on Mac OS X.

I restarted both the server and the client before each test.

That's almost NO difference. This makes me wonder: we've had none of the "lag" 
issues reported on the list. Does that mean that our servers, for some reason, 
are not compressing to begin with? What else could explain why some folks have 
issues on their servers while others don't?

So strange.

 - Peter 
On May 15, 2013, at 22:54 PM, DragonLight <[email protected]> wrote:

> Do not know specifically, but from watching the numbers seems about 1.5x more 
> going out then normal. Really other then a little bit more bandwidth it was 
> hardly noticeable. Thats a real rough guess from sitting in a 32 player 
> server and watching what I was receiving from the server.
> 
> Some low bandwidth folks had a hard time playing though, but there was very 
> few of them. Most of our players have high bandwidth connections though so 
> wasn't noticeable.
> 
> CPU usage was lower, was kind of nice actually :) Should make that a normal 
> option in Source games to let owners decided to compress snapshots or not to 
> save CPU cycles at the expense of a little more bandwidth.
> 
> Quoting Jeff Sugar <[email protected]>:
> 
>> Out of curiosity, how much more is it?
>> 
>> I know we can handle it, since the server's been running fine with no
>> complaints, but I'm away from the PC, so I thought one of you had done a
>> comparison of the bandwith reqs.
>> On May 15, 2013 4:51 PM, "DragonLight" <[email protected]> wrote:
>> 
>>> Thats great news, our servers have been running great still. Hopefully
>>> we'll see a mandatory patch for all source games that fixes the issue soon.
>>> 
>>> Anyone else out there who is running TF2 I would recommend getting the
>>> prerelease and putting the new cvars in your server.cfg for now until a
>>> patch is released to officially fix it. Just make sure your bandwidth can
>>> cope with uncompressed snapshots.
>>> 
>>> 
>>> steamcmd.exe +login "anonymous" +force_install_dir "C:\yourserver\server1"
>>> "+app_update 232250 -beta prerelease" validate quit
>>> 
>>> sv_compressfragments 0
>>> sv_**compressstringtablebaselines 0
>>> 
>>> 
>>> Quoting D Bauhmz <[email protected]>:
>>> 
>>> DragonLight the the commands worked for us as well. Hopefully while
>>>> they're
>>>> pursuing these issues they'll fix up the player join thing too. Maybe
>>>> we'll
>>>> wind up coming out better off than we were before the issue! :)
>>>> 
>>>> *crosses fingers*
>>>> 
>>>> 
>>>> On Wed, May 15, 2013 at 5:59 PM, scott biszmaier <[email protected]> wrote:
>>>> 
>>>> perfect! thanks for the prompt reply, got it working and the commands
>>>>> are working fine now... will report shortly with results!
>>>>> 
>>>>> 
>>>>> ------------------------------
>>>>> scott biszmaier
>>>>> 
>>>>> 
>>>>> -----Original Message-----
>>>>> From: DragonLight <[email protected]>
>>>>> To: Half-Life dedicated Win32 server mailing list <
>>>>> [email protected]>
>>>>> Sent: Wed, May 15, 2013 2:47 pm
>>>>> Subject: Re: [hlds] Who do we send netspike.txt log too?
>>>>> 
>>>>> Had the exact same problem, had to add the quotes to get it to work.
>>>>> Example:
>>>>> 
>>>>> steamcmd.exe +login "anonymous" +force_install_dir
>>>>> "C:\yourserver\server1" "+app_update 232250 -beta prerelease" validate
>>>>> quit
>>>>> 
>>>>> Notice the quotes between app_update and prerelease section, thats
>>>>> what I was missing. It should only download like 1 or 2 small files,
>>>>> start it up and try the commands again.
>>>>> 
>>>>> -DragonLight
>>>>> 
>>>>> Quoting scott biszmaier <[email protected]>:
>>>>> 
>>>>> > so i've updated my server to the pre-release version and i'm getting
>>>>> this
>>>>> > when i try to test the new commands;
>>>>> >
>>>>> >> Unknown command "sv_compressfragments"
>>>>> >> Unknown command "sv_**compressstringtablebaselines"
>>>>> >
>>>>> >
>>>>> >  i get this when i run the version command;
>>>>> >
>>>>> >> Protocol version 24
>>>>> >> Exe version 1756932 (tf)
>>>>> >> Exe build: 10:36:54 May 14 2013 (5287) (440)
>>>>> >
>>>>> > which is the pre-release version according to  Peter
>>>>> > this in the command line i used to update the tf2 server;
>>>>> >
>>>>> >> steamcmd.exe +login anonymous +force_install_dir
>>>>> >> c:\games\tf2\test\SRCDS\**orangebox +app_update 232250 -beta
>>>>> >> prerelease +quit
>>>>> >
>>>>> > suggestions?
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > scott biszmaier
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > -----Original Message-----
>>>>> > From: Peter Jerde <[email protected]>
>>>>> > To: Half-Life dedicated Win32 server mailing list
>>>>> > <[email protected]>
>>>>> > Sent: Wed, May 15, 2013 11:26 am
>>>>> > Subject: Re: [hlds] Who do we send netspike.txt log too?
>>>>> >
>>>>> >
>>>>> > Are you sure you actually updated it?
>>>>> >
>>>>> > "cvarlist comp" should show you the two variables if you have the
>>>>> prerelease
>>>>> > version.
>>>>> >
>>>>> > Use the version command to make sure you're actually running the
>>>>> prerelease
>>>>> > version. My Windows test server shows this on the pre-release version:
>>>>> >
>>>>> >>          Protocol version 24
>>>>> >>          Exe version 1756932 (tf)
>>>>> >>          Exe build: 10:36:54 May 14 2013 (5287) (440)
>>>>> >
>>>>> > whereas my production servers show:
>>>>> >
>>>>> >>          Protocol version 24
>>>>> >>          Exe version 1756932 (tf)
>>>>> >>          Exe build: 12:02:13 May  7 2013 (5287) (440)
>>>>> >>
>>>>> >
>>>>> >
>>>>> > If you used the all-on-one-line method of invoking steamcmd, maybe you
>>>>> didn't
>>>>> > quote the beta flag properly?
>>>>> >
>>>>> > The command line I used was:
>>>>> >
>>>>> >> steamcmd +login anonymous "+force_install_dir c:\path" "+app_update
>>>>> 232250
>>>>> > -beta prerelease" +quit
>>>>> >
>>>>> >  - Peter
>>>>> >
>>>>> > On May 15, 2013, at 13:12 PM, DragonLight <[email protected]>
>>>>> wrote:
>>>>> >
>>>>> >> Updated one of my servers to the prerelease beta version but its not
>>>>> > recognizing the new sv_ commands.
>>>>> >>
>>>>> >> Quoting Fletcher Dunn <[email protected]>:
>>>>> >>
>>>>> >>> 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: 
>>>>> >>> hlds-bounces@list.**valvesoftware.com<[email protected]>
>>>>> >>> [mailto:hlds-bounces@list.**valvesoftware.com<[email protected]><
>>>>> hlds-bounces@list.**valvesoftware.com<[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:fletcherd@**valvesoftware.com<[email protected]><
>>>>> [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:
>>>>> >>> hlds-bounces@list.**valvesoftware.com<[email protected]>
>>>>> <mailto:hlds-**[email protected]<[email protected]><
>>>>> hlds-bounces@list.**valvesoftware.com<[email protected]>
>>>>> ?>>
>>>>> > [mailto:hlds-bounces@list.**valvesoftware.com<[email protected]>
>>>>> <mailto:hlds-**[email protected]<[email protected]><
>>>>> hlds-bounces@list.**valvesoftware.com<[email protected]>
>>>>> %3Cmailto:**hlds-bounces@list.**valvesoftware.com<3cmailto%[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]><
>>>>> [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] <
>>>>> [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<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<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<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

Reply via email to