Project Description
There are multiple network benchmark tools already, most popular probably being netperf and iperf. Each of them has its pros and cons but the biggest drawback probably is that netperf runs only one connection (flow) and while iperf can use multiple connections, it still runs in a single thread. For benchmarking of contemporary fast networks like 40Gb/s or 100Gb/s ethernet, this can be a severe limitation as the performance is often CPU bound. Even on 10Gb/s ethernet, we are often unable to saturate the medium if tunneling or complex packet processing is involved.
Out of the two, only netperf seems to have public development and rewriting an application which was never intended to be multithreaded is hard and bug prone. Recently I also learned about uperf but it looks abandoned and feels rather complicated to use. So why not use the hackweek as an opportunity to see how hard is it to write a simple bencharking utility?
Goal for Hackweek 20
Essential features:
- implementation of a multithreaded client and server
- TCP throughput and latency tests (like netperf
TCP_STREAMandTCP_RR) - configurable basic parameters (message size, receive/send buffer size)
Nice to have features (if time allows, leave for later otherwise):
- statistical evaluation (like netperf
-iand-I) - flexible and future proof control protocol (netlink based?)
- optional output suitable for automated processing (XML / json?)
- more test modes (UDP, SCTP,
TCP_CRR,TCP_CC) - man page
- a package in OBS (compatible down to SLE11-SP4-LTSS)
End of Hackweek 20 status
Code available in github repository, tag hackweek20-end.
Done:
- multithreaded client (nperf) and server (nperfd) utility
TCP_STREAMandTCP_RRtests- configurable basic test parameters
- simple, per iteration, per thread and raw data output
- basic statistical processing (averages, mean deviation)
- help text (
nperf -h/nperfd -h)
ToDo:
- daemonized nperfd
- statistical evaluation (like netperf
-iand-I) - more test modes (UDP, SCTP,
TCP_CRR,TCP_CC) - flexible and future proof control protocol (netlink based?)
- optional output suitable for automated processing (XML / json?)
- man page
- a package in OBS (compatible down to SLE11-SP4-LTSS)
The utilities can be used for throughput and roundtrip time measurement but there is still work to be done before they are suitable for general use.
Resources
- netperf
- iperf
github repository - project code on Github
Looking for hackers with the skills:
This project is part of:
Hack Week 20
Activity
Comments
Be the first to comment!
Similar Projects
Add a machine-readable output to dmidecode by jdelvare
Description
There have been repeated requests for a machine-friendly dmidecode output over the last decade. During Hack Week 19, 5 years ago, I prepared the code to support alternative output formats, but didn't have the time to go further. Last year, Jiri Hnidek from Red Hat Linux posted a proof-of-concept implementation to add JSON output support. This is a fairly large pull request which needs to be carefully reviewed and tested.
Goals
Review Jiri's work and provide constructive feedback. Merge the code if acceptable. Evaluate the costs and benefits of using a library such as json-c.
Improve the picotm Transaction Manager by tdz
Picotm is a system-level transaction manager. It provides transactional semantics to low-level C operations, such as
- memory access,
- modifying data structures,
- (some) file I/O, and
- common interfaces from the C Standard Library and POSIX.
Picotm also handles error detection and recovery for all it's functionality. It's fully modular, so new functionality can be added.
For the Hackweek, I want to dedicate some time to picotm. I want to finish some of the refactoring work that I have been working on. If there's time left, I'd like to investigate two-phase commits and how to support them in picotm.
Picotm is available at http://picotm.org/.
pudc - A PID 1 process that barks to the internet by mssola
Description
As a fun exercise in order to dig deeper into the Linux kernel, its interfaces, the RISC-V architecture, and all the dragons in between; I'm building a blog site cooked like this:
- The backend is written in a mixture of C and RISC-V assembly.
- The backend is actually PID1 (for real, not within a container).
- We poll and parse incoming HTTP requests ourselves.
- The frontend is a mere HTML page with htmx.
The project is meant to be Linux-specific, so I'm going to use io_uring, pidfs, namespaces, and Linux-specific features in order to drive all of this.
I'm open for suggestions and so on, but this is meant to be a solo project, as this is more of a learning exercise for me than anything else.
Goals
- Have a better understanding of different Linux features from user space down to the kernel internals.
- Most importantly: have fun.
Resources
Smart lighting with Pico 2 by jmodak
Description
I am trying to create a smart-lighting project with a Raspberry Pi Pico that reacts to a movie's visuals and audio that involves combining two distinct functions: ambient screen lighting(visual response) and sound-reactive lighting(audio response)
Goals
- Visuals: Capturing the screen's colour requires an external device to analyse screen content and send colour data to the MCU via serial communication.
- Audio: A sound sensor module connected directly to the Pico that can detect sound volume.
- Pico 2W: The MCU receives data fro, both inputs and controls an LED strip.
Resources
- Raspberry Pi Pico 2 W
- RGB LED strip
- Sound detecting sensor
- Power supply
- breadboard and wires
x64id: An x86/x64 instruction disassembler by m.crivellari
Description
This is an old side project. An x86/x64 machine code decoder. It is useful to get instructions' length and identify each of its fields.
Example:
C7 85 68 FF FF FF 00 00 00 00
This is the instruction:
MOV DWORD PTR SS:[LOCAL.38],0
What follows are some of the information collected by the disassembler, based on the specific instruction:
RAW bytes (hex): C7 85 68 FF FF FF 00 00 00 00
Instr. length: 10
Print instruction fields:
Located Prefixes 0:
OP: 0xC7
mod_reg_rm: 0x85
disp (4): 0xFFFFFF68
Iimm: 0x0
Lacks the mnemonic representation: from the previous machine code is not able to produce the "MOV..." instruction, for example.
Goals
The goal is almost easy: partially implement the mnemonic representation. I have already started during the weekend, likely tomorrow I will push the branch!
Resources
- The project: https://github.com/DispatchCode/x64-Instruction-Decoder/
- This is useful to avoid gdb and objdump in local: https://defuse.ca/online-x86-assembler.htm
- Another interesting resource is https://godbolt.org/
Progress
- An initial implementation can be found at: https://github.com/DispatchCode/x64-Instruction-Decoder/tree/mnemonic-support It is described under the "Mnemonic translation" in the README file!
Let's consider this example:
[...other bytes...] 43 89 44 B5 00 01 00 [...other bytes...]