-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 03/21/2015 14:42, Konstantin Belousov wrote:
> It seems to be a consequnce of the code from r222869. The
> test_tsc() does not trust the P-state invariant report and
> explicitely check for the family. Your CPU family is 0x14, while
> code on
On 3/21/2015 2:42 PM, Konstantin Belousov wrote:
It seems to be a consequnce of the code from r222869. The test_tsc()
does not trust the P-state invariant report and explicitely check for
the family. Your CPU family is 0x14, while code only bumps TSC priority
for family 0x15+.
Currently, tsc_
On Sat, Mar 21, 2015 at 02:13:06PM -0400, Mike Tancsa wrote:
> On 3/21/2015 11:52 AM, John Baldwin wrote:
>
> >> http://tancsa.com/time/
> >
> > Do you know why you are using the HPET instead of TSC for timestamping?
>
> Hi,
>
> I am not consciously making any time keep decisions.
>
> kern.even
On 3/21/2015 11:52 AM, John Baldwin wrote:
http://tancsa.com/time/
Do you know why you are using the HPET instead of TSC for timestamping?
Hi,
I am not consciously making any time keep decisions.
kern.eventtimer.choice: HPET(550) HPET1(450) LAPIC(400) i8254(100) RTC(0)
kern.timecounter.cho
On 3/21/15 12:31 PM, Adrian Chadd wrote:
> On 21 March 2015 at 08:52, John Baldwin wrote:
>> On 3/20/15 8:46 PM, Mike Tancsa wrote:
>>> On 3/20/2015 8:15 PM, Konstantin Belousov wrote:
>
> For the purpose of devfs, does it make sense to bump timestamps like
> normal filesystems for eac
On 21 March 2015 at 08:52, John Baldwin wrote:
> On 3/20/15 8:46 PM, Mike Tancsa wrote:
>> On 3/20/2015 8:15 PM, Konstantin Belousov wrote:
For the purpose of devfs, does it make sense to bump timestamps like
normal filesystems for each read/write operation? Looks like Mac OS X
>>>
On 3/20/15 8:46 PM, Mike Tancsa wrote:
> On 3/20/2015 8:15 PM, Konstantin Belousov wrote:
>>>
>>> For the purpose of devfs, does it make sense to bump timestamps like
>>> normal filesystems for each read/write operation? Looks like Mac OS X
>>> will bump timestamps for each operation but Debian do
On 3/20/2015 8:15 PM, Konstantin Belousov wrote:
For the purpose of devfs, does it make sense to bump timestamps like
normal filesystems for each read/write operation? Looks like Mac OS X
will bump timestamps for each operation but Debian don't.
First question is, what timecounter hardware is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/20/15 17:15, Konstantin Belousov wrote:
>> For the purpose of devfs, does it make sense to bump timestamps
>> like normal filesystems for each read/write operation? Looks
>> like Mac OS X will bump timestamps for each operation but Debian
>> d
On Fri, Mar 20, 2015 at 04:53:42PM -0700, Xin Li wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 03/20/15 14:02, Mike Tancsa wrote:
> > OK, I think I found where the RELENG_10 performance loss happened.
> > It seems
> > https://lists.freebsd.org/pipermail/svn-src-stable-10/2015-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/20/15 14:02, Mike Tancsa wrote:
> OK, I think I found where the RELENG_10 performance loss happened.
> It seems
> https://lists.freebsd.org/pipermail/svn-src-stable-10/2015-March/004778.html
>
> is the issue.
>
> Testing with a kernel from r
Mike Tancsa wrote on 03/20/2015 22:02:
OK, I think I found where the RELENG_10 performance loss happened. It seems
https://lists.freebsd.org/pipermail/svn-src-stable-10/2015-March/004778.html
is the issue.
Testing with a kernel from r279796 I get 76-77Mb of throughput. With
r279848 it drops to
OK, I think I found where the RELENG_10 performance loss happened. It seems
https://lists.freebsd.org/pipermail/svn-src-stable-10/2015-March/004778.html
is the issue.
Testing with a kernel from r279796 I get 76-77Mb of throughput. With
r279848 it drops to about 60Mb
---Mike
On 3/20/2
OK, just to refocus,
I had been tracking down what I thought was a regression between RELENG9
and RELENG10, but looks more like an issue that cropped up somewhere
between the beginning of March and now. For RELENG9, I was actually
using a kernel from sources back on Jan 29th by accident. If
On 3/18/2015 5:14 PM, John-Mark Gurney wrote:
# dtrace -x stackframes=100 -n 'profile-997 /arg0/ { @[stack()] = count(); }
tick-60s { exit(0); }' -o out.kern_stacks
Also, another thing you can do is to compare the two using differential
flame graphs:
http://www.brendangregg.com/blog/2014-11-09/
And compiling 1.0.1l on RELENG_9 shows the same performance profile on
RELENG_10. Smaller packets are slower, larger are faster
16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes
20245.49k21646.52k22179.87k55431.85k55981.40k R10
34178.77k35559.29k36305.70k
On 3/18/2015 6:40 PM, Matt Smith wrote:
Isn't OpenSSL in the base on releng9 the 0.9.8 version whereas in
releng10 it's the 1.0.1 version? This could make a significant
difference. I've heard rumours before that the newer version is a lot
slower but I've never had cause to believe it.
openssl
On 3/18/2015 6:39 PM, Adrian Chadd wrote:
.. ipfw showed up?
I can take it out for both. If anything, I want to test with pf
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
C
Dear all,
> On 18.03.2015, at 23:41, "Matt Smith" wrote:
>
>> On Mar 18 18:28, Mike Tancsa wrote:
>>> On 3/18/2015 5:14 PM, John-Mark Gurney wrote:
>>> As I've never used OpenVPN before and their docs don't go into saying
>>> what it's using.. Is OpenVPN a kernel or userland VPN? Do they use
>>>
On Mar 18 18:28, Mike Tancsa wrote:
On 3/18/2015 5:14 PM, John-Mark Gurney wrote:
As I've never used OpenVPN before and their docs don't go into saying
what it's using.. Is OpenVPN a kernel or userland VPN? Do they use
IPSec in the kernel? or are they just using UDP or TCP for their
connections
.. ipfw showed up?
-a
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
On 3/18/2015 6:28 PM, Mike Tancsa wrote:
Will do, I will work on those.
Here is the kernel one for now
http://tancsa.com/10-kern.svg
---Mike
--
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sent
On 3/18/2015 5:14 PM, John-Mark Gurney wrote:
So, I would first identify the machine w/ the cpu limited load.. I
assume that is apu...
Yup, the APU. The machines on either side are significantly faster
Then I would look at where most of the cpu time
is being spent, be it openvpn itself, or
On Mar 18, 2015, at 2:14 PM, John-Mark Gurney wrote:
> As I've never used OpenVPN before and their docs don't go into saying
> what it's using.. Is OpenVPN a kernel or userland VPN? Do they use
> IPSec in the kernel? or are they just using UDP or TCP for their
> connections?
OpenVPN runs in user
Mike Tancsa wrote this message on Wed, Mar 18, 2015 at 15:49 -0400:
> On 3/16/2015 9:20 AM, John-Mark Gurney wrote:
> >
> > Since you have at test framework ready, you could generate some flame
> > graphs[1] using dtrace to help see where things might be having an
> > impact...
> >
> > These are ve
On 3/16/2015 9:20 AM, John-Mark Gurney wrote:
Since you have at test framework ready, you could generate some flame
graphs[1] using dtrace to help see where things might be having an
impact...
These are very easy to generate, and posting them would be useful...
[1] http://www.brendangregg.com/
Mike Tancsa wrote this message on Sun, Mar 15, 2015 at 20:34 -0400:
> As part of moving from a RELENG8 based image to a RELENG9 or 10, I was
> doing some simple performance testing and found RELENG_9 to be quite a
> bit faster when generating traffic through a pcengines APU (dual core,
> AMD64,
As part of moving from a RELENG8 based image to a RELENG9 or 10, I was
doing some simple performance testing and found RELENG_9 to be quite a
bit faster when generating traffic through a pcengines APU (dual core,
AMD64, 2G of RAM). Both are using generic kernels
blasting across an aes-128cbc
28 matches
Mail list logo
