[gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

I am back from my visit at a customer where I installed a new and shiny
gentoo server for running VMs (KVM).

Currently I don't have access as my VPN only works from my static IP at
home (my router seems to be offline right now ... and I am still away
from office for the weekend) so I can't check details now ...

basically:

I tried to copy/rsync some file with ~8GB over a gigabit connection ...
from old to new server. Checked ethtool for gigabit, looked ok. I always
saw the behavior that the transfer started rather fast and slowed down
within minutes. Let's say ~50 MB/s in the start and then down to maybe 2
or so. That is way from the expected throughput with such new hardware.

The NICs in the new server are BCM-something, Broadcom, using the tg3
Tigon module (exact model not available right now as mentioned above).

In "dmesg" I see lines like

hpet1: lost 1 rtc interrupts

which makes me wonder if that leads to the lousy performance (btw, I
fear slow virtualization performance as well).

Dealing with HPET I checked for kernel support and also added kernel
options to GRUB:

hpet=force clocksource=hpet

which lead to

# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet

I am unsure if I should further investigate things around this HPET-issue?

My thinkpad here shows "tsc" as clocksource ... good/better ?

What direction to go? force or disable HPET?

-

btw I saw the same slowdown on 2 NICs: one connects the server to the
LAN via GB-switch, the other connects the 2 servers directly via
crossconnect-cable (dedicated for backups).

I tried rsync with various options, scp, and even some tar/netcat-combo ...

The system runs gentoo sources 3.10.7, amd64 ...

-

Thanks for any thoughts on this!

Stefan

[gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?

[Nicolas Sebrecht]

The 27/09/13, Stefan G. Weichinger wrote:
> 
> I am back from my visit at a customer where I installed a new and shiny
> gentoo server for running VMs (KVM).
> 
> Currently I don't have access as my VPN only works from my static IP at
> home (my router seems to be offline right now ... and I am still away
> from office for the weekend) so I can't check details now ...
> 
> basically:
> 
> I tried to copy/rsync some file with ~8GB over a gigabit connection ...
> from old to new server. Checked ethtool for gigabit, looked ok. I always
> saw the behavior that the transfer started rather fast and slowed down
> within minutes. Let's say ~50 MB/s in the start and then down to maybe 2
> or so. That is way from the expected throughput with such new hardware.

You should give details of the tests. It looks like a hard disk write
speed bottleneck.

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 27.09.2013 15:02, schrieb Nicolas Sebrecht:

> You should give details of the tests. It looks like a hard disk write
> speed bottleneck.

I will get access again on monday.

That's a hardware RAID-10 on 6 SAS disks ... that should be fast enough ...

[gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?

[Nicolas Sebrecht]

The 27/09/13, Stefan G. Weichinger wrote:
> Am 27.09.2013 15:02, schrieb Nicolas Sebrecht:
> 
> > You should give details of the tests. It looks like a hard disk write
> > speed bottleneck.
> 
> I will get access again on monday.
> 
> That's a hardware RAID-10 on 6 SAS disks ... that should be fast enough ...

Try avoiding to write on disks. Use devices /dev/null and /dev/zero with
both protocol and command lines not optimizing zeros for network tests.

You could also use dedicated network performance tools if you have
install rights.

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 27.09.2013 15:18, schrieb Nicolas Sebrecht:

> Try avoiding to write on disks. Use devices /dev/null and /dev/zero with
> both protocol and command lines not optimizing zeros for network tests.
> 
> You could also use dedicated network performance tools if you have
> install rights.

Will do next week to focus on the main issues ... did some bonnie-tests
yesterday, which were quite OK so I assume it's not the disk-performance.

AFAI googled rsync and ssh have their issues with big files ... but
tar/netcat wasn't really fast either.

Stefan

Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Volker Armin Hemmann]

Am 27.09.2013 12:33, schrieb Stefan G. Weichinger:
> I am back from my visit at a customer where I installed a new and shiny
> gentoo server for running VMs (KVM).
>
> Currently I don't have access as my VPN only works from my static IP at
> home (my router seems to be offline right now ... and I am still away
> from office for the weekend) so I can't check details now ...
>
> basically:
>
> I tried to copy/rsync some file with ~8GB over a gigabit connection ...
> from old to new server. Checked ethtool for gigabit, looked ok. I always
> saw the behavior that the transfer started rather fast and slowed down
> within minutes. Let's say ~50 MB/s in the start and then down to maybe 2
> or so. That is way from the expected throughput with such new hardware.
>
> The NICs in the new server are BCM-something, Broadcom, using the tg3
> Tigon module (exact model not available right now as mentioned above).
>
> In "dmesg" I see lines like
>
> hpet1: lost 1 rtc interrupts
>
> which makes me wonder if that leads to the lousy performance (btw, I
> fear slow virtualization performance as well).
>
> Dealing with HPET I checked for kernel support and also added kernel
> options to GRUB:
>
> hpet=force clocksource=hpet
>
> which lead to
>
> # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> hpet
>
> I am unsure if I should further investigate things around this HPET-issue?
>
> My thinkpad here shows "tsc" as clocksource ... good/better ?
faster, if it works. Completely broken, if it doesn't.

> What direction to go? force or disable HPET?
>
>
neither

Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 27.09.2013 17:55, schrieb Volker Armin Hemmann:

>> What direction to go? force or disable HPET?
>>
>>
> neither

And what to do to avoid those lost interrupts?

Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 29.09.2013 16:37, schrieb Stefan G. Weichinger:
> Am 27.09.2013 17:55, schrieb Volker Armin Hemmann:
> 
>>> What direction to go? force or disable HPET?
>>>
>>>
>> neither
> 
> And what to do to avoid those lost interrupts?

Is there no good suggestion for this?

Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Volker Armin Hemmann]

Am 30.09.2013 11:54, schrieb Stefan G. Weichinger:
> Am 29.09.2013 16:37, schrieb Stefan G. Weichinger:
>> Am 27.09.2013 17:55, schrieb Volker Armin Hemmann:
>>
>>>> What direction to go? force or disable HPET?
>>>>
>>>>
>>> neither
>> And what to do to avoid those lost interrupts?
> Is there no good suggestion for this?
>
>
>
>
>
let the kernel figure out the best clocksource for you?

if you have a real problem with lost interrupts, go to lkml.

Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 30.09.2013 19:07, schrieb Volker Armin Hemmann:
> Am 30.09.2013 11:54, schrieb Stefan G. Weichinger:
>> Am 29.09.2013 16:37, schrieb Stefan G. Weichinger:
>>> Am 27.09.2013 17:55, schrieb Volker Armin Hemmann:
>>>
>>>>> What direction to go? force or disable HPET?
>>>>>
>>>>>
>>>> neither
>>> And what to do to avoid those lost interrupts?
>> Is there no good suggestion for this?
>>
>>
>>
>>
>>
> let the kernel figure out the best clocksource for you?
> 
> if you have a real problem with lost interrupts, go to lkml.

I am gonna reboot the system without forcing any clocksource after my
current "emerge -e @system" (I did that to fit the transferred VM-image
to the given hardware/CPU). And I will maybe upgrade to 3.10.7-r1 as well.

What is the best way to transfer multi-GB-files in LAN? I don't really
need encryption here ...

thanks, Stefan

Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Bruce Hill]

On Mon, Sep 30, 2013 at 07:36:35PM +0200, Stefan G. Weichinger wrote:
> 
> What is the best way to transfer multi-GB-files in LAN? I don't really
> need encryption here ...

My choice is always "rsync -av /source/ user@IP:~/destination/" because it
won't copy a corrupt file. Make sure you understand the use of slash first.
And the -av is going to preserve timestamps and give you verbose output. If
you also want to see status of your copying add --progress.
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Bruce Hill]

On Mon, Sep 30, 2013 at 07:36:35PM +0200, Stefan G. Weichinger wrote:
> 
> What is the best way to transfer multi-GB-files in LAN? I don't really
> need encryption here ...

Did not mention rsync has:
-n, --dry-run               perform a trial run with no changes made

as well as many other options..."man rsync".
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 30.09.2013 19:46, schrieb Bruce Hill:
> On Mon, Sep 30, 2013 at 07:36:35PM +0200, Stefan G. Weichinger wrote:
>>
>> What is the best way to transfer multi-GB-files in LAN? I don't really
>> need encryption here ...
> 
> Did not mention rsync has:
> -n, --dry-run               perform a trial run with no changes made
> 
> as well as many other options..."man rsync".

Thanks for both replies ... I know all these options already and use
them regularly ...   exactly these commands stall after a while and get
really slow throughput.

I am currently rebooting the upgraded machine ...

Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 30.09.2013 19:07, schrieb Volker Armin Hemmann:
> Am 30.09.2013 11:54, schrieb Stefan G. Weichinger:
>> Am 29.09.2013 16:37, schrieb Stefan G. Weichinger:
>>> Am 27.09.2013 17:55, schrieb Volker Armin Hemmann:
>>>
>>>>> What direction to go? force or disable HPET?
>>>>>
>>>>>
>>>> neither
>>> And what to do to avoid those lost interrupts?
>> Is there no good suggestion for this?
>>
>>
>>
>>
>>
> let the kernel figure out the best clocksource for you?
> 
> if you have a real problem with lost interrupts, go to lkml.

After reboot without any clocksource options it still choses hpet and it
still shows:

[ 1747.393960] hpet1: lost 2 rtc interrupts
[ 1747.452994] hpet1: lost 1 rtc interrupts
[ 1747.481786] hpet1: lost 1 rtc interrupts
[ 1747.527556] hpet1: lost 1 rtc interrupts
[ 1747.660527] hpet1: lost 1 rtc interrupts
[ 1747.726264] hpet1: lost 1 rtc interrupts


:-(

I would be very happy to get some hints how to debug this ...

Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 30.09.2013 20:23, schrieb Stefan G. Weichinger:

> [ 1747.393960] hpet1: lost 2 rtc interrupts
> [ 1747.452994] hpet1: lost 1 rtc interrupts
> [ 1747.481786] hpet1: lost 1 rtc interrupts
> [ 1747.527556] hpet1: lost 1 rtc interrupts
> [ 1747.660527] hpet1: lost 1 rtc interrupts
> [ 1747.726264] hpet1: lost 1 rtc interrupts
> 
> 
> :-(
> 
> I would be very happy to get some hints how to debug this ...

booted with "hpet=disable" ... so far no more lost interrupts in dmesg.

I will simply let the scp take its time over night ... and I hope the
KVM-performance will be OK when I start the converted VM.

S

Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 30.09.2013 22:03, schrieb Stefan G. Weichinger:

> I will simply let the scp take its time over night ... and I hope the
> KVM-performance will be OK when I start the converted VM.

I used split and tar to split the image-file into 100 MB parts and rsync
them over right now.

Maybe I have something wrong in my kernel ... the server shows a load of
around 3 ... while only the rsync is running and my mosh-session ...

This is a 24-core-system ... it shouldn't even blink ...

2 CPUs: AMD Opteron(tm) Processor 6344

I have:

CFLAGS="-O2 -march=native -pipe"
CXXFLAGS="-O2 -march=native -pipe"
CHOST="x86_64-pc-linux-gnu"

maybe one of you would be so kind and helpful and check my kernel-config
for obvious stupidity:

https://dl.dropboxusercontent.com/u/24516209/config

Thanks in advance, Stefan

[gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?

[Nicolas Sebrecht]

The 01/10/13, Stefan G. Weichinger wrote:

> I used split and tar to split the image-file into 100 MB parts and rsync
> them over right now.
> 
> Maybe I have something wrong in my kernel ... the server shows a load of
> around 3 ... while only the rsync is running and my mosh-session ...
> 
> This is a 24-core-system ... it shouldn't even blink ...

If you are sure the load don't come from userland (htop?), I would
think about reporting a kernel bug. This might be an issue with the NIC
driver.

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 01.10.2013 14:32, schrieb Nicolas Sebrecht:
> The 01/10/13, Stefan G. Weichinger wrote:
> 
>> I used split and tar to split the image-file into 100 MB parts and rsync
>> them over right now.
>>
>> Maybe I have something wrong in my kernel ... the server shows a load of
>> around 3 ... while only the rsync is running and my mosh-session ...
>>
>> This is a 24-core-system ... it shouldn't even blink ...
> 
> If you are sure the load don't come from userland (htop?), I would
> think about reporting a kernel bug. This might be an issue with the NIC
> driver.

lspci shows:

Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)

This is a 4-port NIC ... maybe I need some specific drivers and not only
the tg3-kernel-module?

Stefan

Re: [gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 01.10.2013 16:00, schrieb Stefan G. Weichinger:

> Broadcom Corporation NetXtreme BCM5719 Gigabit Ethernet PCIe (rev 01)
> 
> This is a 4-port NIC ... maybe I need some specific drivers and not only
> the tg3-kernel-module?

for the records and if someone wants to join in:

recompiled the kernel, put in some ACPI-stuff and chose "generic X86_64"
for the processor type. This somehow helped ... the load is lower now
and the system is more responsive.

I am considering to change the (auto-generated? by systemd) mount
options for the ext4-fs: data=ordered ...

-

Right now I am re-cat-ing my splitted image file ... we'll see.

Stefan

Re: [gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Would someone please take a look at this dmesg:

https://dl.dropboxusercontent.com/u/24516209/dmesg.txt

and tell me what those ugly messages around the CPUs could mean?

I still see suboptimal performance on this hardware ...

Thanks!

[gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?

[Nicolas Sebrecht]

On Wed, Oct 09, 2013 at 04:53:56PM +0200, Stefan G. Weichinger wrote:
> 
> Would someone please take a look at this dmesg:
> 
> https://dl.dropboxusercontent.com/u/24516209/dmesg.txt
> 
> and tell me what those ugly messages around the CPUs could mean?
> 
> I still see suboptimal performance on this hardware ...

I would think about a kernel bug first and try with a much lower
version.

-- 
Nicolas Sebrecht

Re: [gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 09.10.2013 20:20, schrieb Nicolas Sebrecht:

> I would think about a kernel bug first and try with a much lower
> version.

Yep. A bit scary with a server which is hundreds of kilometers away.

Got to get that HP IlO-thingy going in my browser(s) ...

S

Re: [gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?

[Volker Armin Hemmann]

Am 09.10.2013 21:17, schrieb Stefan G. Weichinger:
> Am 09.10.2013 20:20, schrieb Nicolas Sebrecht:
>
>> I would think about a kernel bug first and try with a much lower
>> version.
> Yep. A bit scary with a server which is hundreds of kilometers away.
>
> Got to get that HP IlO-thingy going in my browser(s) ...
>
> S
>
>
>
go with that dmesg, lspci, kernel config etc pp to lkml. Seriously.

Re: [gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 09.10.2013 21:57, schrieb Volker Armin Hemmann:

> go with that dmesg, lspci, kernel config etc pp to lkml. Seriously.

phew ... that sounds like making a fool of myself ... ;-)
But maybe you are right, thanks.

Considering to test 3.8.13 ... got the IlO to display the console in a
browser ... and will test choosing a kernel in the GRUB-menu before I
really switch over.

S

Re: [gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 09.10.2013 22:05, schrieb Stefan G. Weichinger:
> Am 09.10.2013 21:57, schrieb Volker Armin Hemmann:
> 
>> go with that dmesg, lspci, kernel config etc pp to lkml. Seriously.
> 
> phew ... that sounds like making a fool of myself ... ;-)
> But maybe you are right, thanks.
> 
> Considering to test 3.8.13 ... got the IlO to display the console in a
> browser ... and will test choosing a kernel in the GRUB-menu before I
> really switch over.

Compiled 3.8.13 and rebooted successfully ...

still laggy ... still these lines in dmesg:


[  477.896055] hpet1: lost 1 rtc interrupts
[  477.933359] hpet1: lost 1 rtc interrupts
[  478.050117] hpet1: lost 1 rtc interrupts
[  478.315080] hpet1: lost 1 rtc interrupts
[  478.409115] hpet1: lost 1 rtc interrupts
[  478.444083] hpet1: lost 1 rtc interrupts
[  478.638091] hpet1: lost 1 rtc interrupts
[  478.780332] hpet1: lost 1 rtc interrupts
[  478.862724] hpet1: lost 1 rtc interrupts
[  478.950488] hpet1: lost 1 rtc interrupts


While I disabled most of that HPET-stuff (took from my own server here):

# zgrep -i hpet /proc/config.gz
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_HPET is not set


This is quite frustrating already ... but I repeat myself, sorry.

Re: [gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 09.10.2013 22:40, schrieb Stefan G. Weichinger:

> While I disabled most of that HPET-stuff (took from my own server here):
> 
> # zgrep -i hpet /proc/config.gz
> CONFIG_HPET_TIMER=y
> CONFIG_HPET_EMULATE_RTC=y
> # CONFIG_HPET is not set
> 
> 
> This is quite frustrating already ... but I repeat myself, sorry.

I achieved *something* ... I still have to diff kernel-configs but right
now I am happily rsyncing that vmdk-image with around 40 MB/s  ....

That virt-manager-issue is still there but at least the basic
performance seems way better now.

I could transfer the KVM-raw-image to an LVM-LV within a few minutes ...
the same dd-command took hours before and never succeeded.

Some more tests now.

S

Re: [gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 10.10.2013 00:11, schrieb Stefan G. Weichinger:
> Am 09.10.2013 22:40, schrieb Stefan G. Weichinger:
> 
>> While I disabled most of that HPET-stuff (took from my own server here):
>>
>> # zgrep -i hpet /proc/config.gz
>> CONFIG_HPET_TIMER=y
>> CONFIG_HPET_EMULATE_RTC=y
>> # CONFIG_HPET is not set
>>
>>
>> This is quite frustrating already ... but I repeat myself, sorry.
> 
> I achieved *something* ... I still have to diff kernel-configs but right
> now I am happily rsyncing that vmdk-image with around 40 MB/s  ....

quite happy after dozens of hours spent on this:


# time rsync -av 192.168.1.200:/mnt/vm_apps/xy.vmdk . --progress

[...]

  8058765312 100%   53.58MB/s    0:02:23 (xfer#1, to-check=0/1)

sent 42 bytes  received 8059749181 bytes  55776811.23 bytes/sec
total size is 8058765312  speedup is 1.00

real    2m23.856s
user    2m28.640s
sys     0m26.820s

nice!

;-)

This is 3.8.13 now ... with some changed options, sure.

For now I am happy ... can't believe it yet ;-)

Re: [gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?

[Bruce Hill]

On Thu, Oct 10, 2013 at 12:18:06AM +0200, Stefan G. Weichinger wrote:
> 
> This is 3.8.13 now ... with some changed options, sure.
> 
> For now I am happy ... can't believe it yet ;-)

Why do you use a kernel that has been abandoned?

https://www.kernel.org/

You should use a longterm kernel, preferably 3.10 series at this point.

Why not use 3.8 series, or one marked EOL? Because no more patches will be
applied against them, so no more bug/security fixes.
-- 
Happy Penguin Computers               >')
126 Fenco Drive                       ( \
Tupelo, MS 38801                       ^^
support@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

Re: [gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 10.10.2013 14:20, schrieb Bruce Hill:
> On Thu, Oct 10, 2013 at 12:18:06AM +0200, Stefan G. Weichinger wrote:
>>
>> This is 3.8.13 now ... with some changed options, sure.
>>
>> For now I am happy ... can't believe it yet ;-)
> 
> Why do you use a kernel that has been abandoned?
> 
> https://www.kernel.org/
> 
> You should use a longterm kernel, preferably 3.10 series at this point.
> 
> Why not use 3.8 series, or one marked EOL? Because no more patches will be
> applied against them, so no more bug/security fixes.

3.8.13 is 3.8 series, or ... ?

I don't plan to stay with 3.8.13, this is just an intermediate step to
get a working config. For now I don't have any more lost hpet interrupts
etc and the LAN speed is fine. Emerging packages as well ...

From this config I will then try 3.10.7-r1 again.

Re: [gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?

[Stefan G. Weichinger]

Am 10.10.2013 16:38, schrieb Stefan G. Weichinger:
> I don't plan to stay with 3.8.13, this is just an intermediate step to
> get a working config. For now I don't have any more lost hpet interrupts
> etc and the LAN speed is fine. Emerging packages as well ...
> 
> From this config I will then try 3.10.7-r1 again.

Went back to 3.10.7-r1 yesterday ... performance fine so far.

Today I checked back and found the following in dmesg.
Should I disable some option?

Thanks for any feedback, Stefan



> [20788.258330] NMI backtrace for cpu 16
[20788.258334] CPU: 16 PID: 0 Comm: swapper/16 Not tainted
3.10.7-gentoo-r1 #1
[20788.258336] Hardware name: HP ProLiant DL385p Gen8, BIOS A28 12/10/2012
[20788.258338] task: ffff88042dcc9fe0 ti: ffff88042dcd6000 task.ti:
ffff88042dcd6000
[20788.258340] RIP: 0010:[<ffffffffa0006e31>]  [<ffffffffa0006e31>]
acpi_idle_enter_simple+0x9e/0xde [processor]
[20788.258346] RSP: 0018:ffff88042dcd7e78  EFLAGS: 00000093
[20788.258348] RAX: 000012e824917a00 RBX: ffff880c2d1c78a0 RCX:
000000000000b6e8
[20788.258350] RDX: 0000000000000ff9 RSI: ffff88082fc80000 RDI:
000000000000b6e0
[20788.258352] RBP: 0000000000000002 R08: 0000000000000000 R09:
0000000000000192
[20788.258354] R10: 0000000000000001 R11: 0000000000000000 R12:
ffff880c2d1c7800
[20788.258356] R13: 000012e605db654b R14: ffffffffa00087d8 R15:
0000000000000000
[20788.258358] FS:  00007fcbeb7de700(0000) GS:ffff88082fc80000(0000)
knlGS:00000000f77556c0
[20788.258360] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[20788.258362] CR2: 00007fd4098d2000 CR3: 000000042d3a4000 CR4:
00000000000407a0
[20788.258364] DR0: 00000000000000a0 DR1: 0000000000000000 DR2:
0000000000000003
[20788.258365] DR3: 00000000000000b0 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[20788.258367] Stack:
[20788.258368]  ffff88102ccd4c00 ffffffffa0008710 0000000000000002
ffffffff8140284b
[20788.258371]  0000000000000000 00000000000001f6 0000000000000000
ffffffff81403b11
[20788.258374]  ffff88102ccd4c00 0000000000000002 ffffffffa0008710
ffff88042dcd7fd8
[20788.258378] Call Trace:
[20788.258382]  [<ffffffff8140284b>] ? cpuidle_enter_state+0x4b/0xe0
[20788.258386]  [<ffffffff81403b11>] ? ladder_select_state+0x31/0x1e0
[20788.258390]  [<ffffffff8140297a>] ? cpuidle_idle_call+0x9a/0x140
[20788.258394]  [<ffffffff8103b919>] ? arch_cpu_idle+0x9/0x30
[20788.258398]  [<ffffffff81095439>] ? cpu_startup_entry+0x59/0x130
[20788.258399] Code: 01 03 75 02 0f 09 e8 1f 50 08 e1 8a 43 08 3c 01 75
0a 48 89 df e8 c0 78 04 e1 eb 17 3c 02 75 07 e8 0f f9 ff ff eb 0c 8b 53
04 ec <48> 8b 15 4c e0 81 e1 ed 31 ff e8 90 50 08 e1 80 7b 08 01 74 10
[20788.258440] NMI backtrace for cpu 20
[20788.258444] CPU: 20 PID: 0 Comm: swapper/20 Not tainted
3.10.7-gentoo-r1 #1
[20788.258445] Hardware name: HP ProLiant DL385p Gen8, BIOS A28 12/10/2012
[20788.258447] task: ffff88042dccb960 ti: ffff88042dcde000 task.ti:
ffff88042dcde000
[20788.258449] RIP: 0010:[<ffffffffa0006e31>]  [<ffffffffa0006e31>]
acpi_idle_enter_simple+0x9e/0xde [processor]
[20788.258456] RSP: 0018:ffff88042dcdfe78  EFLAGS: 00000093
[20788.258457] RAX: 000012e824919a00 RBX: ffff880c2d1c50a0 RCX:
000000000000b6e8
[20788.258459] RDX: 0000000000000ff9 RSI: ffff88082fd00000 RDI:
000000000000b6e0
[20788.258461] RBP: 0000000000000002 R08: 0000000000000000 R09:
0000000000000193
[20788.258463] R10: 0000000000000001 R11: 0000000000000000 R12:
ffff880c2d1c5000
[20788.258464] R13: 000012e605db857d R14: ffffffffa00087d8 R15:
0000000000000000
[20788.258467] FS:  00007fcbeb7de700(0000) GS:ffff88082fd00000(0000)
knlGS:00000000f778d700
[20788.258469] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[20788.258471] CR2: 00007fd4098d2000 CR3: 000000042d3a4000 CR4:
00000000000407a0
[20788.258473] DR0: 00000000000000a0 DR1: 0000000000000000 DR2:
0000000000000003
[20788.258474] DR3: 00000000000000b0 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[20788.258476] Stack:
[20788.258477]  ffff880c2d9e0400 ffffffffa0008710 0000000000000002
ffffffff8140284b
[20788.258480]  0000000000000000 00000000000001f7 0000000000000000
ffffffff81403b11
[20788.258484]  ffff880c2d9e0400 0000000000000002 ffffffffa0008710
ffff88042dcdffd8
[20788.258487] Call Trace:
[20788.258491]  [<ffffffff8140284b>] ? cpuidle_enter_state+0x4b/0xe0
[20788.258495]  [<ffffffff81403b11>] ? ladder_select_state+0x31/0x1e0
[20788.258498]  [<ffffffff8140297a>] ? cpuidle_idle_call+0x9a/0x140
[20788.258502]  [<ffffffff8103b919>] ? arch_cpu_idle+0x9/0x30
[20788.258506]  [<ffffffff81095439>] ? cpu_startup_entry+0x59/0x130
[20788.258508] Code: 01 03 75 02 0f 09 e8 1f 50 08 e1 8a 43 08 3c 01 75
0a 48 89 df e8 c0 78 04 e1 eb 17 3c 02 75 07 e8 0f f9 ff ff eb 0c 8b 53
04 ec <48> 8b 15 4c e0 81 e1 ed 31 ff e8 90 50 08 e1 80 7b 08 01 74 10

Re: [gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?

[Volker Armin Hemmann]

Am 14.10.2013 08:23, schrieb Stefan G. Weichinger:
> Am 10.10.2013 16:38, schrieb Stefan G. Weichinger:
>> I don't plan to stay with 3.8.13, this is just an intermediate step to
>> get a working config. For now I don't have any more lost hpet interrupts
>> etc and the LAN speed is fine. Emerging packages as well ...
>>
>> From this config I will then try 3.10.7-r1 again.
> Went back to 3.10.7-r1 yesterday ... performance fine so far.
>
> Today I checked back and found the following in dmesg.
> Should I disable some option?
>
> Thanks for any feedback, Stefan
>
>
>
>> [20788.258330] NMI backtrace for cpu 16
> [20788.258334] CPU: 16 PID: 0 Comm: swapper/16 Not tainted
> 3.10.7-gentoo-r1 #1
> [20788.258336] Hardware name: HP ProLiant DL385p Gen8, BIOS A28 12/10/2012
> [20788.258338] task: ffff88042dcc9fe0 ti: ffff88042dcd6000 task.ti:
> ffff88042dcd6000
> [20788.258340] RIP: 0010:[<ffffffffa0006e31>]  [<ffffffffa0006e31>]
> acpi_idle_enter_simple+0x9e/0xde [processor]
> [20788.258346] RSP: 0018:ffff88042dcd7e78  EFLAGS: 00000093
> [20788.258348] RAX: 000012e824917a00 RBX: ffff880c2d1c78a0 RCX:
> 000000000000b6e8
> [20788.258350] RDX: 0000000000000ff9 RSI: ffff88082fc80000 RDI:
> 000000000000b6e0
> [20788.258352] RBP: 0000000000000002 R08: 0000000000000000 R09:
> 0000000000000192
> [20788.258354] R10: 0000000000000001 R11: 0000000000000000 R12:
> ffff880c2d1c7800
> [20788.258356] R13: 000012e605db654b R14: ffffffffa00087d8 R15:
> 0000000000000000
> [20788.258358] FS:  00007fcbeb7de700(0000) GS:ffff88082fc80000(0000)
> knlGS:00000000f77556c0
> [20788.258360] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [20788.258362] CR2: 00007fd4098d2000 CR3: 000000042d3a4000 CR4:
> 00000000000407a0
> [20788.258364] DR0: 00000000000000a0 DR1: 0000000000000000 DR2:
> 0000000000000003
> [20788.258365] DR3: 00000000000000b0 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [20788.258367] Stack:
> [20788.258368]  ffff88102ccd4c00 ffffffffa0008710 0000000000000002
> ffffffff8140284b
> [20788.258371]  0000000000000000 00000000000001f6 0000000000000000
> ffffffff81403b11
> [20788.258374]  ffff88102ccd4c00 0000000000000002 ffffffffa0008710
> ffff88042dcd7fd8
> [20788.258378] Call Trace:
> [20788.258382]  [<ffffffff8140284b>] ? cpuidle_enter_state+0x4b/0xe0
> [20788.258386]  [<ffffffff81403b11>] ? ladder_select_state+0x31/0x1e0
> [20788.258390]  [<ffffffff8140297a>] ? cpuidle_idle_call+0x9a/0x140
> [20788.258394]  [<ffffffff8103b919>] ? arch_cpu_idle+0x9/0x30
> [20788.258398]  [<ffffffff81095439>] ? cpu_startup_entry+0x59/0x130
> [20788.258399] Code: 01 03 75 02 0f 09 e8 1f 50 08 e1 8a 43 08 3c 01 75
> 0a 48 89 df e8 c0 78 04 e1 eb 17 3c 02 75 07 e8 0f f9 ff ff eb 0c 8b 53
> 04 ec <48> 8b 15 4c e0 81 e1 ed 31 ff e8 90 50 08 e1 80 7b 08 01 74 10
> [20788.258440] NMI backtrace for cpu 20
> [20788.258444] CPU: 20 PID: 0 Comm: swapper/20 Not tainted
> 3.10.7-gentoo-r1 #1
> [20788.258445] Hardware name: HP ProLiant DL385p Gen8, BIOS A28 12/10/2012
> [20788.258447] task: ffff88042dccb960 ti: ffff88042dcde000 task.ti:
> ffff88042dcde000
> [20788.258449] RIP: 0010:[<ffffffffa0006e31>]  [<ffffffffa0006e31>]
> acpi_idle_enter_simple+0x9e/0xde [processor]
> [20788.258456] RSP: 0018:ffff88042dcdfe78  EFLAGS: 00000093
> [20788.258457] RAX: 000012e824919a00 RBX: ffff880c2d1c50a0 RCX:
> 000000000000b6e8
> [20788.258459] RDX: 0000000000000ff9 RSI: ffff88082fd00000 RDI:
> 000000000000b6e0
> [20788.258461] RBP: 0000000000000002 R08: 0000000000000000 R09:
> 0000000000000193
> [20788.258463] R10: 0000000000000001 R11: 0000000000000000 R12:
> ffff880c2d1c5000
> [20788.258464] R13: 000012e605db857d R14: ffffffffa00087d8 R15:
> 0000000000000000
> [20788.258467] FS:  00007fcbeb7de700(0000) GS:ffff88082fd00000(0000)
> knlGS:00000000f778d700
> [20788.258469] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [20788.258471] CR2: 00007fd4098d2000 CR3: 000000042d3a4000 CR4:
> 00000000000407a0
> [20788.258473] DR0: 00000000000000a0 DR1: 0000000000000000 DR2:
> 0000000000000003
> [20788.258474] DR3: 00000000000000b0 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [20788.258476] Stack:
> [20788.258477]  ffff880c2d9e0400 ffffffffa0008710 0000000000000002
> ffffffff8140284b
> [20788.258480]  0000000000000000 00000000000001f7 0000000000000000
> ffffffff81403b11
> [20788.258484]  ffff880c2d9e0400 0000000000000002 ffffffffa0008710
> ffff88042dcdffd8
> [20788.258487] Call Trace:
> [20788.258491]  [<ffffffff8140284b>] ? cpuidle_enter_state+0x4b/0xe0
> [20788.258495]  [<ffffffff81403b11>] ? ladder_select_state+0x31/0x1e0
> [20788.258498]  [<ffffffff8140297a>] ? cpuidle_idle_call+0x9a/0x140
> [20788.258502]  [<ffffffff8103b919>] ? arch_cpu_idle+0x9/0x30
> [20788.258506]  [<ffffffff81095439>] ? cpu_startup_entry+0x59/0x130
> [20788.258508] Code: 01 03 75 02 0f 09 e8 1f 50 08 e1 8a 43 08 3c 01 75
> 0a 48 89 df e8 c0 78 04 e1 eb 17 3c 02 75 07 e8 0f f9 ff ff eb 0c 8b 53
> 04 ec <48> 8b 15 4c e0 81 e1 ed 31 ff e8 90 50 08 e1 80 7b 08 01 74 10
>
>
>
>

nmo, you should finally go to lkml. Something is very wrong with your setup.