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