Re: [j-nsp] force-64bit

[Olivier Benghozi]

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 restart rpd yourself, because it will 
be done automatically at the commit and ruin your network for about 10 minutes".


By the way, auto-64-bit is probably the good option to use, since it activates 
the 64 bit mode only if you have enough RAM installed.
We've been used 64 bit rpd here for 1 year (in 13.3 and 14.2).


> Le 1 juin 2016 à 20:20, Theo Voss  a écrit :
> 
> I’ve lost a rpd suddenly during daily ops a couple of month ago by OOM, ATAC 
> investigated the issue for months and conclusion was solely OOM. Referring to 
> my question, Tim says "Enabling this will cause RPD to restart as you kill 
> one process and start another.“. That’s what I suspected, but is 
> contradictory to the Juniper documentation, thanks! :-)

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] force-64bit

[Tim Hoffman via juniper-nsp]

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 and perhaps the use of a few 64 bit instead of 32 bit
> variables — but even with a low risk of bugs, if there is no benefit, I’m
> not sure what the point of adding even a low risk of bugs.
>
> This is also not super new feature, it's been in shipping software for
> over two years.


So this means we're half way towards it being stable right
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] force-64bit

[Vincent Bernat]

 ❦  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 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 apply to rpd.
-- 
He jests at scars who never felt a wound.
-- Shakespeare, "Romeo and Juliet, II. 2"
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] force-64bit

[Theo Voss]

I’ve lost a rpd suddenly during daily ops a couple of month ago by OOM, ATAC 
investigated the issue for months and conclusion was solely OOM. Referring to 
my question, Tim says "Enabling this will cause RPD to restart as you kill one 
process and start another.“. That’s what I suspected, but is contradictory to 
the Juniper documentation, thanks! :-)



Best,
Theo

-Ursprüngliche Nachricht-
Von: Phil Rosenthal 
Datum: Mittwoch, 1. Juni 2016 um 18:22
An: Theo Voss 
Cc: "juniper-nsp@puck.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 for a rpd process using more than 4GB of ram.

Is this a theoretical use case, or is there an actual need?

Best Regards,
-Phil Rosenthal
> On Jun 1, 2016, at 3:58 AM, Theo Voss  wrote:
> 
> Hi,
> 
> has anybody enabled „system processes force-64bit“ on 64bit Junos? Have you 
> done this during daily ops or during a maintenance window? According to 
> Juniper documentation [1] rpd must not be restarted to enable 64-bit mode: 
> „You need not restart the routing protocol process (rpd) to use the 64-bit 
> mode.“...
> 
> Thanks in advance for your comments! ;-)
> 
> https://www.juniper.net/documentation/en_US/junos14.2/topics/reference/configuration-statement/routing-edit-system-processes.html
> 
> 
> Cheers,
> Theo Voss
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] force-64bit

[Saku Ytti]

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 — 
> but even with a low risk of bugs, if there is no benefit, I’m not sure what 
> the point of adding even a low risk of bugs.

This is also not super new feature, it's been in shipping software for
over two years.

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] force-64bit

[Chris Adams]

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 with a low risk of bugs, if there is no benefit, I’m not sure what 
> the point of adding even a low risk of bugs.

Presumably, this is a straight-up recompile.  It is possible that there
was some sloppy coding (most common 32->64 bit conversion problems come
from assuming int and pointer are the same size); that kind of bug
usually gets sorted out pretty rapidly (and would probably be changed in
the common source, not just a 64-bit fork).
-- 
Chris Adams 
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] force-64bit

[Chris Adams]

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 would be lower than that.  I can't remember whether 32 bit
FreeBSD uses a 2G/2G or 3G/1G user/kernel memory split, but you
definitely can't have 4G in a single user process (PAE only extends
physical addressing, not virtual addressing used for processes).

-- 
Chris Adams 
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] force-64bit

[Phil Rosenthal]

> 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, you'd need 
> significant RIB scale (which does exist in larger networks) to require this…

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 with a 
low risk of bugs, if there is no benefit, I’m not sure what the point of adding 
even a low risk of bugs.

Best Regards,
-Phil

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] force-64bit

[david.roy]

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 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
this...

Enabling this will cause RPD to restart as you kill one process and start
another.

Tim

On Wed, Jun 1, 2016 at 9:22 AM, Phil Rosenthal  wrote:

> 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 this a theoretical use case, or is there an actual need?
>
> Best Regards,
> -Phil Rosenthal
> > On Jun 1, 2016, at 3:58 AM, Theo Voss  wrote:
> >
> > Hi,
> >
> > has anybody enabled „system processes force-64bit“ on 64bit Junos? Have
> you done this during daily ops or during a maintenance window? According to
> Juniper documentation [1] rpd must not be restarted to enable 64-bit mode:
> „You need not restart the routing protocol process (rpd) to use the 64-bit
> mode.“...
> >
> > Thanks in advance for your comments! ;-)
> >
> >
> https://www.juniper.net/documentation/en_US/junos14.2/topics/reference/configuration-statement/routing-edit-system-processes.html
> >
> >
> > Cheers,
> > Theo Voss
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



--
Tim Hoffman | Twitter, Inc.
1355 Market St. | San Francisco, CA | 94103
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] force-64bit

[Tim Hoffman via juniper-nsp]

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
this...

Enabling this will cause RPD to restart as you kill one process and start
another.

Tim

On Wed, Jun 1, 2016 at 9:22 AM, Phil Rosenthal  wrote:

> 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 this a theoretical use case, or is there an actual need?
>
> Best Regards,
> -Phil Rosenthal
> > On Jun 1, 2016, at 3:58 AM, Theo Voss  wrote:
> >
> > Hi,
> >
> > has anybody enabled „system processes force-64bit“ on 64bit Junos? Have
> you done this during daily ops or during a maintenance window? According to
> Juniper documentation [1] rpd must not be restarted to enable 64-bit mode:
> „You need not restart the routing protocol process (rpd) to use the 64-bit
> mode.“...
> >
> > Thanks in advance for your comments! ;-)
> >
> >
> https://www.juniper.net/documentation/en_US/junos14.2/topics/reference/configuration-statement/routing-edit-system-processes.html
> >
> >
> > Cheers,
> > Theo Voss
> > ___
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>



-- 
Tim Hoffman | Twitter, Inc.
1355 Market St. | San Francisco, CA | 94103
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] force-64bit

[Phil Rosenthal]

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 this a theoretical use case, or is there an actual need?

Best Regards,
-Phil Rosenthal
> On Jun 1, 2016, at 3:58 AM, Theo Voss  wrote:
> 
> Hi,
> 
> has anybody enabled „system processes force-64bit“ on 64bit Junos? Have you 
> done this during daily ops or during a maintenance window? According to 
> Juniper documentation [1] rpd must not be restarted to enable 64-bit mode: 
> „You need not restart the routing protocol process (rpd) to use the 64-bit 
> mode.“...
> 
> Thanks in advance for your comments! ;-)
> 
> https://www.juniper.net/documentation/en_US/junos14.2/topics/reference/configuration-statement/routing-edit-system-processes.html
> 
> 
> Cheers,
> Theo Voss
> ___
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

[j-nsp] force-64bit

[Theo Voss]

Hi,

has anybody enabled „system processes force-64bit“ on 64bit Junos? Have you 
done this during daily ops or during a maintenance window? According to Juniper 
documentation [1] rpd must not be restarted to enable 64-bit mode: „You need 
not restart the routing protocol process (rpd) to use the 64-bit mode.“...

Thanks in advance for your comments! ;-)

https://www.juniper.net/documentation/en_US/junos14.2/topics/reference/configuration-statement/routing-edit-system-processes.html


Cheers,
Theo Voss
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp