Re: [hlds_linux] Changelog?
http://steampowered.com/v/index.php?area=posts&AppId=240&cc=US -Richard Eid On Wed, Sep 3, 2008 at 7:30 PM, Chris S <[EMAIL PROTECTED]> wrote: > Where can I find a changelog for all of the CSS updates? > > I am interested in knowing all of the updates since version : > 1.0.0.34/73224 > > Thanks > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
[hlds_linux] Changelog?
Where can I find a changelog for all of the CSS updates? I am interested in knowing all of the updates since version : 1.0.0.34/73224 Thanks ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] [hlds] Counter-Strike 1.6 Beta Available
[Request] Can valve make an WAD directory in next hlds release for Counter strike beta? to make better order and better manipulation for multiple servers installations? ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] [hlds] Counter-Strike 1.6 Beta Available
At 05:28 PM 9/2/2008, Alfred Reynolds wrote:
>We compile against glibc-2.3.2 and that abstracts the details of any
>kernel level calls for us (we never directly sysctl), so it should be
>old.
>
>- Alfred
A couple of other questions.
How are you doing your memcpy/memset in the srcds_{i686,amd}? letting
gcc generate the code or did you write your own? I'm trying to reduce
L1 cache usage on source by replacing some memcpy functions (whatever
gcc decides to create) with memcpy that uses
movnti instructions. I might even use movntq for more savings but
that's an overkill..
Why don't you use clock_gettime() instead of gettimeofday() for the
Linux binaries? gettimeofday has alot of know problems considering it
best guesses wallclock time and can go backwards..
clock_gettime(CLOCK_MONOTONIC) is a little better, considering the
former is old and nonstandard.
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] [hlds] Counter-Strike 1.6 Beta Available
At 05:28 PM 9/2/2008, Alfred Reynolds wrote:
>We compile against glibc-2.3.2 and that abstracts the details of any
>kernel level calls for us (we never directly sysctl), so it should be
>old.
>
>- Alfred
A couple of other questions.
How are you doing your memcpy/memset in the srcds_{i686,amd}? letting
gcc generate the code or did you write your own? I'm trying to reduce
L1 cache usage on source by replacing some memcpy functions (whatever
gcc decides to create) with memcpy that uses
movnti instructions. I might even use movntq for more savings but
that's an overkill..
Why don't you use clock_gettime() instead of gettimeofday() for the
Linux binaries? gettimeofday has alot of know problems considering it
best guesses wallclock time and can go backwards..
clock_gettime(CLOCK_MONOTONIC) is a little better, considering the
former is old and nonstandard.
___
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Measuring the real update rates of players
Yes, I do agree that there is a serious problem with players that deliberately sabotage their own rates to produce that skipping effect, especially on competitive servers. css wrote: > You've got good points there. > > I use the system to get rid of total ~10-25/s rate laggy players, who are > very clearly moving jiggy. They don't have high ping, but for some reason > they move by jumping one meter at a time. I believe that's because of low > update rates. Anyways, they move laggy and I believe this system catches > them better than anything else. > > The server does extrapolation and interpolation, which should dampen the > loss of update packets. It probably works quite well, because on my server > there are all the time players who have rates jumping between 30-66/s, and > everybody seems to move smooth. > > I believe this system could be used to create "truly 66/100 tick servers", > which make sure that *all* players do send 66 updates per second all the > time. At least if I had one of those 1000 fps 100 tick servers, I sure > would like to be sure that everybody who play there are doing the most of > it. > > In more casual way this is probably better used to kick those laggy low > raters who have hacked their cl_cmdrate (or ping) to show something else > than the truth. Also one of my plans has been to dump the status of > players to a web page. Then everybody could say something like "rates" > in-game and they'd see this web page and could check everybody's rates. > Now there are many players just looking at each other's cl_cmdrates and > calling them low raters groundlessly > > Someone might think that it's wrong to calculate packets as "updates" > because one packet may contain multiple commands. This is true, but it's > probably about one in a million packets that contains more than one > command. Most packets that I see are around 35 bytes containing probably > no commands at all. > > Thanks for feedback. I hope to see some results from other server admins. > > -- > Ghost > > On Tue, 2 Sep 2008, Crazy Canucks wrote: > > >> Someone official can correct me if I am wrong, but from everything I >> have read, lagging clients have absolutely no effect on the server, or >> on any player other than themselves (other than in certain cases with >> extremely low update rates where the client may appear to "skip"). High >> ping and low update kickers in general though only serve to reinforce an >> unwarranted bias against those who may be connecting to a server from a >> distance, or whose hardware, or connection might not be ideal. >> >> If your aim is to create an "in-crowd" of rich players with the latest >> hardware and perfect connections, then this sort of plugin will >> accomplish that admirably. If your aim is to create a competitive >> server environment which provides the best possible technical support, >> in terms of bandwidth and update rates, for your clients, this sort of >> plugin will have no effect whatsoever. If your aim is to create a fun, >> competitive server with a great atmosphere, this kind of plugin will >> have the opposite effect... >> >> Cheers, Drek >> > > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > > ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Measuring the real update rates of players
You've got good points there. I use the system to get rid of total ~10-25/s rate laggy players, who are very clearly moving jiggy. They don't have high ping, but for some reason they move by jumping one meter at a time. I believe that's because of low update rates. Anyways, they move laggy and I believe this system catches them better than anything else. The server does extrapolation and interpolation, which should dampen the loss of update packets. It probably works quite well, because on my server there are all the time players who have rates jumping between 30-66/s, and everybody seems to move smooth. I believe this system could be used to create "truly 66/100 tick servers", which make sure that *all* players do send 66 updates per second all the time. At least if I had one of those 1000 fps 100 tick servers, I sure would like to be sure that everybody who play there are doing the most of it. In more casual way this is probably better used to kick those laggy low raters who have hacked their cl_cmdrate (or ping) to show something else than the truth. Also one of my plans has been to dump the status of players to a web page. Then everybody could say something like "rates" in-game and they'd see this web page and could check everybody's rates. Now there are many players just looking at each other's cl_cmdrates and calling them low raters groundlessly Someone might think that it's wrong to calculate packets as "updates" because one packet may contain multiple commands. This is true, but it's probably about one in a million packets that contains more than one command. Most packets that I see are around 35 bytes containing probably no commands at all. Thanks for feedback. I hope to see some results from other server admins. -- Ghost On Tue, 2 Sep 2008, Crazy Canucks wrote: > Someone official can correct me if I am wrong, but from everything I > have read, lagging clients have absolutely no effect on the server, or > on any player other than themselves (other than in certain cases with > extremely low update rates where the client may appear to "skip"). High > ping and low update kickers in general though only serve to reinforce an > unwarranted bias against those who may be connecting to a server from a > distance, or whose hardware, or connection might not be ideal. > > If your aim is to create an "in-crowd" of rich players with the latest > hardware and perfect connections, then this sort of plugin will > accomplish that admirably. If your aim is to create a competitive > server environment which provides the best possible technical support, > in terms of bandwidth and update rates, for your clients, this sort of > plugin will have no effect whatsoever. If your aim is to create a fun, > competitive server with a great atmosphere, this kind of plugin will > have the opposite effect... > > Cheers, Drek ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Measuring the real update rates of players
2008/9/3 Fedot <[EMAIL PROTECTED]> > Hi > > yes you are right > but as i write before there is a bug with ping > can you add this feature like at ace_rates? to check clients rates? > > yours letter from 3 сентября 2008 г., 19:12:49: > -- > > No, no, no! > > > ACE rates look at client's cl_*rate settings and kick those players who > > have set cl_cmdrate or cl_updaterate too low. That's stupid for two > > reason: > > > 1. I can have cl_cmdrate and cl_updaterate set to 10/10, but when I join > > on a server where they have sv_mincmdrate and sv_minupdaterate set to 66, > > my game will automatically use those values. ACE rates would kick me even > > though I have good rates. Stupid. > > > 2. My computer is somewhat old. It can't hold solid 66 FPS at any time. > > I've set my cl_cmdrate and cl_updaterate to professional 101/101 levels. > > Anyway, when I play, my game sends only the number of updates that my FPS > > is. For example if my FPS happens to drop to 40, then my cmdrate is 40 - > > although I have cl_cmdrate 100. ACE rates wouldn't kick me, because I've > > got those "good rates". Stupid. > > > I hope you both can take a better look at the system. Thanks for the > > general feedback, though. It's good to have comparison to different rate > > forcing systems. > > > I'll post longer reply to Crazy Canuck's message later. He got some good > > points which don't fit to this post ;) > > -- > > > -- > With regards > Fedot > mailto:[EMAIL PROTECTED] > > > ___ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > who cares about rates (what can be faked), when you can check the number or packets sebt by the user with iptables? Tyrael ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Measuring the real update rates of players
Hi yes you are right but as i write before there is a bug with ping can you add this feature like at ace_rates? to check clients rates? yours letter from 3 сентября 2008 г., 19:12:49: -- > No, no, no! > ACE rates look at client's cl_*rate settings and kick those players who > have set cl_cmdrate or cl_updaterate too low. That's stupid for two > reason: > 1. I can have cl_cmdrate and cl_updaterate set to 10/10, but when I join > on a server where they have sv_mincmdrate and sv_minupdaterate set to 66, > my game will automatically use those values. ACE rates would kick me even > though I have good rates. Stupid. > 2. My computer is somewhat old. It can't hold solid 66 FPS at any time. > I've set my cl_cmdrate and cl_updaterate to professional 101/101 levels. > Anyway, when I play, my game sends only the number of updates that my FPS > is. For example if my FPS happens to drop to 40, then my cmdrate is 40 - > although I have cl_cmdrate 100. ACE rates wouldn't kick me, because I've > got those "good rates". Stupid. > I hope you both can take a better look at the system. Thanks for the > general feedback, though. It's good to have comparison to different rate > forcing systems. > I'll post longer reply to Crazy Canuck's message later. He got some good > points which don't fit to this post ;) -- -- With regards Fedot mailto:[EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Measuring the real update rates of players
On Tue, 2 Sep 2008, Cc2iscooL wrote: > Client gets kicked. Umm.. That's what is supposed to happen. I think you tried to point out that in a gunfight everybody's rates drop below 66/s. That's not true. Also - obviously - the rate tracking system counts minimum / average / maximum over longer period. If you had tried the system you probably would have better idea what's it all about. The system can be set to kick (as I've actually done) players whose maximum rate in the past couple minutes has been less than 25/s. I recommend testing the system if you're interested about the idea. On Wed, 3 Sep 2008, Fedot wrote: > the better way too block that kind of players is setting the ES (event > script) + ace_rates script it kicks players if they rates is more/less > some limits and it work perfectly No, no, no! ACE rates look at client's cl_*rate settings and kick those players who have set cl_cmdrate or cl_updaterate too low. That's stupid for two reason: 1. I can have cl_cmdrate and cl_updaterate set to 10/10, but when I join on a server where they have sv_mincmdrate and sv_minupdaterate set to 66, my game will automatically use those values. ACE rates would kick me even though I have good rates. Stupid. 2. My computer is somewhat old. It can't hold solid 66 FPS at any time. I've set my cl_cmdrate and cl_updaterate to professional 101/101 levels. Anyway, when I play, my game sends only the number of updates that my FPS is. For example if my FPS happens to drop to 40, then my cmdrate is 40 - although I have cl_cmdrate 100. ACE rates wouldn't kick me, because I've got those "good rates". Stupid. I hope you both can take a better look at the system. Thanks for the general feedback, though. It's good to have comparison to different rate forcing systems. I'll post longer reply to Crazy Canuck's message later. He got some good points which don't fit to this post ;) -- Ghost ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Measuring the real update rates of players
Hi hm i checked the code - perfect work, keep going i'll test this script at my servers yours letter from 3 сентября 2008 г., 2:02:09: -- > Hello. > I've been running a public CS:S server for few years now, and throughout > the years players have complained about laggy "low raters". From the > beginning there have been sv_mincmdrate and sv_minupdaterate set to match > the tickrate on the server. According to the information related to these > variables, they should enforce the lowest acceptable update rate for > players. Unfortunately that's not true if player's computer is unable to > achieve the desired rate. (Also it was only about year ago when the > server's sv_*rate settings were actually patched to do what they were > supposed to do.) > Some time ago I came up with pretty neat solution to find "low raters" > from the diverse bunch of players. The solution is to measure the real > update rate by Linux's iptables. Obviously the Linux server itself sees > every packet that comes and goes from the game server. That's why it's > possible to measure the true rate for all players - and get rid of laggy > "low raters". Looking just at player's cl_*rate settings is not reliable > at all - and mostly useless because the server can enforce the rates. > I've been amazed to see how many players are not achieving the solid 66 > updates per second. I've set limit on my server to 25/s, but still couple > players per hour get kicked due to low rate. > Requirements for the system: > * Linux server with root access > * Semi-optional: Mani / Beetles / SourceMod plugin > The system can be used on for example public "hi-performance" 66/100 tick > servers to make sure that all players achieve the solid ~66 updates per > second. It could be also used on match servers to ensure that all > competitors have solid update rate. > It's still under development. Having feedback from other server admins > would be useful. > Download: > http://css.setti.info/code/ratetables/ratetables2.pl > More information and talk at srcds.com forums: > http://forums.srcds.com/viewtopic/7255 > -- > Ghost > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- -- With regards Fedot mailto:[EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] [hlds] Counter-Strike 1.6 Beta Available
On Wed, 3 Sep 2008, Guy Watkins wrote: > } -Original Message- > } From: [EMAIL PROTECTED] [mailto:hlds_linux- > } [EMAIL PROTECTED] On Behalf Of kabukiUkie > } Sent: Wednesday, September 03, 2008 12:04 AM > } To: Half-Life dedicated Linux server mailing list > } Subject: Re: [hlds_linux] [hlds] Counter-Strike 1.6 Beta Available > } > } +1 on 64-bit binaries > } > } we have a beta server running for several days now, and one thing i > } noticed > } is that the player count reported in the server info is all messed up. I > } see > } a few other servers with the same problem. basically, the server info in > } the > } steam browser list and in game show that there are x amount of players > } connected when there really aren't that many or any at all. console status > } reports the correct number of players. > > I have seen this with CSS for about 1 year now. Normally off by 1, but I > have seen it off by 2 and 3. I think this is reset if I restart the server. > > Also, server info shows 1 or 2 player names, even with no one connected. I > can even restart the server and the players are still listed. So, this > seems to be a client issue. Sounds like it caches the data somewhere (over the rainbow) /Bjorn ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Measuring the real update rates of players
Hi the better way too block that kind of players is setting the ES (event script) + ace_rates script it kicks players if they rates is more/less some limits and it work perfectly and yes there are bug with rates example cl_cmrate/cl_updaterate 101 you have real ping at server ~100 you write cl_cmrate/cl_updaterate 1 and you ping is 5 or 1 - street magic -) no kicks for high ping and other players can't kill you because you are lagger and yes your rates is forced by server parameters(sv_mincmdrate and sv_minupdaterate) client consol showed that rates. but your ping is 5 not real 100 and Valve please add new plugins: sv_minchoke, sv_minloss - will be very helpfully yours letter from 3 сентября 2008 г., 2:02:09: -- > Hello. > I've been running a public CS:S server for few years now, and throughout > the years players have complained about laggy "low raters". From the > beginning there have been sv_mincmdrate and sv_minupdaterate set to match > the tickrate on the server. According to the information related to these > variables, they should enforce the lowest acceptable update rate for > players. Unfortunately that's not true if player's computer is unable to > achieve the desired rate. (Also it was only about year ago when the > server's sv_*rate settings were actually patched to do what they were > supposed to do.) > Some time ago I came up with pretty neat solution to find "low raters" > from the diverse bunch of players. The solution is to measure the real > update rate by Linux's iptables. Obviously the Linux server itself sees > every packet that comes and goes from the game server. That's why it's > possible to measure the true rate for all players - and get rid of laggy > "low raters". Looking just at player's cl_*rate settings is not reliable > at all - and mostly useless because the server can enforce the rates. > I've been amazed to see how many players are not achieving the solid 66 > updates per second. I've set limit on my server to 25/s, but still couple > players per hour get kicked due to low rate. > Requirements for the system: > * Linux server with root access > * Semi-optional: Mani / Beetles / SourceMod plugin > The system can be used on for example public "hi-performance" 66/100 tick > servers to make sure that all players achieve the solid ~66 updates per > second. It could be also used on match servers to ensure that all > competitors have solid update rate. > It's still under development. Having feedback from other server admins > would be useful. > Download: > http://css.setti.info/code/ratetables/ratetables2.pl > More information and talk at srcds.com forums: > http://forums.srcds.com/viewtopic/7255 > -- > Ghost > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- -- With regards Fedot mailto:[EMAIL PROTECTED] ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
