I was avoiding writing a reply, as has been stated by probably about 7
mails now, the subject in question has been covered. It is for this
reason, you may note, that the conversation had actually stopped from
the list prior to the first complaint being sent. Subsiquently, two more
arrived. How interesting.
With regard to the argument, clearly I was upset, and some of the things
I said were taken too personally, where I had not intention for them to
have been. Either way, we discussed this off the list and did not
continue the discussion here. Still the complaints keep coming.
Please feel free to flame me again though, if you think this was another
"one too many" response, but I feel I just have to say, I had finished,
it was over, the complaints kept it going into today, nothing else!
blkraven wrote:
I respect people for giving good information, like James has done.
I can understand that people want specific information. But what I don't get
is if people get upset when they don't get what their looking for, really a
lot of people are ignorant about a lot of things (me included, no I'm not to
proud to accept my own or someone else's disabilities), and good specific
information is hard to come by.
It's human nature to want to help out, so people who think they have some
knowledge about a questions their bound to reply with it, in the end this
knowledge can turn out to be partly correct or completely incorrect.
I still don't see the point for people to get upset over this; if someone
has read something somewhere about an issue someone here is asking about,
and he shares it to try to help out. And then gets a load of arguing, really
I still find that rude.
Yes, I kind of have resolved it with James amicably.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Whisper
Sent: vrijdag 9 september 2005 5:25
To: [email protected]
Subject: Re: [hlds] Tick Rate Guide Updated
--
[ Picked text/plain from multipart/alternative ]
Geeze, some of you are so thinned skinned
All I want, all I ever wanted, is very specific answers to quite specific
questions, thus far up and until now, none of you have been able to answer
these questions.
Finally though, after chipping away and chipping away, somebody has come up
with an explanation about one specific area that does make some sense and
gives me at least, a deeper understanding of what it is I trying to achieve.
The relatively minor banter between blkraven and James Tucker was such a
non-issue and they even appeared to resolve it amicably in the end, and
James actually gave this list some very useful information because of it.
Dabosman, I don't like to debate, I just like to get straight answers that
make logical sense, and so far nobody has provided a straight answer as to
why 3 measurements of pings are at complete odds with each other.
If people were happy to accept answers despite what all observable eveidence
demonstrates, we would still think the Earth is the centre of the universe.
On 9/9/05, Brian M Frain (eternal) <[EMAIL PROTECTED]> wrote:
--
[ Picked text/plain from multipart/alternative ]
Well said LDuke but we shouldn't have to take such drastic measures. A few
are ruining the good for the rest. It is you same guys always bickering
that
ruins this list.
On 9/8/05, James Tucker <[EMAIL PROTECTED]> wrote:
Yup, create a filter for the subject line.
LDuke wrote:
--
[ Picked text/plain from multipart/alternative ]
Is there a way I can automatically send this thread to my junkmail box
and
still recieve the rest of the HLDS mailing list?
On 9/8/05, James Tucker <[EMAIL PROTECTED]> wrote:
Whisper wrote:
--
[ Picked text/plain from multipart/alternative ]
Well finally an answer that makes logical sense as to why default
kernel
resolution servers fps seem to sit at around 64
:)
I didn't write the guide from the techincal perspective, although I'd
love
nothing more than to have all the technical knowledge to not only
write
the
document but then explain the underlying logic for each and every
step
of
the process.
Then we should begin. Off-list.
That being said, I also just want shit to work and I also was seeing
at
the
time I originally wrote the thread in the STEAM forums every 2nd
question
related to tickrate with nobody able to produce a definitive answer
as
to
how to actually make it work and why.
Exactly, and it is for this reason I have a strong appreciation for
all
the hard work you have put in, and again you have my thanks for that.
My explanation of how rate sv_maxrate sv_minrate relate to each other
as
well as sv_maxupdaterate sv_minupdaterate cl_updaterate relate to
each
other
managed to confuse even the developers on how it works, and I am
still
trying to work out how to explain it better to a less technical
audience.
Indeed, technical explanations in simple terms are hard. It is
gerneally
best to stay away from abstractions and generalisations for the simple
reason that they do not expand well to include other, or more complex
ideas. There are many examples of this problem available in the
archives
of most technical mailing lists.
Since the last netcode update, where Alfred announced that the cmdrate
and updaterate numbers should now properly correlate with packets per
second rates shown in net_channels I have found the technical
descriptions are now easy to create, and general explanation is much
simpler. Gone are the days when you had to set cl_updaterate 100 or
above to get 40-50 packets per second out of a 100 tickrate server in
certain scenarios. Nowadays, with sane settings on the server, the
client settings work as expected, and achieve predicable results. The
same goes for the server settings.
Just to let you know James, our GSP actually exists to cater
primarily
to
broadband users, with the majority sitting on sub 50ms pings and some
on
sub
10ms pings so to give them a good end user experience we tweak the
servers
up for broadband users with good connections and most of us do notice
a
considerable difference between a 33 tickrate server with default
rates,
and
a 66 tickrate server with 20000/100 rates.
Indeed you will. There is no dispute over proper rate selection here
:)
If you look at the settings closely, you will notice that since the
netcode update, you can set sv_maxupdaterate 66 (I set 67/70 in most
places, as sometimes it still sends a little more than the tickrate).
There are no more updates to be sent than the ticks, so 100 is
slightly
overspecified. This does not cause an issue of course, as it's merely
a
cap, and doesn't change anything that occurs in the data flow in this
scenario.
On 9/8/05, James Tucker < [EMAIL PROTECTED]> wrote:
Whisper wrote:
--
[ Picked text/plain from multipart/alternative ]
Please feel free to write you own or tell us precisely where you
think
we
are going wrong and why.
I have detailed this inline in each mail. Your guide is generally
good,
and is targeted for a different audience than this list. I would be
more
than happy to assist you in adding/correcting anyhting. Many thanks
for
actually producing it.
I'd love nothing that a logically correct and complete reproducable
guide
on how to get the most out of a server.
Unfortunately, I just agreed to spend most of my time keeping my
information to myself. You have others to thank for that.
As some of us have come to find out Valve can sometimes be
completely
open
about certain issues and on others they completely clam up like we
we've
mentioned the mad cousin that nobody ever talks about.
Indeed. I got a t-shirt too.
If in fact THE DEFAULT TIMER RESOLUTION OF THE WINDOWS KERNEL IS
7.8ms.
why
do our servers only get around 65fps even though fps_max is clearly
set
and
defaulted to 300 unless you change it?
Ah, well you see, 65fps isn't 60Hz :)
Typcially (as a general, but not accurate rule) srcds does not run
at
greater than (kernel timer resolution/2)fps. This is true of the
linux
builds aswell, which more accurately hit 50fps for a 10ms timer
which
is
the default on 2.4.x branch kernels. FYI - most linux srcds hosts
now
use a 1000Hz, or 1ms resolution on linux platforms.
On windows, the timer resoution is around 7.8ms by default, which is
around about 128Hz, which is around about double 65fps. Now clearly,
the
correlation is the same, as the code is the same, and the problem is
the
same.
srcds clearly contains some timer dependant code, that is referenced
at
least twice in one frame. This creates an artificial frame limit, as
the
processor will block busy-waiting untill that poll, or will yeild to
other threads, but either way, will not process frame data until the
timer poll.
_______________________________________________
To unsubscribe, edit your list preferences, or view the list
archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
--
_______________________________________________
To unsubscribe, edit your list preferences, or view the list
archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
--
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
--
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
--
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
