All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thilo Schulz <arny@ats.s.bawue.de>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Low latency on large uploads - almost done but not quite.
Date: Wed, 18 Jun 2003 12:32:31 +0000	[thread overview]
Message-ID: <marc-lartc-105593952930181@msgid-missing> (raw)
In-Reply-To: <marc-lartc-105560610320685@msgid-missing>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 17 June 2003 20:16, sufcrusher wrote:
> (one of) the reasons for the unstable ping is that a packet of ~ 1500 bytes
> on a 128kbit connection (like yours and mine) takes roughly a 10th of a
> second to send (100ms). So at the moment a large packet is being sent and a
> quake packet is next in the queue, it still has to wait 100ms (worst case).
> This latency of course adds to the normal latency you already have to the
> quake server.

Yes, I have thought so too and thought about playing around with the MTU .. 
but did not really want to change it yet.
Thank you anyways for these helpful hints, I am going to try it as soon as 
possible :)

> I'm assuming the burst and quantum settings can be optimized for smaller
> packet sizes to take full advantage of this. But to be honest I haven't
> really done that yet.

The lower the burst settings, the less delay I have in theory, so high-prio 
queues _definitely_ get their turn in time.

> I use a cable connection which has a more than 10 times faster download
> than upload, so for me shaping the download isn't very effective. If you
> want to limit the maximum packetsize for incoming packets as well (at least
> for TCP) you can simply do this:

The same applies to me, I have 768 kbyte/s downlink, I doubt that this is an 
issue when gaming.

> For 1000 bytes packets. You can also use --clamp-mss-to-mtu option, which
> probably makes sense. Note that the MSS thing only works for new
> connections.

I have to do this anyways, as my pppoe is limiting the MTU on the virtual ppp0 
device to 1492 because ethernet frames can only have a certain size and pppoe 
still encapsules ppp in the ethernet.

> Also make sure you patched the kernel to use the high resolution timer
> (info at www.docum.org somewhere). That helped a lot in my case (you can
> put the ceilingrates closer to the actual 128kbit and therefore reduce
> latency as well). I'm not sure it's still necessary on 2.4.20 and/or
> 2.4.21.

I have a 133 Mhz AMD 486 - whether setting the resolution timer up would be 
very good for performance I don't know.

 - Thilo Schulz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+8FviZx4hBtWQhl4RAkyNAKC+3wE3bqMmQEr8qwkxdpPX6cuzdwCff03Z
6YTVuELLr1BNRPl/hym44Fw=4Qwt
-----END PGP SIGNATURE-----

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

  parent reply	other threads:[~2003-06-18 12:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-14 15:54 [LARTC] Low latency on large uploads - almost done but not quite Thilo Schulz
2003-06-15  9:09 ` Stef Coene
2003-06-15 11:44 ` Thilo Schulz
2003-06-15 12:00 ` Stef Coene
2003-06-16  7:54 ` [LARTC] Low latency on large uploads - almost done but not Corey Rogers
2003-06-17 18:16 ` [LARTC] Low latency on large uploads - almost done but not quite sufcrusher
2003-06-18 12:32 ` Thilo Schulz [this message]
2003-06-18 19:10 ` sufcrusher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-lartc-105593952930181@msgid-missing \
    --to=arny@ats.s.bawue.de \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.