Quartz,
I'm sorry I'm not familiar with either of the processor's you're
describing. In the vague terms you have given, I am 100% that the answer is
use the multicore setup.
On Tue, Sep 1, 2015 at 2:06 PM, Quartz wrote:
> but the short answer is to use the
>>
Em 01-09-2015 14:21, Quartz escreveu:
> Also, does a local DNS resolver really consume that much cpu that it
> would see any notable effect from having another core? I thought that
> was more a RAM thing.
If it will be the resolver for your entire internal LAN (and the
firewall itself), then it
A small office isn't that much different from a home server.
It's not actually a small office, that's just the best analogy I could
think of.
I
see, that more than really wanting to know if you'd be ok with mp,
you're seeking validation to go through with a single core.
Well... that's
Em 01-09-2015 14:18, Quartz escreveu:
> It's not actually a small office, that's just the best analogy I could
> think of.
My home server many times ends up having more traffic to deal with than
my small office. So an analogy not always plays in our favour.
> Well... that's kind of the same
Dhcp, no. DNS, yes.
Also, does a local DNS resolver really consume that much cpu that it
would see any notable effect from having another core? I thought that
was more a RAM thing.
not
paying a context-switching tax during these simultaneous load events will
make a bigger difference than any other single factor.
I guess that's what I was getting at in my original poorly worded
question: at what point do context switches negate the benefit of a
faster single core (given
but the short answer is to use the
multi-processor system. The single core will perform better when you care
nothing about your performance, the multi-core system will perform better
the only time you care at all about performance.
I think some information is getting lost here. I'm not
On Tue, Sep 1, 2015 at 12:41 PM, Giancarlo Razzolini
wrote:
> Em 01-09-2015 14:21, Quartz escreveu:
> > Also, does a local DNS resolver really consume that much cpu that it
> > would see any notable effect from having another core? I thought that
> > was more a RAM thing.
>
Hey,
Not sure if this is the best place to post this, but I noticed I never
received mlarkin@'s announcement to tech@ about the coming hypervisor
for amd64 (and i386?)
I did some checking to make sure my spamfilters didn't somehow eat it,
but it didn't look like it even showed up in my maillog.
On 01.09.2015 22:05, Todd C. Miller wrote:
The mailing list server has been hitting a kernel bug that may have
caused some outgoing messages to be lost.
- todd
Some incoming messages as well. My first message about "ddb.html typo"
got lost too:
Hi!
This is the MAILER-DAEMON,
Hello! I compile libdgiplus with some changes (in "LIB_DEPENDS" I added
"graphics/cairo" and instead of "--with-pango" I used "--with-cairo").
Makefile looks like this now:
# $OpenBSD: Makefile,v 1.20 2014/07/18 16:00:28 ajacoutot Exp $
COMMENT=GDI+ comptible API
DISTNAME=
The mailing list server has been hitting a kernel bug that may have
caused some outgoing messages to be lost.
- todd
On Mon, Aug 31, 2015 at 05:04:09PM -0700, Gabriel Kuri wrote:
> In migrating from bind to nsd, I currently have split views in bind and
> need to run multiple instances of nsd to accomplish the same thing. What's
> the best way to start multiple instances of nsd? I tried copying
> /etc/rc.d/nsd to
Are you doing anything above 5Gbps? Or above 500k pps?
if not, get whichever.
If you are, then higher frequency cores are better; today.
If you are running dhcp server, then you are likely not.
On 2015 Aug 31 (Mon) at 22:38:47 -0400 (-0400), Quartz wrote:
:Quick question: I need to make a
The -P or -d flags don't make a difference. The interesting thing is that
if I rename /etc/rc.d/nsd-internal to /etc/rc.d/nsd it works fine. If copy
the original /etc/rc.d/nsd to /etc/rc.d/nsd-internal, it doesn't work. It
seems like something is preventing it from starting because the rc script
I don't think it's off topic but others might. I'm writing this post to
remember Chuck Yerkes, a long time contributor to the misc@openbsd list.
While riding his motorcycle 11 years ago Chuck was involved in an accident
and passed away as a result of his injuries.
Any idea if running an ipsec vpn or openvpn on the same machine will
benefit from the second core? working remotely over VPN is quite common
these days. so all the extra juice may help encryption etc. is it so?
On Tue, Sep 1, 2015 at 8:59 PM, Quartz wrote:
> Maybe this
> Quartz [qua...@sneakertech.com] wrote:
> > Quick question: I need to make a decision between a faster single core and a
> > slower multicore. The faq currently states that pf gets no improvement from
> > mp. Is this still correct/current information? Presumably it would see no
> > benefit from
I red all thoughts till now and my advice is if you are going to buy
a new hardware now (year 2015) take multi core CPU. The OpenBSD just
get better every day and if you follow tech@, source-changes@ and
misc@ you already know that our beloved OS soon or later will spread
load on all CPU/CORES
I'm sorry I'm not familiar with either of the processor's you're
describing. In the vague terms you have given,
I haven't described any specific models yet, I'm being a little vague
because I was looking more for general guidance than having the list
debate the pros and cons of dozens of
On a more serious note, I don't see how one can actually buy faster
single-core performance for this purpose. If the question was more
detailed, describing specific models of machines, we'd be able to
show it makes no financial sense. The cheapest stuff is good enough.
As I said before, I
The recommendation
that people use SP kernels for networking is no longer valid.
Ah, thank you for mentioning this explicitly. I had a memory of this
kicking around at the bottom of my subconscious. I knew there was
something else about this issue but couldn't put my finger on it.
Maybe this webpage would help you make an informed choice?
https://calomel.org/pf_config.html
That looks like a good reference for setting up pf and the right way to
architect your pf.conf, but it doesn't appear to address any of the cpu
threading issues I'm trying to figure out. Thanks
The short answer is, unless you can guarantee that pf will have its own
core and no other process will race against it (you can't), then go for
the mp.
OK, so after more info you're switching to the mp side? If that's true
then all the latest recommendations from this afternoon forwards are in
As I said before, I think information is getting lost here in the
discussion. The issue is we need something that fits within certain
restrictive thermal/size/power/noise limits; these are all fanless
setups and some might even be battery powered.
And when I say "fanless" I mean *completely*
Quartz [qua...@sneakertech.com] wrote:
> Quick question: I need to make a decision between a faster single core and a
> slower multicore. The faq currently states that pf gets no improvement from
> mp. Is this still correct/current information? Presumably it would see no
> benefit from
> On Sep 1, 2015, at 8:40 PM, Quartz wrote:
>
> there won't even be any fans in the chassis or power supply, so low TDP is
super important, and that ends up meaning low performance
Embedded systems can often benefit from efficient power design & inefficiency
can unduly
Em 01-09-2015 16:06, Quartz escreveu:
> I think some information is getting lost here. I'm not comparing
> single vs multi core operation in a purely mathematical sense on
> identical hardware. I'm trying to decide between a setup that uses a
> relatively fast single core vs a setup that uses
Maybe this webpage would help you make an informed choice?
https://calomel.org/pf_config.html
Sent from my iPod
> On 01 Sep 2015, at 04:38, Quartz wrote:
>
> Quick question: I need to make a decision between a faster single core and a
> slower multicore. The faq
Nope. I'll try installing another BSD to see what breaks there
Sent from my iPod
> On 01 Sep 2015, at 18:27, Martin Pieuchot wrote:
>
>> On 01/09/15(Tue) 17:55, Joseph Borg wrote:
>> Interesting. Is it possible to change the IRQ to something useful in UKC?
>>
>> The boot log
On 01.09.2015 22:06, Quartz wrote:
but the short answer is to use the
multi-processor system. The single core will perform better when you
care
nothing about your performance, the multi-core system will perform
better
the only time you care at all about performance.
I think some information
On 9/1/2015 3:40 PM, Joseph Borg wrote:
> Maybe this webpage would help you make an informed choice?
>
> https://calomel.org/pf_config.html
>
You must be new around here.
--
James Shupe
I also experienced undelivered messages when I was posting to the "bugs"
mailing list. However, they would still show up on the official mailing
list page 2-3 weeks back.
On Tuesday, September 1, 2015, Atanas Vladimirov wrote:
> On 01.09.2015 22:05, Todd C. Miller wrote:
>
>>
more info:
I'm running OpenBSD 5.4 yet, I checked the changelogs between -current and 5.4
and haven't seen improvements regarding ECMP and IPv6.
Maybe someone can point me in the right direction regarding my problem ?
Thanks for your help,
Romain
-Original Message-
From:
On 2015-08-30, Vivek Vinod wrote:
> I run a miniscule ISP. Speed tests are flawed. Depends on which ones you are
> running - they basically download a file (typically 2 to 10 MB) and determine
> how much time that took. Then they report the "mbps".
They're more likely to
Le mardi 01 septembre 2015 à 09:16 +, Aviolat Romain a écrit :
> more info:
>
> I'm running OpenBSD 5.4 yet, I checked the changelogs between
> -current and 5.4 and haven't seen improvements regarding ECMP and
> IPv6.
>
> Maybe someone can point me in the right direction regarding my
>
On 2015-09-01, Edgar Pettijohn wrote:
> Might need to add the -P flag to specify a different pid. What happens
> if you start the second instance with the -d flag?
Currently the rc.d script for NSD starts the program via nsd-control
which only offers the -c flag.
> Quick question: I need to make a decision between a faster single core
> and a slower multicore.
Quick answer: faster multiple cores within similar thermal envelope,
i.e. newer lithography.
With the latest snap of amd64, my NFS mount from fstab is now failing to
mount at boot with this line:
mount_nfs: can't resolve address for host microserver
Changing the fstab entry to reference the IP address caused the boot
process to hang with a portmapper RPC error.
Is anyone else seeing
Rerun with pf disabled.
On Tue, Sep 1, 2015 at 11:44 PM, Joe Gidi wrote:
> With the latest snap of amd64, my NFS mount from fstab is now failing to
> mount at boot with this line:
>
> mount_nfs: can't resolve address for host microserver
>
> Changing the fstab entry to
Thanks, it was the dash. I changed it to an underscore and it works great.
I also linked it to /etc/rc.d/nsd and set the options in /etc/rc.conf.local.
On Mon, Aug 31, 2015 at 11:49 PM, Antoine Jacoutot
wrote:
> On Mon, Aug 31, 2015 at 05:04:09PM -0700, Gabriel Kuri
Coming soon to http://www.openbsd.org/lyrics.html is the next 5.8
release song "A Year In The Life".
I seem to have this bad habit of talking to Theo about release
themes when drinking alcohol, and it brings out the poet (My
inner Weird Al) in me. Then I get cajoled into finishing the Opus
On 01/09/15(Tue) 17:55, Joseph Borg wrote:
> Interesting. Is it possible to change the IRQ to something useful in UKC?
>
> The boot log seems to crap out at a certain point and starts from the top,
> overwriting the first twenty odd lines at a horizontal offset.
>
> Precisely between 'vgafb0 at
For an OpenBSD machine acting as a gateway/firewall/router with a
handful of related tasks (pf, dhcp server, etc) would mp yield anything?
Of course, yes. Just because PF doesn't get any benefits (yet) from MP,
it doesn't mean these other programs won't.
Sorry that was unclear wording on my
Hi misc readers!
This is my first attempt to ask for help using misc@openbsd.org, so please
bear with me if I'm making mistakes. Also, apologies if I'm asking about
something recently discussed.
I want to limit the number of tls ciphersâ in httpd.conf so that only
strong (>128 bit) ciphers
Em 01-09-2015 10:21, Quartz escreveu:
>
> Sorry that was unclear wording on my part. This machine is 95% pf
> routing with some dhcp/dns on the side- AFAIK those won't account for
> much so if there's nothing else there wouldn't really be a benefit
> going multicore, right?
Dhcp, no. DNS, yes. As
Adam Jeanguenat wrote:
> tedu wrote:
> > doas allows PATH to be inherited, but resets it for itself to a
> > limited set. this was so that e.g., "permit :wheel cmd ls" can't
> > be tricked by creating a symlink ls -> /bin/sh. however, if there
> > are no restrictions on the command, then the
are we talking home router here or something more specialized?
A little more specialized. It's a sort of embedded system and it needs
to fit within some size/thermal/watts/noise constraints. It needs to
serve something roughly equivalent to a small office.
now if i needed a
On Tue, Sep 1, 2015 at 6:14 AM, Andreas Thulin
wrote:
> Hi misc readers!
>
>
> My current httpd.conf contains a line saying
>
> tls ciphers "STRONG:ECDHE:!aNULL:!SSLv3:@STRENGTH"
>
> which renders out "Configuration OK" with '# /usr/sbin/httpd -n'.
>
A really stupid
Interesting. Is it possible to change the IRQ to something useful in UKC?
The boot log seems to crap out at a certain point and starts from the top,
overwriting the first twenty odd lines at a horizontal offset.
Precisely between 'vgafb0 at pci0' and 'wsdisplay0 at vgafb0'. But could be a
50 matches
Mail list logo