07-31-2026, 11:01 AM
|
#1 |
|
Junior Member
 
Posts: 8
Karma: 10
Join Date: Apr 2022
Device: PW6
|
Fixing slow ssh/sftp speeds | usbnetlite | openssh
So I was pretty peeved with slow transfer speeds over ssh/sftp compared to usbms (pw5) and mtp (pw6).
I was using ssh provided by usbnetlite by notmarek. The ssh here is a mix of patched dropbear and openssh (for sftp-server). I saw there was a merged PR (#11) by Sighery that increases transfer speed but the latest release doesn't include it. So I tried building it myself and also updated the dropbear (and its patch), openssh and xz submodules with ChatGPT's help. I was able to compile the binaries and build a update.bin update file. But I wasn't able to update using this either by MRPI or putting it in /mnt/us and updating (the update button didn't show in Kindle UI). I don't remember how I worked it out last time, so I simply replaced the binaries at /mnt/us/usbnetlite without touching anything else. Following are some benchmarks (done while connecting using usb): Original dropbear: copy to /mnt/us 5.5 MB/s. Note that usr, sys cpu time are of host and not of much value. You have to open system usage viewer like top, htop, btm on kindle while tranferring. Or you can guess somewhat by file tranfer speed. Code:
❯ time scp file.mkv pw6-sub:/mnt/us ** WARNING: connection is not using a post-quantum key exchange algorithm. ** This session may be vulnerable to "store now, decrypt later" attacks. ** The server may need to be upgraded. See https://openssh.com/pq.html file.mkv 100% 615MB 5.5MB/s 01:51 ________________________________________________________ Executed in 112.26 secs fish external usr time 3.68 secs 23.62 millis 3.66 secs sys time 4.26 secs 9.98 millis 4.25 secs ~ took 1m52s 6.3 MB/s Code:
❯ time scp file.mkv pw6-sub:/mnt/base-us ** WARNING: connection is not using a post-quantum key exchange algorithm. ** This session may be vulnerable to "store now, decrypt later" attacks. ** The server may need to be upgraded. See https://openssh.com/pq.html file.mkv 100% 615MB 6.3MB/s 01:36 ________________________________________________________ Executed in 97.56 secs fish external usr time 3.45 secs 2.04 millis 3.44 secs sys time 3.76 secs 0.01 millis 3.76 secs ~ took 1m37s 8.1 MB/s Updated dropbear: copy to /mnt/base-us (with WINDOW_SIZE="6291456" # 6 MiB) 9.5 MB/s Code:
❯ time scp file.mkv pw6-main:/mnt/base-us file.mkv 100% 615MB 9.5MB/s 01:05 ________________________________________________________ Executed in 65.59 secs fish external usr time 2.84 secs 0.07 millis 2.84 secs sys time 2.22 secs 1.74 millis 2.22 secs ~ took 1m5s **A question to readers: would there be any problem with using /mnt/base-us instead of /mnt/us? Like increased wear and tear of flash or file corruption? So far nothing seems wrong.** So we see some improvement but still much slower than ~20-25MB/s as I remember of MTP. Increasing WINDOW_SIZE didn't help much and there seems to be a 10MB limit by MAX_RECV_WINDOW. I could patch it and rebuild dropbear but after some more detours I decided to build openssh instead. Some more info and benchmarks USB Network speed Code:
❯ iperf -s ----------------------------------------------------------- Server listening on 5201 (test #1) ----------------------------------------------------------- Accepted connection from 192.168.15.244, port 34524 [ 5] local 192.168.15.201 port 5201 connected to 192.168.15.244 port 34536 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 39.2 MBytes 329 Mbits/sec [ 5] 1.00-2.00 sec 38.9 MBytes 326 Mbits/sec [ 5] 2.00-3.00 sec 38.9 MBytes 326 Mbits/sec [ 5] 3.00-4.00 sec 39.0 MBytes 327 Mbits/sec [ 5] 4.00-5.00 sec 39.1 MBytes 328 Mbits/sec [ 5] 5.00-6.00 sec 39.1 MBytes 328 Mbits/sec [ 5] 6.00-7.00 sec 39.0 MBytes 327 Mbits/sec [ 5] 7.00-8.00 sec 39.1 MBytes 328 Mbits/sec [ 5] 8.00-9.00 sec 39.1 MBytes 328 Mbits/sec [ 5] 9.00-10.00 sec 39.0 MBytes 327 Mbits/sec [ 5] 10.00-10.01 sec 128 KBytes 201 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.01 sec 391 MBytes 327 Mbits/sec receiver and run iperf3 -c 192.168.15.244 on kindle Updated dropbear speed (not writing to disk: discarding to /dev/null) Code:
❯ time ssh pw6-main "cat > /dev/null" < 'Downloads/qbit/[Commie] Natsume Yuujinchou Shichi/[Com mie] Natsume Yuujinchou Shichi - 01v2 [EA74BB87].mkv' ________________________________________________________ Executed in 61.60 secs fish external usr time 2.24 secs 810.00 micros 2.24 secs sys time 2.00 secs 975.00 micros 2.00 secs ~ took 1m1s ❯ du -sh 'Downloads/qbit/[Commie] Natsume Yuujinchou Shichi/[Commie] Natsume Yuujinchou Shichi - 01v2 [EA74BB87].mkv' 616M Downloads/qbit/[Commie] Natsume Yuujinchou Shichi/[Commie] Natsume Yuujinchou Shichi - 01v2 [EA74BB87].mkv This means that our updated usbnetlite dropbear itself has a bottleneck. I also noted that one core hovers between 90-100% and another at 70-90% CPU usage during file transfer, so CPU seems to have a bottleneck. Let's see what ciphers dropbear supports: Code:
root@kindle ~# dropbearmulti dropbear -Q cipher chacha20-poly1305@openssh.com aes256-ctr aes128-ctr Code:
❯ ssh -vv pw6-main true 2>&1 | grep "kex: client->server cipher" debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none Our CPU: Code:
root@kindle ~# cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 48.62 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 processor : 1 model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 48.62 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm aes pmull sha1 sha2 crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd03 CPU revision : 4 Hardware : Mediatek Cortex-A7 (Device Tree) Revision : 0000 Serial : 9cd66db875a30c1a Let's try aes128-ctr: Code:
❯ sftp -o Ciphers=aes128-ctr pw6-main ... some file transfer ... (one core permanently 100 another hovering 30 to 60) Conclusion: Either slow on our cpu or dropbear doesn't have a good implementation. Also on our build vm, after reading the Makefile, I found that sftp is built with `--without-openssl`: Code:
user1@arch ~/kindle-usbnetlite (master)> rg "openssl" ... Makefile 43:OPENSSH_CONFIG_OPTIONS=--without-openssl ... Also,on our PW6: Code:
root@kindle ~# openssl version WARNING: can't open config file: /usr/ssl/openssl.cnf OpenSSL 1.0.2q 20 Nov 2018 root@kindle ~ [1]# openssl speed -evp aes-128-gcm WARNING: can't open config file: /usr/ssl/openssl.cnf Doing aes-128-gcm for 3s on 16 size blocks: 18330172 aes-128-gcm's in 2.91s Doing aes-128-gcm for 3s on 64 size blocks: 13283973 aes-128-gcm's in 2.95s Doing aes-128-gcm for 3s on 256 size blocks: 6537939 aes-128-gcm's in 3.00s Doing aes-128-gcm for 3s on 1024 size blocks: 2141687 aes-128-gcm's in 3.00s Doing aes-128-gcm for 3s on 8192 size blocks: 291119 aes-128-gcm's in 3.00s OpenSSL 1.0.2q 20 Nov 2018 built on: reproducible build, date unspecified options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: arm-zeusdistro-linux-gnueabi-gcc -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon-vfpv4 -mtune=cortex-a7 --sysroot=/home/builder/yocto/source/build/tmp/sysroots/bellatrix4 -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_SRP -DOPENSSL_NO_SCTP -DOPENSSL_NO_DTLS1 -DOPENSSL_NO_SRTP -DOPENSSL_NO_CAST -DOPENSSL_NO_HEARTBEATS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_GOST -DOPENSSL_NO_KRB5 -DOPENSSL_NO_GMP -march=armv7-a -Wa,--noexecstack -O3 -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-gcm 100784.45k 288194.67k 557904.13k 731029.16k 794948.95k After trying few more things to improve dropbear, I moved onto openssh. Maybe it'd work better without `--without-openssl` option when building. Openssh After a lengthy process, I was able to compile musl static openssh binaries (vanilla, no patches specifically for kindle). I used the musl toolchain available here: https://toolchains.bootlin.com/ Code:
root@kindle ~# file /usr/local/bin/sshd /usr/local/bin/sshd: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped Code:
root@kindle ~# eza --tree --level=2 -l --no-permissions --no-time --no-user /usr/local - /usr/local - ├── bin 6.6M │ ├── bat 4.2M │ ├── btm 2.3M │ ├── dust 22k │ ├── elfedit 2.6M │ ├── eza 2.9M │ ├── fd 676k │ ├── file 1.6M │ ├── fio 13M │ ├── fish 4.6M │ ├── fzf 416k │ ├── htop 137k │ ├── ifstat 476k │ ├── less 38k │ ├── lessecho 55k │ ├── lesskey 108k │ ├── lnstat 194k │ ├── mbuffer 606k │ ├── nm 534k │ ├── nnn 133k │ ├── nstat 744k │ ├── readelf 116k │ ├── rtacct 345k │ ├── scp 333k │ ├── sftp 597k │ ├── size 186k │ ├── ss 4.2M │ ├── ssh 3.6M │ ├── ssh-add 3.6M │ ├── ssh-agent 3.8M │ ├── ssh-keygen 3.8M │ ├── ssh-keyscan 3.7M │ ├── ssh-keysign 127 │ ├── ssh-login.sh 3.6M │ ├── ssh-pkcs11-helper 3.6M │ ├── ssh-sk-helper 3.8M │ ├── sshd 2.2M │ ├── strace 7.8k │ ├── strace-graph 1.9k │ ├── strace-log-merge 602k │ ├── strings 1.0M │ └── zoxide - ├── etc - │ └── fish - ├── libexec 259k │ ├── sftp-server 4.2M │ ├── sshd-auth 4.3M │ └── sshd-session - └── share - ├── doc - ├── fish - ├── man - ├── misc - ├── pkgconfig - └── terminfo Finally, started sshd with: Code:
root@kindle ~# /usr/local/bin/sshd -D -e \
-f /mnt/us/ssh/sshd_config \
-o Port=2222
Code:
root@kindle ~# cat /mnt/us/ssh/sshd_config Hostkey /var/local/ssh/ssh_kindle_ed25519_key PubkeyAuthentication yes AuthorizedKeysFile /mnt/us/ssh/authorized_keys #AuthorizedKeysFile /var/local/ssh/authorized_keys StrictModes no PermitRootLogin yes PasswordAuthentication no KbdInteractiveAuthentication no ChallengeResponseAuthentication no Subsystem sftp /usr/local/libexec/sftp-server PidFile /tmp/sshd.pid PrintMotd no #LogLevel DEBUG3 #LogLevel DEBUG1 LogLevel INFO SetEnv HOME=/mnt/us openssh: copy to /mnt/us Code:
❯ time scp -P 2222 file.mkv pw6-main:/mnt/us file.mkv 100% 615MB 13.6MB/s 00:45 ________________________________________________________ Executed in 45.52 secs fish external usr time 2.74 secs 0.00 millis 2.74 secs sys time 2.38 secs 1.83 millis 2.38 secs ~ took 45s openssh: copy to /mnt/base-us Code:
❯ time scp -P 2222 file.mkv pw6-main:/mnt/base-us file.mkv 100% 615MB 20.8MB/s 00:29 ________________________________________________________ Executed in 29.88 secs fish external usr time 2.83 secs 0.70 millis 2.83 secs sys time 1.90 secs 1.94 millis 1.90 secs What's the bottleneck now? We checked earlier that usb networking can do 40MB/s. Let's test a different cipher, ChatGPT said earlier that our CPU should be better with aes-gcm. Let's test openssh cipher performance without writing to disk: Code:
❯ pv file.mkv | ssh -p 2222 -c chacha20-poly1305@openssh.com pw6-main "cat >/dev/null" 615MiB 0:00:20 [30.6MiB/s] [===============================================>] 100% ~ took 20s ❯ pv file.mkv | ssh -p 2222 -c aes256-gcm@openssh.com pw6-main "cat >/dev/null" 615MiB 0:00:18 [32.4MiB/s] [===============================================>] 100% ~ took 19s ❯ pv file.mkv | ssh -p 2222 -c aes128-gcm@openssh.com pw6-main "cat >/dev/null" 615MiB 0:00:19 [31.8MiB/s] [===============================================>] 100% ~ took 19s ❯ pv file.mkv | ssh -p 2222 -c aes256-ctr pw6-main "cat >/dev/null" 615MiB 0:00:18 [33.1MiB/s] [===============================================>] 100% ~ took 18s ❯ pv file.mkv | ssh -p 2222 -c aes128-ctr pw6-main "cat >/dev/null" 615MiB 0:00:20 [30.5MiB/s] [===============================================>] 100% ~ took 20s Similar results with some variation, all of them around 30MB/s. Faster than dropbear but it won't saturate usbnet. But why is writing to disk (/mnt/base-us) only ~20 MB/s? Let's try copying to disk instead with various ciphers to see if chacha20-poly1305 is the problem. Probably not. Code:
❯ time scp -P 2222 -c aes256-gcm@openssh.com file.mkv pw6-main:/mnt/base-us file.mkv 100% 615MB 21.3MB/s 00:28 ________________________________________________________ Executed in 29.09 secs fish external usr time 1.14 secs 0.00 millis 1.14 secs sys time 1.81 secs 2.27 millis 1.81 secs ~ took 29s ❯ time scp -P 2222 -c aes128-gcm@openssh.com file.mkv pw6-main:/mnt/base-us file.mkv 100% 615MB 22.0MB/s 00:28 ________________________________________________________ Executed in 28.24 secs fish external usr time 1.01 secs 0.00 millis 1.01 secs sys time 1.70 secs 1.62 millis 1.69 secs ~ took 28s ❯ time scp -P 2222 -c aes128-ctr file.mkv pw6-main:/mnt/base-us file.mkv 100% 615MB 21.4MB/s 00:28 ________________________________________________________ Executed in 28.99 secs fish external usr time 1.70 secs 9.25 millis 1.69 secs sys time 1.81 secs 10.05 millis 1.80 secs ~ took 28s ❯ time scp -P 2222 -c chacha20-poly1305@openssh.com file.mkv pw6-main:/mnt/base-us file.mkv 100% 615MB 21.8MB/s 00:28 ________________________________________________________ Executed in 28.46 secs fish external usr time 3.19 secs 0.67 millis 3.18 secs sys time 1.76 secs 1.17 millis 1.76 secs ~ took 28s Write to disk (/mnt/us) from /dev/zero Code:
root@kindle ~# time dd if=/dev/zero of=/mnt/us/test1.bin bs=4K count=262144 262144+0 records in 262144+0 records out 1073741824 bytes (1.0GB) copied, 58.741142 seconds, 17.4MB/s ________________________________________________________ Executed in 58.75 secs fish external usr time 0.69 secs 3.87 millis 0.69 secs sys time 11.83 secs 2.94 millis 11.82 secs root@kindle ~# time dd if=/dev/zero of=/mnt/us/test2.bin bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.0GB) copied, 45.021753 seconds, 22.7MB/s ________________________________________________________ Executed in 45.03 secs fish external usr time 0.02 secs 3.83 millis 0.01 secs sys time 6.19 secs 2.97 millis 6.19 secs Code:
root@kindle ~# time dd if=/dev/zero of=/mnt/base-us/test1.bin bs=4K count=262144 262144+0 records in 262144+0 records out 1073741824 bytes (1.0GB) copied, 41.526672 seconds, 24.7MB/s ________________________________________________________ Executed in 41.54 secs fish external usr time 0.21 secs 14.38 millis 0.19 secs sys time 5.68 secs 0.00 millis 5.68 secs root@kindle ~# time dd if=/dev/zero of=/mnt/base-us/test3.bin bs=32M count=32 32+0 records in 32+0 records out 1073741824 bytes (1.0GB) copied, 35.827699 seconds, 28.6MB/s ________________________________________________________ Executed in 35.85 secs fish external usr time 0.00 secs 3.39 millis 0.00 secs sys time 5.18 secs 1.26 millis 5.18 secs Code:
root@kindle ~# time dd if=/mnt/base-us/file.mkv of=/mnt/base-us/test bs=4M 153+1 records in 153+1 records out 644973054 bytes (615.1MB) copied, 30.461555 seconds, 20.2MB/s ________________________________________________________ Executed in 30.48 secs fish external usr time 0.00 secs 0.00 millis 0.00 secs sys time 3.58 secs 3.83 millis 3.57 secs root@kindle ~# time dd if=/mnt/base-us/file.mkv of=/mnt/base-us/test bs=16M 38+1 records in 38+1 records out 644973054 bytes (615.1MB) copied, 29.249815 seconds, 21.0MB/s root@kindle ~ [1]# time dd if=/mnt/base-us/file.mkv of=/mnt/base-us/test bs=64M 9+1 records in 9+1 records out 644973054 bytes (615.1MB) copied, 28.346839 seconds, 21.7MB/s ________________________________________________________ Executed in 28.40 secs fish external usr time 0.00 secs 4.88 millis 0.00 secs sys time 3.38 secs 3.54 millis 3.38 secs Let's see if this includes sync time too: Code:
root@kindle ~# time sh -c 'dd if=/mnt/base-us/file.mkv of=/mnt/base-us/test bs=64M && sync' 9+1 records in 9+1 records out 644973054 bytes (615.1MB) copied, 28.848862 seconds, 21.3MB/s ________________________________________________________ Executed in 30.56 secs fish external usr time 0.01 secs 6.07 millis 0.01 secs sys time 3.44 secs 6.26 millis 3.44 secs Also a fio test: Code:
root@kindle ~# fio \
--name=seqwrite \
--filename=/mnt/base-us/fio.test \
--size=1G \
--rw=write \
--bs=1M \
--ioengine=sync \
--direct=0
seqwrite: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=sync, iodepth=1
fio-3.42-116-gc76c
Starting 1 process
seqwrite: Laying out IO file (1 file / 1024MiB)
Jobs: 1 (f=1): [W(1)][100.0%][w=40.0MiB/s][w=40 IOPS][eta 00m:00s]
seqwrite: (groupid=0, jobs=1): err= 0: pid=32622: Fri Jul 31 10:25:06 2026
write: IOPS=23, BW=23.4MiB/s (24.6MB/s)(1024MiB/43701msec)
clat (usec): min=1953, max=1839.8k, avg=42436.02, stdev=85982.27
lat (msec): min=2, max=1839, avg=42.63, stdev=85.97
clat percentiles (msec):
| 1.00th=[ 3], 5.00th=[ 3], 10.00th=[ 3], 20.00th=[ 3],
| 30.00th=[ 4], 40.00th=[ 17], 50.00th=[ 28], 60.00th=[ 40],
| 70.00th=[ 50], 80.00th=[ 80], 90.00th=[ 81], 95.00th=[ 90],
| 99.00th=[ 300], 99.50th=[ 514], 99.90th=[ 1020], 99.95th=[ 1838],
| 99.99th=[ 1838]
bw ( KiB/s): min= 2043, max=194560, per=100.00%, avg=25406.76, stdev=25861.76, samples=82
iops : min= 1, max= 190, avg=24.38, stdev=25.32, samples=82
lat (msec) : 2=0.88%, 4=30.57%, 10=6.25%, 20=6.64%, 50=26.95%
lat (msec) : 100=25.20%, 250=2.25%, 500=0.68%, 750=0.39%, 2000=0.20%
cpu : usr=0.57%, sys=7.92%, ctx=10339, majf=0, minf=25
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,1024,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0.00ns, window=0.00ns, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=23.4MiB/s (24.6MB/s), 23.4MiB/s-23.4MiB/s (24.6MB/s-24.6MB/s), io=1024MiB (1074MB), run=43701-43701msec
Disk stats (read/write):
loop0: ios=1/1178, sectors=8/1989408, merge=0/0, ticks=746/1533678, in_queue=1560132, util=50.67%
root@kindle ~# fio \
--name=seqwrite-direct \
--filename=/mnt/base-us/fio.test \
--size=1G \
--rw=write \
--bs=1M \
--ioengine=sync \
--direct=1
seqwrite-direct: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=sync, iodepth=1
fio-3.42-116-gc76c
Starting 1 process
seqwrite-direct: Laying out IO file (1 file / 1024MiB)
Jobs: 1 (f=1): [W(1)][95.6%][eta 00m:02s]
seqwrite-direct: (groupid=0, jobs=1): err= 0: pid=831: Fri Jul 31 10:26:55 2026
write: IOPS=23, BW=23.5MiB/s (24.6MB/s)(1024MiB/43618msec)
clat (msec): min=3, max=4171, avg=42.36, stdev=254.30
lat (msec): min=3, max=4171, avg=42.55, stdev=254.29
clat percentiles (msec):
| 1.00th=[ 4], 5.00th=[ 4], 10.00th=[ 4], 20.00th=[ 5],
| 30.00th=[ 5], 40.00th=[ 5], 50.00th=[ 6], 60.00th=[ 6],
| 70.00th=[ 13], 80.00th=[ 40], 90.00th=[ 81], 95.00th=[ 81],
| 99.00th=[ 262], 99.50th=[ 1972], 99.90th=[ 3910], 99.95th=[ 4178],
| 99.99th=[ 4178]
bw ( KiB/s): min= 2043, max=174080, per=100.00%, avg=40130.73, stdev=47186.49, samples=52
iops : min= 1, max= 170, avg=38.85, stdev=46.14, samples=52
lat (msec) : 4=19.14%, 10=49.61%, 20=7.03%, 50=6.84%, 100=15.04%
lat (msec) : 250=1.27%, 500=0.10%, 750=0.20%, 2000=0.29%, >=2000=0.49%
cpu : usr=0.54%, sys=1.14%, ctx=1630, majf=0, minf=17
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,1024,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0.00ns, window=0.00ns, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=23.5MiB/s (24.6MB/s), 23.5MiB/s-23.5MiB/s (24.6MB/s-24.6MB/s), io=1024MiB (1074MB), run=43618-43618msec
Disk stats (read/write):
loop0: ios=1/2083, sectors=8/2031400, merge=0/0, ticks=1080/166983, in_queue=189450, util=99.82%
Slight improvements can be made, but probably not worth it. Maybe having a buffer or increasing transfer block size would help with the use case of copying hundreds of small files (epubs). Who knows? Closing remarks: Using openssh binaries and /mnt/base-us instead of /mnt/us takes you from 5.6 MB/s to 20-21 MB/s. This took me several days. Although I'm a linux user for some time now (from 2018), I don't consider myself a programmer. And I almost never compiled programs from source and then I suddenly threw myself in cross-compiling for kindle. BTW, LLMs really helped throughout the process, this wouldn't be possible otherwise. The few binaries that I've compiled (including the openssh ones) for testing and a pleasant ssh experience are available here: https://github.com/tiklii/kindle-hf-binaries Also, I'd be thankful if someone does the work of updating usbnetlite or make another usbnetwork project with openssh binaries instead. I'm not touching that since it involves the boot process, and it is quite easy to mess up and brick your kindle. |
|
|
 |
«
Previous Thread
|
Next Thread
»
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Tools Recompiled USBNetLite for >5.18.2 (hard float) | hhhhhhhhh | Kindle Developer's Corner | 15 | 02-02-2026 06:27 AM |
| SSH over wifi too slow | test1234 | Kindle Developer's Corner | 3 | 08-30-2015 08:48 AM |
| Fixing slow PDFs | PF4Mobile | Onyx Boox | 3 | 09-25-2011 10:39 AM |
| Request Geek Tools for moving files to/from the Library: ssh/sftp/rsync/samba | kenjennings | enTourage Archive | 6 | 04-06-2010 11:36 PM |
All times are GMT -4. The time now is 09:08 AM.