

More than ten years ago, researchers at Google published a paper with the seemingly heretical title “More Bandwidth Doesn’t Matter (much)”. We published our own blog showing it is faster to fly 1TB of data from San Francisco to London than it is to upload it on a 100 Mbps connection. Unfortunately, things haven’t changed much. When you make purchasing decisions about home Internet plans, you probably consider the bandwidth of the connection when evaluating Internet performance. More bandwidth is faster speed, or so the marketing goes. In this post, we’ll use real-world data to show both bandwidth and – spoiler alert! – latency impact the speed of an Internet connection. By the end, we think you’ll understand why Cloudflare is so laser focused on reducing latency everywhere we can find it.
First, we should quickly define bandwidth and latency. Bandwidth is the amount of data that can be transmitted at any single time. It’s the maximum throughput, or capacity, of the communications link between two servers that want to exchange data. Usually, the bottleneck – the place in the network where the connection is constrained by the amount of bandwidth available – is in the “last mile”, either the Continue reading
One of my readers sent me this question:
In your observations on IPv6 assignments, what are common point-to-point IPv6 interfaces on routers? I know it always depends, but I’m hearing /64, /112, /126 and these opinions are causing some passionate debate.
(Checks the calendar) It’s 2023, IPv6 RFC has been published almost 25 years ago, and there are still people debating this stuff and confusing those who want to deploy IPv6? No wonder we’re not getting it deployed in enterprise networks ;)
One of my readers sent me this question:
In your observations on IPv6 assignments, what are common point-to-point IPv6 interfaces on routers? I know it always depends, but I’m hearing /64, /112, /126 and these opinions are causing some passionate debate.
(Checks the calendar) It’s 2023, IPv6 RFC has been published almost 25 years ago, and there are still people debating this stuff and confusing those who want to deploy IPv6? No wonder we’re not getting it deployed in enterprise networks ;)
Sometimes you want to see functions of a library, as they’re called. I know of two ways of doing this.
Let’s have a super simple test program:
#include<iostream>
#include<unistd.h>
void func1() {}
void func2() {}
int main()
{
std::cout << "Hello world\n";
func1();
func2();
func1();
// Wait a bit for bpftrace to be able to aquire the function name.
// Not applicable for something that doesn't exist.
sleep(1);
}
Start a bpftrace in one terminal, and run the program in another.
$ sudo bpftrace -e 'uprobe:./a.out:func* { print(func); }'
Attaching 2 probes...
func1()
func2()
func1()
$ gdb a.out
[…]
(gdb) rbreak func.*
[…]
(gdb) commands
Type commands for breakpoint(s) 1-3, one per line.
End with a line saying just "end".
>silent
>bt 1
>cont
>end
(gdb) r
Starting program: […]/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
#0 0x0000555555555215 in _GLOBAL__sub_I__Z5func1v ()
Hello world
#0 0x000055555555516d in func1() ()
#0 0x0000555555555174 in func2() ()
#0 0x000055555555516d in func1() ()
[Inferior 1 (process 424744) exited normally]
(gdb)
bpftrace is lower (but Continue reading
This week's Network Break discusses NetBox Labs's $20 million funding round and why it spun itself out of NS1's IBM acquisition, Intel Foundry and Arm teaming up on SoC manufacturing, why Amazon sees headwinds for public cloud spending (and why the opportunity is still huge), how the juice-jacking threat got hyped, and more tech news.
The post Network Break 426: NetBox Labs Raises $20 Million; Intel Foundry, Arm Team Up To Make SoCs appeared first on Packet Pushers.
I already mentioned the introduction of VRF- and VLAN access links in netlab release 1.5.1. Let’s see how they can simplify your lab topologies.
I always tried to make lab topologies as concise as I could, sometimes cheating using JSON-in-YAML syntax. For example, the topology describing three routers running OSPF could be as simple as this:
module: [ ospf ]
nodes: [ r1, r2, r3 ]
links: [ r1-r2, r2-r3, r3-r1 ]
Let’s unravel that:
I already mentioned the introduction of VRF- and VLAN access links in netlab release 1.5.1. Let’s see how they can simplify your lab topologies.
I always tried to make lab topologies as concise as I could, sometimes cheating using JSON-in-YAML syntax. For example, the topology describing three routers running OSPF could be as simple as this:
module: [ ospf ]
nodes: [ r1, r2, r3 ]
links: [ r1-r2, r2-r3, r3-r1 ]
Let’s unravel that:
The BGP RFCs state that external BGP peers should insert their own AS into the AS PATH advertised to eBGP peers. Some peers strip their AS, generally for commercial gain. Juniper and Cisco have opposite default behaviors for handling this. Make sure you set bgp enforce-first-as on Juniper routers. Caveats apply.
A few years ago I was looking at some traffic reporting anomalies. My IPFIX data said that traffic with next-hop AS <dodgy-AS> was around 3Gb. But my SNMP data showed that a PNI to that peer was doing 8-10Gb.
I first doubted my router, because I had issues with IPFIX in the past on that specific platform. I also wondered about sampling rates. I have high flow rates, and need to set the sampling to be more coarse. But it was a big anomaly.
Slicing & dicing the data different ways, and chatting to colleagues about it, we saw what was going on. IPFIX showed the right volumes when reporting on destination interface. But some prefixes received from the peer did not contain the peer’s AS. We still accepted them.
Huh? Isn’t it normal behavior, to insert your own AS into any prefixes you advertise to Continue reading
I mentioned in my last post that I would start updating practical use cases for generative AI. The first example use case is your project documentation. As software engineers, we spend days of our lives writing project docs. The reality is that people learn and consume data differently. Overly detailed docs may cause some people’s eyes to glaze over while ...
The post ChatGPT your Project Docs appeared first on NetworkStatic | Brent Salisbury's Blog.
I’ve been getting into RISC-V optimization recently. Partly because I got my SiFive VisionFive 2, and partly because unlike x86 the number of RISC-V instructions is so managable that I may actually have a chance at beating the compiler.
I’m optimizing the inner loops of GNURadio, or in other words the volk library. I’ve been getting up to a about a doubling of the speed compared to the compiled C code, depending on the function.
But it got me thinking how far I could tweak the compiler and its options, too.
Yes, I should have done this much sooner.
Many years ago now I built some data processing thing in C++, and thought it ran too slowly. Sure, I did a debug build, but how much slower could that be? Half speed? Nope. 20x slower.
Of course this time I never compared to a debug build, so don’t expect that kind of difference. Don’t expect that it’ll reach my hand optimized assembly either, imperfect as it may be.
This may look like a synthetic benchmark, in simplified C++:
complex volk_32fc_x2_dot_prod_32fc_generic(const vector<complex> &in1,
const vector<complex> &in2)
{
complex res;
for (unsigned int i = 0; i Continue reading