Checking in...

[sfx2000]

Sorry for being a bit quiet over the last few weeks... has nothing to do with the community here - I'm staying in touch with several key forum members.

First off - I'm ok, everything is fine with health, family, job...

Speaking of jobs - that's what is keeping me really, really busy these days - and it's a good kind of busy. It brings together over 30 years of experience in engineering, wireless, and telecommunications - along with a couple of stints as a solo player building my own businesses...

It's a startup - but a very well funded international startup - and we're doing very cool things - closer to the bleeding edge than I've been in some time.

It's a tingly kind of fun - feels good to be back in the game and do something that one feels passionate about.

 

[System Error Message]

i've been busy too, starting some startups, however i am working on multi processor routers

 

[sfx2000]

i've been busy too, starting some startups, however i am working on multi processor routers

Nice - interesting field these days - esp with SDN/NFV - OpenStack is one realization there - if not absolute, they at least define some functional blocks to work with.

I've gone down the path of AI/Cloud/Robotics as my 5G play... I'm working on the comms stuff as part of that.

 

[sfx2000]

i've been busy too, starting some startups, however i am working on multi processor routers

I had to let go of my science project - it's shipping actually, white box stuff in Asia after I sold it off to them. Get a nice royalty check every month which is nice.

 

[System Error Message]

I had to let go of my science project - it's shipping actually, white box stuff in Asia after I sold it off to them. Get a nice royalty check every month which is nice.

You're always welcome to join my science project instead. Not much i will leak here but i havent gotten any responses from AMD semi custom

 

[sfx2000]

You're always welcome to join my science project instead. Not much i will leak here but i havent gotten any responses from AMD semi custom

Try not to make your stuff platform dependent - SDWAN is something that can run on an appliance, or should be able to be spun up as a VM or container in the cloud.

That was the real secret sauce to cafeole - HW was an enabler, but the base OS and the containers, along with the cloud management platform (and container registry) is what sold the platform...

ARM support that was the real challenge (and we did four different chips) - doing the same over amd64 would be much easier - even on real AMD hardware (or Intel for that matter).

 

[System Error Message]

Try not to make your stuff platform dependent - SDWAN is something that can run on an appliance, or should be able to be spun up as a VM or container in the cloud.

That was the real secret sauce to cafeole - HW was an enabler, but the base OS and the containers, along with the cloud management platform (and container registry) is what sold the platform...

ARM support that was the real challenge (and we did four different chips) - doing the same over amd64 would be much easier - even on real AMD hardware (or Intel for that matter).

i wanted an epyc with 2 ryzen cpus and 2 radeons, 8 memory channels, NICs connected to infinity fabric and some PCIe, not to mention the southbridge would be good for other features too from m.2, usb3, sata and more stuff.

 

[sfx2000]

i wanted an epyc with 2 ryzen cpus and 2 radeons, 8 memory channels, NICs connected to infinity fabric and some PCIe, not to mention the southbridge would be good for other features too from m.2, usb3, sata and more stuff.

With 2 socket Xeon E5's, we're doing 100GB routed performance with SDWAN and/or MPLS with SSL security - Coleto Creek for SSL offload, but rest is all SW (linux). With SW routing, clock speed is the key driver...

The little box - Denverton based - can do the 1GB easily with the same SW stack.

Fun stuff... having access to those kind of pipes brings a whole new perspective to things - I've done 10GB and 40GB in the past

 

[System Error Message]

With 2 socket Xeon E5's, we're doing 100GB routed performance with SDWAN and/or MPLS with SSL security - Coleto Creek for SSL offload, but rest is all SW (linux). With SW routing, clock speed is the key driver...

The little box - Denverton based - can do the 1GB easily with the same SW stack.

Fun stuff... having access to those kind of pipes brings a whole new perspective to things - I've done 10GB and 40GB in the past

I know but 100GB routing performance was achieved using 2 GTX 480s long in the past, so imagine how much more routing performance you can get using a GPU now with the right NIC. Infinity fabric is flexible in that it doesnt just have to be a CPU on it, so for a router having the NICs on it to talk to the processors and memory directly rather than via PCIe is a huge reduction in latency for improved performance gains. While infinity fabric isnt the best for gaming it certainly does well for this sort of stuff.

Its not only routing performance, theres NAT, BGP, VPN and PPP performance to worry about too coupled with filter performance (some countries will require filtering to ensure any court ruling required for implementation can be implemented like blocking a website for instance). So if you couple all this together, will those 2 socket xeons maintain such speeds?

Many x86 CPUs have hardware encryption but GPUs will still outperform CPUs in this.

 

[sfx2000]

Its not only routing performance, theres NAT, BGP, VPN and PPP performance to worry about too coupled with filter performance (some countries will require filtering to ensure any court ruling required for implementation can be implemented like blocking a website for instance). So if you couple all this together, will those 2 socket xeons maintain such speeds?

Yes... Quick Assist isn't the only trick, but it helps out quite a bit with the offload... QAT was off-CPU up until recently with some of the Xeon's and the supporting chipsets. The Denverton appliances are fun, as they're essentially Intel small cores (Goldmont). The previous gen Rangley's are essentially the same as Netgate's SG-2440 line, and they're good for most small business and home connections - the stack compared to pfSense - similar in many respects, we get full QAT support, not sure if/when pfSense will decide to implement - I've heard that Rangeley might be out of scope, as it's QAT 1.5, whereas Coleto Creek and the Xeon implementation are QAT 1.6, if I recall correctly.

The AMD stuff is interesting, and it's done some interesting stuff in the lab - but since we're a tight intel shop for production, it's going to take time for anything AMD to get into the product line card for a routing application - we're looking at them actually for other things.

Fun thing - like others - we are looking at an ARM based solution - guess what chip vendors - hint, it's wide and fast, and it's not Marvell or AMCC - Broadcom's Vulcan kinda died with the Avago deal...

 

[System Error Message]

Yes... Quick Assist isn't the only trick, but it helps out quite a bit with the offload... QAT was off-CPU up until recently with some of the Xeon's and the supporting chipsets. The Denverton appliances are fun, as they're essentially Intel small cores (Goldmont). The previous gen Rangley's are essentially the same as Netgate's SG-2440 line, and they're good for most small business and home connections - the stack compared to pfSense - similar in many respects, we get full QAT support, not sure if/when pfSense will decide to implement - I've heard that Rangeley might be out of scope, as it's QAT 1.5, whereas Coleto Creek and the Xeon implementation are QAT 1.6, if I recall correctly.

The AMD stuff is interesting, and it's done some interesting stuff in the lab - but since we're a tight intel shop for production, it's going to take time for anything AMD to get into the product line card for a routing application - we're looking at them actually for other things.

Fun thing - like others - we are looking at an ARM based solution - guess what chip vendors - hint, it's wide and fast, and it's not Marvell or AMCC - Broadcom's Vulcan kinda died with the Avago deal...

Would be better with the dual socket 32 core epyc with 8 ram channels per socket and loads of PCIe lanes while being cheaper

Im guessing you're using either qualcomm or one of the chinese chips.

 

[sfx2000]

Many x86 CPUs have hardware encryption but GPUs will still outperform CPUs in this.

For routing accel - GPU's _can_ do this, but they're costly in power and heat - GPU's like nVidia and AMD have another place in the stack for ML/AI type of functions, which they're very effective at. The Xeon Phi stuff is similar in X86 with some of the more esoteric AVX512 stuff - that's another group - some of the newer Xeon's have similar support - AVX512 has different flavors of support across intel's product line.

The "many x86 CPU's" - mostly AES-NI and the SSE extensions along with some AVX - some intel chips have very specific things for SSL beyond that, see above with QAT.

 

[System Error Message]

For routing accel - GPU's _can_ do this, but they're costly in power and heat - GPU's like nVidia and AMD have another place in the stack for ML/AI type of functions, which they're very effective at. The Xeon Phi stuff is similar in X86 with some of the more esoteric AVX512 stuff - that's another group - some of the newer Xeon's have similar support - AVX512 has different flavors of support across intel's product line.

The "many x86 CPU's" - mostly AES-NI and the SSE extensions along with some AVX - some intel chips have very specific things for SSL beyond that, see above with QAT.

but the 16 ddr4 ram channels and 128 PCIe lanes with a total of 64 cores at 4Ghz, cant deny that would beat the intel xeon line even without using hardware acceleration for routing.

 

[sfx2000]

Im guessing you're using either qualcomm or one of the chinese chips.

Not Qualcomm - not HiSilicon (Huawei) - it's up in the valley however... it's a startup...

That being said - QCOM's Centriq and HiSilicon - they're also very effective.

 

[sfx2000]

but the 16 ddr4 ram channels and 128 PCIe lanes with a total of 64 cores at 4Ghz, cant deny that would beat the intel xeon line even without using hardware acceleration for routing.

It's how the cores communicate - AMD has done a great leap with Epyc - but that brings them to parity with Intel - and Intel stuff still is faster in certain tasks, mainly with how the cores work together...

AMD's next gen Xen cores likely will address some of those shortcomings...

Clock speed helps with SW routing - that's a given when dealing with packets per second - there's other bottlenecks - and Intel has more time and development there.