-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 only
On 21 March 2015 at 08:52, John Baldwin j...@freebsd.org 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/21/15 12:31 PM, Adrian Chadd wrote:
On 21 March 2015 at 08:52, John Baldwin j...@freebsd.org 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
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 don't.
First
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)
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.eventtimer.choice:
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,
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
-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
don't.
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
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
-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 r279796
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
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:
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,
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
Dear all,
On 18.03.2015, at 23:41, Matt Smith f...@xtaz.co.uk 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 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
.. 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: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.
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 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
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]
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 very easy to
On Mar 18, 2015, at 2:14 PM, John-Mark Gurney j...@funkthat.com 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?
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, 2G
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
