Tony.
Here is a post by Ron Ayton that I've had archived for some time now. Hope
it helps.....
----------------------------------------------------------------------------
-----------------------------------------
A few ideas and thoughts on how to improve on-line connections Most of us
are not blessed with Cable etc. so we have to make the most of dial-up modem
connections, so this is a brief idea on how to improve your analogue,
dial-up modem connections.... This is simply to give you some idea of where
to begin and what to play with to try to improve your on-line gaming
connections, using an analogue modem. Firstly, the DUN you use for the
Internet is NOT suitable for on-line gaming. It most likely would be using
Data Compression, Error Correction, Maximum FIFO Buffers and probably going
as hard as your poor little modem can peddle, or harder if i believe half of
the tales i hear about.... All of the above is VERY bad news for on-line
gaming. You should make up another DUN for on-line gaming, with Data
Compression and Error Correction turned OFF. Also, turn down the maximum
connect speed of your modem to 24000, 26400 or 28800 at a maximum. The
quality of the lines in your area, will dictate the best speed for you. This
can be done in the Modem Properties tab of your DUN for the designated
Modem. Read the booklet that comes with your modem for the initialization
strings you need. NOTE: Some people are under the mistaken belief that a
slower connect speed will take longer to get to the host, resulting in
higher latencys (pings) etc. This is totally false.!!! The connection speed
of your modem, is a false analogy, as the connection speed only refers to
how much bandwidth the modem is capable of sending at any given time, NOT
how fast it can send it. Hence, the ammount of data that a GPL host requires
from a client, will get to the host at exactly the same time, whether the
client is using 26400 baud or 56000 baud, and 99.9% of the time, the 26400
baud rate from the client will have a lot less errors and be a lot more
stable than the 56000 baud's best effort, unless you are lucky enough to
live in a area where optical fibre abounds, all the way from you to the
host, which is very unlikely. :) I only ever use a maximum of 26400 on-line
with GPL, as the lines in my area, leave a bit to be desired, but with my
normal internet dun, i use 33 to 56k baud, and let the error correction fix
any problems i encounter, which is fine for surfing and general internet use
etc. (error correction is a definite no-no for GPL on-line) To make more
than one DUN with different modem initialization strings, you will need to
go to the MODEMS in the control panel and ADD another modem. This will not
overwrite your present modem settings, but will add another modem to the
modems you have listed in the modem list. As you add more modems to the
list, Windows will simply add a #2 #3 #4 etc etc to the end of the modem
name. That way you can set up as many DUN's as you have modem names, each
one with different initialization strings. Once you have your on-line DUNS
and modem set up correctly, you will actually find that disco's, error
filled connections and high latency's will simply become a bad memory...
NOTE: The FIFO buffers should be set no higher than the 2nd mark from the
left, unfortunately these are global settings, so if you set them at the 2nd
setting from the left, that is where they will remain, regardless of which
DUN you are using. I have not noticed any lesser performance in surfing or
downloading with the buffers set there anyway, so i just leave them there
all the time. Make sure you turn Error Correction off, also turn off the
Data Compression and select Hardware Flow Control in you modem's properties
tab for the On-Line gaming DUN. If you are a paranoid type, as i am, you
could also add those commands to the extra settings in the modem
initialization string, just in case you don't trust windows to carry out
your wishes and let's face it, who trusts windows to do anything right when
it comes to gaming anyway.. I have included the following line for my US
Robotics modem in my On-Line Gaming DUN.. &F1&K0&M0&U10&N13 &F1 Resets modem
to standard, in case windows messed it up. &K0 Disables Data Compression, in
case windows forgot. &M0 Disables Error Correction, as per above scenario..
&U10 Sets the floor connect speed to 19200. &N13 Sets the ceiling connect
speed to 26400. The above is an example for the US Robotics modem, different
modems will vary slightly in the initialization strings, so read your manual
for further details to achieve similiar results. Secondly.. Windows in it's
infinite wisdom sets up the Port settings on the extra conservative side by
default. This needs to be changed manually. To do this: Go to the Control
Panel, go to System, go to Device Manager, go to Ports (com & lpt). Select
Com1 , go to Port Settings, and adjust the following to read as follows:
Bits per second 115200 Data 8 Parity none Stop Bits 1 Flow Control Hardware
Go to Advanced and adjust the FIFO Buffers so they are 1 mark from the left
side. Do the same for Com Port 2. The following topics, are relevant to the
new CORE.INI file, that ships with GPL 1.1 NOTE: This file is called:
COREINI.SAMPLE and must be re-named to: CORE.INI before GPL 1.1 can make use
of it. It is located in the: SIERRA\GPL\ folder, after the GPL 1.1 patch has
been installed... A couple of slight adjustments are needed to get the best
out of the new CORE.INI file. Following, is a brief example of a couple of
changes i made to my CORE.INI file, to suit on-line play on VROC. The parts
you need to alter from the CORE.INI that ships with GPL1.1 are the two lines
concerned with band width: net_mdm_client_send =2 &
net_mdm_server_send_every =2 Change both of those to 3, like below in the
pasted example. net_mdm_client_send_every = 3 ; Client packet freq on dialup
net_mdm_client_send_size = 84 ; Client packet size on dialup
net_mdm_server_send_every = 3 ; Server packet freq on dialup
net_mdm_server_send_size = 84 ; Server packet size on dialup That is the
standardized band settings that VROC uses, for clients and hosts, and
everyone running on VROC, should alter the relevant lines to match the above
criteria. Also, for me, the new Synch method does not work well... The best
way to tell if the new synch method is working for you, is to race on-line,
and if you are noticing a lot of slow motion & speed-up effects, then the
new synch method is not working well for you. The new synch method does not
use the: clock_adj_delay = 4 line either, as that is disabled when the
synch_method is set to 1. I have changed the line: synch_method =1 to
synch_method = 0 (which re-enables the old version of synchronization) By
altering that line back to 0, GPL 1.1, uses the following line:
clock_adj_delay = 4 ; How often may client adjust clock? The number of 4,
did not work for me at all, so after much experimenting with different
values, both locally here in Australia, and to overseas hosts, i settled for
a value of: 16 eg: clock_adj_delay = 16 ; How often may client adjust clock?
That cured all my slow-mo problems, and 99 % of my warping problems.
Anything under 14, began to give me frame stuttering, so i left it at 16,
which seems strange, as before with version 1.000 of GPL, the default delay
setting of 12, and even 10 seemd to work best. However, with the new GPL
1.1, a clock setting of 16 seems to be much more stable and stutter/warp
free. You may need to experiment with this line, to suit your own local and
overseas conditions, but generally, if you have good low pings to your
regular hosts, a value of 8 to 10, seems to work well enough. If latency is
an issue, then a higher value of 12 14 or 16, seems to do a better job of
keeping the client's computer in synchronization with the hosting computer.
NOTE: This line does not effect the hosting computer, or the other clients,
it is simply a localized, client based, instruction set. The only way this
line could effect the other clients and host, is if you alter this value to
some ridiculous ammount, which causes your own computer to fall out of
synchronization with the hosting computer at a much larger rate, and then,
the other clients would notice your car disappearing (warping) around more
than usual, however, this does not effect the other clients in any other
way. NOTE: Things may change for the better, when the patch for the patch is
released, in regards to what synch method we will end up using, but for the
moment, the older (original) version of: snych_method = 0 seems to work best
for the majority of us.. Hopefully, when the patch for the patch is
released, we can go back to the new method: synch_method = 1 which should
allow for a more seamless adjustment of the timing, between the hosting and
client's computer. NOTE: GSB2 & VROC2, allows the setting up and use of the
old synchronization method in the joining screen, if you would rather do it
from there, than make the designated changes in your CORE.INI file...
Another line you may want to change is the line that says: disable_modem = 0
; Don't look for/use modems If you change that line to: disable_modem = 1 ;
Don't look for/use modems By disabling modem lookup, GPL 1.1, will start up
a lot quicker.. This only effects the modem to modem dial-up playing between
two players, and will not effect GPL's Internet play.... The only other line
you might need to alter, is the line: alternate_ip_addr_lookup = 0 ; Find IP
addresses another way If GPL cannot find your ip address, to enable you to
join on-line races, change that line to 1.. eg: alternate_ip_addr_lookup = 1
; Find IP addresses another way Finally, why do people insist on having to
run at 1024x768 with all the eye candy on for on-line racing. Frame rates DO
matter as far as warping and good on-line play go. If you are not seeing
36fps in on-line play, then your CPU is being taxed. Give your CPU a rest
and turn down the
...
read more »
