11 Commits (79b7fa9ac30e4067b203dbd0f476ee7e4d347173)

Author	SHA1	Message	Date
Josh Bleecher Snyder	25df067dd0	all: adapt to opaque netaddr types ... This commit is a mishmash of automated edits using gofmt: gofmt -r 'netaddr.IPPort{IP: a, Port: b} -> netaddr.IPPortFrom(a, b)' -w . gofmt -r 'netaddr.IPPrefix{IP: a, Port: b} -> netaddr.IPPrefixFrom(a, b)' -w . gofmt -r 'a.IP.Is4 -> a.IP().Is4' -w . gofmt -r 'a.IP.As16 -> a.IP().As16' -w . gofmt -r 'a.IP.Is6 -> a.IP().Is6' -w . gofmt -r 'a.IP.As4 -> a.IP().As4' -w . gofmt -r 'a.IP.String -> a.IP().String' -w . And regexps: \w*(.*)\.Port = (.*) -> $1 = $1.WithPort($2) \w*(.*)\.IP = (.*) -> $1 = $1.WithIP($2) And lots of manual fixups. Signed-off-by: Josh Bleecher Snyder <josh@tailscale.com>	4 years ago
Josh Bleecher Snyder	aacb2107ae	all: add extra information to serialized endpoints ... magicsock.Conn.ParseEndpoint requires a peer's public key, disco key, and legacy ip/ports in order to do its job. We currently accomplish that by: * adding the public key in our wireguard-go fork * encoding the disco key as magic hostname * using a bespoke comma-separated encoding It's a bit messy. Instead, switch to something simpler: use a json-encoded struct containing exactly the information we need, in the form we use it. Our wireguard-go fork still adds the public key to the address when it passes it to ParseEndpoint, but now the code compensating for that is just a couple of simple, well-commented lines. Once this commit is in, we can remove that part of the fork and remove the compensating code. Signed-off-by: Josh Bleecher Snyder <josharian@gmail.com>	4 years ago
Josh Bleecher Snyder	773fcfd007	Revert "wgengine/bench: skip flaky test" ... This reverts commit d707e2f7e5. Signed-off-by: Josh Bleecher Snyder <josh@tailscale.com>	4 years ago
Josh Bleecher Snyder	68911f6778	wgengine/bench: ignore "engine closing" errors ... On benchmark completion, we shut down the wgengine. If we happen to poll for status during shutdown, we get an "engine closing" error. It doesn't hurt anything; ignore it. Fixes tailscale/corp#1776 Signed-off-by: Josh Bleecher Snyder <josh@tailscale.com>	4 years ago
Brad Fitzpatrick	d707e2f7e5	wgengine/bench: skip flaky test ... Updates tailscale/corp#1776 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	4 years ago
Josh Bleecher Snyder	8d2a90529e	wgengine/bench: hold lock in TrafficGen.GotPacket while calling first packet callback ... Without any synchronization here, the "first packet" callback can be delayed indefinitely, while other work continues. Since the callback starts the benchmark timer, this could skew results. Worse, if the benchmark manages to complete before the benchmark timer begins, it'll cause a data race with the benchmark shutdown performed by package testing. That is what is reported in #1881. This is a bit unfortunate, in that it means that users of TrafficGen have to be careful to keep this callback speedy and lightweight and to avoid deadlocks. Fixes #1881 Signed-off-by: Josh Bleecher Snyder <josh@tailscale.com>	4 years ago
Josh Bleecher Snyder	a72fb7ac0b	wgengine/bench: handle multiple Engine status callbacks ... It is possible to get multiple status callbacks from an Engine. We need to wait for at least one from each Engine. Without limiting to one per Engine, wait.Wait can exit early or can panic due to a negative counter. Signed-off-by: Josh Bleecher Snyder <josh@tailscale.com>	4 years ago
Josh Bleecher Snyder	6618e82ba2	wgengine/bench: close Engines on benchmark completion ... This reduces the speed with which these benchmarks exhaust their supply fds. Not to zero unfortunately, but it's still helpful when doing long runs. Signed-off-by: Josh Bleecher Snyder <josh@tailscale.com>	4 years ago
Josh Bleecher Snyder	7ee891f5fd	all: delete wgcfg.Key and wgcfg.PrivateKey ... For historical reasons, we ended up with two near-duplicate copies of curve25519 key types, one in the wireguard-go module (wgcfg) and one in the tailscale module (types/wgkey). Then we moved wgcfg to the tailscale module. We can now remove the wgcfg key type in favor of wgkey. Signed-off-by: Josh Bleecher Snyder <josharian@gmail.com>	4 years ago
Avery Pennarun	a7fe1d7c46	wgengine/bench: improved rate selection. ... The old decay-based one took a while to converge. This new one (based very loosely on TCP BBR) seems to converge quickly on what seems to be the best speed. Signed-off-by: Avery Pennarun <apenwarr@tailscale.com>	4 years ago
Avery Pennarun	a92b9647c5	wgengine/bench: speed test for channels, sockets, and wireguard-go. ... This tries to generate traffic at a rate that will saturate the receiver, without overdoing it, even in the event of packet loss. It's unrealistically more aggressive than TCP (which will back off quickly in case of packet loss) but less silly than a blind test that just generates packets as fast as it can (which can cause all the CPU to be absorbed by the transmitter, giving an incorrect impression of how much capacity the total system has). Initial indications are that a syscall about every 10 packets (TCP bulk delivery) is roughly the same speed as sending every packet through a channel. A syscall per packet is about 5x-10x slower than that. The whole tailscale wireguard-go + magicsock + packet filter combination is about 4x slower again, which is better than I thought we'd do, but probably has room for improvement. Note that in "full" tailscale, there is also a tundev read/write for every packet, effectively doubling the syscall overhead per packet. Given these numbers, it seems like read/write syscalls are only 25-40% of the total CPU time used in tailscale proper, so we do have significant non-syscall optimization work to do too. Sample output: $ GOMAXPROCS=2 go test -bench . -benchtime 5s ./cmd/tailbench goos: linux goarch: amd64 pkg: tailscale.com/cmd/tailbench cpu: Intel(R) Core(TM) i7-4785T CPU @ 2.20GHz BenchmarkTrivialNoAlloc/32-2 56340248 93.85 ns/op 340.98 MB/s 0 %lost 0 B/op 0 allocs/op BenchmarkTrivialNoAlloc/124-2 57527490 99.27 ns/op 1249.10 MB/s 0 %lost 0 B/op 0 allocs/op BenchmarkTrivialNoAlloc/1024-2 52537773 111.3 ns/op 9200.39 MB/s 0 %lost 0 B/op 0 allocs/op BenchmarkTrivial/32-2 41878063 135.6 ns/op 236.04 MB/s 0 %lost 0 B/op 0 allocs/op BenchmarkTrivial/124-2 41270439 138.4 ns/op 896.02 MB/s 0 %lost 0 B/op 0 allocs/op BenchmarkTrivial/1024-2 36337252 154.3 ns/op 6635.30 MB/s 0 %lost 0 B/op 0 allocs/op BenchmarkBlockingChannel/32-2 12171654 494.3 ns/op 64.74 MB/s 0 %lost 1791 B/op 0 allocs/op BenchmarkBlockingChannel/124-2 12149956 507.8 ns/op 244.17 MB/s 0 %lost 1792 B/op 1 allocs/op BenchmarkBlockingChannel/1024-2 11034754 528.8 ns/op 1936.42 MB/s 0 %lost 1792 B/op 1 allocs/op BenchmarkNonlockingChannel/32-2 8960622 2195 ns/op 14.58 MB/s 8.825 %lost 1792 B/op 1 allocs/op BenchmarkNonlockingChannel/124-2 3014614 2224 ns/op 55.75 MB/s 11.18 %lost 1792 B/op 1 allocs/op BenchmarkNonlockingChannel/1024-2 3234915 1688 ns/op 606.53 MB/s 3.765 %lost 1792 B/op 1 allocs/op BenchmarkDoubleChannel/32-2 8457559 764.1 ns/op 41.88 MB/s 5.945 %lost 1792 B/op 1 allocs/op BenchmarkDoubleChannel/124-2 5497726 1030 ns/op 120.38 MB/s 12.14 %lost 1792 B/op 1 allocs/op BenchmarkDoubleChannel/1024-2 7985656 1360 ns/op 752.86 MB/s 13.57 %lost 1792 B/op 1 allocs/op BenchmarkUDP/32-2 1652134 3695 ns/op 8.66 MB/s 0 %lost 176 B/op 3 allocs/op BenchmarkUDP/124-2 1621024 3765 ns/op 32.94 MB/s 0 %lost 176 B/op 3 allocs/op BenchmarkUDP/1024-2 1553750 3825 ns/op 267.72 MB/s 0 %lost 176 B/op 3 allocs/op BenchmarkTCP/32-2 11056336 503.2 ns/op 63.60 MB/s 0 %lost 0 B/op 0 allocs/op BenchmarkTCP/124-2 11074869 533.7 ns/op 232.32 MB/s 0 %lost 0 B/op 0 allocs/op BenchmarkTCP/1024-2 8934968 671.4 ns/op 1525.20 MB/s 0 %lost 0 B/op 0 allocs/op BenchmarkWireGuardTest/32-2 1403702 4547 ns/op 7.04 MB/s 14.37 %lost 467 B/op 3 allocs/op BenchmarkWireGuardTest/124-2 780645 7927 ns/op 15.64 MB/s 1.537 %lost 420 B/op 3 allocs/op BenchmarkWireGuardTest/1024-2 512671 11791 ns/op 86.85 MB/s 0.5206 %lost 411 B/op 3 allocs/op PASS ok tailscale.com/wgengine/bench 195.724s Updates #414. Signed-off-by: Avery Pennarun <apenwarr@tailscale.com>	4 years ago