Re: [j-nsp] force-64bit
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
> 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
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
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
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
❦ 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
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
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
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
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
> 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
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
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
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