Go to file
Norwin Roosen c3ee33f8ce
fix pattern size regression
2020-12-29 21:09:00 +01:00
benchmarks document ideas, add readme img 2019-01-22 11:12:29 +01:00
pixelflut new randoffset for each draw 2020-12-29 21:08:31 +01:00
render fix pattern size regression 2020-12-29 21:09:00 +01:00
rpc fix pattern size regression 2020-12-29 21:09:00 +01:00
.gitignore add binary to gitignore 2019-01-11 18:30:27 +01:00
IDEAS.md idea: p2p job distribution 2020-01-14 15:26:16 +01:00
LICENSE Initial commit 2019-01-06 21:54:30 +01:00
README.md update README 2019-01-23 16:05:06 +01:00
main.go add initial randoffset mode 2020-12-29 18:28:19 +01:00

README.md

🌊🌊🌊 Hochwasser 🌊🤽🌊

Highly efficient client for Pixelflut: Faster than sturmflut! (In some benchmarks at least)

Can currently only send a single picture though.

benchmark

The following benchmark was run on a max-spec X280 against version d4c574b.

I could not figure out what the performance bottleneck is, but it doesn't seem to be CPU limited, as turbo-boost doesn't kick in.

To reproduce, run the following commands in separate shells:

iperf -s -p 1337
go run main.go -image benchmark/test.png -connection 10

screenshot: 55 Gbps of hochwasser

55 Gbps on average! 🌊🌊🌊

sturmflut (./sturmflut 127.0.0.1:1337 benchmark/test.png -t 10, version 8ec6ee9) managed to get 48 Gpbs throughput on this system.

Hint: Benchmarking throughput against the pixelnuke server is pointless, as performance is then CPU-limited to ~1 Gbps by the server. Using iperf removes the server limitation. This also means that these metrics of several Gbps are far higher than realworld scenarios.

future ideas

For future ideas check IDEAS