1

Goal: when running a FPS game in Linux, automate the setup of higher priority for its network traffic

I know such tasks are usually accomplished with a combination of iptables (to mark IP packets meeting certain criteria) and tc (to prioritize those IP packets).

Problems:

  • earlier version of iptables had an --pid-owner option with a warning in the manpage that this is broken on SMP kernels. My recent version of iptables (1.4.7) doesn't mention this option in the manpage at all
  • probably I can't use a single destination port to match traffic, because game servers run on different ports

I aim for a wrapper shell script which will:

  • run the game executable
  • find its name/pid
  • based on this will increase the priority of network traffic for this process
  • when I exit the game, will restore everything to defaults

Is this possible? I'm willing to go as far as dealing with custom netfilter modules, if there are any which could help.

2 Answers 2

0

I don't think you want to mess with QoS on the client; on your router maybe, but on the client machine, you're just introducing extra packet processing which is actually going to slow things down. On the router you're prioritizing those packets above other packets (like other http connections or other traffic also going through the router), so it's a win, but on the client you're doing extra filtering instead of just handing the packets straight through to the process.

You might want to use nice to adjust your client process priority though, so it will get faster access to the CPU than background things running on the same machine.

You might want to tune up your network receive/send buffer size to help minimize retransmits.

If you're trying to control actual bandwidth being generated by your computer, then you'll need more data on what exactly the FPS traffic is and how close it is to the 'other' traffic that you want to de-prioritize. You may be able to get away with something as simple as 'prioritize UDP over TCP' if your FPS uses UDP and your other traffic is all TCP. Or it may be more complex. Once you know how to characterize each set of traffic though, then you'll want to look at other answers for details.

2
  • CPU is not an issue. Generally I get ~100ms pings on ADSL, but I have a hourly cronjob that uploads backups to a remote server and as soon as it starts, the game begins to lag. This is upload (outgoing) so I'm supposed to be able to control the order it leaves my host. My biggest issue is I have no idea how to match IP packets by PID with iptables so I could process them differently (send to different queues)
    – halp
    Sep 3, 2010 at 2:23
  • Indeed, prioritizing UDP over TCP is a clever idea, since the data transfer that hogs my upload is over TCP. Yes, FPS games usually send data over UDP so this is certainly a valid approach.
    – halp
    Sep 3, 2010 at 4:07
0

With iptables alone it is not possible but with TC you can, the default iptables is FIFO "first in first out" but using TC you can prioritize ports,protocol,ips.

Example of a full nat solution with QoS

With iptables netfilter you can still use the ipt_owner module:

-m owner –uid-owner replace_with_user

  owner
       This  module  attempts  to  match various characteristics of the packet
       creator, for locally generated packets. This match is only valid in the
       OUTPUT and POSTROUTING chains. Forwarded packets do not have any socket
       associated with them. Packets from kernel threads do have a socket, but
       usually no owner.

       [!] --uid-owner username

       [!] --uid-owner userid[-userid]
              Matches if the packet socket's file structure (if it has one) is
              owned by the given user. You may also specify a  numerical  UID,
              or an UID range.

       [!] --gid-owner groupname

       [!] --gid-owner groupid[-groupid]
              Matches  if  the  packet socket's file structure is owned by the
              given group.  You may also specify a numerical  GID,  or  a  GID
              range.

       [!] --socket-exists
              Matches if the packet is associated with a socket.

       [!] -m or --match / -p or --protocol
              iptables can use extended packet matching modules. These are loaded
              in two ways: implicitly, when -p or --protocol is specified, or with
              the -m or --match options, followed by the matching module name;
              after these, various extra command line options become available,
              depending on the specific module. 

While it will not work if the packets are coming from any computer within your network, it will work if the application is running within the firewall server, otherwise you would be better of matching the MAC.

4
  • My input data is only the PID of the game process.
    – halp
    Sep 3, 2010 at 1:03
  • updated with more info.
    – Prix
    Sep 3, 2010 at 2:06
  • My question states why I can't match by owner - because matching by PID seems to be deprecated and that's exactly what I need.
    – halp
    Sep 3, 2010 at 2:24
  • @halp uid-owner wasn't the broken one; that was pid-owner, cmd-owner. I am not sure but i belive pid and cmd were removed completly now. Also you have --socket-exists aswell. Oh and yes they do work for SMP kernel
    – Prix
    Sep 3, 2010 at 2:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .