Low transmission efficiency on moderate/low host

Using version: dev+20191224233758
CPU Model:             Intel Core i7 9xx (Nehalem Class Core i7)
CPU Cache Size:    4096 KB
CPU Number:          1 vCPU
Memory Usage:          208.73 MB / 985.53 MB

Machine info generated by LemonBench.
Command: curl -fsL https://ilemonra.in/LemonBenchIntl | bash -s fast
Using iperf3 for test:
server: iperf3 -s
client: iperf3 -c [ip] -P 10
2 hosts are located in the same DataCenter and both of them have up to 1Gbps bandwidth.
TCP Raw (dierct transmission):
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   112 MBytes  94.1 Mbits/sec  127             sender
[  4]   0.00-10.00  sec   111 MBytes  93.4 Mbits/sec                  receiver
[  6]   0.00-10.00  sec  94.8 MBytes  79.5 Mbits/sec  111             sender
[  6]   0.00-10.00  sec  94.1 MBytes  78.9 Mbits/sec                  receiver
[  8]   0.00-10.00  sec  87.6 MBytes  73.5 Mbits/sec  128             sender
[  8]   0.00-10.00  sec  86.9 MBytes  72.9 Mbits/sec                  receiver
[ 10]   0.00-10.00  sec  79.2 MBytes  66.4 Mbits/sec  115             sender
[ 10]   0.00-10.00  sec  78.5 MBytes  65.9 Mbits/sec                  receiver
[ 12]   0.00-10.00  sec  81.7 MBytes  68.5 Mbits/sec  108             sender
[ 12]   0.00-10.00  sec  80.8 MBytes  67.7 Mbits/sec                  receiver
[ 14]   0.00-10.00  sec   130 MBytes   109 Mbits/sec  114             sender
[ 14]   0.00-10.00  sec   129 MBytes   108 Mbits/sec                  receiver
[ 16]   0.00-10.00  sec   100 MBytes  84.0 Mbits/sec  117             sender
[ 16]   0.00-10.00  sec  99.4 MBytes  83.4 Mbits/sec                  receiver
[ 18]   0.00-10.00  sec  98.1 MBytes  82.3 Mbits/sec   79             sender
[ 18]   0.00-10.00  sec  97.5 MBytes  81.8 Mbits/sec                  receiver
[ 20]   0.00-10.00  sec   105 MBytes  88.1 Mbits/sec  137             sender
[ 20]   0.00-10.00  sec   104 MBytes  87.5 Mbits/sec                  receiver
[ 22]   0.00-10.00  sec  99.6 MBytes  83.5 Mbits/sec  144             sender
[ 22]   0.00-10.00  sec  98.6 MBytes  82.7 Mbits/sec                  receiver
[SUM]   0.00-10.00  sec   989 MBytes   829 Mbits/sec  1180             sender
[SUM]   0.00-10.00  sec   981 MBytes   823 Mbits/sec                  receiver

UDP Raw:
Command: iperf3 -c [IP] -u -b 80M -P 10
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  94.7 MBytes  79.4 Mbits/sec  0.881 ms  3/39 (7.7%)
[  4] Sent 39 datagrams
[  6]   0.00-10.00  sec  94.7 MBytes  79.4 Mbits/sec  0.886 ms  3/39 (7.7%)
[  6] Sent 39 datagrams
[  8]   0.00-10.00  sec  94.7 MBytes  79.4 Mbits/sec  0.885 ms  3/39 (7.7%)
[  8] Sent 39 datagrams
[ 10]   0.00-10.00  sec  94.7 MBytes  79.4 Mbits/sec  0.875 ms  3/38 (7.9%)
[ 10] Sent 38 datagrams
[ 12]   0.00-10.00  sec  94.7 MBytes  79.4 Mbits/sec  0.841 ms  3/40 (7.5%)
[ 12] Sent 40 datagrams
[ 14]   0.00-10.00  sec  94.7 MBytes  79.4 Mbits/sec  0.772 ms  7/46 (15%)
[ 14] Sent 46 datagrams
[ 16]   0.00-10.00  sec  94.7 MBytes  79.4 Mbits/sec  0.829 ms  7/44 (16%)
[ 16] Sent 44 datagrams
[ 18]   0.00-10.00  sec  94.7 MBytes  79.4 Mbits/sec  0.828 ms  2/37 (5.4%)
[ 18] Sent 37 datagrams
[ 20]   0.00-10.00  sec  94.7 MBytes  79.4 Mbits/sec  0.829 ms  2/37 (5.4%)
[ 20] Sent 37 datagrams
[ 22]   0.00-10.00  sec  94.7 MBytes  79.4 Mbits/sec  0.795 ms  6/43 (14%)
[ 22] Sent 43 datagrams
[SUM]   0.00-10.00  sec   947 MBytes   794 Mbits/sec  0.842 ms  39/402 (9.7%)

Command: iperf3 -c [IP] -u -b 100M -P 10
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec   118 MBytes  99.0 Mbits/sec  1.217 ms  0/43 (0%)
[  4] Sent 43 datagrams
[  6]   0.00-10.00  sec   118 MBytes  99.0 Mbits/sec  1.290 ms  54/100 (54%)
[  6] Sent 100 datagrams
[  8]   0.00-10.00  sec   118 MBytes  99.0 Mbits/sec  1.400 ms  49/93 (53%)
[  8] Sent 93 datagrams
[ 10]   0.00-10.00  sec   118 MBytes  99.0 Mbits/sec  1.326 ms  9/53 (17%)
[ 10] Sent 53 datagrams
[ 12]   0.00-10.00  sec   118 MBytes  99.0 Mbits/sec  1.244 ms  0/43 (0%)
[ 12] Sent 43 datagrams
[ 14]   0.00-10.00  sec   118 MBytes  99.0 Mbits/sec  1.462 ms  52/97 (54%)
[ 14] Sent 97 datagrams
[ 16]   0.00-10.00  sec   118 MBytes  99.0 Mbits/sec  1.358 ms  22/68 (32%)
[ 16] Sent 68 datagrams
[ 18]   0.00-10.00  sec   118 MBytes  99.0 Mbits/sec  1.667 ms  123/167 (74%)
[ 18] Sent 167 datagrams
[ 20]   0.00-10.00  sec   118 MBytes  99.0 Mbits/sec  1.509 ms  51/96 (53%)
[ 20] Sent 96 datagrams
[ 22]   0.00-10.00  sec   118 MBytes  99.0 Mbits/sec  1.238 ms  0/42 (0%)
[ 22] Sent 42 datagrams
[SUM]   0.00-10.00  sec  1.15 GBytes   990 Mbits/sec  1.371 ms  360/802 (45%)

Wireguard:
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  40.7 MBytes  34.2 Mbits/sec  166             sender
[  4]   0.00-10.00  sec  40.3 MBytes  33.8 Mbits/sec                  receiver
[  6]   0.00-10.00  sec  86.7 MBytes  72.7 Mbits/sec  536             sender
[  6]   0.00-10.00  sec  85.3 MBytes  71.5 Mbits/sec                  receiver
[  8]   0.00-10.00  sec  43.7 MBytes  36.7 Mbits/sec  183             sender
[  8]   0.00-10.00  sec  43.3 MBytes  36.3 Mbits/sec                  receiver
[ 10]   0.00-10.00  sec  38.2 MBytes  32.0 Mbits/sec  129             sender
[ 10]   0.00-10.00  sec  37.7 MBytes  31.6 Mbits/sec                  receiver
[ 12]   0.00-10.00  sec  37.7 MBytes  31.6 Mbits/sec  127             sender
[ 12]   0.00-10.00  sec  37.3 MBytes  31.3 Mbits/sec                  receiver
[ 14]   0.00-10.00  sec  38.5 MBytes  32.3 Mbits/sec  125             sender
[ 14]   0.00-10.00  sec  38.1 MBytes  31.9 Mbits/sec                  receiver
[ 16]   0.00-10.00  sec  34.2 MBytes  28.7 Mbits/sec  133             sender
[ 16]   0.00-10.00  sec  33.9 MBytes  28.4 Mbits/sec                  receiver
[ 18]   0.00-10.00  sec  36.3 MBytes  30.5 Mbits/sec  178             sender
[ 18]   0.00-10.00  sec  35.9 MBytes  30.1 Mbits/sec                  receiver
[ 20]   0.00-10.00  sec  33.7 MBytes  28.2 Mbits/sec  104             sender
[ 20]   0.00-10.00  sec  33.3 MBytes  28.0 Mbits/sec                  receiver
[ 22]   0.00-10.00  sec  27.8 MBytes  23.4 Mbits/sec   87             sender
[ 22]   0.00-10.00  sec  27.5 MBytes  23.1 Mbits/sec                  receiver
[SUM]   0.00-10.00  sec   418 MBytes   350 Mbits/sec  1768             sender
[SUM]   0.00-10.00  sec   413 MBytes   346 Mbits/sec                  receiver

Nebula (using default):
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  2.94 MBytes  2.47 Mbits/sec   89             sender
[  4]   0.00-10.00  sec  2.81 MBytes  2.36 Mbits/sec                  receiver
[  6]   0.00-10.00  sec  2.40 MBytes  2.02 Mbits/sec   94             sender
[  6]   0.00-10.00  sec  2.28 MBytes  1.91 Mbits/sec                  receiver
[  8]   0.00-10.00  sec  2.64 MBytes  2.22 Mbits/sec   71             sender
[  8]   0.00-10.00  sec  2.51 MBytes  2.10 Mbits/sec                  receiver
[ 10]   0.00-10.00  sec  2.99 MBytes  2.51 Mbits/sec   85             sender
[ 10]   0.00-10.00  sec  2.88 MBytes  2.41 Mbits/sec                  receiver
[ 12]   0.00-10.00  sec  2.30 MBytes  1.93 Mbits/sec   65             sender
[ 12]   0.00-10.00  sec  2.23 MBytes  1.87 Mbits/sec                  receiver
[ 14]   0.00-10.00  sec  2.60 MBytes  2.18 Mbits/sec   74             sender
[ 14]   0.00-10.00  sec  2.48 MBytes  2.08 Mbits/sec                  receiver
[ 16]   0.00-10.00  sec  2.25 MBytes  1.89 Mbits/sec   84             sender
[ 16]   0.00-10.00  sec  2.13 MBytes  1.78 Mbits/sec                  receiver
[ 18]   0.00-10.00  sec  3.00 MBytes  2.51 Mbits/sec   69             sender
[ 18]   0.00-10.00  sec  2.86 MBytes  2.40 Mbits/sec                  receiver
[ 20]   0.00-10.00  sec  3.37 MBytes  2.83 Mbits/sec   60             sender
[ 20]   0.00-10.00  sec  3.26 MBytes  2.73 Mbits/sec                  receiver
[ 22]   0.00-10.00  sec  3.11 MBytes  2.61 Mbits/sec   73             sender
[ 22]   0.00-10.00  sec  2.97 MBytes  2.49 Mbits/sec                  receiver
[SUM]   0.00-10.00  sec  27.6 MBytes  23.2 Mbits/sec  764             sender
[SUM]   0.00-10.00  sec  26.4 MBytes  22.1 Mbits/sec                  receiver

Nebula (using chachapoly):
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  2.47 MBytes  2.07 Mbits/sec   31             sender
[  4]   0.00-10.00  sec  2.35 MBytes  1.97 Mbits/sec                  receiver
[  6]   0.00-10.00  sec  4.07 MBytes  3.42 Mbits/sec   32             sender
[  6]   0.00-10.00  sec  3.81 MBytes  3.19 Mbits/sec                  receiver
[  8]   0.00-10.00  sec  4.09 MBytes  3.43 Mbits/sec   32             sender
[  8]   0.00-10.00  sec  3.93 MBytes  3.30 Mbits/sec                  receiver
[ 10]   0.00-10.00  sec  4.33 MBytes  3.63 Mbits/sec   33             sender
[ 10]   0.00-10.00  sec  4.12 MBytes  3.46 Mbits/sec                  receiver
[ 12]   0.00-10.00  sec  5.71 MBytes  4.79 Mbits/sec   30             sender
[ 12]   0.00-10.00  sec  5.54 MBytes  4.64 Mbits/sec                  receiver
[ 14]   0.00-10.00  sec  4.04 MBytes  3.39 Mbits/sec   74             sender
[ 14]   0.00-10.00  sec  3.88 MBytes  3.25 Mbits/sec                  receiver
[ 16]   0.00-10.00  sec  2.87 MBytes  2.41 Mbits/sec   42             sender
[ 16]   0.00-10.00  sec  2.68 MBytes  2.25 Mbits/sec                  receiver
[ 18]   0.00-10.00  sec  3.27 MBytes  2.74 Mbits/sec   22             sender
[ 18]   0.00-10.00  sec  3.09 MBytes  2.59 Mbits/sec                  receiver
[ 20]   0.00-10.00  sec  4.42 MBytes  3.71 Mbits/sec   66             sender
[ 20]   0.00-10.00  sec  4.26 MBytes  3.57 Mbits/sec                  receiver
[ 22]   0.00-10.00  sec  1.98 MBytes  1.66 Mbits/sec   34             sender
[ 22]   0.00-10.00  sec  1.88 MBytes  1.58 Mbits/sec                  receiver
[SUM]   0.00-10.00  sec  37.3 MBytes  31.2 Mbits/sec  396             sender
[SUM]   0.00-10.00  sec  35.5 MBytes  29.8 Mbits/sec                  receiver

This is the cause CPU Number: 1 vCPU and it was explained in #42. In short, you need at least 2 vCPU as data encryption is expensive.

@nfam
Well, I used another 2 hosts again. It can carry 5Gbps bandwidth.
Conclusion: With 2 vCPU, wireguard can reach the maximum bandwidth(5 Gbps). Relatively, Nebula can only carry up to 580 Mbps.
I don't think it is not the performance issue. IT IS THE PERFORMANCE ISSUE. The gap is huge.
Machine Info:
 CPU Model:             AMD EPYC 7571
 CPU Cache Size:        512 KB
 CPU Number:            2 vCPU
 Virt Type:             KVM
 Memory Usage:          140.67 MB / 1.92 GB
 Swap Usage:            [ No Swapfile/Swap Partition ]

TCP Raw:
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-3.55   sec   214 MBytes   504 Mbits/sec    0             sender
[  4]   0.00-3.55   sec  0.00 Bytes  0.00 bits/sec                  receiver
[  6]   0.00-3.55   sec   213 MBytes   504 Mbits/sec    0             sender
[  6]   0.00-3.55   sec  0.00 Bytes  0.00 bits/sec                  receiver
[  8]   0.00-3.55   sec   211 MBytes   498 Mbits/sec    0             sender
[  8]   0.00-3.55   sec  0.00 Bytes  0.00 bits/sec                  receiver
[ 10]   0.00-3.55   sec   213 MBytes   502 Mbits/sec    0             sender
[ 10]   0.00-3.55   sec  0.00 Bytes  0.00 bits/sec                  receiver
[ 12]   0.00-3.55   sec   213 MBytes   503 Mbits/sec    0             sender
[ 12]   0.00-3.55   sec  0.00 Bytes  0.00 bits/sec                  receiver
[ 14]   0.00-3.55   sec   211 MBytes   497 Mbits/sec    0             sender
[ 14]   0.00-3.55   sec  0.00 Bytes  0.00 bits/sec                  receiver
[ 16]   0.00-3.55   sec   210 MBytes   497 Mbits/sec    0             sender
[ 16]   0.00-3.55   sec  0.00 Bytes  0.00 bits/sec                  receiver
[ 18]   0.00-3.55   sec   213 MBytes   502 Mbits/sec    0             sender
[ 18]   0.00-3.55   sec  0.00 Bytes  0.00 bits/sec                  receiver
[ 20]   0.00-3.55   sec   210 MBytes   497 Mbits/sec    0             sender
[ 20]   0.00-3.55   sec  0.00 Bytes  0.00 bits/sec                  receiver
[ 22]   0.00-3.55   sec   210 MBytes   497 Mbits/sec    0             sender
[ 22]   0.00-3.55   sec  0.00 Bytes  0.00 bits/sec                  receiver
[SUM]   0.00-3.55   sec  2.07 GBytes  5.00 Gbits/sec    0             sender
[SUM]   0.00-3.55   sec  0.00 Bytes  0.00 bits/sec                  receive

Wireguard:
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   773 MBytes   649 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   771 MBytes   647 Mbits/sec                  receiver
[  6]   0.00-10.00  sec   773 MBytes   648 Mbits/sec    0             sender
[  6]   0.00-10.00  sec   771 MBytes   647 Mbits/sec                  receiver
[  8]   0.00-10.00  sec   570 MBytes   478 Mbits/sec    0             sender
[  8]   0.00-10.00  sec   568 MBytes   477 Mbits/sec                  receiver
[ 10]   0.00-10.00  sec   570 MBytes   478 Mbits/sec    0             sender
[ 10]   0.00-10.00  sec   568 MBytes   477 Mbits/sec                  receiver
[ 12]   0.00-10.00  sec   570 MBytes   478 Mbits/sec    0             sender
[ 12]   0.00-10.00  sec   568 MBytes   477 Mbits/sec                  receiver
[ 14]   0.00-10.00  sec   570 MBytes   478 Mbits/sec    0             sender
[ 14]   0.00-10.00  sec   568 MBytes   477 Mbits/sec                  receiver
[ 16]   0.00-10.00  sec   570 MBytes   478 Mbits/sec    0             sender
[ 16]   0.00-10.00  sec   568 MBytes   477 Mbits/sec                  receiver
[ 18]   0.00-10.00  sec   475 MBytes   398 Mbits/sec    2             sender
[ 18]   0.00-10.00  sec   473 MBytes   397 Mbits/sec                  receiver
[ 20]   0.00-10.00  sec   505 MBytes   423 Mbits/sec    1             sender
[ 20]   0.00-10.00  sec   503 MBytes   422 Mbits/sec                  receiver
[ 22]   0.00-10.00  sec   570 MBytes   478 Mbits/sec    0             sender
[ 22]   0.00-10.00  sec   568 MBytes   477 Mbits/sec                  receiver
[SUM]   0.00-10.00  sec  5.81 GBytes  4.99 Gbits/sec    3             sender
[SUM]   0.00-10.00  sec  5.79 GBytes  4.97 Gbits/sec                  receiver

Nebula (using default):
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  46.5 MBytes  39.0 Mbits/sec  1528             sender
[  4]   0.00-10.00  sec  46.2 MBytes  38.8 Mbits/sec                  receiver
[  6]   0.00-10.00  sec  81.1 MBytes  68.0 Mbits/sec  2074             sender
[  6]   0.00-10.00  sec  80.7 MBytes  67.7 Mbits/sec                  receiver
[  8]   0.00-10.00  sec  63.3 MBytes  53.1 Mbits/sec  1936             sender
[  8]   0.00-10.00  sec  62.8 MBytes  52.7 Mbits/sec                  receiver
[ 10]   0.00-10.00  sec  52.4 MBytes  44.0 Mbits/sec  1680             sender
[ 10]   0.00-10.00  sec  52.2 MBytes  43.8 Mbits/sec                  receiver
[ 12]   0.00-10.00  sec  59.8 MBytes  50.1 Mbits/sec  1767             sender
[ 12]   0.00-10.00  sec  59.4 MBytes  49.8 Mbits/sec                  receiver
[ 14]   0.00-10.00  sec  70.1 MBytes  58.8 Mbits/sec  2197             sender
[ 14]   0.00-10.00  sec  69.8 MBytes  58.5 Mbits/sec                  receiver
[ 16]   0.00-10.00  sec  65.0 MBytes  54.5 Mbits/sec  1948             sender
[ 16]   0.00-10.00  sec  64.5 MBytes  54.1 Mbits/sec                  receiver
[ 18]   0.00-10.00  sec  59.3 MBytes  49.7 Mbits/sec  1750             sender
[ 18]   0.00-10.00  sec  58.9 MBytes  49.4 Mbits/sec                  receiver
[ 20]   0.00-10.00  sec  78.5 MBytes  65.8 Mbits/sec  2193             sender
[ 20]   0.00-10.00  sec  78.0 MBytes  65.4 Mbits/sec                  receiver
[ 22]   0.00-10.00  sec  59.9 MBytes  50.3 Mbits/sec  1972             sender
[ 22]   0.00-10.00  sec  59.5 MBytes  49.9 Mbits/sec                  receiver
[SUM]   0.00-10.00  sec   636 MBytes   533 Mbits/sec  19045             sender
[SUM]   0.00-10.00  sec   632 MBytes   530 Mbits/sec                  receiver

Nebula (using chachapoly):
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  67.2 MBytes  56.3 Mbits/sec  1944             sender
[  4]   0.00-10.00  sec  66.8 MBytes  56.0 Mbits/sec                  receiver
[  6]   0.00-10.00  sec  58.1 MBytes  48.7 Mbits/sec  1799             sender
[  6]   0.00-10.00  sec  57.7 MBytes  48.4 Mbits/sec                  receiver
[  8]   0.00-10.00  sec  79.4 MBytes  66.6 Mbits/sec  2056             sender
[  8]   0.00-10.00  sec  78.9 MBytes  66.2 Mbits/sec                  receiver
[ 10]   0.00-10.00  sec  62.4 MBytes  52.4 Mbits/sec  1679             sender
[ 10]   0.00-10.00  sec  62.1 MBytes  52.1 Mbits/sec                  receiver
[ 12]   0.00-10.00  sec  80.5 MBytes  67.5 Mbits/sec  2444             sender
[ 12]   0.00-10.00  sec  80.1 MBytes  67.2 Mbits/sec                  receiver
[ 14]   0.00-10.00  sec  55.6 MBytes  46.7 Mbits/sec  1765             sender
[ 14]   0.00-10.00  sec  55.4 MBytes  46.4 Mbits/sec                  receiver
[ 16]   0.00-10.00  sec  65.7 MBytes  55.1 Mbits/sec  2033             sender
[ 16]   0.00-10.00  sec  65.2 MBytes  54.7 Mbits/sec                  receiver
[ 18]   0.00-10.00  sec  77.0 MBytes  64.6 Mbits/sec  2284             sender
[ 18]   0.00-10.00  sec  76.6 MBytes  64.2 Mbits/sec                  receiver
[ 20]   0.00-10.00  sec  62.7 MBytes  52.6 Mbits/sec  1801             sender
[ 20]   0.00-10.00  sec  62.4 MBytes  52.3 Mbits/sec                  receiver
[ 22]   0.00-10.00  sec  74.0 MBytes  62.1 Mbits/sec  2196             sender
[ 22]   0.00-10.00  sec  73.7 MBytes  61.8 Mbits/sec                  receiver
[SUM]   0.00-10.00  sec   683 MBytes   573 Mbits/sec  20001             sender
[SUM]   0.00-10.00  sec   679 MBytes   569 Mbits/sec                  receiver

Wireguard is generally faster in benchmarks because it avoids syscall overhead by being in the kernel, however we have never witnessed a gap like this in testing or production, so need more information if you'd like to debug why you are seeing such slow speeds.
Can you provide more info, including: nebula configuration, wireguard MTU, nebula MTU, physical/virtual intervace MTU, txqueuelen for all interfaces, cpuinfo output from inside the guests, and exact iperf commands run on each platform.
Notably, it is extremely strange to see nebula chachapoly performing faster than nebula AES on this hardware. AES-NI should be present and easily beats chachapoly on x86/64 hardware.

@rawdigits Due to the low specification (need at least 2 vCPUs), ignore the 1st test to avoid superfluous factors.
Before everything I should answer, I have to say there might be a UDP QoS in AWS network between AWS gateways. After your reply, I re-create the 2 instances with the same spec again(cuz I terminated the instances I used before), and AWS give me 2 instances with different gateways(for LAN, but the instances I tested before have the same gateway).
I checked the extreme bandwidth again before replying to these, the bandwidth somethings become 1 Gbps, sometimes become 2 Gbps. I think we need a more restricted environment for the test. Meantime, Nebule keeps 500+Mbps.
I also tried to proceed the UDP Raw test to proof that guess, however...
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec   594 MBytes   498 Mbits/sec  0.744 ms  64831/64856 (1e+02%)
[  4] Sent 64856 datagrams
[  6]   0.00-10.00  sec   594 MBytes   498 Mbits/sec  0.744 ms  64831/64856 (1e+02%)
[  6] Sent 64856 datagrams
[  8]   0.00-10.00  sec   594 MBytes   498 Mbits/sec  0.793 ms  64832/64856 (1e+02%)
[  8] Sent 64856 datagrams
[ 10]   0.00-10.00  sec   594 MBytes   498 Mbits/sec  0.831 ms  64833/64856 (1e+02%)
[ 10] Sent 64856 datagrams
[ 12]   0.00-10.00  sec   594 MBytes   498 Mbits/sec  0.831 ms  64833/64856 (1e+02%)
[ 12] Sent 64856 datagrams
[ 14]   0.00-10.00  sec   594 MBytes   498 Mbits/sec  1.003 ms  64836/64856 (1e+02%)
[ 14] Sent 64856 datagrams
[ 16]   0.00-10.00  sec   594 MBytes   498 Mbits/sec  1.003 ms  64836/64856 (1e+02%)
[ 16] Sent 64856 datagrams
[ 18]   0.00-10.00  sec   594 MBytes   498 Mbits/sec  1.064 ms  64836/64855 (1e+02%)
[ 18] Sent 64855 datagrams
[ 20]   0.00-10.00  sec   594 MBytes   498 Mbits/sec  1.063 ms  64836/64855 (1e+02%)
[ 20] Sent 64855 datagrams
[ 22]   0.00-10.00  sec   594 MBytes   498 Mbits/sec  1.065 ms  64836/64855 (1e+02%)
[ 22] Sent 64855 datagrams
[SUM]   0.00-10.00  sec  5.80 GBytes  4.98 Gbits/sec  0.914 ms  648340/648557 (1e+02%)

I don't know this result is trustable or not (look at the package lost rate).
Whatever.
I used AWS EC2 servers(x86) located in Singapore for the 2nd test.

CPU info:
Command: cat /proc/cpuinfo
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse 3dnowprefetch topoext vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 clzero xsaveerptr arat npt nrip_save
bugs            : sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass
bogomips        : 4399.94
TLB size        : 2560 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 23
model           : 1
model name      : AMD EPYC 7571
stepping        : 2
microcode       : 0x8001227
cpu MHz         : 2199.972
cache size      : 512 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse 3dnowprefetch topoext vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 clzero xsaveerptr arat npt nrip_save
bugs            : sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass
bogomips        : 4399.94
TLB size        : 2560 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: [blank here]

txqueuelen:
Host 1:
ens5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9001
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
        inet6 fe80::438:c8ff:fe21:792c  prefixlen 64  scopeid 0x20<link>
        ether 06:38:c8:21:79:2c  txqueuelen 1000  (Ethernet)
        RX packets 50169  bytes 71428440 (71.4 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6837  bytes 659595 (659.5 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 258  bytes 24480 (24.4 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 258  bytes 24480 (24.4 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

neb0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1300
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  destination <IP_ADDRESS>
        inet6 fe80::e38d:f0d6:5309:8ac7  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7  bytes 336 (336.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1200
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  destination <IP_ADDRESS>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Host2:
ens5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9001
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
        inet6 fe80::49c:7ff:fe6d:d866  prefixlen 64  scopeid 0x20<link>
        ether 06:9c:07:6d:d8:66  txqueuelen 1000  (Ethernet)
        RX packets 50626  bytes 71729376 (71.7 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7425  bytes 735435 (735.4 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 282  bytes 32952 (32.9 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 282  bytes 32952 (32.9 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

neb0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1300
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  destination <IP_ADDRESS>
        inet6 fe80::be4f:56b5:6fb2:3db7  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 2  bytes 168 (168.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5  bytes 312 (312.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1200
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  destination <IP_ADDRESS>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 6  bytes 624 (624.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 32  bytes 2028 (2.0 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

iperf3 commands:
Server: iperf3 -s
Client:
TCP: iperf3 -c [IP] -P 10
UDP: iperf3 -c [IP] -u -b 80M -P 10 (change 80M according to the number about expected_bandwidth/10)
Change the IP to the relative LAN IP or public IP for test. RAW for public IP/AWS LAN IP, LAN IP(not aws LAN IP) for wireguard and nebula.
-P 10 is for the extreme stress test to get the maximum bandwidth.
use -p [port] to specify the port if necessary. The default is 5201.
Note: iperf and iperf3 are not the same commands. And the commands on all the platforms are the same.
Wireguard configs:
Config 1:
[Interface]
PrivateKey =
Address = <IP_ADDRESS>/24
PostUp   = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens5 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens5 -j MASQUERADE
ListenPort = 23456
DNS = <IP_ADDRESS>
MTU = 1200

[Peer]
PublicKey =
Endpoint = config_2_ip:23456
AllowedIPs = <IP_ADDRESS>/32
PersistentKeepalive = 25

Config 2
[Interface]
PrivateKey =
Address = <IP_ADDRESS>/24
PostUp   = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens5 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens5 -j MASQUERADE
ListenPort = 23456
DNS = <IP_ADDRESS>
MTU = 1200

[Peer]
PublicKey =
AllowedIPs = <IP_ADDRESS>/32

Nebula configs:
Config for <IP_ADDRESS>
pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/host.crt
  key: /etc/nebula/host.key

static_host_map:
  "<IP_ADDRESS>": ["<IP_ADDRESS>:12345"]
  # This is AWS LAN IP.
  # Each AWS instances in the same location can connect each other via their own LAN IP.

lighthouse:
  am_lighthouse: true
  serve_dns: false
  dns:
    host: <IP_ADDRESS>
    port: 53
  interval: 20
  hosts:

listen:
  host: <IP_ADDRESS>
  port: 12345

punchy: true
punch_back: true

cipher: chachapoly

tun:
  dev: neb0
  drop_local_broadcast: false
  drop_multicast: false
  tx_queue: 500
  mtu: 1300
  routes:
  unsafe_routes:

logging:
  level: info
  format: text

firewall:
  conntrack:
    tcp_timeout: 120h
    udp_timeout: 3m
    default_timeout: 10m
    max_connections: 100000

  outbound:
    # Allow all outbound traffic from this node
    - port: any
      proto: any
      host: any

  inbound:
    - port: any
      proto: any
      host: any

    # Allow icmp between any nebula hosts
    - port: any
      proto: icmp
      host: any

    # Allow tcp/443 from any host with BOTH laptop and home group
    - port: 443
      proto: tcp
      groups:
        - laptop
        - home

Config for <IP_ADDRESS>
pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/host.crt
  key: /etc/nebula/host.key

static_host_map:
  "<IP_ADDRESS>": ["<IP_ADDRESS>:12345"]

lighthouse:
  am_lighthouse: false
  serve_dns: false
  dns:
    host: <IP_ADDRESS>
    port: 53
  interval: 20
  hosts:
    - "<IP_ADDRESS>"

listen:
  host: <IP_ADDRESS>
  port: 0

punchy: true
punch_back: true

cipher: chachapoly

tun:
  dev: neb0
  drop_local_broadcast: false
  drop_multicast: false
  tx_queue: 500
  mtu: 1300
  routes:
  unsafe_routes:

logging:
  level: info
  format: text

firewall:
  conntrack:
    tcp_timeout: 120h
    udp_timeout: 3m
    default_timeout: 10m
    max_connections: 100000

  outbound:
    # Allow all outbound traffic from this node
    - port: any
      proto: any
      host: any

  inbound:
    - port: any
      proto: any
      host: any

    # Allow icmp between any nebula hosts
    - port: any
      proto: icmp
      host: any

    # Allow tcp/443 from any host with BOTH laptop and home group
    - port: 443
      proto: tcp
      groups:
        - laptop
        - home

I do the test3, on GCP servers with 4 vCPU 3.6G RAM 10 Gbps bandwidth.

Conclusion: weird result, maybe 4 vCPU isn't enough?
Using Nebula version v1.0.0.
Machine & System Info:
 OS Release:            Ubuntu 18.04.3 LTS (Bionic Beaver)  (x86_64)
 CPU Model:             Intel(R) Xeon(R) CPU @ 2.20GHz
 CPU Cache Size:        56320 KB
 CPU Number:            4 vCPU
 Virt Type:             KVM
 Memory Usage:          285.44 MB / 3.46 GB
 Swap Usage:            [ No Swapfile/Swap Partition ]
 Boot Device:           /dev/sda1
 Disk Usage:            1.39 GB / 9.98 GB
 CPU Usage:             6.2% used, 0.5% iowait, 0.0% steal
 Load (1/5/15min):      0.60 0.25 0.11
 Uptime:                0 Days, 0 Hours, 4 Minutes, 41 Seconds

Ifconfig
ens4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1460
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
        inet6 fe80::4001:aff:fe94:7  prefixlen 64  scopeid 0x20<link>
        ether 42:01:0a:94:00:07  txqueuelen 1000  (Ethernet)
        RX packets 1718639  bytes 277653574 (277.6 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 8414408  bytes<PHONE_NUMBER>3 (26.9 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 296  bytes 29991 (29.9 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 296  bytes 29991 (29.9 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

neb0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1300
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  destination <IP_ADDRESS>
        inet6 fe80::ed3:9ce6:5e89:d3a9  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 513508  bytes 27332237 (27.3 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1366383  bytes<PHONE_NUMBER> (1.7 GB)
        TX errors 0  dropped 227 overruns 0  carrier 0  collisions 0

wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1200
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  destination <IP_ADDRESS>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 369120  bytes 35424456 (35.4 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4667423  bytes<PHONE_NUMBER> (5.7 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

CPU Info:
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti ssbd ibrs ibpb stibp fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt arat md_clear arch_capabilities
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit
bogomips        : 4400.00
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 79
model name      : Intel(R) Xeon(R) CPU @ 2.20GHz
stepping        : 0
microcode       : 0x1
cpu MHz         : 2200.000
cache size      : 56320 KB
physical id     : 0
siblings        : 4
core id         : 1
cpu cores       : 2
apicid          : 3
initial apicid  : 3
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti ssbd ibrs ibpb stibp fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt arat md_clear arch_capabilities
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs taa itlb_multihit
bogomips        : 4400.00
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

TCP Raw:
Command:  iperf3 -c <IP_ADDRESS> -u -P 10
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.03  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.03  sec   958 MBytes   801 Mbits/sec                  receiver
[  7]   0.00-10.03  sec  0.00 Bytes  0.00 bits/sec                  sender
[  7]   0.00-10.03  sec  1.36 GBytes  1.16 Gbits/sec                  receiver
[  9]   0.00-10.03  sec  0.00 Bytes  0.00 bits/sec                  sender
[  9]   0.00-10.03  sec   972 MBytes   813 Mbits/sec                  receiver
[ 11]   0.00-10.03  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 11]   0.00-10.03  sec  1.33 GBytes  1.14 Gbits/sec                  receiver
[ 13]   0.00-10.03  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 13]   0.00-10.03  sec   973 MBytes   814 Mbits/sec                  receiver
[ 15]   0.00-10.03  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 15]   0.00-10.03  sec  1.46 GBytes  1.25 Gbits/sec                  receiver
[ 17]   0.00-10.03  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 17]   0.00-10.03  sec   976 MBytes   816 Mbits/sec                  receiver
[ 19]   0.00-10.03  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 19]   0.00-10.03  sec   993 MBytes   831 Mbits/sec                  receiver
[ 21]   0.00-10.03  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 21]   0.00-10.03  sec  1.48 GBytes  1.27 Gbits/sec                  receiver
[ 23]   0.00-10.03  sec  0.00 Bytes  0.00 bits/sec                  sender
[ 23]   0.00-10.03  sec   974 MBytes   815 Mbits/sec                  receiver
[SUM]   0.00-10.03  sec  0.00 Bytes  0.00 bits/sec                  sender
[SUM]   0.00-10.03  sec  11.3 GBytes  9.72 Gbits/sec                  receive

UDP Raw:
Command:  iperf3 -c <IP_ADDRESS> -u -b 100M -P 10
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec   118 MBytes  99.3 Mbits/sec  0.125 ms  0/15146 (0%)
[  4] Sent 15146 datagrams
[  6]   0.00-10.00  sec   118 MBytes  99.3 Mbits/sec  0.124 ms  0/15146 (0%)
[  6] Sent 15146 datagrams
[  8]   0.00-10.00  sec   118 MBytes  99.3 Mbits/sec  0.126 ms  0/15146 (0%)
[  8] Sent 15146 datagrams
[ 10]   0.00-10.00  sec   118 MBytes  99.3 Mbits/sec  0.125 ms  0/15146 (0%)
[ 10] Sent 15146 datagrams
[ 12]   0.00-10.00  sec   118 MBytes  99.3 Mbits/sec  0.124 ms  0/15146 (0%)
[ 12] Sent 15146 datagrams
[ 14]   0.00-10.00  sec   118 MBytes  99.3 Mbits/sec  0.125 ms  0/15146 (0%)
[ 14] Sent 15146 datagrams
[ 16]   0.00-10.00  sec   118 MBytes  99.3 Mbits/sec  0.127 ms  0/15146 (0%)
[ 16] Sent 15146 datagrams
[ 18]   0.00-10.00  sec   118 MBytes  99.3 Mbits/sec  0.135 ms  0/15146 (0%)
[ 18] Sent 15146 datagrams
[ 20]   0.00-10.00  sec   118 MBytes  99.3 Mbits/sec  0.133 ms  0/15146 (0%)
[ 20] Sent 15146 datagrams
[ 22]   0.00-10.00  sec   118 MBytes  99.3 Mbits/sec  0.132 ms  0/15146 (0%)
[ 22] Sent 15146 datagrams
[SUM]   0.00-10.00  sec  1.16 GBytes   993 Mbits/sec  0.128 ms  0/151460 (0%)

Nebula (chachapoly):
Command: iperf3 -c <IP_ADDRESS> -P 10
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   128 MBytes   107 Mbits/sec  2495             sender
[  4]   0.00-10.00  sec   127 MBytes   107 Mbits/sec                  receiver
[  6]   0.00-10.00  sec   183 MBytes   153 Mbits/sec  3512             sender
[  6]   0.00-10.00  sec   182 MBytes   153 Mbits/sec                  receiver
[  8]   0.00-10.00  sec   145 MBytes   122 Mbits/sec  2374             sender
[  8]   0.00-10.00  sec   144 MBytes   121 Mbits/sec                  receiver
[ 10]   0.00-10.00  sec   117 MBytes  97.8 Mbits/sec  2116             sender
[ 10]   0.00-10.00  sec   116 MBytes  97.3 Mbits/sec                  receiver
[ 12]   0.00-10.00  sec   137 MBytes   115 Mbits/sec  2757             sender
[ 12]   0.00-10.00  sec   137 MBytes   115 Mbits/sec                  receiver
[ 14]   0.00-10.00  sec   166 MBytes   139 Mbits/sec  3062             sender
[ 14]   0.00-10.00  sec   165 MBytes   138 Mbits/sec                  receiver
[ 16]   0.00-10.00  sec   139 MBytes   117 Mbits/sec  2535             sender
[ 16]   0.00-10.00  sec   139 MBytes   116 Mbits/sec                  receiver
[ 18]   0.00-10.00  sec   130 MBytes   109 Mbits/sec  2483             sender
[ 18]   0.00-10.00  sec   129 MBytes   108 Mbits/sec                  receiver
[ 20]   0.00-10.00  sec   141 MBytes   118 Mbits/sec  2653             sender
[ 20]   0.00-10.00  sec   140 MBytes   118 Mbits/sec                  receiver
[ 22]   0.00-10.00  sec   133 MBytes   111 Mbits/sec  2528             sender
[ 22]   0.00-10.00  sec   132 MBytes   110 Mbits/sec                  receiver
[SUM]   0.00-10.00  sec  1.39 GBytes  1.19 Gbits/sec  26515             sender
[SUM]   0.00-10.00  sec  1.38 GBytes  1.18 Gbits/sec                  receiver

Nebula (aes):
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   152 MBytes   128 Mbits/sec  3099             sender
[  4]   0.00-10.00  sec   152 MBytes   127 Mbits/sec                  receiver
[  6]   0.00-10.00  sec   233 MBytes   195 Mbits/sec  4048             sender
[  6]   0.00-10.00  sec   232 MBytes   195 Mbits/sec                  receiver
[  8]   0.00-10.00  sec   169 MBytes   142 Mbits/sec  3657             sender
[  8]   0.00-10.00  sec   168 MBytes   141 Mbits/sec                  receiver
[ 10]   0.00-10.00  sec   120 MBytes   100 Mbits/sec  2559             sender
[ 10]   0.00-10.00  sec   119 MBytes  99.9 Mbits/sec                  receiver
[ 12]   0.00-10.00  sec   169 MBytes   142 Mbits/sec  3437             sender
[ 12]   0.00-10.00  sec   168 MBytes   141 Mbits/sec                  receiver
[ 14]   0.00-10.00  sec   167 MBytes   140 Mbits/sec  3422             sender
[ 14]   0.00-10.00  sec   166 MBytes   139 Mbits/sec                  receiver
[ 16]   0.00-10.00  sec   167 MBytes   140 Mbits/sec  3438             sender
[ 16]   0.00-10.00  sec   166 MBytes   140 Mbits/sec                  receiver
[ 18]   0.00-10.00  sec   129 MBytes   108 Mbits/sec  3008             sender
[ 18]   0.00-10.00  sec   128 MBytes   107 Mbits/sec                  receiver
[ 20]   0.00-10.00  sec   145 MBytes   121 Mbits/sec  2818             sender
[ 20]   0.00-10.00  sec   144 MBytes   121 Mbits/sec                  receiver
[ 22]   0.00-10.00  sec   144 MBytes   121 Mbits/sec  2885             sender
[ 22]   0.00-10.00  sec   144 MBytes   120 Mbits/sec                  receiver
[SUM]   0.00-10.00  sec  1.56 GBytes  1.34 Gbits/sec  32371             sender
[SUM]   0.00-10.00  sec  1.55 GBytes  1.33 Gbits/sec                  receiver

Wireguard:
Command: iperf3 -c <IP_ADDRESS> -P 10
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   128 MBytes   108 Mbits/sec   89             sender
[  4]   0.00-10.00  sec   127 MBytes   107 Mbits/sec                  receiver
[  6]   0.00-10.00  sec   110 MBytes  91.9 Mbits/sec   67             sender
[  6]   0.00-10.00  sec   109 MBytes  91.2 Mbits/sec                  receiver
[  8]   0.00-10.00  sec   191 MBytes   161 Mbits/sec   66             sender
[  8]   0.00-10.00  sec   190 MBytes   159 Mbits/sec                  receiver
[ 10]   0.00-10.00  sec   131 MBytes   110 Mbits/sec   53             sender
[ 10]   0.00-10.00  sec   131 MBytes   110 Mbits/sec                  receiver
[ 12]   0.00-10.00  sec   111 MBytes  92.8 Mbits/sec   82             sender
[ 12]   0.00-10.00  sec   110 MBytes  92.1 Mbits/sec                  receiver
[ 14]   0.00-10.00  sec   165 MBytes   139 Mbits/sec   94             sender
[ 14]   0.00-10.00  sec   164 MBytes   138 Mbits/sec                  receiver
[ 16]   0.00-10.00  sec   154 MBytes   129 Mbits/sec   56             sender
[ 16]   0.00-10.00  sec   153 MBytes   128 Mbits/sec                  receiver
[ 18]   0.00-10.00  sec   288 MBytes   241 Mbits/sec   47             sender
[ 18]   0.00-10.00  sec   285 MBytes   239 Mbits/sec                  receiver
[ 20]   0.00-10.00  sec   178 MBytes   149 Mbits/sec  102             sender
[ 20]   0.00-10.00  sec   176 MBytes   148 Mbits/sec                  receiver
[ 22]   0.00-10.00  sec   159 MBytes   133 Mbits/sec   57             sender
[ 22]   0.00-10.00  sec   158 MBytes   133 Mbits/sec                  receiver
[SUM]   0.00-10.00  sec  1.58 GBytes  1.35 Gbits/sec  713             sender
[SUM]   0.00-10.00  sec  1.57 GBytes  1.34 Gbits/sec                  receiver

Config:
Wireguard:
HightCPU-1
[Interface]
PrivateKey =
Address = <IP_ADDRESS>/24
PostUp   = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens4 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens4 -j MASQUERADE
ListenPort = 23456
DNS = <IP_ADDRESS>
MTU = 1200

[Peer]
PublicKey =
AllowedIPs = <IP_ADDRESS>/32

HighCPU-2
[Interface]
PrivateKey =
Address = <IP_ADDRESS>/24
PostUp   = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens4 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -D FORWARD -o wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens4 -j MASQUERADE
ListenPort = 23456
DNS = <IP_ADDRESS>
MTU = 1200

[Peer]
PublicKey =
Endpoint = <IP_ADDRESS>:23456
AllowedIPs = <IP_ADDRESS>/32
PersistentKeepalive = 25

Nebula:
HighCPU-1
pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/host.crt
  key: /etc/nebula/host.key

static_host_map:

lighthouse:
  am_lighthouse: true
  serve_dns: false
  dns:
    host: <IP_ADDRESS>
    port: 53
  interval: 20
  hosts:

listen:
  host: <IP_ADDRESS>
  port: 12345

punchy: true
punch_back: true

cipher: chachapoly

tun:
  dev: neb0
  drop_local_broadcast: false
  drop_multicast: false
  tx_queue: 500
  mtu: 1300
  routes:
  unsafe_routes:

logging:
  level: info
  format: text

firewall:
  conntrack:
    tcp_timeout: 120h
    udp_timeout: 3m
    default_timeout: 10m
    max_connections: 100000

  outbound:
    # Allow all outbound traffic from this node
    - port: any
      proto: any
      host: any

  inbound:
    - port: any
      proto: any
      host: any

    # Allow icmp between any nebula hosts
    - port: any
      proto: icmp
      host: any

    # Allow tcp/443 from any host with BOTH laptop and home group
    - port: 443
      proto: tcp
      groups:
        - laptop
        - home

HighCPU-2
pki:
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/host.crt
  key: /etc/nebula/host.key

static_host_map:
  "<IP_ADDRESS>": ["<IP_ADDRESS>:12345"]

lighthouse:
  am_lighthouse: false
  serve_dns: false
  dns:
    host: <IP_ADDRESS>
    port: 53
  interval: 20
  hosts:
    - "<IP_ADDRESS>"

listen:
  host: <IP_ADDRESS>
  port: 0

punchy: true
punch_back: true

cipher: chachapoly

tun:
  dev: neb0
  drop_local_broadcast: false
  drop_multicast: false
  tx_queue: 500
  mtu: 1300
  routes:
  unsafe_routes:

logging:
  level: info
  format: text

firewall:
  conntrack:
    tcp_timeout: 120h
    udp_timeout: 3m
    default_timeout: 10m
    max_connections: 100000

  outbound:
    # Allow all outbound traffic from this node
    - port: any
      proto: any
      host: any

  inbound:
    - port: any
      proto: any
      host: any

    # Allow icmp between any nebula hosts
    - port: any
      proto: icmp
      host: any

    # Allow tcp/443 from any host with BOTH laptop and home group
    - port: 443
      proto: tcp
      groups:
        - laptop
        - home

It seems like your result is fine now, then?
One thing I just realized may affect your earlier tests: If you have wireguard running between the hosts, it is possible nebula will go over that wireguard tunnel and you'll be encrypting every packet twice. For all tests with nebula, make sure wireguard is not running, as nebula discovers all of the different interfaces on a host and if that link is up, it may be used.

If this is the case, #52 is related.

@rawdigits I intended to do the follow-up about the performance in the VM with the moderate or low specification. And yes, when it comes to the machine with lower spec, this happened.
Indirectly, it proofs that nebula cost more computing resources than wireguard.
You mentioned that Wireguard "being in the kernel". I considered this as that WireGuard patch the kernel. Maybe this causes the difference on performance.
But, am I so mean? If so, I'm sorry about that.
Same, GCP servers. The configs are literally the same (I use the snapshots) so I won't post again.

 OS Release:            Ubuntu 18.04.3 LTS (Bionic Beaver)  (x86_64)
 CPU Model:             Intel(R) Xeon(R) CPU @ 2.20GHz
 CPU Cache Size:        56320 KB
 CPU Number:            2 vCPU
 Virt Type:             KVM
 Memory Usage:          237.87 MB / 7.30 GB
 Swap Usage:            [ No Swapfile/Swap Partition ]
 Boot Device:           /dev/sda1
 Disk Usage:            1.59 GB / 9.98 GB
 CPU Usage:             4.2% used, 0.6% iowait, 0.0% steal
 Load (1/5/15min):      0.20 0.20 0.10
 Uptime:                0 Days, 0 Hours, 15 Minutes, 57 Seconds

Result:
TCP Raw:
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   694 MBytes   582 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   693 MBytes   581 Mbits/sec                  receiver
[  6]   0.00-10.00  sec  1.40 GBytes  1.20 Gbits/sec    0             sender
[  6]   0.00-10.00  sec  1.40 GBytes  1.20 Gbits/sec                  receiver
[  8]   0.00-10.00  sec   871 MBytes   730 Mbits/sec    0             sender
[  8]   0.00-10.00  sec   869 MBytes   729 Mbits/sec                  receiver
[ 10]   0.00-10.00  sec  1.90 GBytes  1.63 Gbits/sec    0             sender
[ 10]   0.00-10.00  sec  1.89 GBytes  1.63 Gbits/sec                  receiver
[ 12]   0.00-10.00  sec   899 MBytes   754 Mbits/sec    0             sender
[ 12]   0.00-10.00  sec   898 MBytes   753 Mbits/sec                  receiver
[ 14]   0.00-10.00  sec   824 MBytes   691 Mbits/sec    0             sender
[ 14]   0.00-10.00  sec   823 MBytes   690 Mbits/sec                  receiver
[ 16]   0.00-10.00  sec   691 MBytes   580 Mbits/sec    0             sender
[ 16]   0.00-10.00  sec   690 MBytes   579 Mbits/sec                  receiver
[ 18]   0.00-10.00  sec   894 MBytes   750 Mbits/sec    0             sender
[ 18]   0.00-10.00  sec   892 MBytes   748 Mbits/sec                  receiver
[ 20]   0.00-10.00  sec  2.44 GBytes  2.09 Gbits/sec    0             sender
[ 20]   0.00-10.00  sec  2.43 GBytes  2.09 Gbits/sec                  receiver
[ 22]   0.00-10.00  sec   888 MBytes   745 Mbits/sec    0             sender
[ 22]   0.00-10.00  sec   886 MBytes   743 Mbits/sec                  receiver
[SUM]   0.00-10.00  sec  11.4 GBytes  9.75 Gbits/sec    0             sender
[SUM]   0.00-10.00  sec  11.3 GBytes  9.74 Gbits/sec                  receiver

Wireguard:
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   246 MBytes   206 Mbits/sec   96             sender
[  4]   0.00-10.00  sec   245 MBytes   206 Mbits/sec                  receiver
[  6]   0.00-10.00  sec   199 MBytes   167 Mbits/sec  171             sender
[  6]   0.00-10.00  sec   198 MBytes   166 Mbits/sec                  receiver
[  8]   0.00-10.00  sec   131 MBytes   110 Mbits/sec  165             sender
[  8]   0.00-10.00  sec   130 MBytes   109 Mbits/sec                  receiver
[ 10]   0.00-10.00  sec   161 MBytes   135 Mbits/sec  161             sender
[ 10]   0.00-10.00  sec   160 MBytes   134 Mbits/sec                  receiver
[ 12]   0.00-10.00  sec   250 MBytes   210 Mbits/sec  170             sender
[ 12]   0.00-10.00  sec   248 MBytes   208 Mbits/sec                  receiver
[ 14]   0.00-10.00  sec   243 MBytes   204 Mbits/sec   69             sender
[ 14]   0.00-10.00  sec   242 MBytes   203 Mbits/sec                  receiver
[ 16]   0.00-10.00  sec   379 MBytes   318 Mbits/sec  174             sender
[ 16]   0.00-10.00  sec   376 MBytes   315 Mbits/sec                  receiver
[ 18]   0.00-10.00  sec   279 MBytes   234 Mbits/sec  111             sender
[ 18]   0.00-10.00  sec   277 MBytes   233 Mbits/sec                  receiver
[ 20]   0.00-10.00  sec   190 MBytes   159 Mbits/sec  143             sender
[ 20]   0.00-10.00  sec   188 MBytes   158 Mbits/sec                  receiver
[ 22]   0.00-10.00  sec   187 MBytes   157 Mbits/sec  125             sender
[ 22]   0.00-10.00  sec   186 MBytes   156 Mbits/sec                  receiver
[SUM]   0.00-10.00  sec  2.21 GBytes  1.90 Gbits/sec  1385             sender
[SUM]   0.00-10.00  sec  2.20 GBytes  1.89 Gbits/sec                  receiver

Nebula (aes): [Already turned off the Wireguard]
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  93.8 MBytes  78.7 Mbits/sec  2375             sender
[  4]   0.00-10.00  sec  93.4 MBytes  78.3 Mbits/sec                  receiver
[  6]   0.00-10.00  sec   109 MBytes  91.7 Mbits/sec  2488             sender
[  6]   0.00-10.00  sec   109 MBytes  91.4 Mbits/sec                  receiver
[  8]   0.00-10.00  sec  81.5 MBytes  68.4 Mbits/sec  2292             sender
[  8]   0.00-10.00  sec  81.2 MBytes  68.1 Mbits/sec                  receiver
[ 10]   0.00-10.00  sec  65.6 MBytes  55.1 Mbits/sec  2021             sender
[ 10]   0.00-10.00  sec  65.2 MBytes  54.7 Mbits/sec                  receiver
[ 12]   0.00-10.00  sec  75.3 MBytes  63.2 Mbits/sec  1988             sender
[ 12]   0.00-10.00  sec  75.1 MBytes  63.0 Mbits/sec                  receiver
[ 14]   0.00-10.00  sec  88.1 MBytes  73.9 Mbits/sec  2398             sender
[ 14]   0.00-10.00  sec  87.9 MBytes  73.7 Mbits/sec                  receiver
[ 16]   0.00-10.00  sec  74.7 MBytes  62.6 Mbits/sec  1941             sender
[ 16]   0.00-10.00  sec  74.1 MBytes  62.2 Mbits/sec                  receiver
[ 18]   0.00-10.00  sec  82.2 MBytes  68.9 Mbits/sec  2186             sender
[ 18]   0.00-10.00  sec  81.8 MBytes  68.6 Mbits/sec                  receiver
[ 20]   0.00-10.00  sec  58.1 MBytes  48.7 Mbits/sec  1924             sender
[ 20]   0.00-10.00  sec  57.8 MBytes  48.5 Mbits/sec                  receiver
[ 22]   0.00-10.00  sec  83.8 MBytes  70.3 Mbits/sec  2206             sender
[ 22]   0.00-10.00  sec  83.4 MBytes  70.0 Mbits/sec                  receiver
[SUM]   0.00-10.00  sec   812 MBytes   681 Mbits/sec  21819             sender
[SUM]   0.00-10.00  sec   809 MBytes   678 Mbits/sec                  receiver

Nebula (chachapoly):
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  92.3 MBytes  77.4 Mbits/sec  2041             sender
[  4]   0.00-10.00  sec  92.0 MBytes  77.1 Mbits/sec                  receiver
[  6]   0.00-10.00  sec  75.7 MBytes  63.5 Mbits/sec  2119             sender
[  6]   0.00-10.00  sec  75.4 MBytes  63.2 Mbits/sec                  receiver
[  8]   0.00-10.00  sec  83.5 MBytes  70.0 Mbits/sec  2199             sender
[  8]   0.00-10.00  sec  83.2 MBytes  69.8 Mbits/sec                  receiver
[ 10]   0.00-10.00  sec  62.7 MBytes  52.6 Mbits/sec  1975             sender
[ 10]   0.00-10.00  sec  62.2 MBytes  52.2 Mbits/sec                  receiver
[ 12]   0.00-10.00  sec  66.1 MBytes  55.5 Mbits/sec  2014             sender
[ 12]   0.00-10.00  sec  65.7 MBytes  55.1 Mbits/sec                  receiver
[ 14]   0.00-10.00  sec  63.3 MBytes  53.1 Mbits/sec  2005             sender
[ 14]   0.00-10.00  sec  63.0 MBytes  52.9 Mbits/sec                  receiver
[ 16]   0.00-10.00  sec  79.0 MBytes  66.2 Mbits/sec  2054             sender
[ 16]   0.00-10.00  sec  78.7 MBytes  66.0 Mbits/sec                  receiver
[ 18]   0.00-10.00  sec  80.8 MBytes  67.8 Mbits/sec  2097             sender
[ 18]   0.00-10.00  sec  80.5 MBytes  67.5 Mbits/sec                  receiver
[ 20]   0.00-10.00  sec  82.0 MBytes  68.7 Mbits/sec  2161             sender
[ 20]   0.00-10.00  sec  81.7 MBytes  68.5 Mbits/sec                  receiver
[ 22]   0.00-10.00  sec  78.9 MBytes  66.2 Mbits/sec  1855             sender
[ 22]   0.00-10.00  sec  78.6 MBytes  65.9 Mbits/sec                  receiver
[SUM]   0.00-10.00  sec   764 MBytes   641 Mbits/sec  20520             sender
[SUM]   0.00-10.00  sec   761 MBytes   638 Mbits/sec                  receiver

@nfam It seems Nebula needs at least 4 vCPUs to perform best.

It really depends. For benchmarks like iperf3 you could just change your nebula MTU (in config.yaml) to 8600 and you'll probably max out the interface. Whether that is useful depends on the workloads you use. If you are sending around large files on nodes sitting next to each other, jumbo MTU is the way to go.
I explain a bit here: https://arstechnica.com/gadgets/2019/12/how-to-set-up-your-own-nebula-mesh-vpn-step-by-step/?comments=1&post=38427375

@rawdigits You're right. After I set the MTU into 8600, it can reach 1.72 Gbps. Thank you for telling me the right way to test.
I change the title. Recently I will test the maximum bandwidth Nebula/WireGuard can reach on different VMs with different specifications/config's options. If something useful or the conclusion made, I will post here.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   184 MBytes   154 Mbits/sec  1144             sender
[  4]   0.00-10.00  sec   183 MBytes   153 Mbits/sec                  receiver
[  6]   0.00-10.00  sec   255 MBytes   214 Mbits/sec  1396             sender
[  6]   0.00-10.00  sec   253 MBytes   213 Mbits/sec                  receiver
[  8]   0.00-10.00  sec   191 MBytes   160 Mbits/sec  1151             sender
[  8]   0.00-10.00  sec   190 MBytes   159 Mbits/sec                  receiver
[ 10]   0.00-10.00  sec   136 MBytes   114 Mbits/sec  907             sender
[ 10]   0.00-10.00  sec   135 MBytes   113 Mbits/sec                  receiver
[ 12]   0.00-10.00  sec   282 MBytes   237 Mbits/sec  1617             sender
[ 12]   0.00-10.00  sec   281 MBytes   235 Mbits/sec                  receiver
[ 14]   0.00-10.00  sec   157 MBytes   131 Mbits/sec  1077             sender
[ 14]   0.00-10.00  sec   155 MBytes   130 Mbits/sec                  receiver
[ 16]   0.00-10.00  sec   163 MBytes   136 Mbits/sec  908             sender
[ 16]   0.00-10.00  sec   161 MBytes   135 Mbits/sec                  receiver
[ 18]   0.00-10.00  sec   220 MBytes   185 Mbits/sec  1263             sender
[ 18]   0.00-10.00  sec   219 MBytes   184 Mbits/sec                  receiver
[ 20]   0.00-10.00  sec   190 MBytes   159 Mbits/sec  1234             sender
[ 20]   0.00-10.00  sec   189 MBytes   158 Mbits/sec                  receiver
[ 22]   0.00-10.00  sec   210 MBytes   176 Mbits/sec  1131             sender
[ 22]   0.00-10.00  sec   209 MBytes   175 Mbits/sec                  receiver
[SUM]   0.00-10.00  sec  1.94 GBytes  1.67 Gbits/sec  11828             sender
[SUM]   0.00-10.00  sec  1.93 GBytes  1.66 Gbits/sec                  receiver

No worries, and thanks for the feedback. There are many variables to performance that it is hard to distill down to one useful benchmark. I definitely recommend pps (packets per second) as probably the limiting factor in most modern secure network tunnels.
Closing this one for now, but happy to reopen if needed.

@rawdigits
I tried with MTU 8600 with two machine in local LAN, (one ubuntu server and one Raspberry Pi3B+ )  the config is almost same with config in example except the light house node ip
I could perf with LAN ip with 95+Mbps but  with nebula the perf result is 45Mbps and with MTU 8600, is the data encrypt really took that much resource?

Chacha is definitely faster for devices that don't have AES-NI instructions (intel/amd x86 cpus primarily). Because my personal network has a lot of different devices, I use chacha for the entire network. If you are using nebula for a large set of production servers, AES-NI may be a better choice.

I've made my own benchmarks with my Raspberry Pi 4 (lighthouse) running Manjaro ARM from my laptop which is also running Manjaro, and i've got the following results:
nebula, AES, MTU = 1300:             ~ 115 MBits/s
nebula, AES, MTU = 8600:             ~ 150 MBits/s
nebula, chachapoly, MTU = 1300:  ~ 215 MBits/s
nebula, chachapoly, MTU = 8600:  ~ 150 MBits/s
direct connect:                                ~ 500 MBits/s
wireguard:                                       ~ 500 MBits/s

Both of the machines are in local area and i've used the iperf3 package.
I must be doing something wrong because according to the discussion setting MTU to 8600 would max out the connection, which is not what's happening. Since using MTU = 8600 actually decreases the speed while using chachapoly i assume that there's an issue at my end perhaps.
Raspberry Pi 4 (lighthouse):
pki:
  # every node needs a copy of the CA certificate,
  # and its own certificate and key, ONLY.
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/TinyPiNAS.crt
  key: /etc/nebula/TinyPiNAS.key

static_host_map:
  # how to find one or more lighthouse nodes
  # format "Nebula IP": ["public IP or hostname:port"]
  "<IP_ADDRESS>": ["----:1337"]

lighthouse:
  # if you're a lighthouse, say you're a lighthouse
  am_lighthouse: true

listen:
  # listen interface - "<IP_ADDRESS>" is a wildcard
  host: <IP_ADDRESS>
  port: 1337

# Cipher allows you to choose between the available ciphers for your network
# this value must be identical on all nodes/lighthouse
# chachapoly is less expensive for machines without AES built in the hardware
#cipher: chachapoly

# sensible defaults. don't monkey with these unless
# you're CERTAIN you know what you're doing.
tun:
  # Name of the device
  dev: nebula1

  # Toggles forwarding of local broadcast packets
  # the address of which depends on the ip/mask encoded in pki.cert
  drop_local_broadcast: false

  # Toggles forwarding of multicast packets
  drop_multicast: false

  # Sets the transmit queue length, if you notice lots of transmit drops
  # on the tun it may help to raise this number. Default is 500
  tx_queue: 500

  # Default MTU for every packet,
  # safe setting is (and the default) 1300 for internet based traffic
  mtu: 1300

logging:
  # panic, fatal, error, warning, info, or debug. Default is info
  level: info

  # json or text formats currently available. Default is text
  format: text

# Nebula has its own firewall in addition to anything
# your system has in place, and it's all default deny.
# So if you don't specify some rules here, you'll drop
# all traffic, and curse and wonder why you can't ping
# one node from another.
firewall:
  conntrack:
    tcp_timeout: 120h
    udp_timeout: 3m
    default_timeout: 10m
    max_connections: 100000

  # since everything is default deny, all rules you
  # actually SPECIFY here are allow rules.
  outbound:
    - port: any
      proto: any
      host: any

  inbound:
    - port: any
      proto: any
      host: any

Laptop:
pki:
  # every node needs a copy of the CA certificate,
  # and its own certificate and key, ONLY.
  ca: /etc/nebula/ca.crt
  cert: /etc/nebula/Legion.crt
  key: /etc/nebula/Legion.key

static_host_map:
 # how to find one or more lighthouse nodes
 # format "Nebula IP": ["public IP or hostname:port"]
 "<IP_ADDRESS>": ["---:1337"]

lighthouse:
  # if you're a lighthouse, say you're a lighthouse
  am_lighthouse: false

  # interval is the number of seconds between updates from this node
  # to a lighthouse. during updates, a node sends information about
  # its current IP addresses to each node.
  interval: 15

  hosts:
    # If you're NOT a lighthouse, list lighthouse nodes here, one per line
    # It's the internal IP not the global IP
    - "<IP_ADDRESS>"

listen:
  # listen interface - "<IP_ADDRESS>" is a wildcard
  host: <IP_ADDRESS>
  port: 1337

punchy:
  # Continues to punch inbound/outbound at a regular interval to avoid
  # expiration of firewall nat mappings
  punch: true

# Cipher allows you to choose between the available ciphers for your network
# this value must be identical on all nodes/lighthouse
# chachapoly is less expensive for machines without AES built in the hardware
#cipher: chachapoly

# sensible defaults. don't monkey with these unless
# you're CERTAIN you know what you're doing.
tun:
  # Name of the device
  dev: nebula1

  # Toggles forwarding of local broadcast packets
  # the address of which depends on the ip/mask encoded in pki.cert
  drop_local_broadcast: false

  # Toggles forwarding of multicast packets
  drop_multicast: false

  # Sets the transmit queue length, if you notice lots of transmit drops
  # on the tun it may help to raise this number. Default is 500
  tx_queue: 500

  # Default MTU for every packet,
  # safe setting is (and the default) 1300 for internet based traffic
  mtu: 1300

logging:
  # panic, fatal, error, warning, info, or debug. Default is info
  level: info

  # json or text formats currently available. Default is text
  format: text

# Nebula has its own firewall in addition to anything
# your system has in place, and it's all default deny.
# So if you don't specify some rules here, you'll drop
# all traffic, and curse and wonder why you can't ping
# one node from another.
firewall:
  conntrack:
    tcp_timeout: 120h
    udp_timeout: 3m
    default_timeout: 10m
    max_connections: 100000

  # since everything is default deny, all rules you
  # actually SPECIFY here are allow rules.
  outbound:
    - port: any
      proto: any
      host: any

  inbound:
    - port: any
      proto: any
      host: any

Also two small questions:

Considering the main use for nebula is gaming, default MTU should do it right? And all modern hardware have AES built in so i shouldn't be changing to chachapoly for this purpose?
Do i need static_host_map defined in my Raspberry Pi 4 (lighthouse)?


KARAF-3809: Fix issues under windows.

This PR is related to KARAF-3809: Fix issues under windows.

I don't fix it's a good idea to depend to sshd for this. Can you update the PR without sshd OsUtil dependency ?

I'm updating your PR anyway.

Guillaume already fixed the Builder. Can you close your PR ?


Unable to apply Enchantments as expected

Minecraft Version
1.20.1
What Mods Conflicts with
Apotheosis
Describe the Incompatibility
I was hoping that the hyper enchanting would allow for automatically applying an enchantment regardless of its level. With or without the additional benefits of Hyper enchanting there seems to be odd behaviour
There are two noticeable problems:
First, by using normal experience, with an efficiency V book, I get, as expected, an efficiency V netherite pickaxe.
With hyper experience I get efficiency IV
 So somewhere the calculation for the hyper xp boosts are lost.
Second, if I try to apply an efficiency IX book the pickaxe gets skipped and pushed down the line without enchanting

Other Mods
Apotheosis
Additional Context
I tried with  both hyper experience and normal

While I can see the problems that could arise from just letting the book determine the level (ping ponging back and forth between enchant/disenchant to re-enchant, it would be nice to be able to have this provided through a data pack for what enchantments level should be. A recommendation for that is to gather all the registered values (say multiple mods set in a json that efficiency's max value) and take the highest. This way both mod makers and pack makers could make a conscious choice for how they need the balancing to work without having a rigid config setting.
Crash Report or Log
No response
Mod Version
create_enchantment_industry-1.20.1-for-create-0.5.1.e-1.2.6.d.jar
Incompatible Mod Version
Apotheosis-1.20.1-7.0.5.jar
Forge Version
47.1.47

About first problem:
From the screenshot you given, with hyper experience you get efficiency VI instead of IV, which is expected behavior.
About second problem:
Could you please provide debug.log? If Apotheosis compat failed it will be depicted in debug.log.

About first problem: From the screenshot you given, with hyper experience you get efficiency VI instead of IV,

I can read........ MY BAD! I honestly thought in all of my checks even posting it was IV ...

Could you please provide debug.log? If Apotheosis compat failed it will be depicted in debug.log.

[05Oct2023 15:37:49.611] [Render thread/INFO] [net.minecraft.client.gui.components.ChatComponent/]: [CHAT] <Soaryn> MAKE PICK
[05Oct2023 15:37:56.781] [Server thread/DEBUG] [plus.dragons.createenchantmentindustry.EnchantmentIndustry/]: Failed to load EnchHooks from Apotheosis, fall back to vanilla method...
[05Oct2023 15:37:59.893] [Server thread/INFO] [net.minecraft.server.MinecraftServer/]: [Not Secure] <Soaryn> End-----------------------
[05Oct2023 15:37:59.896] [Render thread/INFO] [net.minecraft.client.gui.components.ChatComponent/]: [CHAT] <Soaryn> End-----------------------

Reflect fails on newest version. That's strange....
I'll check it. Thanks for reporting.

OK fixed!


Improvements. Audio and subtitles.

Add support for subtitles.
Add an option for download more than 1 audio track or subtitle when you go to merge into mkv

Yes, would love to download subtitles.


Fix S param script

Closes #15.
Note I'm merging into the "meep" branch, not master.

Thank you Alec @smartalecH


teleopti card list

introduce card list directive on the section 2.4 which it may be used by
others

Sorry for the delay to check this pr ..
As for https://github.com/Teleopti/styleguide/pull/10 could you move the directives outsite the vendor folder and add some tests please?

@lanzhiping Is this PR still relevant ?

I have finished the refactor according to what you advised, and then I am in the middle of an PBI. But there are an new feature "select multiple" in the real WFM project what I haven`t have a chance to merge to github, so... But I think I can push my current changes once I go back to office on Monday.


euphone, begemmed (logical-conflict)

This pull request was generated by the 'mq' tool

/trunk merge


usages: align flag types separately from names

Fixes spf13/cobra#856.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


xtools build hard-coded to use IAMCU compiler for all x86 targets

I have brew binutils 2.30 installed, but it installs it as "greadelf" and not "readelf" and CMake can't find it. Creating a symlink did not help.
 CMake Error at /Users/andrew/zephyr/cmake/extensions.cmake:984 (message):   No such file or directory: CMAKE_READELF: 'CMAKE_READELF-NOTFOUND' Call Stack (most recent call first):   /Users/andrew/zephyr/cmake/compiler/gcc.cmake:14 (assert_exists)   /Users/andrew/zephyr/cmake/toolchain.cmake:38 (include)   /Users/andrew/zephyr/cmake/app/boilerplate.cmake:242 (include)   CMakeLists.txt:1 (include)

We could improve the error message too.
"CMake Error at /Users/andrew/zephyr/cmake/extensions.cmake:984 (message): No such file or directory: CMAKE_READELF: 'CMAKE_READELF-NOTFOUND'"
Actually means that the build can't find the toolchain.

The error message is now a lot more useful.
I think it still shouldn't default to IAMCU for all x86 targets though.


Roundtrip testing

Added roundtrip tests to ensure that the library parses to the correct values.

should be handled with PR #118


Documentation clarification

You need to add
allowVolumeExpansion: true
to the page that talks about the configuration for the storage class. I know it is mentioned in the resize page but I think it should also be included as a configurable element to the storage class.
https://openebs.io/docs/user-guides/replicated-storage-user-guide/replicated-pv-mayastor/rs-configuration

@balaharish7 can we expand the docs on this?

This issue is documented in the PR #474.

Closing this as it's resolved.


GHC 8.10 and 9.0 Compatibility

This PR does four things:

Repairs some tests
Opens up compatibility with more servant-client versions
Ups the cabal file spec version
Updates dependency bounds

Thanks mostly thanks to the loosening of the servant constraints, I have been able to successfully build this package under GHC 8.6.5, 8.8.4, 8.10.7 and 9.0.1
Tests
The test repairs cover 3 problems:

runIntegrationSpec expected SpecWith to satisfy the MonadFail constraint which isn't the case (at least with with modern hspec versions).
The /getFile test assumed that it would get a successful response (which wasn't happening).
Sticker tests were checking that a returned sticker was correct with an id field that can no-longer be considered unchanging for each sticker, so I added the sticker_file_unique_id field from the current version of the telegram API.

⚠The addition of the sticker_file_unique_id adds to the interface so at least a minor version bump will be required on release.
What this doesn't do is guarantee that all tests are working nor fix all failing tests that may be a result from incompatibilities with the current version of the Telegram API.
Servant-Client Compatibility
Most of the incompatibility seemed to come from dependence on internal servant modules which subsequently underwent minor changes like renamings.
The fixes should be simple and self-explanatory. All tests except 1 passed, which I believe to be is unrelated and caused by an outdated hardcoded file id
  test/TestCore.hs:15:15:
  1) Main integration tests, /getFile, should get file
       predicate failed on: Left (FailureResponse (Request {requestPath = (BaseUrl {baseUrlScheme = Https, baseUrlHost = "api.telegram.org", baseUrlPort = 443, baseUrlPath = ""},"/bot1159302136:AAG8MeT_d3Ds2gPlso1Zur0yIBVOhR8bztk/getFile"), requestQueryString = fromList [("file_id",Just "AAQEABMXDZEwAARC0Kj3twkzNcMkAAIC")], requestBody = Nothing, requestAccept = fromList [application/json;charset=utf-8,application/json], requestHeaders = fromList []), requestHttpVersion = HTTP/1.1, requestMethod = "GET"} (Response {responseStatusCode = Status {statusCode = 400, statusMessage = "Bad Request"}, responseHeaders = fromList [("Server","nginx/1.18.0"),("Date","Mon, 18 Oct 2021 15:19:34 GMT"),("Content-Type","application/json"),("Content-Length","111"),("Connection","keep-alive"),("Strict-Transport-Security","max-age=31536000; includeSubDomains; preload"),("Access-Control-Allow-Origin","*"),("Access-Control-Expose-Headers","Content-Length,Content-Type,Date,Server,Connection")], responseHttpVersion = HTTP/1.1, responseBody = "{\"ok\":false,\"error_code\":400,\"description\":\"Bad Request: wrong file_id or the file is temporarily unavailable\"}"}))

This fixes #132
To maintain compatibility between both old and new versions of servant I had to resort to a little CPP usage.
I'd prefer to avoid it since in my experience it tends to cause problems with tooling, but dropping compatability with servant-client 0.16 would also drop support with stackage LTS 14, 15 and 16 and therefore support for GHC 8.6 and 8.8 for stackage users.
I expect it may be possible to avoid depending on the internal modules to make this less of an issue.
Upping the Cabal Spec Version
The cabal file was originally on cabal-version >=1.10
Later cabal versions add convenient improvements to cabal file syntax and also provide more information so that tools lik HLS can function, IIRC, such as through the autogen-modules field.
I don't think it likely that there are any users out there who desperately need support for old versions of cabal or stack so I don't think it's too much of an issue to drop support for them.
As such I've upped the cabal-version to 3.4, and made some adjustments to make it compliant.
Dependency bounds.
I have added upper and lower bounds to every library dependency in accordance with the Hackage PVP. This will avoid tools resolving build plans that seem valid but lead to build errors.
These bounds are broad enough to build on GHC 8.6.5 through to GHC 9.0.1 according to my testing.
This fixes #130.
The dependency bounds on servant libs currently look a little odd:
, servant (>= 0.16 && < 0.18) || ^>= 0.18
, servant-client (>= 0.16 && < 0.18) || ^>= 0.18
, servant-client-core (>= 0.16 && < 0.18) || ^>= 0.18

This is because the ^>= 0.18 has subtly different semantics from < 0.19
I could've just done this:
, servant ^>= {0.16, 0.17, 0.18}
, servant-client ^>= {0.16, 0.17, 0.18}
, servant-client-core ^>= {0.16, 0.17, 0.18}

But as more major versions come along those sets are only going to get larger.
I'm happy to change it if preferred.

Hey! Thanks a lot for the effort.
Are there any plans to merge this?
The repo seems a bit abandonded.

Thanks for this PR! I’m trying to use it with nixpks-22.05, but am hitting
[ 1 of 16] Compiling Servant.Client.MultipartFormData ( src/Servant/Client/MultipartFormData.hs, dist/build/Servant/Client/MultipartFormData.o )

src/Servant/Client/MultipartFormData.hs:94:49: error:
    Ambiguous occurrence ‘//’
    It could refer to
       either ‘Network.HTTP.Media.//’,
              imported from ‘Network.HTTP.Media’ at src/Servant/Client/MultipartFormData.hs:34:1-35
              (and originally defined in ‘Network.HTTP.Media.MediaType’)
           or ‘Servant.Client.//’,
              imported from ‘Servant.Client’ at src/Servant/Client/MultipartFormData.hs:39:1-31
              (and originally defined in ‘Servant.Client.Core.HasClient’)
   |
94 |                  Nothing -> pure $ "application"//"octet-stream"
   |                                                 ^^

(Ok, granted, I am forcing the use of the dependencies provided by nixpkgs-22.05, so I should probably investigate myself…)
As @ppmdo says, this repo seems to be relatively abandonned. Do you maybe want to take over the package, @DrewFenwick?

Ok, that’s easy to fix, but I am not sure what to do about
[ 1 of 16] Compiling Servant.Client.MultipartFormData ( src/Servant/Client/MultipartFormData.hs, dist/build/Servant/Client/MultipartFormData.o )

src/Servant/Client/MultipartFormData.hs:55:10: warning: [-Wmissing-methods]
    • No explicit implementation for
        ‘hoistClientMonad’
    • In the instance declaration for
        ‘HasClient m (MultipartFormDataReqBody b :> Post cts' a)’
   |
55 | instance (Core.RunClient m, ToMultipartFormData b, MimeUnrender ct a, cts' ~ (ct ': cts)
   |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...

and unfortunately, https://hackage.haskell.org/package/servant-client-core-0.19/changelog does not give any migration advise.

This might work?


Error downloading same dataset once more

From @forman on June 28, 2017 10:43
Cate Desktop, version 0.8.0-rc.7.dev.2
Multiple data sources with the name "esacci.SEAICE.day.L4.SICONC.multi-sensor.multi-platform.AMSR_50kmEASE2.2-0.NH" found
An error (code 10) occurred while executing a backend process:
Traceback (most recent call last):
File "C:\Users\Norman\IdeaProjects\ccitools\cate-core\cate\util\web\jsonrpchandler.py", line 163, in send_service_method_result
result = future.result()
File "C:\Users\Norman\Miniconda3\envs\cate\lib\concurrent\futures_base.py", line 398, in result
return self.__get_result()
File "C:\Users\Norman\Miniconda3\envs\cate\lib\concurrent\futures_base.py", line 357, in __get_result
raise self._exception
File "C:\Users\Norman\Miniconda3\envs\cate\lib\concurrent\futures\thread.py", line 55, in run
result = self.fn(*self.args, **self.kwargs)
File "C:\Users\Norman\IdeaProjects\ccitools\cate-core\cate\util\web\jsonrpchandler.py", line 216, in call_service_method
result = method(*method_params, monitor=monitor)
File "C:\Users\Norman\IdeaProjects\ccitools\cate-core\cate\webapi\websocket.py", line 183, in make_ds_local
raise ValueError('Multiple data sources with the name "%s" found' % data_source_name)
ValueError: Multiple data sources with the name "esacci.SEAICE.day.L4.SICONC.multi-sensor.multi-platform.AMSR_50kmEASE2.2-0.NH" found
Copied from original issue: CCI-Tools/cate-desktop#22

Not sure if this still applies


Error in Example 2?

Are there errors in "Example 2"?
It first says that "Contoso Fleet Analytics has 60,000 devices", but then does the calculation with 20,000 devices.
Also the sentence "They are using an IoT Hub 24 partition count of 4 as the Time Series Insights event source." doesn't parse.. what's the 24 doing in "IoT Hub 24 partition count of 4"?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: e984b8e1-6bcb-cdbd-1cbc-cd7fafeb6b29
Version Independent ID: 9612407a-f749-42c9-d2e0-331318427fe5
Content: Data storage and ingress in Preview - Azure Time Series Insights
Content Source: articles/time-series-insights/time-series-insights-update-storage-ingress.md
Service: time-series-insights
GitHub Login: @lyrana
Microsoft Alias: lyhughes

Hi @stmax82 there is indeed, this will be fixed

PR created
#please-close


Suggestion packing to npm repo or chocolatey

I would like to use installing this tool not building.
Like https://chocolatey.org/packages/youtube-dl
Commands to will be used:
choco install destreamer
or
npm install -g destreamer
and run destreamer -i "https://web.microsoftstream.com/video/VIDEO-1" in any folders.

We don't have a choco script and I don't know if we ever will, but I'll add it to the possible enchantment list


When realease the training code?

Sorry, due to company policy and the fact that both myself and another key member resigned two months ago, the code is considered a risk file and cannot be taken out of the company. If you have any other detailed questions, please feel free to ask.


win32 installation problems

Hello. Firstly i want to say thanks for your work.
Today i tried to install sqip on my laptop with windows 10. And found few problems:

child_process.execSync('type primitive') works incorrect for me (in checkForPrimitive function).
process.env.PWD return undefined (in getInputfilePath function).

I fix that issues and create pull request (#14). Now all work good for me.
Please, check my solution. Maybe i do something wrong.
Thanks.

@mbalabash Thank you so much for the Pull Request (https://github.com/technopagan/sqip/pull/14) that fixes this issue! Awesome! 👍


cargo fetch fails on stable when an optional dependency uses nightly cargo features

The cargo fetch command fetches all the dependencies available, including optional ones. This was fine before cargo nightly features were introduced, but it's starting to cause problems now.
When an optional dependency now uses a nightly-only feature, building the crate works fine since the optional dependency is not pulled in, but running cargo fetch on stable errors out because the optional dependency is using the feature, and features are not allowed on stable.
Steps to reproduce:
$ cargo init foo
$ cd foo
$ echo 'clippy = { version = "*", optional = true }' > Cargo.toml
$ cargo build # works fine
$ cargo fetch # errors out

Some chat about this on #rust-infra

It looks like this is unfortunately not easy to fix in Cargo right now. Gating on the ability to use nightly features happens pretty deep within Cargo and otherwise providing a path to avoid doing things like parsing the manifest currently results in a good deal of duplication.
@pietroalbini what's the current impact of this on crater? Does it mean that stable->beta runs have lots of regressions? Or lots of build failures?

The impact of this on crater is something like 200 crates that can't be built. Crater can easily be fixed though: we just need to add the magic environment variable to turn on nightly features when executing cargo fetch, so it's not really a problem.
I opened the issue mostly to see if this can be fixed for everyone else: it's not a good UX having cargo fetch that fails while cargo build works. Since properly fixing this seems to be hard, would it be easier to turn errors into warnings during cargo fetch?

Hm yeah this certainly isn't impossible to fix by any stretch! We'd basically need to tweak how the errors are reported about gated features manifests and do something differently when downloading vs compiling. That's nontrivial compared to ignoring one error somewhere, but not impossible!


Fix: Syntax files don't match short SHA1 refs longer than 7

Git will only generate short SHA1 refs that are 7 characters long if the 7 character ref is unambiguous. For larger repositories Git will begin to generate larger short SHA1 refs to keep refs unambiguous. This fix allows GitSavvy to correctly highlight refs longer than 7 characters.
See http://git-scm.com/book/en/v2/Git-Tools-Revision-Selection#Short-SHA-1 for more information.
Closes #323.

Looks good! Thanks for the fix, @ddevlin!

This is great!  I'd also like for the short-hashes to be padded on the right, so that the next column lines up.  How do you feel about adding that to this PR?  If you're not comfortable giving it a try, we can split that off into a separate ticket and merge this in as-is.

Going to merge this as-is.


empty-block report about empty functions

Bug Report

TSLint version: 4.3.1
TypeScript version: 2.1.5
Running TSLint via:  CLI

TypeScript code being linted
function f() {}

with tslint.json configuration:
{
   "no-empty": true
}

Actual behavior
Error: block is empty.
Expected behavior
No error (like in eslint). Eslint has separate rule for this case http://eslint.org/docs/rules/no-empty-function, which also covers empty constructors.

we could take a PR for a rule option to the existing rule to allow-empty-functions. I would rather add a new option here rather than bloat the list of rules

Close issue, because related PR https://github.com/palantir/tslint/pull/3624 was merged.


Performance with large amount of data

Hi, your component looks great and very promising. I was about to build something using FlatList horizontal and pagingEnabled, because I need to handle up to thousands of slides. Will this be still performant with your library? I haven’t digged in very deeply so far into your codebase, but it looks like you already kinda lazy render the elements, right?
Thank you!

hi there -- i think so, but know that it unmounts components outside of the adjacentChildren range, so long as your slides don't need to store their latent state (e.g scrollposition or some kind of other UI state) then it might be a good option

For now, it will be just a big image and some profile informations (building a facebook/instagram story viewer), so this might be a good one for me. I'm excited to try out
Do you think 3D Cube transitions would be possible? I actually want to replace this with native-pager now. If this is not feasible I'll go for another animation. But would be nice to have.
https://github.com/wcandillon/can-it-be-done-in-react-native/blob/master/season1/instagram-stories/components/Stories3.js
This approach uses reanimated.
(See my GIF attached, looks great, but it lacks badly in performance after only 20 slides, since it uses a ScrollView and renders everything at once). Do you think something like this is possible? Code is already nearly there.

i would think so - if you're familiar with and are using interpolated values, then you should be able to update transform properties of your screens -- i would look at the pageInterpolation prop

I'm pretty new to it, I'll try to achieve it. Might be worth for your examples though if this is achievable. (Would drop a 100$ donation/bounty for it)

Your Component IS JUST AWESOME. I had one special component which relied on FileSystem (for caching image into filesystem) which made your component stutter extremely (UI drops to 20-30fps), but after removing it, it runs just SO AMAZINGLY smooth. 59-60 fps no matter how fast I slide. This is by far the best swiping component I've seen.
My offer is valid. 100 $ tip for integrating the cube transition (nice to have with the mask, if not possible its even ok without)


GH-395: Add CorrelatedProducerListener

Resolves https://github.com/spring-projects/spring-kafka/issues/395
SCSt needs a reference to the sent message in order to generate an error message on a send failure.

I believe we need to cherry-pick this back to all versions (to 1.1.x) - minus the KafkaOperations changes.

Now I see what you mean - the user provides the callback. OK; will rework.


mojave-xcode-10.2 & mojave-flutter upgrades

Xcode 10.2 has been released just now and includes a ABI stable version of Swift, 5.0.
Cirrus should support the new Xcode version & also update the flutter vm image.

Waiting for it to appear here so it can be installed through command-line.

mojave-xcode-10.2 is now available 🙌

Fantastic. Can we also create a mojave-flutter-xcode-10.2 image, to be somewhat sure it won't break builds for others..

@fkorotkov thx for your help


Cannot get adapter on somewhat older Windows laptop

Machine:

A 5 year old HP Pavilion x360 Convertible
Intel(R) Core(TM) i3-6100U CPU
Windows 10 x64

Wgpu won't give me an adapter, instead it errors with:
viewport Y-flip is not supported, hiding the adapter: Intel(R) HD Graphics 520
thread '<unnamed>' panicked at 'Unable to request adapter: NotFound', src\device.rs:49:10

The wgpu code that raises the error is here:
https://github.com/gfx-rs/wgpu/blob/f25a45f4e2588ed39183dc068b69f2aebfa6aa66/wgpu-hal/src/vulkan/adapter.rs#L858-L867

I can make it work, sortof by doing both of these:

Make it use DX12, either by forcing it, or by disabling the windows-specific override to use Vulkan.
Disable the WGPUNativeFeature_TEXTURE_ADAPTER_SPECIFIC_FORMAT_FEATURES.

However, without that native-feature-flag, float32 textures cannot be interpolated, and we assume that they do in pygfx.

Well.. intel graphics are typically very lacking on the feature spectrum.

Well.. intel graphics are typically very lacking on the feature spectrum.

Yes, but 5 years is not that old ...

My Vulkan version was 1.0.31, which is smaller than 1.2, so it ticks one of the checks in the Rust code above. I tried to upgrade my graphics driver, which was ... interesting. The short summary/recipy is:

Open the Intel driver detection page: https://www.intel.com/support/go/gfx/dl.html
Let it detect your system settings, and search for the graphics section.
There you find a button to install the driver.
Alternatively, it may tell that you have custom drivers from your laptop manufacturer (e.g. HP). You could try to upgrade these instead. I personally found that these were outdated (from 2018), so instead I uninstalled my current graphics driver and went back to the first bulletpoint of this list.

Eventually, it now works again! Using the Vulkan backend and with float-sampling enabled! 🎉
Takeaway: on older machines you may want to make sure your graphics driver is up-to-date (with the vanilla Intel drivers).


Where are you seeing any usages of mcrypt? Just want to make sure we're looking at the same thing.
Thanks for the help!

I merely noticed it in the system requirements, have not had the chance to use it yet. Why is it required?

That was actually left over from older Laravel 5.0 documentation. Thanks for catching that!
Fixed with commit : f6a59a8cf35ec44f9f6021ad6a69e524a6861101


How to attach to existing opened windows application

Hello,
I am using Appium and trying to attach to an existing app, but I always receive the following error SessionNotCreated below:

My code is same of issue #569:

can someone understand why?
During the framework execution , I have open 3 applications before the one I am calling (that gives the error).
I am using this way to open the application because it has unusual long startup time.
thanks

@danielemarinelli Looks like you are trying to attach to the incorrect window ("...is not top level window...")
Maybe the title of the main window is not the same as you expected... (you can try to look on app title in 'process explorer' app).
Also, try to find all windows by title and attach to each of them.
I suggest attaching by process #534 (comment)

Thanks for the answer @Shakevg.
Probably I wasn't catching the window title.
I will try #534 too.


Add defined() guard for checkout_llvm build flag

Adds a guard before uses of the checkout_llvm flag, defaulting it to
false when unset. This prevents breakages when used in trees that hasn't
defined that gn flag.
Also fixed manually in topaz in:
https://turquoise-internal-review.googlesource.com/c/integration/+/133882

Closing to send via git cl upload. It's been a while since I've sent a patch to the SDK it seems :)


Error While Running train.py

I am getting this error when I try to run train.py, any idea why ?? Thanks
Traceback (most recent call last):
File "C:\Users...\AppData\Roaming\Python\Python35\site-packages\tensorflow\python\client\session.py", line 1039, in _do_call
return fn(*args)
File "C:\Users...\AppData\Roaming\Python\Python35\site-packages\tensorflow\python\client\session.py", line 1021, in _run_fn
status, run_metadata)
File "C:\Users...\AppData\Local\Programs\Python\Python35\lib\contextlib.py", line 66, in exit
next(self.gen)
File "C:\Users...\AppData\Roaming\Python\Python35\site-packages\tensorflow\python\framework\errors_impl.py", line 466, in raise_exception_on_not_ok_status
pywrap_tensorflow.TF_GetCode(status))
tensorflow.python.framework.errors_impl.InvalidArgumentError: Input to reshape is a tensor with 50 values, but the requested shape requires a multiple of 36
[[Node: Reshape_1 = Reshape[T=DT_FLOAT, Tshape=DT_INT32, _device="/job:localhost/replica:0/task:0/cpu:0"](strided_slice, Reshape_1/shape)]]
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:/Users/.../PythonPyCharm/Tensorflow_Projects/Plate Recognition/deep-anpr-master/train.py", line 266, in
initial_weights=initial_weights)
File "C:/Users/.../PythonPyCharm/Tensorflow_Projects/Plate Recognition/deep-anpr-master/train.py", line 239, in train
do_batch()
File "C:/Users/.../PythonPyCharm/Tensorflow_Projects/Plate Recognition/deep-anpr-master/train.py", line 222, in do_batch
feed_dict={x: batch_xs, y_: batch_ys})
File "C:\Users...\AppData\Roaming\Python\Python35\site-packages\tensorflow\python\client\session.py", line 778, in run
run_metadata_ptr)
File "C:\Users...\AppData\Roaming\Python\Python35\site-packages\tensorflow\python\client\session.py", line 982, in _run
feed_dict_string, options, run_metadata)
File "C:\Users...\AppData\Roaming\Python\Python35\site-packages\tensorflow\python\client\session.py", line 1032, in _do_run
target_list, options, run_metadata)
File "C:\Users...\AppData\Roaming\Python\Python35\site-packages\tensorflow\python\client\session.py", line 1052, in _do_call
raise type(e)(node_def, op, message)
tensorflow.python.framework.errors_impl.InvalidArgumentError: Input to reshape is a tensor with 50 values, but the requested shape requires a multiple of 36
[[Node: Reshape_1 = Reshape[T=DT_FLOAT, Tshape=DT_INT32, _device="/job:localhost/replica:0/task:0/cpu:0"](strided_slice, Reshape_1/shape)]]
Caused by op 'Reshape_1', defined at:
File "C:/Users/.../PythonPyCharm/Tensorflow_Projects/Plate Recognition/deep-anpr-master/train.py", line 266, in
initial_weights=initial_weights)
File "C:/Users/.../PythonPyCharm/Tensorflow_Projects/Plate Recognition/deep-anpr-master/train.py", line 174, in train
digits_loss, presence_loss, loss = get_loss(y, y_)
File "C:/Users/.../PythonPyCharm/Tensorflow_Projects/Plate Recognition/deep-anpr-master/train.py", line 130, in get_loss
[-1, len(common.CHARS)]),
File "C:\Users...\AppData\Roaming\Python\Python35\site-packages\tensorflow\python\ops\gen_array_ops.py", line 2510, in reshape
name=name)
File "C:\Users...\AppData\Roaming\Python\Python35\site-packages\tensorflow\python\framework\op_def_library.py", line 768, in apply_op
op_def=op_def)
File "C:\Users...\AppData\Roaming\Python\Python35\site-packages\tensorflow\python\framework\ops.py", line 2336, in create_op
original_op=self._default_original_op, op_def=op_def)
File "C:\Users...\AppData\Roaming\Python\Python35\site-packages\tensorflow\python\framework\ops.py", line 1228, in init
self._traceback = _extract_stack()
InvalidArgumentError (see above for traceback): Input to reshape is a tensor with 50 values, but the requested shape requires a multiple of 36
[[Node: Reshape_1 = Reshape[T=DT_FLOAT, Tshape=DT_INT32, _device="/job:localhost/replica:0/task:0/cpu:0"](strided_slice, Reshape_1/shape)]]

I fixed, it was mistake in code made by me.

Hi ,
I got this error also what is the cause of this error