Here it is, complete with OC-768 interface: http://www.cisco.com/en/US/products/ps5763/index.html
I don't think Reuters was impressed: From http://news.yahoo.com/news?tmpl=story&u=/nm/20040525/tc_nm/tech_cisco_router_dc_2 ] Routers, which look like pizza boxes piled atop each other, are one of ] the most boring pieces of equipment to look at, but probably the most ] crucial as they are used to direct information and data on a network. -- 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
Leo Bicknell wrote:
I don't think Reuters was impressed:
From http://news.yahoo.com/news?tmpl=story&u=/nm/20040525/tc_nm/tech_cisco_router_dc_2
] Routers, which look like pizza boxes piled atop each other, are one of ] the most boring pieces of equipment to look at, but probably the most ] crucial as they are used to direct information and data on a network.
You can't go past the on/off switches on our Prockets. No boring switch gear there :-) Mark.
Eric Kuhnke wrote:
Here it is, complete with OC-768 interface:
In the old days, every major provider would already be talking about how they have ordered 200 of these for every major market for redundant deployment -- and are just waiting on Cisco to deliver them the gear. Ahhh... nostalgia. DJ
In message <40B408C8.8010000@ai.net>, Deepak Jain writes:
Eric Kuhnke wrote:
Here it is, complete with OC-768 interface:
In the old days, every major provider would already be talking about how they have ordered 200 of these for every major market for redundant deployment -- and are just waiting on Cisco to deliver them the gear.
Personally, I'm at least as intrigued by the IOS replacement as by the high-speed hardware -- when will that percolate to the rest of the product line? As with any major new software product, it will probably be less reliable at first, but -- given the design goals -- quite likely much more reliable in the not tremendously distant future. --Steve Bellovin, http://www.research.att.com/~smb
On Wed, May 26, 2004 at 07:56:57AM -0400, Steven M. Bellovin wrote:
In message <40B408C8.8010000@ai.net>, Deepak Jain writes:
Eric Kuhnke wrote:
Here it is, complete with OC-768 interface:
In the old days, every major provider would already be talking about how they have ordered 200 of these for every major market for redundant deployment -- and are just waiting on Cisco to deliver them the gear.
Personally, I'm at least as intrigued by the IOS replacement as by the high-speed hardware -- when will that percolate to the rest of the product line? As with any major new software product, it will probably be less reliable at first, but -- given the design goals -- quite likely much more reliable in the not tremendously distant future.
There have long been rumors (and even different groups) that have worked on a IOS replacement, or modular IOS. The rumors i've heard are along the lines of this is mostly different software for this product line. Personally I think we're still a few generations away from having good route processors in all the new routers these days.. they seem to still not put enough power in them to handle the needs of some people (be it I/O performance of flash/disk, performance of traffic directed at the route processor, or ability to utilize the existing physical memory more efficently.. ie: no more fragmentation). - Jared - jared - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
On 26-mei-04, at 16:38, Jared Mauch wrote:
ability to utilize the existing physical memory more efficently.. ie: no more fragmentation).
- Jared
- jared
- jared
Be careful what you wish for, Jared Jared Jared. I don't think the performance hit those already underpowered CPUs are going to take by adopting virtual memory is going to help matters much. Palm has taken an interesting approach to get rid of fragmentation: the OS is allowed to move (some) structures from one physical memory location to another. This only works if the processes that use this memory are written to support this, of course. (BTW, you'll experience very little fragmentation if you make sure your box never comes close to running out of memory.)
On Wed, May 26, 2004, Iljitsch van Beijnum wrote:
Palm has taken an interesting approach to get rid of fragmentation: the OS is allowed to move (some) structures from one physical memory location to another. This only works if the processes that use this memory are written to support this, of course.
Its not a new technique - if you allocate memory "handlers" rather than addresses and ask the OS/Memorymanager to lock a handler in memory (and give you an address) then the OS/MM is able to move around unlocked memory blocks, even on/off disk, at whim. Win16 memory allocation looked like this, and I'm sure it was lifted from something even older. Its not actually a bad idea in a single-process standalone application. It certainly beats using a VM in this instance. Anyway, back to the network topics. Adrian -- Adrian Chadd I'm only a fanboy if <adrian@creative.net.au> I emailed Wesley Crusher.
I saw such technique in 1986 (approx) year on hardware level - russia computer Elbrus did it. : Re: Cisco HFR
On Wed, May 26, 2004, Iljitsch van Beijnum wrote:
Palm has taken an interesting approach to get rid of fragmentation: the OS is allowed to move (some) structures from one physical memory location to another. This only works if the processes that use this memory are written to support this, of course.
Its not a new technique - if you allocate memory "handlers" rather than addresses and ask the OS/Memorymanager to lock a handler in memory (and give you an address) then the OS/MM is able to move around unlocked memory blocks, even on/off disk, at whim.
Win16 memory allocation looked like this, and I'm sure it was lifted from something even older.
Its not actually a bad idea in a single-process standalone application. It certainly beats using a VM in this instance.
Anyway, back to the network topics.
Adrian
-- Adrian Chadd I'm only a fanboy if <adrian@creative.net.au> I emailed Wesley Crusher.
Macs and Lisas did this as well. ---Rob "Alexei Roudnev" <alex@relcom.net> writes:
I saw such technique in 1986 (approx) year on hardware level - russia computer Elbrus did it.
: Re: Cisco HFR
On Wed, May 26, 2004, Iljitsch van Beijnum wrote:
Palm has taken an interesting approach to get rid of fragmentation: the OS is allowed to move (some) structures from one physical memory location to another. This only works if the processes that use this memory are written to support this, of course.
Its not a new technique - if you allocate memory "handlers" rather than addresses and ask the OS/Memorymanager to lock a handler in memory (and give you an address) then the OS/MM is able to move around unlocked memory blocks, even on/off disk, at whim.
Win16 memory allocation looked like this, and I'm sure it was lifted from something even older.
Its not actually a bad idea in a single-process standalone application. It certainly beats using a VM in this instance.
Anyway, back to the network topics.
Adrian
-- Adrian Chadd I'm only a fanboy if <adrian@creative.net.au> I emailed Wesley Crusher.
Iljitsch van Beijnum wrote:
(BTW, you'll experience very little fragmentation if you make sure your box never comes close to running out of memory.)
Reminds me of the fact that you need very little of "QoS" support if you make sure your links never come close to running full. Amazingly that´s still a very popular feature to ask for. Pete
On 26-mei-04, at 18:45, Petri Helenius wrote:
(BTW, you'll experience very little fragmentation if you make sure your box never comes close to running out of memory.)
Reminds me of the fact that you need very little of "QoS" support if you make sure your links never come close to running full. Amazingly that´s still a very popular feature to ask for.
Well, if you can survive periods where memory requirements go beyond 100% of what's available without adverse effects anyway, why would fragmentation be a problem for you? Or maybe it's not really the same thing...
Jared Mauch wrote:
traffic directed at the route processor, or ability to utilize the existing physical memory more efficently.. ie: no more fragmentation).
Haven´t almost all if not all IOS boxen for quite a while shipped with CPU´s which have integrated memory management so memory "fragmentation" is only an allocation strategy / page management issue with four kilobyte pieces. Completely another issue is if there is anyone who dares to touch the memory management code. Pete
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
In the old days, every major provider would already be talking about how they have ordered 200 of these for every major market for redundant deployment -- and are just waiting on Cisco to deliver them the gear.
Personally, I'm at least as intrigued by the IOS replacement as by the high-speed hardware -- when will that percolate to the rest of the product line? As with any major new software product, it will probably be less reliable at first, but -- given the design goals -- quite likely much more reliable in the not tremendously distant future.
Agreed. I am surprised that noone else have brought that up. I understand that the software is built in a way that might not make sense to port to all Cisco platforms, but it would be nice to have on at least the GSRs. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQLTaVqarNKXTPFCVEQInBgCg9b5JTL6uLlYbk3roOixLk6eI3FQAn2pW 7H3YMGyeIqeZz0b55P2T/8v0 =ogBj -----END PGP SIGNATURE-----
Agreed. I am surprised that noone else have brought that up. I understand that the software is built in a way that might not make sense to port to all Cisco platforms, but it would be nice to have on at least the GSRs.
I've heard the rumor that that would be the first port that they would undertake, and that would make some sense. However, I hope that they focus their efforts on stabilizing first and porting second. No point in porting what isn't stable. Tony
Tony Li wrote:
I've heard the rumor that that would be the first port that they would undertake, and that would make some sense. However, I hope that they focus their efforts on stabilizing first and porting second. No point in porting what isn't stable.
I thought the main reason for "in service upgrades" was to allow daily updates to the code instead of the now popular bi-weekly ones. :-) Pete
On 27-mei-04, at 10:19, Petri Helenius wrote:
I thought the main reason for "in service upgrades" was to allow daily updates to the code instead of the now popular bi-weekly ones. :-)
Now if only they can figure out how to get in the bug fixes every night but limit the introduction of new bugs to once every two weeks, we have a winner...
I've heard the rumor that that would be the first port that they would undertake, and that would make some sense. However, I hope that they focus their efforts on stabilizing first and porting second. No point in porting what isn't stable.
I thought the main reason for "in service upgrades" was to allow daily updates to the code instead of the now popular bi-weekly ones. :-)
Oh my god. I am picturing CSR-1 "Auto Update" (ala Windows Update). I think I haven't been this scared in a month. Deepak
Eric Kuhnke wrote:
Here it is, complete with OC-768 interface:
Today's Financial Times in the UK carried a mutli-page (1/3rd or so of each broadsheet page) series of ads for this platform. Ergh, the worst fluffy "now you can do this" marketing I have seen in quite a while. When will they learn that "bigger, faster, harder" is difficult to PR... Peter
Well I for one am happy to see some new things coming into our industry even if it is just another big router. The 40G capability here will be of benefit to a lot of operators in resolving capacity issues, seeing the obvious investment that Cisco have made in this platform is very postive. I expect this 40G capability is the tip of the iceberg with much more to come. Its great to see Cisco being positive about their own achievements rather than print stupid cartoons about their competitors and customers. Regards, Neil.
participants (15)
-
Adrian Chadd -
Alexei Roudnev -
Deepak Jain -
Eric Kuhnke -
Iljitsch van Beijnum -
Jared Mauch -
Kurt Erik Lindqvist -
Leo Bicknell -
Mark Prior -
Neil J. McRae -
Peter Galbavy -
Petri Helenius -
Robert E. Seastrom -
Steven M. Bellovin -
Tony Li