Difference between pages "Broken Traffic Control" and "Amd64-jaguar"

From Funtoo
(Difference between pages)
Jump to navigation Jump to search
 
 
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.
{{Subarch
|CPU Family=64-Bit AMD Processors
|subarch=amd64-jaguar
|CHOST=x86_64-pc-linux-gnu
|CFLAGS=-march=btver2 -O2 -pipe
|USE=mmx sse sse2 sse3 sse4 3dnow 3dnowext
|CPU Features=low-power
|Description=
}}
The '''amd64-jaguar''' (also called AMD Family 16h) subarch supports the  [[Wikipedia:Jaguar (microarchitecture)|AMD jaguar microarchitecture]], which is targeted at low-power devices, including notebooks, tablets and small form-factor desktops and servers. It is perhaps most well-known for being the microarchitecture used for the [[Wikipedia:Playstation 4|Playstation 4]] and [[Wikipedia:Xbox One|Xbox One]], which each use custom 8-core Jaguar APUs.
Socketed Jaguar APUs use the [[Wikipedia:AM1 Socket|AM1 socket]], and  [[Wikipedia:Socket_FT3|FT3 socket]] for mobile devices. G-series [[Wikipedia:System_on_a_chip|"system on a chip" (SoC)]] APUs are available for non-socketed devices such as tablets and embedded system boards.


{{fancyimportant|Many enterprise kernels do not have updated traffic control code. RHEL5 kernels are particularly bad in this area.}}
Desktop Jaguar APUs include the [[Wikipedia:List_of_AMD_accelerated_processing_unit_microprocessors#.22Kabini.22.2C_.22Temash.22_.282013.2C_28_nm.29|Kabini A-series APUs and Temash E-series APUs]], such as the Athlon 5150 and 5350 APUs, and Sempron 2650 and 3850.


=== Broken in RHEL5: Prioritizing Outgoing UDP packets ===
Amd64-jaguar subarches use the MOVBE instruction which is not available on amd64-bulldozer, amd64-piledriver or amd64-steamroller. They are thus not instruction-compatible with any of these subarches.
 
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.
 
However, currently, these rules do not work.
 
<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 07:03, December 20, 2014

This section lists the CPU-optimized Funtoo Linux builds currently available for download for amd64-jaguar.

No downloadable stage builds are currently available for this sub-architecture.

.

Architecture and Optimization

The following settings are applied to all stages for this subarch via Funtoo subarch profiles:

CHOSTx86_64-pc-linux-gnu
CFLAGS-march=btver2 -O2 -pipe


The amd64-jaguar (also called AMD Family 16h) subarch supports the AMD jaguar microarchitecture, which is targeted at low-power devices, including notebooks, tablets and small form-factor desktops and servers. It is perhaps most well-known for being the microarchitecture used for the Playstation 4 and Xbox One, which each use custom 8-core Jaguar APUs. Socketed Jaguar APUs use the AM1 socket, and FT3 socket for mobile devices. G-series "system on a chip" (SoC) APUs are available for non-socketed devices such as tablets and embedded system boards.

Desktop Jaguar APUs include the Kabini A-series APUs and Temash E-series APUs, such as the Athlon 5150 and 5350 APUs, and Sempron 2650 and 3850.

Amd64-jaguar subarches use the MOVBE instruction which is not available on amd64-bulldozer, amd64-piledriver or amd64-steamroller. They are thus not instruction-compatible with any of these subarches.

Retrieved from "https://www.funtoo.org/index.php?title=Broken_Traffic_Control&oldid=7592"