Thanks to all who were able to join us for the IXIA Developer & Oracle Ravello Smart Lab DemoFriday. Read the read the full Q&A here.
The post Worth Reading: The geeks guide to the Barton Aquaduct appeared first on 'net work.
We at Cumulus Networks firmly believe that Linux networking is awesome, as it provides a high function, extensible platform for networking. Linux has always been the platform of choice for decades; every system today starts with Linux as its base and builds around it.
With the advent of the virtual machine and container networking, the constructs that used to be relegated to physical switches are applicable on servers, we thrive on the fact that Cumulus Linux networking IS Linux networking.
So, what does it take to bring that the greatest and latest in Linux to you? It takes two things really:
The kernel is the center of the Linux operating system. We work closely with the Linux kernel community to add new networking features or extend Linux networking APIs for NOSes. With Cumulus Linux 3.0, we started with Linux kernel version 4.1 and networking patches from even more recent kernels. This provides networking applications with the latest Linux APIs, Continue reading
And we could see even more SD-WAN entrants.
But cellular IoT connections are just a small portion of IoT end points.
Although the launch of Pascal stole headlines this year on the GPU computing front, the company’s Tesla K80 GPU, which was launched at the end of 2014, has been finding a home across a broader base of applications and forthcoming systems.
A quick look across the supercomputers on the Top 500 list shows that most sites are still using the Tesla K40 accelerator (launched in 2013) in their systems, with several still on the K20 (emerged in 2012). The Comet supercomputer at the San Diego Supercomputer Center (sports 2 K80s across 36 out of 1944 system nodes), an unnamed energy …
The Middle Ground for the Nvidia Tesla K80 GPU was written by Nicole Hemsoth at The Next Platform.
In last week’s post, we looked at how snaproute’s implementation of BGP in Go moves into trying to connect to a new peer—we chased down the connectRetryTimer to see what it does, but we didn’t fully work through what the code does when actually moving to connect. To jump back into the code, this is where we stopped—
func (st *ConnectState) processEvent(event BGPFSMEvent, data interface{}) {
switch event {
....
case BGPEventConnRetryTimerExp:
st.fsm.StopConnToPeer()
st.fsm.StartConnectRetryTimer()
st.fsm.InitiateConnToPeer()
....
When the connectRetryTimer timer expires, it is not only restarted, but a new connection to the peer is attempted through st.fsm.InitiateConnToPeer(). This, then, is the next stop on the road to figuring out how this implementation of BGP brings up a peer. Before we get there, though, there’s an oddity here that needs to be addressed. If you look through the BGP FSM code, you will only find this call to initiate a connection to a peer in a few places. There is this call, and then one other call, here—
func (st *ConnectState) enter() {
....
st.fsm.AcceptPeerConn()
st.fsm.InitiateConnToPeer()
}The rest of the instances of InitiateConnToPeer() are related to the definition of the function. Continue reading