re: Procket Gets Unstealthyandropat says: "and another thing.. embedded software in my opinion is much harder than a routing protocol."
IMO: Both are hard in a box of this size - different issues. Scaling, performance, stability and features are major issues for the protocols, while, for embedded work, keeping a large system working seamlessly as one and dealing with bezillion conditions in timely manner on a variety of pretty complex hardware (various blades) are the key issues.
re: Procket Gets Unstealthytmc1 says: "i am no expert on switch fabrics but i would say your understanding of switch fabrics is very wrong. i really doubt that juniper has a 4x speedup on the t-640 xbar. most speedup is in the 1.2x - 2x range as it is difficult, expensive and usually unnecessary to do more. read anything by nick mckeown from stanford to understand."
It was difficult back in 1989. Juniper started working on T640 around three/four years ago. A year ago, I derived my info from Juniper's docs about T640 Architecture. If any Juniper people are reading this, maybe they can confirm/deny that the T640 crossbar has a 4X speedup, meaning, each switching element in the crosbar can switch 40G. BTW, go read Nick's paper that "indianajones" referred us to - you will know what I am talking about.
tmc1 says: "secondly, oversubscribing an egress has NOTHING to do with non-blocking behaviour. non-blocking simply means that traffic sent across the fabric in a full mesh will pass at wire-rate without drops. every box ever created is blocking when you oversubscribe the egress. you just cannot get 11 Gig or more out a 10 gig interface... DUH!"
I was not referring to oversubscription, but "bursts" into the same egress port. That is why I said 30 uS (micro seconds). 30 uS @ 10 bits/nS (oc192 line rate) translates to 30*10**-6*10**9/8 ~37 KB burst. This is not much. It is entirely possible that certain number of ingress ports burst into the same egress port at the same time. This blocking will occur on the ingress port - meaning, some ports may see better performance than others. This leads to least common denominator "gaurantees", if at all, to all sources.
Anyways, this is not about Juniper or crossbar. Procket claims to have Shared Memory architecture. I believe the key to the performance of this box is the switching part - lots of companies have solved the NPU side of the story. More light on the switch is what I would like to see. So far, nothing is forthcoming.
re: Procket Gets Unstealthy"I agree that strenuous real-world testing is crucial, but if the software has actually been cooking for 2 years I would expect that it would be pretty solid - anyone one who has worked with it care to speak up?"
I don't have first-hand knowledge of the code. However, I will point out that the code was likely provided early on to potential customers on a PC to help test it. Usually this testing is done in the lab and very innocuous roles in the network (peering router). Since the PC is limited in available interfaces and performance the code really can not be deployed in a serious way until the hardware arrives. My guess is that the actual hardware platforms probably didn't hit customer sites until about six months ago. So there is really not much serious deployment experience of either the code or hardware.
SP's have differing rules for pre-deployment experience prior to their roll out of new stuff. If my assumptions are correct, I suspect that you will not see any major deployments in the next few months unless someone is desperate or likes living on the edge. Major outages caused by router/code failures brings a storm of PR to the SP; and none of it positive.
Procket will be quite busy over the remainder of 2003 trying to gain some momentum in the market. They also will be challenged to make every customer deployment successful and eliminate the skepticism inherent with new stuff.
re: Procket Gets UnstealthyArbitration and scheduling is a different issue. distributed/output scheduling can help.
however if speedup does not even help as nick says then why would anyone (Juniper) create an expensive 4x speedup fabric.
simpleton and indianajones, this would still be an order of magnitude higher than any other speedup out there. when you are talking about 320 Gbps on the T640 - it means you have to have a fabric that is doing 1.2 Terabits internally. The data path size and frequency are still extremely difficult and expensive at that amount of speedup with that throughput. i honestly don't believe that there is ANY production fabric with more than ~2x speedup.
show me, i am from missouri.
------------------------------------------------- He has written a paper in SIGCOMM2002, August which further re-emphasizes this point. In fact, in that paper he has come out and said that Virtual Output Queued architectures (even with switch speedup) cannot offer any predictability and no delay, bandwidth or loss guarantees can be made. I can send you a pointer to the link if you so wish.
My point was to refute your observation that speedup can solve issues in crossbar architectures. As Nick himself has admitted, real-systems behave very differently compared to theoretical results. I have no position on whether it is cheap or expensive to build a switch with 4x speedup. All I can say is that a 4x speedup would be better than a 2x speedup, though I agree with simpleton that if T-640 had only 2x speedup, its performance would be awful.
re: Procket Gets Unstealthy>Procket's NPU design seems to be capable of taking up >the gauntlet for such a task. Now if they can provide >channelized OC-3/OC-12 media adapters with T1/E1 >MLPPP, PPPMux, RFC2508/2509/3095/3241 support and >SONET/SDH APS at a reasonable price point, we would >love to buy 50+ boxes a year.
Thats the real question about procket. Is there NPU design capible of complex layer-2 functionality along with the layer-3 functionality? For example, can they do ethernet VLAN, accounting, queueing, ect just by reprogramming their NPU? Nobody knows. Nobody knows how many functions their NPUs can do at line rate. I would not invest in Procket products until I was confident I fully understood their "new services by just reprogramming the NPU" claims. It sounds real nice, but without hard data and proven examples... sounds risky to me.
re: Procket Gets UnstealthyI think that you are confusing the differentiation between L2 and L3. Procket obviously wanted to raise the bar for the current generation of Internet core routers by adding reliability and scalability. IMO this is what CSCO and JNPR should have been focusing on - if they had done what they had been claiming for years, there would have never been a market for Procket or any other HA startup in the core space.
I'm pretty sure that Procket doesn't want to make cheap L2 boxes to compete with F10, Extreme and Foundry. Nothing I have read so far regarding their hardware or software appears to be positioning for that. What remains to be seen is how much mileage their VLSI chipset gives them in terms of features and futures. Look at the slides on VLSI from this Japanese site (posted earlier about 2 months ago on LR): http://internet.watch.impress....
It shows that the PRO/Silicon chip set consists of 6 processors, ranging from 30.5 to 214 million transistors. The average count is ~121 million transistors. Another slide shows the Terabit Switch Engine and the Adaptive Packet Processor in relation to some competitive processors. Correct me if I am wrong, but isn't ~121 million transistors per processor enormous?
It certainly sounds like a lot of development time and effort went into this PRO/Silicon chipset; I would be suprised if they didn't take future requirements into account when they designed it. Then again, perhaps I'm just an optimist who would for once like to see a company do exactly what they have promised, without all of the excuses and delays.
re: Procket Gets UnstealthyIf you want your router to be an edge access device, which Procket claims, you need extensive L2 functionality... Cisco/Juniper usually does this in their line cards. Can Procket do it just in their NPU?
re: Procket Gets UnstealthySure you can create a burst onto one port for a non-blocking type test. A simple bernoulli distributed input traffic can create a significant burst if you run long enough. In fact that is the best test for true non-blocking behavior.
"and another thing.. embedded software in my opinion is much harder than a routing protocol."
IMO: Both are hard in a box of this size - different issues. Scaling, performance, stability and features are major issues for the protocols, while, for embedded work, keeping a large system working seamlessly as one and dealing with bezillion conditions in timely manner on a variety of pretty complex hardware (various blades) are the key issues.