rate caps may get lifted in coming months...

Honestly not starting a troll topic about what rates are ’correct’, this is for the news that valve may be increasing the maximum ’rate’ value in the source engine in the coming months, and this could result in less lag spikes for some of you lovers of big public servers out there...

http://blogs.users.ra66i.co.uk/raggi...source-engine/

Oh, and I should also add that sure, we will look at upping that limit (there are some fundamental limits due to memory buffering that will need to exist, but we should be able to make it a factor of 10 larger at a minimum I suspect).

- Alfred

When asked on a ***ue-ish timeframe, he said:

When its done (within a month or so if I had to guess) and yup, we would post a changelog point about it.

Hopefully as part of the core engine, this will be automatically ported into CS too. It won’t make alot of difference on 5v5s I shouldn’t think, but on larger servers it could make a big difference, espcially reducing latency server side if it can output the data in less time by not being limited / choked by the low rate cap.

Would this mean also raising the default rates?

Nothing was mentioned on that. I suppose it might not be a bad idea for them, but whilst Alfred still thinks (contrary to his own statistics) that ’over half’ of the steam population have less than 256kbps connections, I doubt it. If they actually look at the numbers properly, then maybe they will.

Stoopid.

The problem with rates and in-game transfer rates always lies with the server. Sure, everyone has over 256k but if the server sent 256k+ to each person on say, a 32 man server that was 100 tick? thats a hell of a lot of bandwidth and power for that server to cope with/handle.

TBH I rarely see any public server that doesn’t give out 20-50+ choke 60-70% of the time, simply because it can’t cope not the clients.

Raising the defaults in-game however would be sensible, though I don’t know enough about how that part works baring in mind by default it should run at 33 tick with 30 / 20 rates... so why do we use 66/100 tick with 66/66 or 100/100 rates? Link me please!

p.s I mean stat wise, of course I realise 66/100 is better than 33 in terms of "feel". 75 im unsure of.

Well tbh,. a small example is: (test it yourself)

on 33 tick : Try to bunnyhop like on a 100 tick (impossible)
on 66 tick: gets better to bunnyhop
on 100 tick: Gets MORE better to bunnyhop

So there’s definately an improvement in stuff on MORE tick, so i think if the rates would be increasing, the reg/lag/choke would be less , thats what i think.

the higher the tick the more demanding it is on the server... hence why a lot of 100 tick servers are rubbish, they simply can’t cope.

Thats fine saying that, I guess what I mean is if valve designed CS/HL2 by default to be:33 tick server, 30 / 20 client rates why do we use 66/66 or 100/100 on higher tick servers? Shouldn’t it be something like:
66 tick: 60/40
100 tick: 90/60

bad maths but you get idea?

The problem with rates and in-game transfer rates always lies with the server. Sure, everyone has over 256k but if the server sent 256k+ to each person on say, a 32 man server that was 100 tick? thats a hell of a lot of bandwidth and power for that server to cope with/handle.

This is somewhat true. Generally, it’s quite often not the total bandwidth that’s the problem, but the packetrate and processing strain on the servers, however as Alfred also quite rightly said, such high levels stop home users from hosting servers. - There is more to this story though, as I know ways to get CS to max out the 30000 limit anyway, and when those situations occur, to not be limited by the rate cap would result in much better data flow (and therefore less lag).

This really isn’t related to tickrate at all. Tickrate is a whole seperate issue, however it may lighten the load on some high tick high man servers, by unrestricting data flow during spikes, as described above and elsehwere.

TBH I rarely see any public server that doesn’t give out 20-50+ choke 60-70% of the time, simply because it can’t cope not the clients.

Sure, but I have also never ever seen reducing ’rate’ being a solution to choke in these scenarios. Generally raising ’rate’ and dropping cl_updaterate are the things that help, aswell as kicking half the players off the server. Generally it’s server side FPS that’s the real source of the problem.

ionbroo that played q3 around 2002?

yes steg... are you one of my former fans?

haha yeah ! used to love watching you carry HoT every game ^^,

lol...

Not saying it’s a bad thing but there are things which need "fixing" before this really.

I live in hope

id like some input from TUF

Interesting read.

raggi > tuf

It shouldn’t affect CSS at all..

jedi - you will see the difference in terms of a more, larger spikes, with rate being set higher, but also more periods of inactivity.

As you well know, the system does not rate limit on the second, i.e. it doesn’t burst all it’s buffers once a second. With the low quantization it does use, I think it will make a difference, when you look at the flow restriction under high interaction scenarios (lots of people in view moving and firing with physics objects being moved).

And as I said, this is most common on large public servers, particularly at the start of rounds, when grenades explode amoung groups and so on.

Oh, and I should also add that sure, we will look at upping that limit (there are some fundamental limits due to memory buffering that will need to exist, but we should be able to make it a factor of 10 larger at a minimum I suspect). You will be shooting yourself in the foot if you use this larger number however.

- Alfred

As Valve have already commented, there is no need to approach this amount of bandwidth due to the methods already in the Source Engine to limit it (and I guess it would require a monster server, which would have GSP’s requesting a whole lot more cash to provide the service), it would seem this comment is a bit of a joke with Valve and they are slyly saying the mod team are simply bad

Unless it’s given a fairly big announcement, idiots will probably still call you for "bad rates" at 30k+

As Valve have already commented, there is no need to approach this amount of bandwidth due to the methods already in the Source Engine to limit it (and I guess it would require a monster server, which would have GSP’s requesting a whole lot more cash to provide the service), it would seem this comment is a bit of a joke with Valve and they are slyly saying the mod team are simply bad

You’re mis-reading what he’s saying. Re-read it.

He says: "if you use this larger number"
What larger number does he say?: "factor of 10 larger"

That is not the order of magnitude they are approaching. Alfred said you’d be shooting yourself in the foot if a mod was trying to send 3mbps, and I agree with him on that fact.

This is not in reference to using more than 240kbps of bandwidth, to which alfreds response was some very poorly executed statistics over his own data.

I wasn’t just commenting that quote and I don’t know many people who can upload more than 240kb/s (or why you would need to in a game as Valve suggest), Alfred’s statistics are close if not correct

Things may marginally improve, however the difference will be barely noticable. It’s rare for the current 30k datalimit to be reached, it’s even more rare for a server to have enough capacity to push over 30k.

I wasn’t just commenting that quote and I don’t know many people who can upload more than 240kb/s (or why you would need to in a game as Valve suggest), Alfred’s statistics are close if not correct

We’re concerned with download (client view) or upload (server view) not the other way around. The client data is still pretty low just like in other mods for the source engine.

Things may marginally improve, however the difference will be barely noticable. It’s rare for the current 30k datalimit to be reached, it’s even more rare for a server to have enough capacity to push over 30k.

TuF - I urge you to spend a minute thinking about the sub-second rate cap, not the ’whole second’ rate cap. As I was describing to J3di in a post above, this happens actually quite frequently, remember 30kb/s is a poor quantization for bandwidth measurement in a 100pps data flow. A better measurement is 2.4kb per packet, which is more closely related to the real buffers. I’m actually unsure exactly what the buffers look like (depth, frequency of flushing and so on) but I do know what the packet flow patterns look like - and realistically, it spikes alot, but not high enough, thus these ’exponential decays’ you see on net_graph, or on a packet logger.

Clearly for something which is relatively immediate (someone dieing) there should not be an exponential decay of data flow from the spike of when it occured, instead in many cases it should be one spike, and then back to normal, with maybe some limited (and flat!!!) data carrying rag-doll and animation corrections.

Lets also not forget that part of the reason for the load on a 100 tick server is that it’s having to do alot of work to choke the data flow. Remove this work, and it should cope with it better. I don’t know too many GSPs that run under 10mbit lines to each box, and as we all know this is something which is concerned with spikes, and not continual flow - so there’s no real cause for concern regarding server capabilities. Furthermore - costs for GSPs who pay for bandwidth in the 95th percentile (VERY COMMON!!!) will actually REDUCE because the top 5% of the spikes essentially gets cut off. - another bonus.

I’d also point out that often servers which are suffering (which are housed in a DC) don’t have trouble with the bandwidth, but the processing power and packetrate - this is not the same as bandwidth and both of these issues could be potentially be relieved by opening up the spikes, as there will be less of the choke management system running (less processing power), and it’s possible less packets will actually be required to carry all the relevant information (although I’m not sure how well the specific implementation allows for this one).