An error occurred fetching the project authors.
- 19 Apr, 2016 1 commit
-
-
Kirill Smelkov authored
I recently discovered that dropbear, compared to openssh over same link with same host and user keys, transfers files several times slower - sometimes up to an order of magnitude slower. This equally applies to both fast LAN IPv4 networks (tried on 1Gbps) and relatively slow "over re6stnet" networks with geographically separated client and server. The problem turned out to be dropbear has very small receive window size default: https://github.com/mkj/dropbear/blob/DROPBEAR_0.53.1/options.h#L258 ---- 8< ---- /* Window size limits. These tend to be a trade-off between memory usage and network performance: */ /* Size of the network receive window. This amount of memory is allocated as a per-channel receive buffer. Increasing this value can make a significant difference to network performance. 24kB was empirically chosen for a 100mbit ethernet network. The value can be altered at runtime with the -W argument. */ #ifndef DEFAULT_RECV_WINDOW #define DEFAULT_RECV_WINDOW 24576 #endif ---- 8< ---- this is maybe appropriate for embedded systems, but small receive window affects networking throughput a lot: e.g. I've tried to run several file downloading benchmarks and changing receive window size from default 24K to 1M (this is maximum according to dropbear documentation) on client side made the downloading several times faster and comparable to downloading speed with using openssh as client. Dropbear has -W option for setting receive window size at runtime, so we could go through all places which use dropbear and add appropriate `-W ...` there. But I think fixing dropbear itself to have more sane defaults for not-very-memory-constrained devices (= devices we run slapos on) is preferable - this way all services will automatically benefit from transfer speedup without taking action on their side with only doing recompilation/redeployment. Besides changing only recv window size at runtime breaks compatibility with openssh: if we only do `-W 1M` on server and try to upload data with openssh as client, dropbear complains [3302] Apr 17 23:10:06 Exit (slapuser2): Bad packet size 32777 and connection terminates. Thus RECV_MAX_PAYLOAD_LEN increase is also required, which cannot be done via option at runtime: https://github.com/mkj/dropbear/blob/DROPBEAR_0.53.1/options.h#L268 ---- 8< ---- /* Maximum size of a received SSH data packet - this _MUST_ be >= 32768 in order to interoperate with other implementations */ #ifndef RECV_MAX_PAYLOAD_LEN #define RECV_MAX_PAYLOAD_LEN 32768 #endif ---- 8< ---- So let's increase DEFAULT_RECV_WINDOW to 1M and RECV_MAX_PAYLOAD_LEN appropriately (experimentally found that at 512K the complain goes away). Below is rough benchmark before and after the change (timings are not very precise, because machines are otherwise busy and network fluctuates, but I think they are reasonable in showing we have at least several times improvement): before after download 1M (re6stnet, slow link) ~12s ~4s upload 1M (re6stnet, slow link) ~12s ~4s download 100M (1Gbps LAN, IPv4) ~12s ~4s upload 100M (1Gbps LAN, IPv4) ~12s ~4s legend: client=dbclient server=dropbear NOTE the original problem equally applies to latest dropbear master, so it is not because we are running old 0.53.1 ( from 2011 ! ) NOTE wrt transfer speed openssh is still faster - not an order of magnitude, but somewhat. Also openssh uses much less CPU compared to dropbear. /cc @Tyagov, @klaus @nexedi, why at all we use dropbear in the first place instead of openssh? /reviewed-by @rafael /reviewed-on !68
-
- 04 Apr, 2016 1 commit
-
-
Kazuhiko Shiozaki authored
-
- 21 Oct, 2015 1 commit
-
-
Kazuhiko Shiozaki authored
-
- 18 Aug, 2014 1 commit
-
-
Kazuhiko Shiozaki authored
-
- 18 Jul, 2013 1 commit
-
-
Romain Courteaud authored
Add a new section ["component"-output] to test the creation of the expected build output. The verification is simply done with the "test" command. The output file are reference as section variable, which allow to reuse the location in the software profile, and so, prevent harcoding the local directory path in the software profile.
-
- 16 Apr, 2013 1 commit
-
-
Cédric de Saint Martin authored
-
- 20 Mar, 2012 1 commit
-
-
Gabriel Monnerat authored
-
- 17 Feb, 2012 1 commit
-
-
Alain Takoudjou authored
-
- 30 Nov, 2011 2 commits
-
-
Antoine Catton authored
I updated the dropbear url because it wasn't uploaded to network cache. I kept an old version because : * our patches don't work anymore with the latest version. * the latest version (at the date of this commit, doesn't have an interesting changelog). * by laziness.
-
Antoine Catton authored
I updated the dropbear url because it wasn't uploaded to network cache. I kept an old version because : * our patches don't work anymore with the latest version. * the latest version (at the date of this commit, doesn't have an interesting changelog). * by laziness.
-
- 03 Nov, 2011 1 commit
-
-
Antoine Catton authored
shell not present in /etc/shells
-
- 02 Nov, 2011 1 commit
-
-
Antoine Catton authored
-
- 13 Oct, 2011 1 commit
-
-
Antoine Catton authored
Replacing openssh buildout by dropbear one. Adding my own dropbear patch which was submitted to dropbear developpers. Add ipv6 patch for dropbear Took here : <https://lists.openwrt.org/pipermail/openwrt-devel/2009-May/004299.html> Minor: Dropbear buildout fine tuning Linking dropbear with slapos zlib
-
- 19 Sep, 2011 1 commit
-
-
Antoine Catton authored
Replacing openssh buildout by dropbear one. Adding my own dropbear patch which was submitted to dropbear developpers. Add ipv6 patch for dropbear Took here : <https://lists.openwrt.org/pipermail/openwrt-devel/2009-May/004299.html> Minor: Dropbear buildout fine tuning Linking dropbear with slapos zlib
-