1000 FPS, network usage and others.

[Drocona]

css, I really disagree with the dev wiki and whispers are "the most reliable" on the net. I'll explain:
Whispers guide was created in october 2005, the last real update was january 2006. That is per definition NOT reliable any more, have you got any idea how many things have changed? There's even a revamping of the source engine involved in here.
Then there's valve's dev wiki, I can say it's more reliable than whispers but at the same time it's a WIKI editable by every noob that wants to run a server, I too have contributed a LOT in these wiki pages but I just don't feel like updating every time because some fart changed it or they think they know better.

I don't want to sound cocky or something but I am the proof here, I've proven myself numerous of times and I can tell you how it works, I've been around with servers for 7+ years of which almost 4 with the SRCDS, I'm sure you can see my history on these boards, I've written approximately 80% of all tutorials available on the net on running a SRCDS, there are MANY copies of my work and re-released under one others name.

Just to give another example, your quote from Whispers: "Server FPS
Because there are no keyboard or mouse I/O's occurring, it only deals with how often the server checks for (incoming) game packets."

Is off, it's only half the truth, to be honest keyboard-mouse i/o has nothing to do with it you can spam the keyboard with 1000 strokes/s it won't make a difference.
Another remark is that server FPS is the "think time" of the computer, which means at every frame it will calculate what happens in the SRCDS, player positions, gun fire, everything. If your server is running 1000FPS and 100 tick the server will check player input and update the players every 10 FPS. This explains why higher FPS makes it smoother, because the more the server updates the more precise it is, even if the tickrate is at 33, you'll just notice it less and in cases like 33 tick, negligible.

Only recently servers are actually able to run 1000FPS, on all my own servers I did 1000 FPS it would make the server unstable but people have proven it to be possible and I've seen them work myself, 1000 FPS isn't just a market stunt anymore, although I'm sure 99% of the GSP's still use it that way.

[css]

Thanks for your reply Drocona, and thanks for moving this topic here. Now it's easier to discuss about servers in general without making unintentional remarks about someone's server .

First of all, could you point me to reliable source of information? Is there such? The developer wiki, although being a wiki, has lots of information in general server perspective. Especially the "lag compensation" thing isn't going to change in the next 10 years. Also other information about interpolation and extrapolation won't change even if computers get much more powerful. The wiki stuff, although old, will most likely be true about CS:S forever, even though there's rumor that the new "Souce 2007" engine will be brought to CS:S too.

I've been into servers for about three years. Three years ago I had couple servers, but it's down to one for couple years now. In general I'd say that I know what the source engine is. I've made several PHP / Perl / Mattie Eventscripts / Sourcemod scripts for the server. I've created one full-scale map. I've made the stats plugin. I've configured every little cvar in the server. I've read Whisper's wiki, Valve's wiki and large amount of information related to mapping, modding and optimizing. I do know how the server works.

Now about the 1000 fps thing.

Can you say for (95-)100% certainty what does the FPS mean? What happens between frame 1 and frame 2? What does "frame" mean in Source engine? Whisper says it's just the interval when the game checks what data it's got.

Now, let's assume we have a 100 tick server running 1000 FPS. Every 10 frames the server calculates where everybody are and then sends out player positions. At the "tick" the server processes incoming user commands, runs a physical simulation step, checks the game rules, and updates all object states. After simulating a tick, the server decides if any client needs a world update and takes a snapshot of the current world state if necessary. [ http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking ]

Between the ticks the server obviously does frames. What's happening there? Presumably it does NOT process incoming user commands, run physical simulation, check game rules or update object states. What happens in a frame?

If the server was 100 tick and 100 FPS. Then the server would - according to Whisper - get 100 times a second user data, process the data and send updates to all players. During a tick (not frame) the server presumably also calculates interpolation and lag compensation things for the client. Now, why would it make any smoother to have the server check 10 times in between what has happened, if it does the final calculation during a tick?

One thought I had was that if the server checks 1000 times a second when it has received game data from clients, then it would know more accurately during a tick that what should happen. But I think it's possible for the server to know exact timestamp when incoming packets have come to the server even if it doesn't check constantly for incoming data.

The snapshot update rate is limited by the server tickrate, a server can't send more then one update per tick. [ http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking ]

In "Lag compensations" article there's "frame loop", but there they say the server would send output to client every frame, so that's bit of a generalized view.

So tell me, what good is 1000 fps? What good is 100000 FPS, if all calculation is done in a tick. What's perfect relation between tickrate and FPS.

Should I increase tickrate as long as FPS remains stable at 1000 FPS? Should I lower tickrate to get higher FPS? Which one is better: High FPS or high tickrate? If I'm happy with 333 FPS server, then should I increase tickrate as long as FPS is over 333? If I want 2000 FPS, should I lower tickrate until I reach 2000 FPS? What's the best compromise between über high tickrate and über high FPS?

Quote:1000 FPS isn't just a market stunt anymore, although I'm sure 99% of the GSP's still use it that way.

Was it Nitoxys (who has written the famous 1000 fps kernel instructions) himself or someone else who said that he doesn't care about 1000 fps, but his customers do. That's why he wanted to know how to reach 1000 fps.


BTW. If you're going to reply, you can also try to shine some light to 100 HZ vs. 1000 HZ vs. 1000 fps thing.

[HBS|Ryan]

Quote:BTW. If you're going to reply, you can also try to shine some light to 100 HZ vs. 1000 HZ vs. 1000 fps thing.

In my setup, i didn't edit the param.h I found better cpu usage if I left the HZ at 100.

[drazah]

i run 1000fps servers myself, my servers are constant 995 - with either 0 or 10 players in a match. I did the same as ryan, i dont edit param.h either.
on an intel Q6600 i can happily run 8 x 12 man css 100 tick servers and all can be full and the fps of the servers sit at 994/995.

[avizeke]

think this should be locked this kind of debate is not healthy,


i trust sweet GSP does some amazing servers either way, and dispite what has been clouded or tarnished here today has not in any way had me in doubt.

wish you the best buddy.

[Drocona]

To be honest css, in all those years, I have never ran SRCDS on an OS other than Windows, so I don't have a clue on how the 100HZ settings would work, like HBS|Ryan said, it works with 100HZ too, which is totally not logical into my eyes.

I will write up a reply soon, i got a headache now and the numbers aren't helping hehe

[css]

Drocona Wrote:I will write up a reply soon, i got a headache now and the numbers aren't helping hehe

Do you have reply coming?

[Drocona]

css Wrote:First of all, could you point me to reliable source of information? Is there such? The developer wiki, although being a wiki, has lots of information in general server perspective.

This is one of the main problems you'll see with most games in the developer/technical world/side. There isn't a big combined official source based on facts posted by VALVe, it's all community work, now I won't say they are not reliable but there are quite a lot of things going around that were said once by some guy that claimed it to be that way and everyone has ever used it since. This means that there will be incorrect information floating around at websites like the wiki's, whenever I edited them to the real deal with explanation it would just get deleted by the next n00b that thinks it's the way everyone tells him to because they tell him...
I'm trying to do my best on these forums to keep the information up to date and verified, I try to have as much as possible but due to having a life too I can't always realize what I'd like to do here.

css Wrote:Especially the "lag compensation" thing isn't going to change in the next 10 years. Also other information about interpolation and extrapolation won't change even if computers get much more powerful. The wiki stuff, although old, will most likely be true about CS:S forever, even though there's rumor that the new "Source 2007" engine will be brought to CS:S too.

This is completely true, they only once changed the lag compensation and stuff a like as far as I know, it works good as it is now, I doubt it will ever be changed too, it would require a total recode of the hit registration and code system. About the engine, I'm not sure if they will revamp CS:S with the Orange Engine, it brings quite some more physics activity and higher bandwidth usage because of that. You may not have noticed but CS:S has gone through quite some engine updates through the years, from my records, CS:S uses about 1.5x more CPU and bandwidth than it did a few years ago. Though going under the same name the hit registration and lag compensation have been changed in one of these updates, since you most likely bought the game, you might want to try and get version 17 of CS:S and see the difference, it's HUGE!

css Wrote:I've been into servers for about three years. Three years ago I had couple servers, but it's down to one for couple years now. In general I'd say that I know what the source engine is. I've made several PHP / Perl / Mattie Eventscripts / Sourcemod scripts for the server. I've created one full-scale map. I've made the stats plugin. I've configured every little cvar in the server. I've read Whisper's wiki, Valve's wiki and large amount of information related to mapping, modding and optimizing. I do know how the server works.

Not arguing with you here

css Wrote:Can you say for (95-)100% certainty what does the FPS mean? What happens between frame 1 and frame 2? What does "frame" mean in Source engine? Whisper says it's just the interval when the game checks what data it's got.

I can not say for certain what happens, since VALVe wrote the code and in no way gives access to any of that (with good reason) there's no proof of anything that's happening in there. From the effects I've seen running various servers with various FPS numbers, the server simply calculates what is happening, lag compensation etc, anything a normal server would do except sending it anywhere, just local stuff about locations etc. I'm sure you read the article from VALVe about lag compensation and inter/extrapolation, it basically says it travels back and forth in time between server-client. Which a higher FPS should be more precise due to more of these calculations, even if the tickrate in such case would only be 33, the game will be more precise and because of that smart system VALVe built, time doesn't matter in these cases.

css Wrote:Between the ticks the server obviously does frames. What's happening there? Presumably it does NOT process incoming user commands, run physical simulation, check game rules or update object states. What happens in a frame?

I pretty much explained that above I think. Like you said, I believe it does NOT get data, just local stuff on the server.

css Wrote:One thought I had was that if the server checks 1000 times a second when it has received game data from clients, then it would know more accurately during a tick that what should happen. But I think it's possible for the server to know exact timestamp when incoming packets have come to the server even if it doesn't check constantly for incoming data.

The snapshot update rate is limited by the server tickrate, a server can't send more then one update per tick. [ http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking ]

I believe the incoming traffic, updates from the clients, are completely variable and don't update all at one an the same time, so updating data on the server would be smoother anyhow, sending it to other clients however seems to be done at every tick instead of variable times. Clients can have many different rithms, since there are a lot of clients at the same time, joined at different timestamps. It would explain how a client can run 33 tick on a 100 tick server without getting a synchronization error.

css Wrote:So tell me, what good is 1000 fps? What good is 100000 FPS, if all calculation is done in a tick. What's perfect relation between tickrate and FPS.

I think that relation really depends on your hardware, I always recommend people on these forums to stick to a max FPS of ~700, because this was the limit of an old P3 and some P4's I had running. Newer hardware might be able to go even higher, 1000FPS just seems really hard to get, on most common systems the performance will decrease above 700FPS because the server just can't keep up, these servers become highly unstable and crash about 5x as many as a normal 512 FPS windows server. You can also experience real bad choppiness in game.
Also what most people still do is look at cs1.6 settings, those servers ran 1000FPS fine, it would simply increase the play speed, clients ran faster, shot faster and reload faster, all that stuff. It's a misconception that this also works for the SRCDS, the SRCDS is a TOTALLY different system.

So basically you have to search your computers limits to get the best FPS ratings.

css Wrote:

Quote:1000 FPS isn't just a market stunt anymore, although I'm sure 99% of the GSP's still use it that way.

Was it Nitoxys (who has written the famous 1000 fps kernel instructions) himself or someone else who said that he doesn't care about 1000 fps, but his customers do. That's why he wanted to know how to reach 1000 fps.

I have no idea, but I totally agree with that, same goes for high tickrate servers, there really is NO need to run 100tickrate on the internet, while all the leagues set totally USELESS requirements for match servers. I just don't get it, all a waste of time, space and resources. If only they did just a LITTLE bit of research, they'd find that there really is no point above ~75 tickrate on internet.

Well long post, if you have any comments/questions, feel free again

[Spartanfrog]

A good stable 512 FPS server, kicks a 1000 FPS server's ass anyday. Just one thought. Also just by looking a servers and playing on them, it seems that bullet registration improves as FPS becomes more stable. Which kinda makes sense from what Drocona said.

[HBS|Ryan]

Im going to have to disagree with Spartie on that one. On the same hardware even, I can tell the difference between 1000fps and 500fps. but to each his own.

same with 66tic to 100tic. goto a good 66tic server and pick up an AK47 and spray it then immediately goto a 100tic and do the same. you can see/hear the difference when you fire the AK

[Spartanfrog]

Eh I notice the difference between tick's, but not FPS. Course the "1000 FPS" i played on could have just sucked .

[skeletor]

as spartanfrog said earlier.. a "stable" 500 fps server will produce better results than a "typical" 1000fps server. (sorry had to add a word)

What you will really notice in a server is rate drops. with a typical 1000fps server, these rates will drop hard, and you will feel it. Where a stable 500 fps server, won't have this. While a stable 1000fps server will will perform better, in all honesty I don't care for them. I have played on a 1000fps server sitting alone on a dual quad core harpertown xeon, and it was a bit better, but honestly, isn't really worth it. By it I mean the extra cpu usage, and cost due to usage.