Going back to the OP, here's a postmortem on exactly what happened:
In short, we had unknowingly downgraded from 64 bit to 32 bit during an
upgrade. It's covered here:
https://doc.pfsense.org/index.php/Upgrade_Guide#Avoiding_Unintended_Architecture_Change
Interestingly, it worked like this:
I wrote MTU since you used it. What I am talking about are packet sizes. If
people bulding internet knew what they where doing then a MTU of 1500 (L2)
or more would be mandatory. But because of old ATM stuff this isn't true
for all of internet. When I say our average packet size was 1200 that has
n
> My point is just that if you have normal traffic patterns, even at 600 you
> should
have no problem pushing 10GE. A MTU of 600 should give you about 53
gigabit/s if you are able yo push 1200 pps with that payload.
An "MTU of 600" wouldn't allow IPv6 to pass over a link. IPv6
requires th
1200 was my average packet size when analyzed in Dataguard Core network (a
smb ISP here in .no) . Im sure others can find different averages. My point
is just that if you have normal traffic patterns, even at 600 you should
have no problem pushing 10GE. A MTU of 600 should give you about 53
gigabit
On Thursday, January 26, 2017, Espen Johansen wrote:
> Are you saying worst case is 80%? Its not normal to have all minimum size
> packets unless you are under ddos.
> Default ethernet is 1526 (1530 with vlan) with a MTU 1500 on a layer 1
> frame.
> A layer 2 frame is 1518 (1522 with vlan).
> If
Are you saying worst case is 80%? Its not normal to have all minimum size
packets unless you are under ddos.
Default ethernet is 1526 (1530 with vlan) with a MTU 1500 on a layer 1
frame.
A layer 2 frame is 1518 (1522 with vlan).
If you want to include all layer headers then 1542 including vlan is t
On Thu, Jan 26, 2017 at 3:12 PM, Vick Khera wrote:
> ahci_load="YES"
>
Indeed, this line is leftover from olden days. This is not necessary
anymore with the FreeBSD 10.x kernel.
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
S
On Thu, Jan 26, 2017 at 12:17 PM, Karl Fife wrote:
> Would you mind sharing a snapshot of your Rangeley-optimized tunables?
>
> IIRC there are un-editable tunables that show on your tunables page that
> are not called out in the XML config.
>
> Thanks Vick
>
>
This is the /boot/loader.conf from o
> On Jan 26, 2017, at 5:06 PM, rai...@ultra-secure.de wrote:
>
> Am 2017-01-26 07:03, schrieb Jim Thompson:
>> It does not.
>> The c2758 SoC is interesting. 8 cores, and the on-die i354 is essentially a
>> block with 4 i350s on it.
>> These have 8 queues for each of rx and tx, so 16 each, for a
.ipc.nmbclusters: 20612
>>>
>>> but nothing explicitly set on the tunables page, just whatever's built
>> in.
>>>
>>> -----Original Message-----
>>> From: List [mailto:list-boun...@lists.pfsense.org ] On
>> Behalf Of Karl Fife
>&
Would you mind sharing a snapshot of your Rangeley-optimized tunables?
IIRC there are un-editable tunables that show on your tunables page that
are not called out in the XML config.
Thanks Vick
On 1/26/2017 9:47 AM, Vick Khera wrote:
On Wed, Jan 25, 2017 at 4:01 PM, Karl Fife wrote:
I r
On Wed, Jan 25, 2017 at 4:01 PM, Karl Fife wrote:
> I recently did a virgin install of 2.3.2 nano on an older atom (a Soekris
> 6501), and found there were no tunables for kern.ipc.nmbclusters nor
> kern.ipc.nmbufs. Maybe it's a nano/full-install difference?I would
> think most people runnin
Am 2017-01-26 07:03, schrieb Jim Thompson:
It does not.
The c2758 SoC is interesting. 8 cores, and the on-die i354 is
essentially a
block with 4 i350s on it.
These have 8 queues for each of rx and tx, so 16 each, for a total of
64
queues.
On the c2xxx series (and other) boxes we ship, we in
-Original Message-
> > From: List [mailto:list-boun...@lists.pfsense.org ] On
> Behalf Of Karl Fife
> > Sent: Wednesday, January 25, 2017 4:02 PM
> > To: pfSense Support and Discussion Mailing List >
> > Subject: Re: [pfSense] Intel Atom C2758 (Rangeley/Avoton) inst
e tunables page, just whatever's built
> in.
> >
> > -Original Message-
> > From: List [mailto:list-boun...@lists.pfsense.org ] On
> Behalf Of Karl Fife
> > Sent: Wednesday, January 25, 2017 4:02 PM
> > To: pfSense Support and Discussion Mailing List
hatever's built in.
>
> -Original Message-
> From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Karl Fife
> Sent: Wednesday, January 25, 2017 4:02 PM
> To: pfSense Support and Discussion Mailing List
> Subject: Re: [pfSense] Intel Atom C2758 (Rangeley/Av
Sent: Wednesday, January 25, 2017 4:02 PM
To: pfSense Support and Discussion Mailing List
Subject: Re: [pfSense] Intel Atom C2758 (Rangeley/Avoton) install/boot
failure with pfSense 2.3.2
This is a good theory, because RRD data from 2.2.6 suggests that the
difference in utilization between the versio
This is a good theory, because RRD data from 2.2.6 suggests that the
difference in utilization between the versions is slight, and that we
had 'barely' exhausted our system default allocation.
Is there a difference between nano and full with respect to the
installer explicitly setting tunables
On 01/25/2017 01:10 PM, Karl Fife wrote:
> The piece that's still missing for me is that there must have been some
> change in default system setting for FreeBSD, or some other change
> between versions, because the system booted fine with pfSense v 2.2.6
Aside from what has already been suggested
This is valuable input. Thank you to you and Peter.
We had to add the tunables rows where they did not exist before. Perhaps
if this had been a brand new virgin installation, the installer would
have made suitable tunables estimates, based on the hardware, and
inserted them into a new config.
esday, January 25, 2017 12:11 PM
To: ESF - Electric Sheep Fencing pfSense Support
Subject: [pfSense] Intel Atom C2758 (Rangeley/Avoton) install/boot failure
with pfSense 2.3.2
pfsense 2.2.6 was running without issue on our Supermicro A1SRi-2758F
rangeley board (Intel Atom C2758)
When we upgraded to
it? Old config overwriting new defaults?
>
> -Original Message-
> From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Karl Fife
> Sent: Wednesday, January 25, 2017 12:11 PM
> To: ESF - Electric Sheep Fencing pfSense Support
> Subject: [pfSense] Intel Atom C27
25, 2017 12:11 PM
To: ESF - Electric Sheep Fencing pfSense Support
Subject: [pfSense] Intel Atom C2758 (Rangeley/Avoton) install/boot failure
with pfSense 2.3.2
pfsense 2.2.6 was running without issue on our Supermicro A1SRi-2758F
rangeley board (Intel Atom C2758)
When we upgraded to 2.3.2, the
On Wed, Jan 25, 2017 at 1:10 PM, Karl Fife wrote:
> pfsense 2.2.6 was running without issue on our Supermicro A1SRi-2758F
> rangeley board (Intel Atom C2758)
>
Are you sure you didn't hard-code them before in the system tunables
section under 2.2? On my C2758 system (exact same motherboard) runn
pfsense 2.2.6 was running without issue on our Supermicro A1SRi-2758F
rangeley board (Intel Atom C2758)
When we upgraded to 2.3.2, the new system failed to boot due to having
insufficient RAM allocated to network memory buffers. We had to
interrupt the boot process increase the value of kern.
25 matches
Mail list logo
