On Saturday, 7 November 2015 10:51 PM, Bruce Evans wrote:
> On Sat, 7 Nov 2015, Hans Petter Selasky wrote:
>
> > On 11/07/15 07:19, Bruce Evans wrote:
> >> I don't know if CTLFLAG_RWTUN with SYSCTL_PROC() actually works for
> >> all types, but it is used with CTLFLAG_STRING for kern.corefile.
> >
On Sat, 7 Nov 2015, Hans Petter Selasky wrote:
On 11/07/15 07:19, Bruce Evans wrote:
I don't know if CTLFLAG_RWTUN with SYSCTL_PROC() actually works for all
types, but it is used with CTLFLAG_STRING for kern.corefile. This is
another bogus undocumented tunable. It is better documented as a sy
On Sat, 7 Nov 2015, Ian Smith wrote:
...
I also notice that with HPET, the timer interrupts themselves, whether
as few as 60-70/s idle in one-shot mode or ~2000/s in periodic, appear
in systat -vm or vmstat -w10 'Int' column, whereas with LAPIC or (yes I
even tried) i8254, these timer interrupts
On 11/07/15 07:19, Bruce Evans wrote:
I don't know if CTLFLAG_RWTUN with SYSCTL_PROC() actually works for all
types, but it is used with CTLFLAG_STRING for kern.corefile. This is
another bogus undocumented tunable. It is better documented as a sysctl
than most since it is old so it is documente
On Sat, 7 Nov 2015 01:51:29 +, Rasool Al-Saadi wrote:
> On Saturday, 7 November 2015 2:05 AM, Hans Petter Selasky wrote:
> > On 11/06/15 11:08, Luigi Rizzo wrote:
> > > On Fri, Nov 6, 2015 at 10:52 AM, Hans Petter Selasky
> > wrote:
> > >> On 11/06/15 09:50, Luigi Rizzo wrote:
> > >>>
On Sat, 7 Nov 2015, Rasool Al-Saadi wrote:
On Saturday, 7 November 2015 2:05 AM, Hans Petter Selasky wrote:
...
It might be worth trying to set:
kern.eventtimer.periodic=1
In /boot/loader.conf . Can you test that too?
You need to reboot before the setting takes into effect.
You don't need
On Saturday, 7 November 2015 2:05 AM, Hans Petter Selasky wrote:
> On 11/06/15 11:08, Luigi Rizzo wrote:
> > On Fri, Nov 6, 2015 at 10:52 AM, Hans Petter Selasky
> wrote:
> >> On 11/06/15 09:50, Luigi Rizzo wrote:
> >>>
> >>> On Fri, Nov 6, 2015 at 9:44 AM, Hans Petter Selasky
> >>>
> >>> wrot
On 6 November 2015 at 12:58, Ian Lepore wrote:
> On Fri, 2015-11-06 at 11:15 -0800, Adrian Chadd wrote:
>> Ideally there'd be both behaviours:
>>
>> * You'd specify whether a timer/sleep needs to be exact or can
>> withstand some jitter (which is what linux provides); and
>> * You can communicate
On Fri, 2015-11-06 at 11:15 -0800, Adrian Chadd wrote:
> Ideally there'd be both behaviours:
>
> * You'd specify whether a timer/sleep needs to be exact or can
> withstand some jitter (which is what linux provides); and
> * You can communicate to the kernel its aggressiveness for coalescing
> wake
Adrian Chadd wrote this message on Fri, Nov 06, 2015 at 11:15 -0800:
> Ideally there'd be both behaviours:
>
> * You'd specify whether a timer/sleep needs to be exact or can
> withstand some jitter (which is what linux provides); and
Isn't that what the precision argument in callout is for?
See
Ideally there'd be both behaviours:
* You'd specify whether a timer/sleep needs to be exact or can
withstand some jitter (which is what linux provides); and
* You can communicate to the kernel its aggressiveness for coalescing wakeups.
Teaching powerd to flip on/off a sysctl for this isn't that t
On Fri, 6 Nov 2015, Ian Lepore wrote:
On Fri, 2015-11-06 at 17:51 +0100, Hans Petter Selasky wrote:
On 11/06/15 17:43, Ian Lepore wrote:
On Fri, 2015-11-06 at 17:28 +0100, Hans Petter Selasky wrote:
Hi,
Do the test II results change with this setting?
sysctl kern.timecounter.allowedde
On Fri, 2015-11-06 at 17:57 +0100, Hans Petter Selasky wrote:
> On 11/06/15 17:51, Hans Petter Selasky wrote:
> > On 11/06/15 17:43, Ian Lepore wrote:
> > > On Fri, 2015-11-06 at 17:28 +0100, Hans Petter Selasky wrote:
> > > > Hi,
> >
> > >
> > > Do the test II results change with this setting?
>
On Fri, 2015-11-06 at 17:51 +0100, Hans Petter Selasky wrote:
> On 11/06/15 17:43, Ian Lepore wrote:
> > On Fri, 2015-11-06 at 17:28 +0100, Hans Petter Selasky wrote:
> > > Hi,
>
> >
> > Do the test II results change with this setting?
> >
> >sysctl kern.timecounter.alloweddeviation=0
> >
>
On 11/06/15 17:51, Hans Petter Selasky wrote:
On 11/06/15 17:43, Ian Lepore wrote:
On Fri, 2015-11-06 at 17:28 +0100, Hans Petter Selasky wrote:
Hi,
Do the test II results change with this setting?
sysctl kern.timecounter.alloweddeviation=0
Yes, it looks much better:
debug.total: 10
On 11/06/15 17:43, Ian Lepore wrote:
On Fri, 2015-11-06 at 17:28 +0100, Hans Petter Selasky wrote:
Hi,
Do the test II results change with this setting?
sysctl kern.timecounter.alloweddeviation=0
Yes, it looks much better:
debug.total: 10013 -> 0
debug.total: 10013 -> 0
debug.total: 1
On Fri, 2015-11-06 at 17:28 +0100, Hans Petter Selasky wrote:
> Hi,
>
> I spent some time to write a test application to investigate this
> issue
> and I found some irregularities, that when
> kern.eventtimer.periodic=0,
> the timer appears to run very irregular.
>
> Test software:
> ==
Hi,
I spent some time to write a test application to investigate this issue
and I found some irregularities, that when kern.eventtimer.periodic=0,
the timer appears to run very irregular.
Test software:
==
fetch http://home.selasky.org:8192/privat/callout_test_dummynet.tar.gz
tar
On 11/06/15 11:08, Luigi Rizzo wrote:
On Fri, Nov 6, 2015 at 10:52 AM, Hans Petter Selasky wrote:
On 11/06/15 09:50, Luigi Rizzo wrote:
On Fri, Nov 6, 2015 at 9:44 AM, Hans Petter Selasky
wrote:
...
Hi,
The C_DIRECT_EXEC flag reduces task switching overhead, that you don't
have
to wakeup
On Fri, Nov 6, 2015 at 10:52 AM, Hans Petter Selasky wrote:
> On 11/06/15 09:50, Luigi Rizzo wrote:
>>
>> On Fri, Nov 6, 2015 at 9:44 AM, Hans Petter Selasky
>> wrote:
...
>>> Hi,
>>>
>>> The C_DIRECT_EXEC flag reduces task switching overhead, that you don't
>>> have
>>> to wakeup a thread to wak
On 11/06/15 09:50, Luigi Rizzo wrote:
On Fri, Nov 6, 2015 at 9:44 AM, Hans Petter Selasky wrote:
On 11/06/15 01:08, Rasool Al-Saadi wrote:
On Thursday, 5 November 2015 8:53 PM, Hans Petter Selasky wrote:
On 11/05/15 00:44, Rasool Al-Saadi wrote:
...
Removing C_HARDCLOCK reduces the prob
On Fri, Nov 6, 2015 at 9:44 AM, Hans Petter Selasky wrote:
> On 11/06/15 01:08, Rasool Al-Saadi wrote:
>>
>>
>> On Thursday, 5 November 2015 8:53 PM, Hans Petter Selasky wrote:
>>>
>>>
>>> On 11/05/15 00:44, Rasool Al-Saadi wrote:
...
>> Removing C_HARDCLOCK reduces the problem but doesn't solve
On 11/06/15 01:08, Rasool Al-Saadi wrote:
On Thursday, 5 November 2015 8:53 PM, Hans Petter Selasky wrote:
On 11/05/15 00:44, Rasool Al-Saadi wrote:
On Wednesday, 4 November 2015 12:34 AM, Hans Petter Selasky wrote:
On 11/03/15 14:14, Rasool Al-Saadi wrote:
Does anyone have thoughts on wha
On Thursday, 5 November 2015 8:53 PM, Hans Petter Selasky wrote:
>
> On 11/05/15 00:44, Rasool Al-Saadi wrote:
> >
> > On Wednesday, 4 November 2015 12:34 AM, Hans Petter Selasky wrote:
> >> On 11/03/15 14:14, Rasool Al-Saadi wrote:
> >>> Does anyone have thoughts on what we can test next to narr
On 11/05/15 00:44, Rasool Al-Saadi wrote:
On Wednesday, 4 November 2015 12:34 AM, Hans Petter Selasky wrote:
On 11/03/15 14:14, Rasool Al-Saadi wrote:
Does anyone have thoughts on what we can test next to narrow down the
root-cause of these unusual timing jumps?
You might also want to test t
On Wednesday, 4 November 2015 12:34 AM, Hans Petter Selasky wrote:
> On 11/03/15 14:14, Rasool Al-Saadi wrote:
> > Does anyone have thoughts on what we can test next to narrow down the
> root-cause of these unusual timing jumps?
>
> You might also want to test the "projects/hps_head" branch, whic
> I have
> attached two RTT vs Time graphs for our experiments.
Oops, the list stripped my attachments, here are the images online at
https://goo.gl/photos/3oxXFvr1T1ZC88PA8 and
https://goo.gl/photos/QM1tQL157w6NRdmE6
> I have attached a graph that compares delta
> values for the two experimen
On 11/03/15 at 02:33P, Hans Petter Selasky wrote:
> On 11/03/15 14:14, Rasool Al-Saadi wrote:
> > Does anyone have thoughts on what we can test next to narrow down the
> > root-cause of these unusual timing jumps?
>
> You might also want to test the "projects/hps_head" branch, which uses a
> bit
On 11/03/15 14:14, Rasool Al-Saadi wrote:
Does anyone have thoughts on what we can test next to narrow down the
root-cause of these unusual timing jumps?
You might also want to test the "projects/hps_head" branch, which uses a
bit different callout implementation.
--HPS
29 matches
Mail list logo