nanog mailing list archives
Re: [ppml] too many variables
From: "vijay gill" <vgill () vijaygill com>
Date: Fri, 10 Aug 2007 11:33:34 -0700
On 8/10/07, Leo Bicknell <bicknell () ufp org> wrote:
In a message written on Fri, Aug 10, 2007 at 11:08:26AM -0700, vijay gill wrote:substantially behind moores observation to be economically viable. I have some small number of route processors in my network and it is a major hassle to get even those few upgraded. In other words, if you have a network that you can upgrade the RPs on every 18 months, letme You're mixing problems. Even though you may only be able to put in a new route processor every 3-5 years doesn't mean the vendor shouldn't have a faster version every 18 months, or even sooner. It's the addition of the two that's the problem. You're 5 year cycle may come a year before the vendors 5 year cycle, putting you on 9 year old gear before you refresh next.
The vendor has to qualify, write code for, and support n versions. This IS a part of the problem. Just blindly swapping out CPUs is non trivial, as any systems engineer can tell you. The support cost will be passed on to the consumer. /vijay Vendor J got it half right. The RP is a separately replaceable
component based on a commodity motherboard, hooked in with commodity ethernet, using the most popular CPU and ram on the market. And yes, I understand needing to pay extra for the sheet metal, cooling calculations, and other items. But, they still cost 10x a PC based on the same components, and are upgraded perhaps every 3 years, at best. They don't even take advantage of perhaps going from a 2.0Ghz processor to a 2.4, using the same motherboard, RAM, disk, etc. But I think the point still stands, I bet Vendor J in particular could pop out a Core 2 Duo based RP with 8 gig of ram and a 300+ gig hard drive in under 6 months while holding the price point if BGP convergence demanded it, and their customers made it a priority. To Bill's original e-mail. Can we count on 2x every 18 months going forward? No. But betting on 2x every 24 months, and accounting for the delta between currently shipping and currently available hardware seems completely reasonable when assessing the real problem. -- Leo Bicknell - bicknell () ufp org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request () tmbg org, www.tmbg.org _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (PPML () arin net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info () arin net if you experience any issues.
Current thread:
- Re: too many variables, (continued)
- Re: too many variables Lucy Lynch (Aug 09)
- Message not available
- Re: too many variables Patrick Giagnocavo (Aug 09)
- Re: too many variables bmanning (Aug 09)
- Re: too many variables bmanning (Aug 09)
- Re: too many variables Wayne E. Bouchard (Aug 09)
- RE: too many variables Lincoln Dale (Aug 09)
- Re: too many variables Joel Jaeggli (Aug 09)
- Re: [ppml] too many variables Leo Bicknell (Aug 10)
- Message not available
- Re: [ppml] too many variables vijay gill (Aug 10)
- Re: [ppml] too many variables Leo Bicknell (Aug 10)
- Re: [ppml] too many variables vijay gill (Aug 10)
- Re: [ppml] too many variables Eliot Lear (Aug 13)
- Re: [ppml] too many variables Leo Bicknell (Aug 13)
- Re: [ppml] too many variables Eliot Lear (Aug 13)
- Re: [ppml] too many variables Cat Okita (Aug 13)
- Re: [ppml] too many variables Barry Shein (Aug 15)
- Re: [ppml] too many variables Scott Whyte (Aug 13)
- Re: [ppml] too many variables Leo Bicknell (Aug 14)
- Re: [ppml] too many variables Adrian Chadd (Aug 14)
- Re: [ppml] too many variables sthaug (Aug 14)
- Message not available
- Re: [ppml] too many variables Bruce M Simpson (Aug 24)