I've been working on congestion control for a while, and one thing that has always bothered me is how traditional loss-based algorithms such as Reno and CUBIC treat packet loss as a congestion signal. There are also many delay-based approaches using RTT, but I wanted to try a different direction: combine loss and RTT into a single probabilistic signal that estimates how congested the network currently is, rather than treating congestion as a binary event.
To experiment with this idea, I built SCP, a reliable transport protocol over UDP, and designed a congestion-control algorithm called SCP-PROB.
SCP-PROB uses deviations in RTT and packet loss to compute a nonlinear congestion probability, then continuously adjusts its sending behavior based on that estimate.
In my experiments, it performs better than Linux CUBIC and other loss-based CCAs in high-random-loss environments, while multiple SCP-PROB flows also show good fairness with each other.
The implementation and experiments are still evolving, and there are several open problems—especially fairness against heterogeneous CCAs and how to attribute congestion to individual flows.
Everyone, eBPF is a revolutionary technology for the Linux kernel that makes the kernel both secure and programmable. I’ve been exploring how to bring similar capabilities to microcontrollers with only tens of kilobytes of memory, so I created ccBPF. It is a programming language based on a C-like subset and includes a BPF virtual machine. I have already developed several demonstrations running on both Linux and the STM32F103C8T6; if you are interested, please feel free to give it a try!
Just checking — is Prometheus/Grafana basically the frontend here? I see everything exposed at /actuator/prometheus, but there doesn’t seem to be a built‑in UI. Do you think something like Zabbix support would be possible?
I’m building ccbpf to bring eBPF‑style programmability to embedded systems.
ccbpf includes:
- a C‑subset compiler (ccbpf‑cc) that generates ccbpf bytecode
- a small, portable VM for MCUs
- a simple map system and hook/event model
- a loadable program format designed for constrained devices
The goal is to let MCUs load and run small, safe, sandboxed programs—similar in spirit to eBPF, but built specifically for embedded environments.
I built a small real‑time operating system for ARM Cortex‑M as a step‑by‑step guide to teach how an RTOS is built from scratch.
The kernel starts from a few hundred lines and grows through context switching, scheduling, interrupts, and simple IPC — all explained in a minimal, readable way.
If you want a practical, tiny example that shows exactly how to write an operating system for microcontrollers, this project is designed for that.
I’ve been building a small, modular Real-Time Operating System (RTOS) for ARM Cortex‑M, focusing on clarity, portability, and hackability.
It started as an experiment to see how small an RTOS kernel could be — the first version was about 400 lines, implementing memory management and a simple multithreaded scheduler. I later expanded it into a complete, readable system and wrote an English tutorial series along the way.
The project includes tutorials covering:
• memory management
• ARM exception model
• context switching
• scheduler design
• IPC and synchronization
Everything is implemented from scratch with readability in mind, and each subsystem is explained step by step.
I've been working on congestion control for a while, and one thing that has always bothered me is how traditional loss-based algorithms such as Reno and CUBIC treat packet loss as a congestion signal. There are also many delay-based approaches using RTT, but I wanted to try a different direction: combine loss and RTT into a single probabilistic signal that estimates how congested the network currently is, rather than treating congestion as a binary event.
To experiment with this idea, I built SCP, a reliable transport protocol over UDP, and designed a congestion-control algorithm called SCP-PROB.
SCP-PROB uses deviations in RTT and packet loss to compute a nonlinear congestion probability, then continuously adjusts its sending behavior based on that estimate.
In my experiments, it performs better than Linux CUBIC and other loss-based CCAs in high-random-loss environments, while multiple SCP-PROB flows also show good fairness with each other.
The implementation and experiments are still evolving, and there are several open problems—especially fairness against heterogeneous CCAs and how to attribute congestion to individual flows.
Here's the paper. Criticism is very welcome.