On Thu, Sep 06, 2018 at 03:02:29AM +0300, Lev Serebryakov wrote:
> Hello Benjamin,
>
> Thursday, September 6, 2018, 1:32:46 AM, you wrote:
>
> >> > I don't think you need something accurate.
> >> Ok, here is results. I'm working in single-user mode.
> >>
> >> TL;DR "Turbo" mode make "openssl"
On Wed, Sep 05, 2018 at 11:15:03PM +0300, Subbsd wrote:
> On Wed, Sep 5, 2018 at 5:58 PM Allan Jude wrote:
> >
> > On 2018-09-05 10:04, Subbsd wrote:
> > > Hi,
> > >
> > > I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12
> > > to latest revision (r338466 the moment) and
Hello Benjamin,
Thursday, September 6, 2018, 1:32:46 AM, you wrote:
>> > I don't think you need something accurate.
>> Ok, here is results. I'm working in single-user mode.
>>
>> TL;DR "Turbo" mode make "openssl" much slower (x3.5)!
>>
>> I can not properly interpret this result.
> You
On Wed, Sep 05, 2018 at 07:27:06PM +0300, Lev Serebryakov wrote:
> On 05.09.2018 17:51, Cy Schubert wrote:
>
> > I don't think you need something accurate.
> Ok, here is results. I'm working in single-user mode.
>
> TL;DR "Turbo" mode make "openssl" much slower (x3.5)!
>
> I can not properly
On Wed, Sep 5, 2018 at 5:58 PM Allan Jude wrote:
>
> On 2018-09-05 10:04, Subbsd wrote:
> > Hi,
> >
> > I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12
> > to latest revision (r338466 the moment) and related to ARC.
> >
> > I can not say which revision was before except that
On 05.09.2018 17:51, Cy Schubert wrote:
> I don't think you need something accurate.
Ok, here is results. I'm working in single-user mode.
TL;DR "Turbo" mode make "openssl" much slower (x3.5)!
I can not properly interpret this result.
But "turbostat" properly detect Turbo/No-Turbo mode, so
On 05.09.2018 17:51, Cy Schubert wrote:
> I don't think you need something accurate.
1.6GHz and 2.48Ghz.. Maybe... I i'm trying now.
> We don't know whether it is implemented through ACPI or similar to the
> old turbo jumper on the MB, which increased the clock rate and sometimes
> the voltage
Differential up here: https://reviews.freebsd.org/D17049 for any
lurkers I didn't manage to tag in the review.
Best,
Conrad
On Wed, Sep 5, 2018 at 12:57 AM, Mark R V Murray wrote:
> Nice catch! Thanks :-)
>
> M
>
>
>> On 5 Sep 2018, at 04:13, Conrad Meyer wrote:
>>
>> Hi Lev,
>>
>> I took a
On 2018-09-05 10:04, Subbsd wrote:
> Hi,
>
> I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12
> to latest revision (r338466 the moment) and related to ARC.
>
> I can not say which revision was before except that the newver.sh
> pointed to ALPHA3.
>
> Problems are observed if
I don't think you need something accurate.
We don't know whether it is implemented through ACPI or similar to the old
turbo jumper on the MB, which increased the clock rate and sometimes the
voltage ( required to maintain stability when increasing the clock rate). We
don't know how your MB
On Wed, Sep 05, 2018 at 05:04:56PM +0300, Subbsd wrote:
> Hi,
>
> I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12
> to latest revision (r338466 the moment) and related to ARC.
>
> I can not say which revision was before except that the newver.sh
> pointed to ALPHA3.
Could
Hi,
I'm seeing a huge loss in performance ZFS after upgrading FreeBSD 12
to latest revision (r338466 the moment) and related to ARC.
I can not say which revision was before except that the newver.sh
pointed to ALPHA3.
Problems are observed if you try to limit ARC. In my case:
On 05.09.2018 15:53, Cy Schubert wrote:
>> 1601 is not the actual frequency. That is just how it is reported. It
>> is almost certainly running much higher than 1601.
>
> We don't know this until we can independently verify it. Do you mind
> running some benchmarks with and without turbo
In message <43d68d5a-d8b7-965d-52a6-3eff6cdae...@vangyzen.net>, Eric
van Gyzen
writes:
> On 9/5/18 4:35 AM, Lev Serebryakov wrote:
> > BTW, these four settings in rc.conf(5)
> >
> >performance_cx_lowest
> >performance_cpu_freq
> >economy_cx_lowest
> >economy_cpu_freq
> >
> >
On 9/5/18 4:35 AM, Lev Serebryakov wrote:
BTW, these four settings in rc.conf(5)
performance_cx_lowest
performance_cpu_freq
economy_cx_lowest
economy_cpu_freq
do NOTHING. They are not used ANYWHERE but rc.conf and rc.conf.5!
They are used by /etc/rc.d/power_profile, but not in
Hello Conrad,
Wednesday, September 5, 2018, 7:39:07 AM, you wrote:
> I believe the EWOULDBLOCK is just a boring leak of tsleep(9)'s timeout
> condition. This may be sufficient to fix the problem:
> --- a/sys/dev/random/randomdev.c
> +++ b/sys/dev/random/randomdev.c
> @@ -156,6 +156,10 @@
Hello Cy,
Wednesday, September 5, 2018, 3:12:34 AM, you wrote:
> Are you running powers?
powerd? yes. With "adaptive" strategy"
> Do you use c-states?
Oops. My fault. I've forgot to set cx_lowest to C3 on all cores.
BTW, these four settings in rc.conf(5)
performance_cx_lowest
Nice catch! Thanks :-)
M
> On 5 Sep 2018, at 04:13, Conrad Meyer wrote:
>
> Hi Lev,
>
> I took a first attempt at reproducing this problem on a fast
> desktop-class system. First steps, give us a way to revert back to
> unseeded status:
>
> --- a/sys/dev/random/fortuna.c
> +++
18 matches
Mail list logo
