Difference between pages "Broken Traffic Control" and "News:New OpenGL management in Funtoo"

From Funtoo
(Difference between pages)
Jump to navigation Jump to search
 
(explanation of the new system)
 
Line 1: Line 1:
The following traffic control examples '''should''' work, but are broken in older implementations of Linux traffic control, as tested by Daniel Robbins.
{{News
|Summary=Funtoo is switching to an improved system for managing multiple OpenGL providers (Mesa/Xorg, AMD and nVidia). The update may involve blockers and file collisions.
|News Format=Extended
|News Category=Packages
|Author=Mgorny
|Publication Status=Draft
|Publication Date=2015/02/28
}}
== New OpenGL management ==
=== System principles ===
The new OpenGL management design assumes that the reference OpenGL implementation (mesa/Xorg) is to be used to build packages. After switching to the new system, all packages will use the mesa/Xorg headers and link to the mesa/Xorg libraries. This improves portability of software built on Funtoo and solves some of the build failures when non-standard OpenGL provider was enabled.


{{fancyimportant|Many enterprise kernels do not have updated traffic control code. RHEL5 kernels are particularly bad in this area.}}
The third-party OpenGL libraries and modules provided by proprietary driver vendors can be enabled for run-time program use. They will not affect how the program is built. However, they will be loaded by the dynamic loader when starting executables. The Xorg server will also load the modules provided by blob driver vendor if appropriate.


=== Broken in RHEL5: Prioritizing Outgoing UDP packets ===
=== Implementation ===
The reference implementation (mesa/Xorg) packages install headers and libraries into standard system locations (/usr/include, /usr/lib*). The compiler and linker finds them using the usual rules and uses them.


These rules should be able to give outgoing UDP traffic a higher priority than other outgoing traffic, which could reduce the latency of outgoing UDP packets if your system (or ideally, your Linux router, which is the ideal point to use these shaping rules) is sending a lot of data all at once to a remote host.  
The third-party OpenGL vendors install libraries and server extension modules into vendor-named subdirectories of /usr/lib*/opengl. Those files are not used directly.


However, currently, these rules do not work.
{{Package|app-admin/eselect-opengl}} is used to select OpenGL implementation used at run-time. The choice of implementation is controlled via dynamic linker configuration (ld.so.conf) and Xorg server configuration. If the reference implementation is selected, the eselect module outputs null configuration that causes the linker and server to use the standard paths. If an another implementation is selected, the configuration prepends /usr/lib*/opengl paths to linker and server configuration, causing them to prefer the third-party libraries over reference.
 
{{NewsFooter}}
<source lang="bash">
wanif=eth0
tc qdisc add dev $wanif root handle 1: prio bands 3
tc qdisc add dev $wanif parent 1:1 handle 10: sfq perturb 10
tc qdisc add dev $wanif parent 1:2 handle 20: sfq perturb 10
tc qdisc add dev $wanif parent 1:3 handle 30: sfq perturb 10
 
tc filter add dev $wanif protocol ip parent 1: prio 1 u32 match ip protocol 0x11 0xff flowid 1:1
tc filter add dev $wanif protocol ip parent 1: prio 1 u32 match ip dst 0.0.0.0/0 flowid 1:2
</source>
 
This code above causes much data to be lost, since the code is not properly classifying all unmatched traffic using the lowest priority (leaf) class (1:3).
 
If the following line is added, which is intended to match all other IP traffic and ensure it gets to 1:3, then behavior improves, but  all ARP packets are still discarded by the <tt>prio</tt> qdisc and the <tt>discarded</tt> counter of the qdisc is incremented accordingly:
 
<source lang="bash">
tc filter add dev $wanif protocol ip parent 1: prio 1 u32 match ip src 0.0.0.0/0 flowid 1:3
</source>
 
I have also experienced issues where the <tt>priomap</tt> does not work properly, and the majority of traffic flows into the wrong child class. It also appears that the first <tt>tc filter</tt> command, which is supposed to prioritize UDP traffic, has the effect of placing all traffic into class <tt>1:2</tt>.
 
This code was tested on a physical interface that was part of a Linux bridge, as well as on the Linux bridge device ('brwan') itself. In both cases, <tt>prio</tt> exhibited strange and unusual behavior that deviated significantly from documented behavior. The kernel being used for this testing is a stable Red Hat Enterprise Linux 5.x kernel with OpenVZ patches (2.6.18-028stab079.2).
 
Based on this testing, <tt>prio</tt> appears to not work correctly at all, at least when used in this configuration, and should be avoided by Linux traffic control users.
 
More documentation on this bug:
 
* http://lists.debian.org/debian-kernel/2007/08/msg00487.html
* Fix for this bug: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=dbaaa07a60edf71670b484a65e14400ab40c84f7
 
[[Category:Networking]]

Revision as of 18:53, February 28, 2015

New OpenGL management in Funtoo

Funtoo is switching to an improved system for managing multiple OpenGL providers (Mesa/Xorg, AMD and nVidia). The update may involve blockers and file collisions.

By Mgorny / February 28, 2015

New OpenGL management

System principles

The new OpenGL management design assumes that the reference OpenGL implementation (mesa/Xorg) is to be used to build packages. After switching to the new system, all packages will use the mesa/Xorg headers and link to the mesa/Xorg libraries. This improves portability of software built on Funtoo and solves some of the build failures when non-standard OpenGL provider was enabled.

The third-party OpenGL libraries and modules provided by proprietary driver vendors can be enabled for run-time program use. They will not affect how the program is built. However, they will be loaded by the dynamic loader when starting executables. The Xorg server will also load the modules provided by blob driver vendor if appropriate.

Implementation

The reference implementation (mesa/Xorg) packages install headers and libraries into standard system locations (/usr/include, /usr/lib*). The compiler and linker finds them using the usual rules and uses them.

The third-party OpenGL vendors install libraries and server extension modules into vendor-named subdirectories of /usr/lib*/opengl. Those files are not used directly.

app-admin/eselect-opengl is used to select OpenGL implementation used at run-time. The choice of implementation is controlled via dynamic linker configuration (ld.so.conf) and Xorg server configuration. If the reference implementation is selected, the eselect module outputs null configuration that causes the linker and server to use the standard paths. If an another implementation is selected, the configuration prepends /usr/lib*/opengl paths to linker and server configuration, causing them to prefer the third-party libraries over reference.