On 17.12.2014. 6:34, Philip Guenther wrote:
Uh, ACPI *requires* that C1 exist. The halt instruction is defined as
entering C1, so not having C1 would mean your CPU lacks a basic
manadatory ia32 instruction. Hopefully the BIOS docs explain that
you're just disabling "deep" C-states or something like that. If not,
yell at the company that made it.
With the exception of "C1E", I wouldn't tell a BIOS to disable
C-states unless it was causing the OS to have a problem or you're
actively trying to use the computer to heat your house. "C1E" is a
cross between C1 and C3; the issue is that bugs in multiple early
hardware implementations mean it'll behave poorly depending on exactly
how the OS handles it. This is something to test...and then test
again with each release you install...
Thank you, this is very informative.
I have disabled C states because I have seen ifq.drops and netlivelocks
when I run udp tcpbench over ix interface and C-states are enabled. This
is between two Dell R620. With Dell R630 I have bigger problems so i
can't test them right now.
tcpbench client sends around 350kpps for 20s
tcpbench server gets around 212kpps
tcpbench udp server drops:
Without C states and C1E:
net.inet.ip.ifq.maxlen=2048
net.inet.ip.ifq.drops=0
kern.netlivelocks=3
With C states and C1E (DAPC):
net.inet.ip.ifq.maxlen=2048
net.inet.ip.ifq.drops=19143
kern.netlivelocks=86
so I explained to myself that C states are bad for packet bursts and
these boxes will be uber high speed firewalls :)
and of course after reading you mail I only disable C1E and everything
is fine.
With C states and without C1E
net.inet.ip.ifq.maxlen=2048
net.inet.ip.ifq.drops=0
kern.netlivelocks=3
Monitor/Mwait - Disabled
I would suggest leaving that on. We ain't using it *right now*, but,
well, the source tree on my laptop is, and more than ever. :-)
mwait is enabled :)
