Re: FreeBSD-11.0-CURRENT on ARM: performance and load average

2014-09-20 Thread Ian Lepore
On Sat, 2014-09-20 at 22:44 +0400, Maxim V FIlimonov wrote:
 Hello everyone,
 
 Recently, I encountered a problem with -CURRENT on an ARM board (cubieboard2 
 to be precise). The problem was that the load average was above 2. Including 
 the fact that the board has 2 CPU cores, that's strange. Also, the network 
 throughput was way too slow: from 3 kilobytes per second earlier to 20..50 
 about now. 
 
 Here's a workaround for that:
  sysctl kern.eventtimer.periodic=1
 With that, the network performance increased while LA decreased to a decent 
 0.3..0.5.

Since it's happening only on that hardware, there's a good chance the
problem is in the allwinner a10/a20 clock driver, not in the general
eventtimer code.  In fact, looking at the code it appears that a
divide-by-16 is being set in the hardware, but not accounted for when
setting the frequency of the eventtimer.

Hmm, it should affect the timecounter too, in which case you'd see
time-of-day advancing 16x too fast.  If ntpd is running it would need to
step the clock pretty frequently, which would show up in syslog.

I don't have hardware to test on, please see if the attached patch makes
a difference.

-- Ian

Index: sys/arm/allwinner/timer.c
===
--- sys/arm/allwinner/timer.c	(revision 271909)
+++ sys/arm/allwinner/timer.c	(working copy)
@@ -199,7 +199,7 @@ a10_timer_attach(device_t dev)
 	val |= TIMER_ENABLE;
 	timer_write_4(sc, SW_TIMER_IRQ_EN_REG, val);
 
-	sc-timer0_freq = SYS_TIMER_CLKSRC;
+	sc-timer0_freq = SYS_TIMER_CLKSRC / 16;
 
 	/* Set desired frequency in event timer and timecounter */
 	sc-et.et_frequency = sc-timer0_freq;
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: FreeBSD-11.0-CURRENT on ARM: performance and load average

2014-09-20 Thread Maxim V FIlimonov
On Saturday 20 September 2014 13:24:08 Ian Lepore wrote:
 Since it's happening only on that hardware, there's a good chance the
 problem is in the allwinner a10/a20 clock driver, not in the general
 eventtimer code.  In fact, looking at the code it appears that a
 divide-by-16 is being set in the hardware, but not accounted for when
 setting the frequency of the eventtimer.
 
 Hmm, it should affect the timecounter too, in which case you'd see
 time-of-day advancing 16x too fast.  If ntpd is running it would need to
 step the clock pretty frequently, which would show up in syslog.
 

I'm running FreeBSD-current on the board right now, the time is just fine.

 I don't have hardware to test on, please see if the attached patch makes
 a difference.
 
 
Well, it did: with the patch applied, the time ran about 60 times as fast as 
it should have. I didn't notice any changes with load average, though: maybe 
it's because I forgot to turn that sysctl setting I set before back to 0.

wbr, Maxim Filimonov
c...@bein.link
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: FreeBSD-11.0-CURRENT on ARM: performance and load average

2014-09-20 Thread Dmitry Marakasov
* Maxim V FIlimonov (c...@bein.link) wrote:

 Recently, I encountered a problem with -CURRENT on an ARM board (cubieboard2 
 to be precise). The problem was that the load average was above 2. Including 
 the fact that the board has 2 CPU cores, that's strange. Also, the network 
 throughput was way too slow: from 3 kilobytes per second earlier to 20..50 
 about now. 
 
 Here's a workaround for that:
  sysctl kern.eventtimer.periodic=1
 With that, the network performance increased while LA decreased to a decent 
 0.3..0.5.

I'm just started to experiment with cubieboard (1) as well.

I've also noticed poor network performance at first, however later
(without any tuning) it gave out 111 kBps. kern.eventtimer.periodic
doesn't seem to affect it.

I've also played with clocks a bit, and was able to increase CPU
rate 3x by configuring PLL1. I've experienced some instability later
(board doesn't always boot from USB, perl build fails), and now I'm
checking if reclocking was the cause.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru  ..:  jabber: amd...@jabber.ruhttp://www.amdmi3.ru
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org