FAO: Owen Lloyd
Comatosed
as you promised to in an earlier thread. As you claim everyone
suggesting/using init strings is wasting their time I welcome your response.
As a reminder the post is below.
*********
Apologies, another batch of corrections coming up....
<snip>
>NB there are no "magic init strings" to solve your problems. having
>examined most of these bandied about by people who have no idea what
they're
>taking about, most of them are:-
Indeed init strings are not "magic" but they can be of use.
>limiting the connection speed to 33.6 (irrelavent as the important bit for
>quake/II is the up direction, which is always 33.6 max anayway)
Incorrect (and in part nonsense). The idea behind limiting speed to 33.6 is
to prevent "retrains". This is where due to a change in line quality during
the course of your connection the modem attempts to negotiate an alternative
speed (could be increase or decrease). This retraining is often the cause of
PJOD. I personally use an init string to limit max/min speed to 41333, in my
case that seems to have pretty much sorted the PJOD trouble.
Your comment on the important part of the connection being the upload is a
total load of arse. As I've said in a previous thread the only data going
upstream is your movement/control data. What comes downstream??? Data
describing every entity in your PVS (potential visible set, thanks for that
Matt ;o). Now which do you think will be greater? Your movement data going
upstream or the entity data describing 4 players firing HBs and RLs in front
of you???
>turning off flow control (which is madness as the overflows get kicked up
to
>the protocol level).
Can't comment on this. I've never tried playing with it but I remember Sujoy
mentioned on his site that he used software flow control as it gave the best
connection IN HIS CASE.
>Turning off hardware compression MNP5/ARQ etc (again just plain stupid).
** Bit of guessing coming up **
If I remember rightly MNP5 compression does in fact introduce some latency
(however small) into the data stream. As the q2 data stream is already
compressed (que Matt with more info please as I'm using distant memory now
;o) additional compression techniques will be of little benefit to the rate
of transfer. I read about turning off MNP5 on "The ping page" (can't
remember URL) where it was suggested that disabling it may improve latency
and have no negative effect as a different protocol would be negotiated by
the modem instead.
** Guessing over **
>If anyone finds any more of these idiots claiming to have the solution to
>all your modem problems - post their modem commands here and I'll be more
>than happy to pick them apart :-] They are just wasting peoples' time.
Ok please do....
AT+MS=12,1,41333,41333,1,0,33600
Modem-Speed = Protocol, Automode, Min speed, Max speed, Coding, RBS, Max
send speed.
Look forward to your post.
Comatosed [CFH]
comatosed@_NOSPAM_bigfoot.com
ICQ 8503080
Resident of #CFH & #Quake2.uk
[WTF]Shadrach
Comatosed wrote in message <7bj7pe$p9q$1...@starburst.uk.insnet.net>...
>I'm still waiting for you to tell me whats wrong with my modem init string
>as you promised to in an earlier thread. As you claim everyone
>suggesting/using init strings is wasting their time I welcome your
response.
Wow, I never even knew he read this newsgroup ;)
Shadrach.
Owen Lloyd
Comatosed wrote in message <7bj7pe$p9q$1...@starburst.uk.insnet.net>...
>I'm still waiting for you to tell me whats wrong with my modem init string
>as you promised to in an earlier thread. As you claim everyone
>suggesting/using init strings is wasting their time I welcome your
response.
Sorry, there's so many posts/day, I rarely scroll back up the list - I'd be
here all day. I also did not say I would say what was wrong with it - it
may be perfectly reasonable, but probably no different than the default,
where it matters - after all, the modem is configured to work as well as it
can.
>
>>limiting the connection speed to 33.6 (irrelavent as the important bit for
>>quake/II is the up direction, which is always 33.6 max anayway)
>
>Incorrect (and in part nonsense). The idea behind limiting speed to 33.6 is
>to prevent "retrains". This is where due to a change in line quality during
>the course of your connection the modem attempts to negotiate an
alternative
>speed (could be increase or decrease). This retraining is often the cause
of
>PJOD. I personally use an init string to limit max/min speed to 41333, in
my
>case that seems to have pretty much sorted the PJOD trouble.
Well bad line quality is still going to cause retrains, no matter what your
max line speed is set to. Not that the line speed is *that* important for
Q2 though - it's latency not bandwidth that it requires, being an
interactive conversation. So limiting the speed it can train up at IS
nonsense. Think about it: If your line is that bad, I suggest you get
*that* fixed, not fiddle with your modem in an attempt to compensate.
>
>Your comment on the important part of the connection being the upload is a
>total load of arse. As I've said in a previous thread the only data going
>upstream is your movement/control data. What comes downstream??? Data
>describing every entity in your PVS (potential visible set, thanks for that
>Matt ;o). Now which do you think will be greater? Your movement data going
>upstream or the entity data describing 4 players firing HBs and RLs in
front
>of you???
Total load of arse is it? I agree, you would think the download would be
greater, for the very reasons you assert, but that is simply not the case.
Fire up Q2, and play for a bit, and then ask your OS how many packets have
been a) transmitted and b) received. You can also just watch the lights on
your modem - more stuff goes up than comes down, I don't know why, but
presumably, the server needs extra data from you that us not passed to the
other clients. After a session tonight, ifconfig reports 149991 RX, and
871692 TX, for the ppp link.
>
>>turning off flow control (which is madness as the overflows get kicked up
>to
>>the protocol level).
>
>Can't comment on this. I've never tried playing with it but I remember
Sujoy
>mentioned on his site that he used software flow control as it gave the
best
>connection IN HIS CASE.
Well he is mistaken - it is just a coincidence (perhaps his hardware flow
control was not actually working due to for eg, the cable not being fully
wired - and software flow control was better than none at all?). If you
turn off flow control, the potential for lost packets increases. These
packets will be re-requested from the server by the IP stack - not by Q2,
which knows they are irrelavent now anyway. So your connection ends up
carrying data that is old and not required.
>
>>Turning off hardware compression MNP5/ARQ etc (again just plain stupid).
>
>** Bit of guessing coming up **
>If I remember rightly MNP5 compression does in fact introduce some latency
>(however small) into the data stream. As the q2 data stream is already
>compressed (que Matt with more info please as I'm using distant memory now
>;o) additional compression techniques will be of little benefit to the rate
>of transfer. I read about turning off MNP5 on "The ping page" (can't
>remember URL) where it was suggested that disabling it may improve latency
>and have no negative effect as a different protocol would be negotiated by
>the modem instead.
Well you are correct on this one, Q2 uses delta compression on the packets
by default. Your modem also does MNP5 and may not be able to compress it
further. So turning this off *may* prove beneficial if your modem has a
particularly slow processor, as giving it less to do should result in lower
latency, at the modem. In practice, I find this make little difference.
Curiously, if you turn off delta compression in Q2, your ping goes up, and
you start to lose packets (as expected) but if you *increase* your "rate"
this problem goes away...another one of those things you would *think* would
be the other way around. However, with 2 lots of compression, you would
expect turning one off to make little difference apart from the small
differences in the efficiency of the respective compression engines, so why
does latency increase significantly when you disable compression in Q2? I
would suggest that the Q2 delta compression is not actually that efficient,
and that the modem *does* manage to further compress the data, by a
significant amount.
>>If anyone finds any more of these idiots claiming to have the solution to
>>all your modem problems - post their modem commands here and I'll be more
>>than happy to pick them apart :-] They are just wasting peoples' time.
>
>Ok please do....
>
>AT+MS=12,1,41333,41333,1,0,33600
>
>Modem-Speed = Protocol, Automode, Min speed, Max speed, Coding, RBS, Max
>send speed.
>
Well, as you already know what they do, I'm not going to spend ages on
this.. (besides which, thats obviously a non standard command "+MS" and you
don't say what your modem is - most modems are configured through the
setting of bit-mapped registers, and I've already covered why the things in
your string are of little consequence). The fact is, that there are other
factors having a much bigger influence on your connection and that was the
point I was making: that fiddling with the moduation/flow control/compresion
on your modem is not going to solve your problems if you have real
connection problems - yeah sure you may garner a few extra ms here and there
and improve it slightly, but you'll be pissing in the wind. There is a 5%
avg difference on spec for silicon based companents for example, so buy 2
identical modems and one may perform better than the next. The traffic on
the network between you and the server, and the load on the server will be
far more influential than any changes you make to your modem. The advent of
faster renderers for example, has resulted in faster frame rates and so more
data being requested from the server (as most people haven't capped their
frame rates). This makes a vast difference to performance. Add in a few
digitally connected players, and the load on the server increases further.
The dial-up servers your ISP uses also make a huge difference as long time
force9 Quake2 players will testify (they had basically 2 types of dial-up
box, and one was miles faster than the other - they have now put all the
3COM HiPer ARC ones on a different number so we don't have to dial in loads
of times to connect to one). They both gave the same bandwidth but the
latency on the old USR Quad racks was enormous - not a problem for
downloads/web as conversation is mostly one way, and not that interactive
except for the acknowledgement packets.
So, although, I agree that in theory, there are reasons for changing these
settings, in reality they make very little diffrence, but you may make small
improvemnts. What I was objecting to was the "'ere john stick this in yer
modem init string and it fixes all your conn problems forever, and almost
makes you an lpb" types. I guess I should have explained what I meant a bit
more in the original post.
Now there *is* soemthing you can do to improve your ping by about 20% if you
have a USR v90 modem - throw it away and use a rockwell based v90 modem! I
just replaced my USR Sportser Flash external with a generic rockwell based
external v90 modem, and the latency is much less. Thats about the only way
to make real difference where modems are concerned - try a different one.
(of course it would be possible to completely screw the settings to make it
much worse I, so in that respect, changing the settings back again , would
be a huge improvement - so I guess I should qualify all that I've said, by
adding that it assumes your settings are reasonable in the first place).
Scoot.
Comatosed
>Well bad line quality is still going to cause retrains, no matter what your
>max line speed is set to. Not that the line speed is *that* important for
>Q2 though - it's latency not bandwidth that it requires, being an
>interactive conversation. So limiting the speed it can train up at IS
>nonsense. Think about it: If your line is that bad, I suggest you get
>*that* fixed, not fiddle with your modem in an attempt to compensate.
My line is very good. The reason you don't want the modem to retrain in the
middle of a game is that it will cause you to PJOD. Nonsense indeed, DOH!
>Total load of arse is it? I agree, you would think the download would be
>greater, for the very reasons you assert, but that is simply not the case.
>Fire up Q2, and play for a bit, and then ask your OS how many packets have
>been a) transmitted and b) received. You can also just watch the lights on
>your modem - more stuff goes up than comes down, I don't know why, but
>presumably, the server needs extra data from you that us not passed to the
>other clients. After a session tonight, ifconfig reports 149991 RX, and
>871692 TX, for the ppp link.
Yes I still thinks its a total load of arse. I checked my in/out a couple of
times - transmit was half that of the receive.
Alan Third
_NOSPAM_bigfoot.com> writes
>Yes I still thinks its a total load of arse. I checked my in/out a couple of
>times - transmit was half that of the receive.
they're not gonna send very much data but they'll receive the same
amount as everyone else.
--
Alan Third [YD]Flxzr
fl...@iroc.freeserve.is.crap.co.uk remove the "is crap"
Stress: The confusion created when one's mind overrides the body's basic
desire to choke the living sh*t out of some prat who desperately
deserves it.
nickb...@gmail.com
[MN] Red Shift here. Found your post randomly but can't see an email for you in this page. Thought I'd reply in case it somehow pops through to you.
Would be fun to get some Q2 going sometime.
All the best, Nick