Re: [j-nsp] force-64bit

2016-06-02 Thread Chris Adams 
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 
> bottleneck makes it less obvious that the same code will run faster when 
> compiled as 64bit. 

That's the eternal argument around larger address space.  But the
previous post was right; the 32-bit x86 architecture is pretty severely
register limited, and the 64-bit x86_64 extentsions helped with that a
lot.  Lots of things that had to go to RAM and back in 32-bit code can
now be passed in registers, which saves a lot of overhead (this is shown
in lots of places).

In architectures without the limited register set, moving from 32 to 64
bit was not as clear cut, but x86 to x86_64 is a big improvement.

Also, you'd only see double the RAM usage if every single thing stored
was a pointer (and no actual data was stored somehow).  Since that's
obviously not the case, RAM usage would be nowhere near double.

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

Re: [j-nsp] force-64bit

2016-06-02 Thread Jesper Skriver 

> 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 apply to rpd.

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 
bottleneck makes it less obvious that the same code will run faster when 
compiled as 64bit. 

/Jesper


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

Re: [j-nsp] force-64bit

2016-06-02 Thread raf 



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




The famous commit roulette :)
It was a good addition if juniper can provide a way of seeing what will 
be impacted during a commit. (with a pub/sub model it should be trivial).


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

Re: [j-nsp] force-64bit

2016-06-01 Thread 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

2016-06-01 Thread 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

2016-06-01 Thread 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

2016-06-01 Thread 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 <p...@isprime.com>
Datum: Mittwoch, 1. Juni 2016 um 18:22
An: Theo Voss <m...@theo-voss.de>
Cc: "juniper-nsp@puck.nether.net" <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 <m...@theo-voss.de> 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

2016-06-01 Thread 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

2016-06-01 Thread 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

2016-06-01 Thread 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

2016-06-01 Thread 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

2016-06-01 Thread 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

2016-06-01 Thread 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

2016-06-01 Thread 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