Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?
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
Re: [gentoo-user] Slow network transfers ... lost interrupts because of clocksource?
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?
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?
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?
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 ^^ supp...@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?
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 ^^ supp...@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?
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?
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?
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?
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?
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
