OT: Hurricane retweet-2-smtp.
Here would be a prime guess.. obviously anyone that can help, karma=good.. -jamie /// from @virtadpt -- > Need sources for Proxim point-to-point microwave hardware. Needed for uplink from mesh to global Net. PLS RT #sandy #nyc #projectbyzantium
Re: Whats so difficult about ISSU
> NANOG56? I only found RPKI Propagation by you. Direct URL would be > appreciated. apologies. i slid a second preso into my time allotment, and i thought the archive maintainer was going to catenate them. here is the second preso, some measurements of the tcp behavior of bgp. http://archive.psg.com/121022.nanog-bgp-tcp.pdf > But I really have 0 doubt that IOSd is run-to-completion nor i. but, as i said but did not write in my preso, consider the following: linux has become a fad in the vendor community. it seems to lend legitimacy to their products in some way, witness this discussion. but linux has the gpl poison. so, any code that they wish to keep proprietary is in userland. randy
Re: Whats so difficult about ISSU
> > as to whether ios/xe is rtc, you may want to see my preso at the last > > nanog. > > NANOG56? I only found RPKI Propagation by you. Direct URL would be > appreciated. Look towards the end of the presentation and you'll find run to completion... Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: Whats so difficult about ISSU
On 10/11/2012 16:48, Saku Ytti wrote: > If native process separation and even native thread separation cannot be > made scale (I'm highly suspicious why it couldn't). As the old joke goes, once you introduce threading to fix a problem, you end up with evmeonr eprboelm.s > Then I wonder why > vendors don't use some existing VM, instead of inventing their own. because of legacy issues. It's easier to rewrite from scratch than to adapt existing code. Nick
Re: Whats so difficult about ISSU
On (2012-11-11 00:14 +0900), Randy Bush wrote: > as to whether ios/xe is rtc, you may want to see my preso at the last > nanog. NANOG56? I only found RPKI Propagation by you. Direct URL would be appreciated. But I really have 0 doubt that IOSd is run-to-completion, exactly like RPD is. But IOSd indeed seems to have 3 OS threads, while RPD is single threaded. As I understand RPD does have green threads though, but that is not helping at all making things simple for JNPR, more if anything, it's making things more complex. If native process separation and even native thread separation cannot be made scale (I'm highly suspicious why it couldn't). Then I wonder why vendors don't use some existing VM, instead of inventing their own. Many existing are free and support green threads and native thread and many-to-many mapping between, so you could get benefit of minimal overhead of green thread and you get benefit of OS level threading (SMP, scheduling) to compartmentalize processes. -- ++ytti
Re: Whats so difficult about ISSU
as to whether ios/xe is rtc, you may want to see my preso at the last nanog. randy
Re: Whats so difficult about ISSU
On (2012-11-10 10:43 +0200), Saku Ytti wrote: > > > So each IOSd process 'show proc cpu' are separate threads to linux? > > Yep. The "show platform software..." commands are used to look at things in > > To be honest I'm very sceptical about this. I fully accept that IOSd is > multithreaded. But I'm having difficulties accepting that each IOSd process > would be own thread scheduled by Linux and that native/IOS > run-to-completion scheduler isn't used at all. Someone who has ASR1004 just ran 'ps auxH' and it's running 3 threads. So IOS XE control-plane is for most parts run-to-completion and relies on classic IOS scheduler and memory-management. I'm not saying this is inherently bad, it is least overhead way to do it, but it also sets requirement for code quality unrealistically high. I'm pretty sure it would be easier to start from scratch and loan IOS BGP, ISIS, OSPF etc code to new project than to try to make IOS be pre-emptive and SMP safe. I'm also not saying IOS XE is bad, JunOS is same design and many consider JunOS good design (I'm not one of them). I think XR and NX-OS are better, more modern examples how to do things now, when we have some extra CPU time in control-plane. It would be interesting ti know what are the roles of these 3 threads. If I'd have to guess, one is IOS control-plane, one is emulation of IOS interrupts and one is abstraction for hardware forwarding. But this is likely far off. -- ++ytti
Re: Whats so difficult about ISSU
On (2012-11-09 20:24 -0500), Pete Lumbis wrote: > > So each IOSd process 'show proc cpu' are separate threads to linux? > Yep. The "show platform software..." commands are used to look at things in To be honest I'm very sceptical about this. I fully accept that IOSd is multithreaded. But I'm having difficulties accepting that each IOSd process would be own thread scheduled by Linux and that native/IOS run-to-completion scheduler isn't used at all. But we're out of scope for ISSU thread in nanog-ml, I think. I do appreciate always when vendors pitch in in public forums, so thank you for that Pete. -- ++ytti
