Once upon a time, Jesper Skriver said:
> The flip side is that all pointers are twice the size, in an application like
> rpd I'd expect most of the memory usage to be pointers, so we can expect ~2x
> the memory usage. That coupled with memory access typically being the
>
> On 01 Jun 2016, at 21:29, Vincent Bernat wrote:
>
> The other benefit would be the ability for rpd to make use of more CPU
> registers and to be faster. On average, one could expect a 20% speedup
> when recompiling for x86-64. I have absolutely no idea if such number
> would
Le 02/06/2016 à 00:02, Olivier Benghozi a écrit :
This is not completely contradictory with the Juniper doc ; as usual with the
Juniper doc written with feet, you have to read between the lines:
-> Written in the doc: "Tip: You need not restart the routing protocol process (rpd)
to use the
This is not completely contradictory with the Juniper doc ; as usual with the
Juniper doc written with feet, you have to read between the lines:
-> Written in the doc: "Tip: You need not restart the routing protocol process
(rpd) to use the 64-bit mode"
-> To be understood: "Joke: You need not
On Wed, Jun 1, 2016 at 11:09 AM, Saku Ytti wrote:
> On 1 June 2016 at 20:32, Phil Rosenthal wrote:
> > I suspect that there is not that high of a risk of bugs due to this
> change, in all likelihood, the only changes required for this was a
> different compiler
❦ 1 juin 2016 18:22 CEST, Phil Rosenthal :
> Even on systems with many peers, 5+ full tables, and a full IGP mesh,
> I haven’t seen rpd much over 1GB of ram in use. 64bit rpd would only
> be beneficial if you have a need for a rpd process using more than 4GB
> of ram.
The
ck.nether.net>
Betreff: Re: [j-nsp] force-64bit
I’ll ask the obvious question — do you actually have a ‘need’ for this?
Even on systems with many peers, 5+ full tables, and a full IGP mesh, I haven’t
seen rpd much over 1GB of ram in use. 64bit rpd would only be beneficial if
you have a need
On 1 June 2016 at 20:32, Phil Rosenthal wrote:
> I suspect that there is not that high of a risk of bugs due to this change,
> in all likelihood, the only changes required for this was a different
> compiler and perhaps the use of a few 64 bit instead of 32 bit variables —
>
Once upon a time, Phil Rosenthal said:
> I suspect that there is not that high of a risk of bugs due to this change,
> in all likelihood, the only changes required for this was a different
> compiler and perhaps the use of a few 64 bit instead of 32 bit variables —
> but even
Once upon a time, Phil Rosenthal said:
> Even on systems with many peers, 5+ full tables, and a full IGP mesh, I
> haven’t seen rpd much over 1GB of ram in use. 64bit rpd would only be
> beneficial if you have a need for a rpd process using more than 4GB of ram.
The break
> On Jun 1, 2016, at 10:35 AM, Tim Hoffman wrote:
>
> 64bit RPD is newer, and by nature will have more bugs - so don't run this
> unless you need it. Check this with "show task memory" - this will show what
> you have used of the RPD accessible memory. As Phil notes,
Hello
We use it since Junos 14.2. No bug encountered related to this feature.
It depends on your sizing. As Tim said check the RPD memory - Just never reach
the 80%.
David
Tim Hoffman via juniper-nsp a écrit
64bit RPD is newer, and by nature will have more bugs - so don't run
64bit RPD is newer, and by nature will have more bugs - so don't run this
unless you need it. Check this with "show task memory" - this will show
what you have used of the RPD accessible memory. As Phil notes, you'd need
significant RIB scale (which does exist in larger networks) to require
I’ll ask the obvious question — do you actually have a ‘need’ for this?
Even on systems with many peers, 5+ full tables, and a full IGP mesh, I haven’t
seen rpd much over 1GB of ram in use. 64bit rpd would only be beneficial if
you have a need for a rpd process using more than 4GB of ram.
Is
14 matches
Mail list logo