NSA310 + kirkwood 6.5.7 improve net performance
Posted by a3vap
|
NSA310 + kirkwood 6.5.7 improve net performance February 28, 2024 02:26PM |
Registered: 5 months ago Posts: 13 |
Hello Everyone,
End of last year, I tried to revive a NSA310 NAS by debianizing it. Thanks to bodhi, and the howtos on this forum, I managed to get it funcionally working with "Debian-6.5.7-kirkwood-tld-1-rootfs-bodhi.tar.bz2".
The only thing that seems a little off, is the performance.
I have put rootfs to the first partition of a WDC WD30EZRX-22D8PB0 3Tb HDD, no other partitions are created yet.
When I tried to download e.g. with wget or a well seeded torrent with aria2c, I see at max 4-5 MB/s with the wget and 5-6 MB/s with aria2, while consuming 100% cpu usage. On the same cable, my laptop can wget the same file with 9-9,5MB/s.
Also when copying something from the NAS, e.g. with pscp from my laptop (no services are installed on the NAS), I get around 3-4MB/s, while the NAS CPU works 100% (sshd+sftp)
Basic HDD test shows OKish speeds
and
Iperf test is close to the capabilities of the 100Mbps (dont judge) house network to the laptop (*.121)
The CPU seems to be going at full speed
After googling and looking at the forum wiki Performance links, I have tried:
- plugging in to the ISP router directly -> no change
- ext2, ext3, ext4 as filesystems to download to -> no change
- turn off flow control with "ethtool -A eth0 rx off tx off", which was on after install => no change
- I found strace utility, which showed the following, but I dont know what to conclude
Is there a way to improve the situation?
Best regards,
Peter
End of last year, I tried to revive a NSA310 NAS by debianizing it. Thanks to bodhi, and the howtos on this forum, I managed to get it funcionally working with "Debian-6.5.7-kirkwood-tld-1-rootfs-bodhi.tar.bz2".
root@debian:~# uname -a Linux debian 6.5.7-kirkwood-tld-1 #2 PREEMPT Wed Oct 18 21:14:11 PDT 2023 armv5tel GNU/Linux
The only thing that seems a little off, is the performance.
I have put rootfs to the first partition of a WDC WD30EZRX-22D8PB0 3Tb HDD, no other partitions are created yet.
root@debian:~# cat /etc/fstab # /etc/fstab: static file system information. # # <file system> <mount point> <type> <options> <dump> <pass> LABEL=rootfs / ext3 noatime,nodiratime,errors=remount-ro 0 1 tmpfs /tmp tmpfs defaults 0 0 /swapfile1 swap swap defaults 0 0
When I tried to download e.g. with wget or a well seeded torrent with aria2c, I see at max 4-5 MB/s with the wget and 5-6 MB/s with aria2, while consuming 100% cpu usage. On the same cable, my laptop can wget the same file with 9-9,5MB/s.
Also when copying something from the NAS, e.g. with pscp from my laptop (no services are installed on the NAS), I get around 3-4MB/s, while the NAS CPU works 100% (sshd+sftp)
Basic HDD test shows OKish speeds
root@debian:~# dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 29.0459 s, 37.0 MB/s
and
root@debian:~# hdparm -tT /dev/sda /dev/sda: Timing cached reads: 474 MB in 2.00 seconds = 236.53 MB/sec Timing buffered disk reads: 312 MB in 3.02 seconds = 103.36 MB/sec
Iperf test is close to the capabilities of the 100Mbps (dont judge) house network to the laptop (*.121)
------------------------------------------------------------ Client connecting to 192.168.1.121, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.1.157 port 50500 connected with 192.168.1.121 port 5001 (icwnd/mss/irtt=14/1448/257) [ ID] Interval Transfer Bandwidth [ 1] 0.0000-10.0330 sec 105 MBytes 88.1 Mbits/sec root@debian:~#
The CPU seems to be going at full speed
root@debian:~# inxi -c CPU: single core Feroceon 88FR131 v5l (-UP-) speed/min/max: 1200/400/1200 MHz Kernel: 6.5.7-kirkwood-tld-1 armv5tel Up: 34m Mem: 53.2/233.4 MiB (22.8%) Storage: 2.73 TiB (0.1% used) Procs: 72 Shell: Bash inxi: 3.3.26
After googling and looking at the forum wiki Performance links, I have tried:
- plugging in to the ISP router directly -> no change
- ext2, ext3, ext4 as filesystems to download to -> no change
- turn off flow control with "ethtool -A eth0 rx off tx off", which was on after install => no change
- I found strace utility, which showed the following, but I dont know what to conclude
root@debian:~# strace -c wget https://cdimage.debian.org/debian-cd/current/armel/iso-cd/debian-12.5.0-armel-netinst.iso ... % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- -------------------- 53.61 15.764566 122 128966 write 27.75 8.159941 64 126653 59 recv 11.15 3.277733 17 189756 fcntl64 7.12 2.093075 16 126605 clock_gettime64 0.17 0.048873 19 2475 ioctl 0.13 0.038816 15 2467 getpgrp 0.02 0.004578 70 65 pselect6 0.01 0.003214 65 49 mmap2 0.01 0.003190 88 36 read
Is there a way to improve the situation?
Best regards,
Peter
|
Re: NSA310 + kirkwood 6.5.7 improve net performance February 28, 2024 03:54PM |
Admin Registered: 13 years ago Posts: 18,575 |
Hi Peter,
> End of last year, I tried to revive a NSA310 NAS
> by debianizing it. Thanks to bodhi, and the howtos
> on this forum, I managed to get it funcionally
> working with
> "Debian-6.5.7-kirkwood-tld-1-rootfs-bodhi.tar.bz2".
Glad to hear another piece of old hardware running the latest Linux kernel!
> The only thing that seems a little off, is the
> performance.
>
> When I tried to download e.g. with wget or a well
> seeded torrent with aria2c, I see at max 4-5 MB/s
> with the wget and 5-6 MB/s with aria2, while
> consuming 100% cpu usage.
Try running some other task in parallel to see if it can get its share of the CPU.
> Iperf test is close to the capabilities of the
> 100Mbps (dont judge) house network to the laptop
That's good. But your iperf test transfered a small file. Try running it with a larger file, eg. 1GB.
======
Here is food for thought. This NSA310 box is a Kirkwood box like other NAS in the family, but the NIC is RealTek's, not Marvell's like others. So there could be a significant difference in performance. The Marvell's NICs in these Kirkwood boxes have been proven to be pretty good in performance. Or could be we are not aware how to tune the RealTek NIC.
List the ethtool info:
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> End of last year, I tried to revive a NSA310 NAS
> by debianizing it. Thanks to bodhi, and the howtos
> on this forum, I managed to get it funcionally
> working with
> "Debian-6.5.7-kirkwood-tld-1-rootfs-bodhi.tar.bz2".
Glad to hear another piece of old hardware running the latest Linux kernel!
> The only thing that seems a little off, is the
> performance.
>
> When I tried to download e.g. with wget or a well
> seeded torrent with aria2c, I see at max 4-5 MB/s
> with the wget and 5-6 MB/s with aria2, while
> consuming 100% cpu usage.
Try running some other task in parallel to see if it can get its share of the CPU.
> Iperf test is close to the capabilities of the
> 100Mbps (dont judge) house network to the laptop
That's good. But your iperf test transfered a small file. Try running it with a larger file, eg. 1GB.
======
Here is food for thought. This NSA310 box is a Kirkwood box like other NAS in the family, but the NIC is RealTek's, not Marvell's like others. So there could be a significant difference in performance. The Marvell's NICs in these Kirkwood boxes have been proven to be pretty good in performance. Or could be we are not aware how to tune the RealTek NIC.
List the ethtool info:
ethtool eth0 ethtool -k eth0 | grep tcp-segment
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: NSA310 + kirkwood 6.5.7 improve net performance February 29, 2024 04:15AM |
Registered: 9 years ago Posts: 50 |
More food for thought: the Marvell kirkwood has no floating point unit. anything that requires floating point is going to make it suffer. As such, transfers requiring encryption (such as SSH/SFTP) are going to eat at the CPU usage, moreso if the speed is slow. I've already come to terms that the most I'll ever get out file transfer-wise is going to be 7-8MB/s maximum on any kirkwood device, and even slower if the file is coming from a USB flash drive or if multiple files are being transferred.
Realtek ethernet chipsets for the most part also don't do tx/rx offload too well, only doing the bare minimum. This plus rather buggy drivers in some OSes except for Windows and maybe Linux? and you have a recipe for disaster. on the BSD end, people avoid realtek like the plague for pfsense/opnsense installations.
A test to try would be to install vsftpd and configure it properly, and then try a plain unencrypted FTP link to the device over the network. You should be able to max out the 100Mbit connection downloading and uploading files.
Ideally, upgrading most of your network via a gigabit switch would be ideal, but I know how hard even sparing $20 is these days (about the cost of a cheap tp-link gig switch) so I'm not going to push that issue.
All in all if the FTP speeds are slow, you have a problem somewhere. if all the wired traffic is going through your router and not a switch, it's the router, most likely. if it's going through a switch plugged into the router, it's likely the switch... I know some switches are weird, I have a 16-port netgear gig switch from the late '00s I recapped that for some strange reason, with slower kirkwood devices, will sometimes only negotiate 100Mbit for those devices unless the switch is rebooted. On the 16-port tp-link which replaced it, no such issue occurs. it negotiates full gigabit and just works.
One of the reasons I stopped using my pogoplug for a webserver and storage box was because of the slow network transfer speed. but, when I went to install owntone on my Kace M300 and put my 100-something gigs of music onto it, I used vsftpd so I wasn't waiting around for each sftp connection to start. it went very quickly and I was hitting about 35-50MB/s upload on the two concurrent transfer channels I had going to the box with filezilla. Marvell never designed this SoC to do what we're doing to it, and never in their wildest dreams did they ever expect its SATA channels to harbor multi-terabyte disks and SSDs that will handily saturate the bus. At the same time, they never expected Cloud Engines to shove a USB3 chipset on it either... the Kirkwood came to be around 2005 or 2006 and USB3 was ratified in 2008. The platform is nearly 20 years old.
One final remark, if you want the CPU to ramp down speed to save power when not being actively used, installing cpufrequtils from apt is going to help in that department. the SoC puts out significantly less heat at 400MHz compared to 1.2GHz. I would also recommend you make sure your power adapter is putting out a clean 12v signal, I've had issues with my pogo v4 in the past when I had it hooked to a 12v supply that had started to put out a very dirty DC sinewave, and I thank my lucky stars it didn't lead to data corruption!
Realtek ethernet chipsets for the most part also don't do tx/rx offload too well, only doing the bare minimum. This plus rather buggy drivers in some OSes except for Windows and maybe Linux? and you have a recipe for disaster. on the BSD end, people avoid realtek like the plague for pfsense/opnsense installations.
A test to try would be to install vsftpd and configure it properly, and then try a plain unencrypted FTP link to the device over the network. You should be able to max out the 100Mbit connection downloading and uploading files.
Ideally, upgrading most of your network via a gigabit switch would be ideal, but I know how hard even sparing $20 is these days (about the cost of a cheap tp-link gig switch) so I'm not going to push that issue.
All in all if the FTP speeds are slow, you have a problem somewhere. if all the wired traffic is going through your router and not a switch, it's the router, most likely. if it's going through a switch plugged into the router, it's likely the switch... I know some switches are weird, I have a 16-port netgear gig switch from the late '00s I recapped that for some strange reason, with slower kirkwood devices, will sometimes only negotiate 100Mbit for those devices unless the switch is rebooted. On the 16-port tp-link which replaced it, no such issue occurs. it negotiates full gigabit and just works.
One of the reasons I stopped using my pogoplug for a webserver and storage box was because of the slow network transfer speed. but, when I went to install owntone on my Kace M300 and put my 100-something gigs of music onto it, I used vsftpd so I wasn't waiting around for each sftp connection to start. it went very quickly and I was hitting about 35-50MB/s upload on the two concurrent transfer channels I had going to the box with filezilla. Marvell never designed this SoC to do what we're doing to it, and never in their wildest dreams did they ever expect its SATA channels to harbor multi-terabyte disks and SSDs that will handily saturate the bus. At the same time, they never expected Cloud Engines to shove a USB3 chipset on it either... the Kirkwood came to be around 2005 or 2006 and USB3 was ratified in 2008. The platform is nearly 20 years old.
One final remark, if you want the CPU to ramp down speed to save power when not being actively used, installing cpufrequtils from apt is going to help in that department. the SoC puts out significantly less heat at 400MHz compared to 1.2GHz. I would also recommend you make sure your power adapter is putting out a clean 12v signal, I've had issues with my pogo v4 in the past when I had it hooked to a 12v supply that had started to put out a very dirty DC sinewave, and I thank my lucky stars it didn't lead to data corruption!
|
Re: NSA310 + kirkwood 6.5.7 improve net performance February 29, 2024 02:18PM |
Admin Registered: 13 years ago Posts: 18,575 |
@sudos,
I agreed with most of what you said. Except for:
> such, transfers requiring encryption (such as
> SSH/SFTP) are going to eat at the CPU usage,
> moreso if the speed is slow.
> I've already come to
> terms that the most I'll ever get out file
> transfer-wise is going to be 7-8MB/s maximum on
> any kirkwood device,
That might be true for other things. But for normal file transfers don't use floating point arithmetics. Does it?
Also, I have not used BitTorrent for a while so not sure, but I don't recall it uses encrypted connections. Please correct me if I'm wrong.
For file transfers (NFS) in a local network environment, somebody in this forum has benchmarked a Kirkwood box and the rate was about 80 MBs, IIRC. And that was with an exported file on HDD.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
I agreed with most of what you said. Except for:
> such, transfers requiring encryption (such as
> SSH/SFTP) are going to eat at the CPU usage,
> moreso if the speed is slow.
> I've already come to
> terms that the most I'll ever get out file
> transfer-wise is going to be 7-8MB/s maximum on
> any kirkwood device,
That might be true for other things. But for normal file transfers don't use floating point arithmetics. Does it?
Also, I have not used BitTorrent for a while so not sure, but I don't recall it uses encrypted connections. Please correct me if I'm wrong.
For file transfers (NFS) in a local network environment, somebody in this forum has benchmarked a Kirkwood box and the rate was about 80 MBs, IIRC. And that was with an exported file on HDD.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: NSA310 + kirkwood 6.5.7 improve net performance February 29, 2024 02:43PM |
Registered: 5 months ago Posts: 13 |
Thanks for the ideas bodhi and sudos!
After some negotiations I managed to get the NAS and my laptop temporarly connected directly to the gigabit ports of the ISP router. This should help rule out the 100M switch and cabling issues. The simple wget and aria2c usercases did not improve. All futher measurements are done in this setup, unless marked.
"Try running some other task in parallel to see if it can get its share of the CPU."
I ran "sysbench --test=cpu --cpu-max-prime=2000 --num-threads=1 run &" in parallel to a wget download.
...
The download speed scales almost linearly, and drops from ~4,5to 2,5MBps.
"List the ethtool info:"
"your iperf test transfered a small file. Try running it with a larger file, eg. 1GB."
100M
1G
1G but from a file
"I've already come to terms that the most I'll ever get out file transfer-wise is going to be 7-8MB/s maximum on any kirkwood device"
That would suffice for me too. The main goal is the classic NAS usage, meaning transmission and minidlna, single user samba.
"Ideally, upgrading most of your network via a gigabit switch would be ideal, but I know how hard even sparing $20 is these days (about the cost of a cheap tp-link gig switch)"
Yes, that could help generally, although currently I have it connected and the speeds did not improve. The sad thing is, that in this home, there are CAT5e cables in the walls into each room, sometimes with not all strands connected properly. :( The 100M "backbone" was enough for the one TV with DLNA with my former NAS (atom n330 mini-itx, died since), thats why I am not even aiming any higher.
"Marvell never designed this SoC to do what we're doing to it"
That is 100% true, but the genius is not always in the design, sometimes it is in the application. :)
For me the plus is giving these things some more life, while doing something useful.
"A test to try would be to install vsftpd and configure it properly, and then try a plain unencrypted FTP link"
Good idea omitting the encryption. After a quick setup (with defaults, so probably non-properly), I am getting very nice speeds. A 1Gb random file put was 19.34 MB/s (150-170Mbps), and get was 29.71 MB/s (230-250 Mbps). CPU consumption is 90%+ for vsftpd or wget. This holds true "everywhere", meaning when I try to download the same ISO from the net, that via https link was 4 MB/s, via http link was 13MB/s. These nonsecure speeds would be very nice generally.
"if you want the CPU to ramp down speed to save power when not being actively used, installing cpufrequtils from apt is going to help in that department."
That I will do for sure, thanks for the tip.
So based on these measurements, unless some crypto part could be compiled with some hidden instructions (dont really know what I say here), the situation is 1) "it is what it is" 2) stay away from protocol with "S" in the name (which will be hard nowadays).
Best regards,
Peter
After some negotiations I managed to get the NAS and my laptop temporarly connected directly to the gigabit ports of the ISP router. This should help rule out the 100M switch and cabling issues. The simple wget and aria2c usercases did not improve. All futher measurements are done in this setup, unless marked.
"Try running some other task in parallel to see if it can get its share of the CPU."
I ran "sysbench --test=cpu --cpu-max-prime=2000 --num-threads=1 run &" in parallel to a wget download.
top - 19:04:00 up 7 min, 2 users, load average: 1.28, 0.62, 0.28 Tasks: 75 total, 2 running, 73 sleeping, 0 stopped, 0 zombie %Cpu(s): 82.8 us, 12.7 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 4.4 si, 0.0 st MiB Mem : 233.4 total, 13.4 free, 46.5 used, 187.5 buff/cache MiB Swap: 512.0 total, 511.7 free, 0.3 used. 186.9 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1167 root 20 0 12932 8140 5040 R 48.4 3.4 0:18.01 wget 1171 root 20 0 19228 5984 4752 S 48.4 2.5 0:02.59 sysbench 18 root 20 0 0 0 0 I 1.0 0.0 0:02.83 kworker/u2:1-events_unbound 1173 root 20 0 7852 4348 2396 R 1.0 1.8 0:00.11 top 38 root 20 0 0 0 0 S 0.6 0.0 0:00.89 kswapd0 1110 root 20 0 13868 8552 7248 S 0.6 3.6 0:01.15 sshd 1135 root 20 0 13868 8476 7168 S 0.3 3.5 0:00.58 sshd
...
The download speed scales almost linearly, and drops from ~4,5to 2,5MBps.
"List the ethtool info:"
root@debian:~# ethtool enp1s0
Settings for enp1s0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
master-slave cfg: preferred slave
master-slave status: slave
Port: Twisted Pair
PHYAD: 0
Transceiver: external
MDI-X: Unknown
Supports Wake-on: pumbg
Wake-on: d
Link detected: yes
root@debian:~# ethtool -k enp1s0 | grep tcp-segment
tcp-segmentation-offload: off
tx-tcp-segmentation: off
root@debian:~#
"your iperf test transfered a small file. Try running it with a larger file, eg. 1GB."
100M
root@debian:~# iperf -c 192.168.1.121 -n 1000M ------------------------------------------------------------ Client connecting to 192.168.1.121, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.1.157 port 47110 connected with 192.168.1.121 port 5001 (icwnd/mss/irtt=14/1448/378) [ ID] Interval Transfer Bandwidth [ 1] 0.0000-95.3165 sec 1000 MBytes 88.0 Mbits/sec
1G
root@debian:~# iperf -c 192.168.1.121 -n 1000M ------------------------------------------------------------ Client connecting to 192.168.1.121, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.1.157 port 53480 connected with 192.168.1.121 port 5001 (icwnd/mss/irtt=14/1448/245) [ ID] Interval Transfer Bandwidth [ 1] 0.0000-25.5917 sec 1000 MBytes 328 Mbits/sec root@debian:~#
1G but from a file
root@debian:~# dd if=/dev/urandom of=sample.txt bs=1M count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 82.6033 s, 13.0 MB/s root@debian:~# iperf -c 192.168.1.121 -F sample.txt ------------------------------------------------------------ Client connecting to 192.168.1.121, TCP port 5001 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 1] local 192.168.1.157 port 54238 connected with 192.168.1.121 port 5001 (icwnd/mss/irtt=14/1448/254) [ ID] Interval Transfer Bandwidth [ 1] 0.0000-40.7216 sec 1.00 GBytes 211 Mbits/sec root@debian:~#
"I've already come to terms that the most I'll ever get out file transfer-wise is going to be 7-8MB/s maximum on any kirkwood device"
That would suffice for me too. The main goal is the classic NAS usage, meaning transmission and minidlna, single user samba.
"Ideally, upgrading most of your network via a gigabit switch would be ideal, but I know how hard even sparing $20 is these days (about the cost of a cheap tp-link gig switch)"
Yes, that could help generally, although currently I have it connected and the speeds did not improve. The sad thing is, that in this home, there are CAT5e cables in the walls into each room, sometimes with not all strands connected properly. :( The 100M "backbone" was enough for the one TV with DLNA with my former NAS (atom n330 mini-itx, died since), thats why I am not even aiming any higher.
"Marvell never designed this SoC to do what we're doing to it"
That is 100% true, but the genius is not always in the design, sometimes it is in the application. :)
For me the plus is giving these things some more life, while doing something useful.
"A test to try would be to install vsftpd and configure it properly, and then try a plain unencrypted FTP link"
Good idea omitting the encryption. After a quick setup (with defaults, so probably non-properly), I am getting very nice speeds. A 1Gb random file put was 19.34 MB/s (150-170Mbps), and get was 29.71 MB/s (230-250 Mbps). CPU consumption is 90%+ for vsftpd or wget. This holds true "everywhere", meaning when I try to download the same ISO from the net, that via https link was 4 MB/s, via http link was 13MB/s. These nonsecure speeds would be very nice generally.
"if you want the CPU to ramp down speed to save power when not being actively used, installing cpufrequtils from apt is going to help in that department."
That I will do for sure, thanks for the tip.
So based on these measurements, unless some crypto part could be compiled with some hidden instructions (dont really know what I say here), the situation is 1) "it is what it is" 2) stay away from protocol with "S" in the name (which will be hard nowadays).
Best regards,
Peter
|
Re: NSA310 + kirkwood 6.5.7 improve net performance February 29, 2024 03:34PM |
Admin Registered: 13 years ago Posts: 18,575 |
Peter,
> "Marvell never designed this SoC to do what we're
> doing to it"
> That is 100% true, but the genius is not always in
> the design, sometimes it is in the application. :)
Yes it is :)
>
> For me the plus is giving these things some more
> life, while doing something useful.
Totally.
> power when not being actively used, installing
> cpufrequtils from apt is going to help in that
> department."
> That I will do for sure, thanks for the tip.
I kept forgetting to add this to the release notes. Thanks @sudos for reminding me.
====
Base on your output of the ethtool, you need to enable TSO (TCP Segment Offload). Try
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 02/29/2024 03:45PM by bodhi.
> "Marvell never designed this SoC to do what we're
> doing to it"
> That is 100% true, but the genius is not always in
> the design, sometimes it is in the application. :)
Yes it is :)
>
> For me the plus is giving these things some more
> life, while doing something useful.
Totally.
> power when not being actively used, installing
> cpufrequtils from apt is going to help in that
> department."
> That I will do for sure, thanks for the tip.
I kept forgetting to add this to the release notes. Thanks @sudos for reminding me.
====
Base on your output of the ethtool, you need to enable TSO (TCP Segment Offload). Try
ethtool -K eth0 tso onHope this will help the transfer rate it a bit higher. For Marvell's NIC, it is significant.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 02/29/2024 03:45PM by bodhi.
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 01, 2024 02:01PM |
Registered: 5 months ago Posts: 13 |
Simple TSO setting failed at first.
But luckily short googling got me to https://bugzilla.kernel.org/show_bug.cgi?id=206969 where they said "TSO depends on SG. To switch TSO on: ethtool -K eth2 tso on sg on"
And indeed, getting data off the NAS improved quite a bit, effectively doubled!
TSO OFF
1073741824 bytes received in 00:32 (31.82 MiB/s)
1073741824 bytes sent in 00:51 (19.92 MiB/s)
TSO ON
1073741824 bytes received in 00:16 (63.26 MiB/s)
1073741824 bytes sent in 00:51 (20.05 MiB/s)
I would have never guessed, that with TSO ON, and selecting the right transfer method would yield such speeds!
So I think I just have to adapt to this and me and the unit will get on fine.
Thank you for your support!
root@debian:~# ethtool -K enp1s0 tso on Actual changes: tx-tcp-segmentation: off [requested on] tx-tcp-ecn-segmentation: off [requested on] tx-tcp-mangleid-segmentation: off [requested on] tx-tcp6-segmentation: off [requested on] Could not change any device features
But luckily short googling got me to https://bugzilla.kernel.org/show_bug.cgi?id=206969 where they said "TSO depends on SG. To switch TSO on: ethtool -K eth2 tso on sg on"
root@debian:~# ethtool -K enp1s0 tso on sg on Actual changes: tx-scatter-gather: on tx-scatter-gather-fraglist: off [requested on] tx-generic-segmentation: on [not requested] tx-tcp-segmentation: on tx-tcp-ecn-segmentation: off [requested on] tx-tcp-mangleid-segmentation: on tx-tcp6-segmentation: on root@debian:~#
And indeed, getting data off the NAS improved quite a bit, effectively doubled!
TSO OFF
1073741824 bytes received in 00:32 (31.82 MiB/s)
1073741824 bytes sent in 00:51 (19.92 MiB/s)
TSO ON
1073741824 bytes received in 00:16 (63.26 MiB/s)
1073741824 bytes sent in 00:51 (20.05 MiB/s)
I would have never guessed, that with TSO ON, and selecting the right transfer method would yield such speeds!
So I think I just have to adapt to this and me and the unit will get on fine.
Thank you for your support!
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 01, 2024 02:31PM |
Admin Registered: 13 years ago Posts: 18,575 |
> And indeed, getting data off the NAS improved
> quite a bit, effectively doubled!
> TSO OFF
> 1073741824 bytes received in 00:32 (31.82 MiB/s)
> 1073741824 bytes sent in 00:51 (19.92 MiB/s)
>
> TSO ON
> 1073741824 bytes received in 00:16 (63.26 MiB/s)
> 1073741824 bytes sent in 00:51 (20.05 MiB/s)
Cool!
> I would have never guessed, that with TSO ON, and
> selecting the right transfer method would yield
> such speeds!
> So I think I just have to adapt to this and me and
> the unit will get on fine.
:)
=======
One more thing: currently this NSA310 u-boot 2017.07 does not suport Ethernet during u-bboot booting phase. It's because back then we don't have support in u-boot this RealTek chip. If you or anybody want to be a tester, I could give it a try adding Ethernet to u-boot (I don't have the hardware so I cannot test it). But it is not a big thing, people rarely need this capability unless they want to boot from NFS rootfs.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> quite a bit, effectively doubled!
> TSO OFF
> 1073741824 bytes received in 00:32 (31.82 MiB/s)
> 1073741824 bytes sent in 00:51 (19.92 MiB/s)
>
> TSO ON
> 1073741824 bytes received in 00:16 (63.26 MiB/s)
> 1073741824 bytes sent in 00:51 (20.05 MiB/s)
Cool!
> I would have never guessed, that with TSO ON, and
> selecting the right transfer method would yield
> such speeds!
> So I think I just have to adapt to this and me and
> the unit will get on fine.
:)
=======
One more thing: currently this NSA310 u-boot 2017.07 does not suport Ethernet during u-bboot booting phase. It's because back then we don't have support in u-boot this RealTek chip. If you or anybody want to be a tester, I could give it a try adding Ethernet to u-boot (I don't have the hardware so I cannot test it). But it is not a big thing, people rarely need this capability unless they want to boot from NFS rootfs.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 01, 2024 09:51PM |
Registered: 1 year ago Posts: 81 |
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 01, 2024 09:56PM |
Admin Registered: 13 years ago Posts: 18,575 |
> I realize I'm kinda cross-posting about this,
Yeah, perhaps you can start a thread about cpufreq-utils and I'll discuss this in that thread. All my Kirkwood boxes run on-demand cpufreq.
> AFAICT, it's set to 'ondemand', which should
> throttle.
Yes.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Yeah, perhaps you can start a thread about cpufreq-utils and I'll discuss this in that thread. All my Kirkwood boxes run on-demand cpufreq.
> AFAICT, it's set to 'ondemand', which should
> throttle.
Yes.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 01, 2024 09:59PM |
Registered: 1 year ago Posts: 81 |
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 04, 2024 09:55AM |
Registered: 5 months ago Posts: 13 |
Hi bodhi,
"If you or anybody want to be a tester, I could give it a try adding Ethernet to u-boot (I don't have the hardware so I cannot test it)."
I could give it a try, if you make a version. I am guessing I would only need to just kwboot is over UART, and see if the network interface is recognized?
BR,
Peter
"If you or anybody want to be a tester, I could give it a try adding Ethernet to u-boot (I don't have the hardware so I cannot test it)."
I could give it a try, if you make a version. I am guessing I would only need to just kwboot is over UART, and see if the network interface is recognized?
BR,
Peter
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 04, 2024 03:00PM |
Admin Registered: 13 years ago Posts: 18,575 |
Peter,
> I could give it a try, if you make a version. I am
> guessing I would only need to just kwboot is over
> UART, and see if the network interface is
> recognized?
Yes, that's the idea. Hopefully it won't be too time consuming. Basically, whenever I build a new version, you then try kwboot and ping the router, and then post the log.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> I could give it a try, if you make a version. I am
> guessing I would only need to just kwboot is over
> UART, and see if the network interface is
> recognized?
Yes, that's the idea. Hopefully it won't be too time consuming. Basically, whenever I build a new version, you then try kwboot and ping the router, and then post the log.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 04, 2024 04:50PM |
Admin Registered: 13 years ago Posts: 18,575 |
Peter,
Please post output of
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Please post output of
dmesg
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 05, 2024 01:22AM |
Registered: 5 months ago Posts: 13 |
Booted from disk it looks like this:
root@192.168.1.157's password: Linux debian 6.5.7-kirkwood-tld-1 #2 PREEMPT Wed Oct 18 21:14:11 PDT 2023 armv5tel The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Fri Mar 1 21:33:29 2024 from 192.168.1.121 debian 192.168.1.157 ZyXEL NSA310 Linux version 6.5.7-kirkwood-tld-1 (root@tldDebian) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #2 PREEMPT Wed Oct 18 21:14:11 PDT 2023 Debian 12.5 Tue Mar 5 08:20:17 CET 2024 up 4 minutes root@debian:~# dmesg [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 6.5.7-kirkwood-tld-1 (root@tldDebian) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #2 PREEMPT Wed Oct 18 21:14:11 PDT 2023 [ 0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=0005397f [ 0.000000] CPU: VIVT data cache, VIVT instruction cache [ 0.000000] OF: fdt: Machine model: ZyXEL NSA310 [ 0.000000] Memory policy: Data cache writeback [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000000000000-0x000000000fffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x000000000fffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000000fffffff] [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Kernel command line: console=ttyS0,115200 root=LABEL=rootfs rootdelay=10 nand_mtd:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2) [ 0.000000] Unknown kernel command line parameters "nand_mtd:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2)", will be passed to user space. [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes, linear) [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes, linear) [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 64960 [ 0.000000] mem auto-init: stack:off, heap alloc:on, heap free:off [ 0.000000] Memory: 232348K/262144K available (12288K kernel code, 1755K rwdata, 5416K rodata, 1024K init, 301K bss, 29796K reserved, 0K cma-reserved) [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] trace event string verifier disabled [ 0.000000] rcu: Preemptible hierarchical RCU implementation. [ 0.000000] Trampoline variant of Tasks RCU enabled. [ 0.000000] Tracing variant of Tasks RCU enabled. [ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. [ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention. [ 0.000000] clocksource: orion_clocksource: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 9556302233 ns [ 0.000002] sched_clock: 32 bits at 200MHz, resolution 5ns, wraps every 10737418237ns [ 0.000049] Switching to timer-based delay loop, resolution 5ns [ 0.000638] Console: colour dummy device 80x30 [ 0.000712] Calibrating delay loop (skipped), value calculated using timer frequency.. 400.00 BogoMIPS (lpj=2000000) [ 0.000743] CPU: Testing write buffer coherency: ok [ 0.000879] pid_max: default: 32768 minimum: 301 [ 0.009624] LSM: initializing lsm=capability,integrity [ 0.012097] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.012135] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 0.024642] RCU Tasks: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1. [ 0.025017] RCU Tasks Trace: Setting shift to 0 and lim to 1 rcu_task_cb_adjust=1. [ 0.025500] Setting up static identity map for 0x100000 - 0x100058 [ 0.025856] mvebu-soc-id: MVEBU SoC ID=0x6281, Rev=0x3 [ 0.026292] rcu: Hierarchical SRCU implementation. [ 0.026309] rcu: Max phase no-delay instances is 1000. [ 0.029326] devtmpfs: initialized [ 0.040979] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns [ 0.041025] futex hash table entries: 256 (order: -1, 3072 bytes, linear) [ 0.043863] prandom: seed boundary self test passed [ 0.048109] prandom: 100 self tests passed [ 0.048126] pinctrl core: initialized pinctrl subsystem [ 0.052019] NET: Registered PF_NETLINK/PF_ROUTE protocol family [ 0.053106] DMA: preallocated 256 KiB pool for atomic coherent allocations [ 0.058458] audit: initializing netlink subsys (disabled) [ 0.059612] audit: type=2000 audit(0.050:1): state=initialized audit_enabled=0 res=1 [ 0.061353] thermal_sys: Registered thermal governor 'step_wise' [ 0.061513] cpuidle: using governor ladder [ 0.061599] cpuidle: using governor menu [ 0.062472] Feroceon L2: Enabling L2 [ 0.062511] Feroceon L2: Cache support initialised. [ 0.066536] platform f1010000.pin-controller: Fixed dependency cycle(s) with /ocp@f1000000/pin-controller@10000/pmx-unknown [ 0.073560] No ATAGs? [ 0.440067] raid6: int32x8 gen() 110 MB/s [ 0.780067] raid6: int32x4 gen() 106 MB/s [ 1.120091] raid6: int32x2 gen() 136 MB/s [ 1.460068] raid6: int32x1 gen() 98 MB/s [ 1.460082] raid6: using algorithm int32x2 gen() 136 MB/s [ 1.800066] raid6: .... xor() 86 MB/s, rmw enabled [ 1.800078] raid6: using intx1 recovery algorithm [ 1.801819] SCSI subsystem initialized [ 1.802180] libata version 3.00 loaded. [ 1.802580] usbcore: registered new interface driver usbfs [ 1.802690] usbcore: registered new interface driver hub [ 1.802759] usbcore: registered new device driver usb [ 1.803146] pps_core: LinuxPPS API ver. 1 registered [ 1.803156] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it> [ 1.803189] PTP clock support registered [ 1.805924] vgaarb: loaded [ 1.807005] clocksource: Switched to clocksource orion_clocksource [ 1.823480] VFS: Disk quotas dquot_6.6.0 [ 1.823917] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 1.858913] NET: Registered PF_INET protocol family [ 1.859232] IP idents hash table entries: 4096 (order: 3, 32768 bytes, linear) [ 1.861473] tcp_listen_portaddr_hash hash table entries: 1024 (order: 0, 4096 bytes, linear) [ 1.861685] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear) [ 1.861716] TCP established hash table entries: 2048 (order: 1, 8192 bytes, linear) [ 1.861763] TCP bind hash table entries: 2048 (order: 2, 16384 bytes, linear) [ 1.861818] TCP: Hash tables configured (established 2048 bind 2048) [ 1.862513] MPTCP token hash table entries: 512 (order: 0, 6144 bytes, linear) [ 1.862759] UDP hash table entries: 256 (order: 0, 4096 bytes, linear) [ 1.862794] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes, linear) [ 1.863676] NET: Registered PF_UNIX/PF_LOCAL protocol family [ 1.877682] RPC: Registered named UNIX socket transport module. [ 1.877698] RPC: Registered udp transport module. [ 1.877705] RPC: Registered tcp transport module. [ 1.877711] RPC: Registered tcp-with-tls transport module. [ 1.877717] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 1.877739] PCI: CLS 0 bytes, default 32 [ 1.880935] Trying to unpack rootfs image as initramfs... [ 2.848727] Freeing initrd memory: 5644K [ 3.703678] Initialise system trusted keyrings [ 3.703774] Key type blacklist registered [ 3.705200] workingset: timestamp_bits=14 max_order=16 bucket_order=2 [ 3.705342] zbud: loaded [ 3.724558] NFS: Registering the id_resolver key type [ 3.724626] Key type id_resolver registered [ 3.724636] Key type id_legacy registered [ 3.724832] nfs4filelayout_init: NFSv4 File Layout Driver Registering... [ 3.724853] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering... [ 3.726440] jffs2: version 2.2. (NAND) (SUMMARY) \xc2\xa9 2001-2006 Red Hat, Inc. [ 3.727423] fuse: init (API version 7.38) [ 3.728874] orangefs_debugfs_init: called with debug mask: :none: :0: [ 3.729213] orangefs_init: module version upstream loaded [ 3.729607] SGI XFS with ACLs, security attributes, realtime, scrub, quota, no debug enabled [ 3.899233] jitterentropy: Initialization failed with host not compliant with requirements: 9 [ 3.899271] xor: measuring software checksum speed [ 3.908120] arm4regs : 1119 MB/sec [ 3.922796] 8regs : 671 MB/sec [ 3.933151] 32regs : 952 MB/sec [ 3.933161] xor: using function: arm4regs (1119 MB/sec) [ 3.933177] async_tx: api initialized (async) [ 3.933193] Key type asymmetric registered [ 3.933202] Asymmetric key parser 'x509' registered [ 3.985597] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 246) [ 3.986047] io scheduler bfq registered [ 4.174917] kirkwood-pinctrl f1010000.pin-controller: registered pinctrl driver [ 4.176995] gpio gpiochip0: Static allocation of GPIO base is deprecated, use dynamic allocation. [ 4.178503] gpio gpiochip1: Static allocation of GPIO base is deprecated, use dynamic allocation. [ 4.179643] mvebu-pcie mbus@f1000000:pcie@82000000: host bridge /mbus@f1000000/pcie@82000000 ranges: [ 4.179685] mvebu-pcie mbus@f1000000:pcie@82000000: Parsing ranges property... [ 4.179727] mvebu-pcie mbus@f1000000:pcie@82000000: MEM 0x00f1040000..0x00f1041fff -> 0x0000040000 [ 4.179774] mvebu-pcie mbus@f1000000:pcie@82000000: MEM 0xffffffffffffffff..0x00fffffffe -> 0x0100000000 [ 4.179803] mvebu-pcie mbus@f1000000:pcie@82000000: IO 0xffffffffffffffff..0x00fffffffe -> 0x0100000000 [ 4.180567] mvebu-pcie mbus@f1000000:pcie@82000000: PCI host bridge to bus 0000:00 [ 4.180588] pci_bus 0000:00: root bus resource [bus 00-ff] [ 4.180608] pci_bus 0000:00: root bus resource [mem 0xf1040000-0xf1041fff] (bus address [0x00040000-0x00041fff]) [ 4.180625] pci_bus 0000:00: root bus resource [mem 0xe0000000-0xefffffff] [ 4.180640] pci_bus 0000:00: root bus resource [io 0x1000-0xeffff] [ 4.180655] pci_bus 0000:00: scanning bus [ 4.180758] pci 0000:00:01.0: [11ab:6281] type 01 class 0x060400 [ 4.181233] pci 0000:00:01.0: vgaarb: pci_notify [ 4.182622] pci_bus 0000:00: fixups for bus [ 4.182642] PCI: bus0: Fast back to back transfers disabled [ 4.182657] pci 0000:00:01.0: scanning [bus 00-00] behind bridge, pass 0 [ 4.182672] pci 0000:00:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring [ 4.182692] pci 0000:00:01.0: scanning [bus 00-00] behind bridge, pass 1 [ 4.182935] pci_bus 0000:01: scanning bus [ 4.182990] pci 0000:01:00.0: [10ec:8168] type 00 class 0x020000 [ 4.183023] pci 0000:01:00.0: reg 0x10: [io 0x0000-0x00ff] [ 4.183054] pci 0000:01:00.0: reg 0x18: [mem 0x00000000-0x00000fff 64bit pref] [ 4.183080] pci 0000:01:00.0: reg 0x20: [mem 0x00000000-0x00003fff 64bit pref] [ 4.183101] pci 0000:01:00.0: reg 0x30: [mem 0x00000000-0x0000ffff pref] [ 4.183220] pci 0000:01:00.0: supports D1 D2 [ 4.183233] pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold [ 4.183250] pci 0000:01:00.0: PME# disabled [ 4.183692] pci 0000:01:00.0: vgaarb: pci_notify [ 4.207123] pci_bus 0000:01: fixups for bus [ 4.207142] PCI: bus1: Fast back to back transfers disabled [ 4.207153] pci_bus 0000:01: bus scan returning with max=01 [ 4.207167] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01 [ 4.207189] pci_bus 0000:00: bus scan returning with max=01 [ 4.207224] pci 0000:00:01.0: BAR 14: assigned [mem 0xe0000000-0xe00fffff] [ 4.207244] pci 0000:00:01.0: BAR 13: assigned [io 0x10000-0x10fff] [ 4.207267] pci 0000:01:00.0: BAR 6: assigned [mem 0xe0000000-0xe000ffff pref] [ 4.207287] pci 0000:01:00.0: BAR 4: assigned [mem 0xe0010000-0xe0013fff 64bit pref] [ 4.207313] pci 0000:01:00.0: BAR 2: assigned [mem 0xe0014000-0xe0014fff 64bit pref] [ 4.207339] pci 0000:01:00.0: BAR 0: assigned [io 0x10000-0x100ff] [ 4.207359] pci 0000:00:01.0: PCI bridge to [bus 01] [ 4.207373] pci 0000:00:01.0: bridge window [io 0x10000-0x10fff] [ 4.207396] pci 0000:00:01.0: bridge window [mem 0xe0000000-0xe00fffff] [ 4.207498] pcieport 0000:00:01.0: vgaarb: pci_notify [ 4.207536] pcieport 0000:00:01.0: assign IRQ: got 0 [ 4.207559] pcieport 0000:00:01.0: enabling device (0140 -> 0143) [ 4.207584] pcieport 0000:00:01.0: enabling bus mastering [ 4.207619] pcieport 0000:00:01.0: vgaarb: pci_notify [ 4.208501] mv_xor f1060800.xor: Marvell shared XOR driver [ 4.269667] mv_xor f1060800.xor: Marvell XOR (Registers Mode): ( xor cpy intr ) [ 4.274374] mv_xor f1060900.xor: Marvell shared XOR driver [ 4.339672] mv_xor f1060900.xor: Marvell XOR (Registers Mode): ( xor cpy intr ) [ 4.344814] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled [ 4.347711] printk: console [ttyS0] disabled [ 4.348391] f1012000.serial: ttyS0 at MMIO 0xf1012000 (irq = 28, base_baud = 12500000) is a 16550A [ 4.348462] printk: console [ttyS0] enabled [ 5.515946] loop: module loaded [ 5.520253] sata_mv f1080000.sata: version 1.28 [ 5.521023] sata_mv f1080000.sata: slots 32 ports 2 [ 5.531491] scsi host0: sata_mv [ 5.537107] scsi host1: sata_mv [ 5.541413] ata1: SATA max UDMA/133 irq 29 [ 5.546245] ata2: SATA max UDMA/133 irq 29 [ 5.552503] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xf1 [ 5.559636] nand: Samsung NAND 128MiB 3,3V 8-bit [ 5.564981] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 [ 5.573340] Scanning device for bad blocks [ 5.637256] Bad eraseblock 611 at 0x000004c60000 [ 5.643517] Bad eraseblock 621 at 0x000004da0000 [ 5.687797] 9 fixed-partitions partitions found on MTD device orion_nand [ 5.695241] Creating 9 MTD partitions on "orion_nand": [ 5.701138] 0x000000000000-0x000000100000 : "uboot" [ 5.707684] 0x000000100000-0x000000180000 : "uboot_env" [ 5.714420] 0x000000180000-0x000000200000 : "key_store" [ 5.721224] 0x000000200000-0x000000280000 : "info" [ 5.727533] 0x000000280000-0x000000c80000 : "etc" [ 5.733728] 0x000000c80000-0x000001680000 : "kernel_1" [ 5.740448] 0x000001680000-0x000004640000 : "rootfs1" [ 5.747246] 0x000004640000-0x000005040000 : "kernel_2" [ 5.753958] 0x000005040000-0x000008000000 : "rootfs2" [ 5.761602] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for information. [ 5.770259] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved. [ 5.784709] orion-ehci f1050000.ehci: EHCI Host Controller [ 5.791090] orion-ehci f1050000.ehci: new USB bus registered, assigned bus number 1 [ 5.799778] orion-ehci f1050000.ehci: irq 30, io mem 0xf1050000 [ 5.827037] orion-ehci f1050000.ehci: USB 2.0 started, EHCI 1.00 [ 5.834220] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.05 [ 5.843293] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 5.851306] usb usb1: Product: EHCI Host Controller [ 5.856942] usb usb1: Manufacturer: Linux 6.5.7-kirkwood-tld-1 ehci_hcd [ 5.864338] usb usb1: SerialNumber: f1050000.ehci [ 5.870930] hub 1-0:1.0: USB hub found [ 5.875529] hub 1-0:1.0: 1 port detected [ 5.881372] usbcore: registered new interface driver usb-storage [ 5.888810] mousedev: PS/2 mouse device common for all mice [ 5.896664] rtc-mv f1010300.rtc: registered as rtc0 [ 5.902396] rtc-mv f1010300.rtc: setting system clock to 2024-03-05T07:16:13 UTC (1709622973) [ 5.912151] i2c_dev: i2c /dev entries driver [ 5.919903] device-mapper: uevent: version 1.0.3 [ 5.925866] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@redhat.com [ 5.935883] device-mapper: multipath round-robin: version 1.2.0 loaded [ 5.943239] device-mapper: multipath queue-length: version 0.2.0 loaded [ 5.950662] device-mapper: multipath service-time: version 0.3.0 loaded [ 5.958118] device-mapper: dm-log-userspace: version 1.3.0 loaded [ 5.968627] ledtrig-cpu: registered to indicate activity on CPUs [ 5.975532] hid: raw HID events driver (C) Jiri Kosina [ 5.981879] drop_monitor: Initializing network drop monitor service [ 5.990475] NET: Registered PF_INET6 protocol family [ 5.998305] Segment Routing with IPv6 [ 6.002701] RPL Segment Routing with IPv6 [ 6.007635] In-situ OAM (IOAM) with IPv6 [ 6.012437] NET: Registered PF_PACKET protocol family [ 6.018812] Key type dns_resolver registered [ 6.043376] registered taskstats version 1 [ 6.048321] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300) [ 6.055903] Loading compiled-in X.509 certificates [ 6.062021] ata1.00: ATA-9: WDC WD30EZRX-22D8PB0, 80.00A80, max UDMA/133 [ 6.077063] ata1.00: 5860533168 sectors, multi 0: LBA48 NCQ (depth 31/32) [ 6.099766] ata1.00: configured for UDMA/133 [ 6.105137] Key type .fscrypt registered [ 6.109858] Key type fscrypt-provisioning registered [ 6.116174] scsi 0:0:0:0: Direct-Access ATA WDC WD30EZRX-22D 0A80 PQ: 0 ANSI: 5 [ 6.131674] sd 0:0:0:0: [sda] 5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB) [ 6.141989] Key type big_key registered [ 6.157193] sd 0:0:0:0: [sda] 4096-byte physical blocks [ 6.163289] sd 0:0:0:0: [sda] Write Protect is off [ 6.168911] usb 1-1: new high-speed USB device number 2 using orion-ehci [ 6.187205] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 6.187378] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 6.207432] sd 0:0:0:0: [sda] Preferred minimum I/O size 4096 bytes [ 6.233080] Key type encrypted registered [ 6.345543] "cryptomgr_test" (103) uses obsolete ecb(arc4) skcipher [ 6.388910] usb 1-1: New USB device found, idVendor=05e3, idProduct=0608, bcdDevice=77.63 [ 6.407146] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 6.420140] usb 1-1: Product: USB2.0 Hub [ 6.435781] hub 1-1:1.0: USB hub found [ 6.445590] hub 1-1:1.0: 4 ports detected [ 6.481102] ata2: SATA link down (SStatus 0 SControl F300) [ 6.817988] sda: sda1 [ 6.827355] sd 0:0:0:0: [sda] Attached SCSI disk [ 8.686892] clk: Disabling unused clocks [ 8.695109] Freeing unused kernel image (initmem) memory: 1024K [ 8.707917] Checked W+X mappings: passed, no W+X pages found [ 8.714335] Run /init as init process [ 8.718788] with arguments: [ 8.718803] /init [ 8.718813] nand_mtd:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2) [ 8.718828] with environment: [ 8.718837] HOME=/ [ 8.718846] TERM=linux [ 10.250267] regulator@1 enforce active low on GPIO handle [ 21.083095] EXT4-fs (sda1): mounting ext3 file system using the ext4 subsystem [ 21.141827] EXT4-fs (sda1): mounted filesystem 45e9dbcf-44aa-42b0-aa1a-7c02a4be5771 ro with ordered data mode. Quota mode: none. [ 24.830775] input: gpio_keys as /devices/platform/gpio_keys/input/input0 [ 25.199172] r8169 0000:01:00.0: vgaarb: pci_notify [ 25.199366] r8169 0000:01:00.0: assign IRQ: got 36 [ 25.199478] pci 0000:00:01.0: enabling bus mastering [ 25.199503] r8169 0000:01:00.0: enabling device (0140 -> 0143) [ 25.298043] r8169 0000:01:00.0: enabling Mem-Wr-Inval [ 25.314896] orion_wdt: Initial timeout 21 sec [ 25.394632] r8169 0000:01:00.0 eth0: RTL8168d/8111d, 00:00:00:00:00:30, XID 283, IRQ 36 [ 25.411581] hwmon_vid: Unknown VRM version of your CPU [ 25.457913] adt7475 0-002e: ADT7476 device, revision 1 [ 25.463801] adt7475 0-002e: Optional features: in0 in4 fan4 pwm2 vid [ 25.543107] r8169 0000:01:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko] [ 25.698754] r8169 0000:01:00.0: vgaarb: pci_notify [ 25.717451] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 26.058296] marvell-cesa f1030000.crypto: CESA device successfully registered [ 27.312899] r8169 0000:01:00.0 enp1s0: renamed from eth0 [ 28.197314] EXT4-fs (sda1): re-mounted 45e9dbcf-44aa-42b0-aa1a-7c02a4be5771 r/w. Quota mode: none. [ 30.813582] Adding 524284k swap on /swapfile1. Priority:-2 extents:12 across:1329856k FS [ 31.117119] random: crng init done [ 31.936063] r8169 0000:01:00.0: Direct firmware load for rtl_nic/rtl8168d-2.fw failed with error -2 [ 31.947193] r8169 0000:01:00.0: Unable to load firmware rtl_nic/rtl8168d-2.fw (-2) [ 31.956492] RTL8211B Gigabit Ethernet r8169-0-100:00: attached PHY driver (mii_bus:phy_addr=r8169-0-100:00, irq=MAC) [ 31.967831] r8169 0000:01:00.0: enabling bus mastering [ 32.049615] r8169 0000:01:00.0 enp1s0: Link is Down [ 33.635714] r8169 0000:01:00.0 enp1s0: Link is Up - 100Mbps/Full - flow control rx/tx root@debian:~#
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 05, 2024 01:29AM |
Admin Registered: 13 years ago Posts: 18,575 |
Thanks Peter!
That's the driver name I am looking for
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
That's the driver name I am looking for
[ 25.199172] r8169 0000:01:00.0: vgaarb: pci_notify [ 25.199366] r8169 0000:01:00.0: assign IRQ: got 36 [ 25.199478] pci 0000:00:01.0: enabling bus mastering [ 25.199503] r8169 0000:01:00.0: enabling device (0140 -> 0143) [ 25.298043] r8169 0000:01:00.0: enabling Mem-Wr-Inval [ 25.314896] orion_wdt: Initial timeout 21 sec [ 25.394632] r8169 0000:01:00.0 eth0: RTL8168d/8111d, 00:00:00:00:00:30, XID 283, IRQ 36 [ 25.411581] hwmon_vid: Unknown VRM version of your CPU [ 25.457913] adt7475 0-002e: ADT7476 device, revision 1 [ 25.463801] adt7475 0-002e: Optional features: in0 in4 fan4 pwm2 vid [ 25.543107] r8169 0000:01:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko] [ 25.698754] r8169 0000:01:00.0: vgaarb: pci_notify [ 25.717451] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 26.058296] marvell-cesa f1030000.crypto: CESA device successfully registered [ 27.312899] r8169 0000:01:00.0 enp1s0: renamed from eth0 [ 28.197314] EXT4-fs (sda1): re-mounted 45e9dbcf-44aa-42b0-aa1a-7c02a4be5771 r/w. Quota mode: none. [ 30.813582] Adding 524284k swap on /swapfile1. Priority:-2 extents:12 across:1329856k FS [ 31.117119] random: crng init done [ 31.936063] r8169 0000:01:00.0: Direct firmware load for rtl_nic/rtl8168d-2.fw failed with error -2 [ 31.947193] r8169 0000:01:00.0: Unable to load firmware rtl_nic/rtl8168d-2.fw (-2) [ 31.956492] RTL8211B Gigabit Ethernet r8169-0-100:00: attached PHY driver (mii_bus:phy_addr=r8169-0-100:00, irq=MAC) [ 31.967831] r8169 0000:01:00.0: enabling bus mastering [ 32.049615] r8169 0000:01:00.0 enp1s0: Link is Down [ 33.635714] r8169 0000:01:00.0 enp1s0: Link is Up - 100Mbps/Full - flow control rx/tx
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 05, 2024 05:11PM |
Admin Registered: 13 years ago Posts: 18,575 |
Hi Peter,
Here is the new NSA310 u-boot (attached to this post).
uboot.2023.04-tld-1.nsa310.kwb
Run kwboot with it, interrupt the u-boot countdown, and
And then
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Here is the new NSA310 u-boot (attached to this post).
uboot.2023.04-tld-1.nsa310.kwb
md5: cf4a7959fd2d7e5f8ec72b95ce5702f8 sha256: 707e43e6b6284c7484668a9eb2c8d9e6516e07279117e6cd59500190b8cf4ba2
Run kwboot with it, interrupt the u-boot countdown, and
dm tree ping <the router IP address>if the ping is successful
dm treeif the ping is not successful
pci enum dm tree ping <the router IP address>
And then
mii info
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 06, 2024 12:19PM |
Registered: 5 months ago Posts: 13 |
Hi,
Sadly not successful yet, details below.
Boot went OK, but immediately, I see a No ethernet found.
As expected, ping fails.
The outputs:
Sadly not successful yet, details below.
Boot went OK, but immediately, I see a No ethernet found.
root@raspberrypi:/home/pi# kwboot -t -B 115200 /dev/ttyAMA0 -b uboot.2023.04-tld-1.nsa310.kwb -p Sending boot message. Please reboot the target...- Sending boot image... 0 % [......................................................................] ... 99 % [....................................] [Type Ctrl-\ + c to quit] U-Boot 2023.04-tld-1 (Mar 05 2024 - 12:29:09 -0800) ZyXEL NSA310 1-Bay Power Media Server SoC: Kirkwood 88F6281_A1 Model: ZyXEL NSA310 DRAM: 256 MiB Core: 15 devices, 12 uclasses, devicetree: separate NAND: 128 MiB Loading Environment from NAND... OK Resetting console stdin/stdout/stderr to serial... In: serial Out: serial Err: serial Net: No ethernet found. Error occured, error code = 64 Hit any key to stop autoboot: 0
As expected, ping fails.
NSA310> ping 192.168.1.1 No ethernet found. ping failed; host 192.168.1.1 is not alive
The outputs:
NSA310> pci enum pcie0.0: Link up
NSA310> dm tree Class Index Probed Driver Name ----------------------------------------------------------- root 0 [ + ] root_driver root_driver simple_bus 0 [ + ] simple_bus |-- mbus@f1000000 misc 0 [ + ] pcie_mvebu_base | `-- pcie@82000000 pci 0 [ + ] pcie_mvebu | `-- pcie0.0 pci 1 [ + ] pci_bridge_drv | `-- pci_0:0.0 ethernet 0 [ ] eth_rtl8169 | `-- eth_rtl8169 bootdev 0 [ ] eth_bootdev | `-- eth_rtl8169.bootdev simple_bus 1 [ + ] simple_bus |-- ocp@f1000000 gpio 0 [ ] gpio_mvebu | |-- gpio@10100 gpio 1 [ ] gpio_mvebu | |-- gpio@10140 serial 0 [ + ] ns16550_serial | |-- serial@12000 timer 0 [ + ] orion_timer | |-- timer@20300 usb 0 [ ] ehci_mvebu | |-- ehci@50000 rtc 0 [ ] rtc-mv | |-- rtc@10300 ahci 0 [ ] sata_mv_ahci | `-- sata@80000 simple_bus 2 [ ] simple_bus |-- regulators bootstd 0 [ ] bootstd_drv `-- bootstd bootmeth 0 [ ] bootmeth_distro `-- distro
NSA310> mii info NULL device name! No such device: <NULL> NULL device name! ... <repeats 32 times total> ... NULL device name! No such device: <NULL> NSA310>
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 06, 2024 01:37PM |
Admin Registered: 13 years ago Posts: 18,575 |
>
>
>
>
At this point, ping the router again.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> NSA310> pci enum > pcie0.0: Link up >>
>
>
> NSA310> dm tree > Class Index Probed Driver > Name > ----------------------------------------------------------- > root 0 [ + ] root_driver > root_driver > simple_bus 0 [ + ] simple_bus > |-- mbus@f1000000 > misc 0 [ + ] pcie_mvebu_base | > `-- pcie@82000000 > pci 0 [ + ] pcie_mvebu | > `-- pcie0.0 > pci 1 [ + ] pci_bridge_drv | > `-- pci_0:0.0 > ethernet 0 [ ] eth_rtl8169 | > `-- eth_rtl8169 > bootdev 0 [ ] eth_bootdev | > `-- eth_rtl8169.bootdev > simple_bus 1 [ + ] simple_bus > |-- ocp@f1000000 > gpio 0 [ ] gpio_mvebu | > |-- gpio@10100 > gpio 1 [ ] gpio_mvebu | > |-- gpio@10140 > serial 0 [ + ] ns16550_serial | > |-- serial@12000 > timer 0 [ + ] orion_timer | > |-- timer@20300 > usb 0 [ ] ehci_mvebu | > |-- ehci@50000 > rtc 0 [ ] rtc-mv | > |-- rtc@10300 > ahci 0 [ ] sata_mv_ahci | > `-- sata@80000 > simple_bus 2 [ ] simple_bus > |-- regulators > bootstd 0 [ ] bootstd_drv > `-- bootstd > bootmeth 0 [ ] bootmeth_distro > `-- distro >>
>
> NSA310> mii info > NULL device name! > No such device: <NULL> > NULL device name! > ... > <repeats 32 times total> > ... > NULL device name! > No such device: <NULL> > NSA310> >
At this point, ping the router again.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 06, 2024 01:44PM |
Registered: 5 months ago Posts: 13 |
Oh, sorry, I was not following directions.
The ping then gives
The ping then gives
NSA310> ping 192.168.1.1 Warning: eth_rtl8169 MAC addresses don't match: Address in ROM is 00:00:00:00:00:30 Address in environment is 52:3b:20:9c:11:51 pci_hose_bus_to_phys: invalid physical address pci_hose_bus_to_phys: invalid physical address pci_hose_bus_to_phys: invalid physical address pci_hose_bus_to_phys: invalid physical address pci_hose_bus_to_phys: invalid physical address pci_hose_bus_to_phys: invalid physical address Using eth_rtl8169 device pci_hose_bus_to_phys: invalid physical address pci_hose_bus_to_phys: invalid physical address pci_hose_bus_to_phys: invalid physical address pci_hose_bus_to_phys: invalid physical address ARP Retry count exceeded; starting again ping failed; host 192.168.1.1 is not alive NSA310>I dont remember, if there was an option during uboot install to customize the MAC, but I skipped it for sure. The device could not tell its MAC when it arrived to me.
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 06, 2024 02:41PM |
Admin Registered: 13 years ago Posts: 18,575 |
Peter,
> I dont remember, if there was an option during
> uboot install to customize the MAC, but I skipped
> it for sure. The device could not tell its MAC
> when it arrived to me.
> Warning: eth_rtl8169 MAC addresses don't match:
> Address in ROM is 00:00:00:00:00:30
> Address in environment is 52:3b:20:9c:11:51
That's OK. The MAC address 52:3b:20:9c:11:51 is randomly generated when none exists. You can look for the MAC address on the label sticker outside the case (bottom or back).
> pci_hose_bus_to_phys: invalid physical address
> pci_hose_bus_to_phys: invalid physical address
> pci_hose_bus_to_phys: invalid physical address
> pci_hose_bus_to_phys: invalid physical address
> pci_hose_bus_to_phys: invalid physical address
> pci_hose_bus_to_phys: invalid physical address
> Using eth_rtl8169 device
> pci_hose_bus_to_phys: invalid physical address
> pci_hose_bus_to_phys: invalid physical address
> pci_hose_bus_to_phys: invalid physical address
> pci_hose_bus_to_phys: invalid physical address
Looks like I've missed some configuration.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> I dont remember, if there was an option during
> uboot install to customize the MAC, but I skipped
> it for sure. The device could not tell its MAC
> when it arrived to me.
> Warning: eth_rtl8169 MAC addresses don't match:
> Address in ROM is 00:00:00:00:00:30
> Address in environment is 52:3b:20:9c:11:51
That's OK. The MAC address 52:3b:20:9c:11:51 is randomly generated when none exists. You can look for the MAC address on the label sticker outside the case (bottom or back).
> pci_hose_bus_to_phys: invalid physical address
> pci_hose_bus_to_phys: invalid physical address
> pci_hose_bus_to_phys: invalid physical address
> pci_hose_bus_to_phys: invalid physical address
> pci_hose_bus_to_phys: invalid physical address
> pci_hose_bus_to_phys: invalid physical address
> Using eth_rtl8169 device
> pci_hose_bus_to_phys: invalid physical address
> pci_hose_bus_to_phys: invalid physical address
> pci_hose_bus_to_phys: invalid physical address
> pci_hose_bus_to_phys: invalid physical address
Looks like I've missed some configuration.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 06, 2024 10:14PM |
Registered: 9 years ago Posts: 50 |
bodhi Wrote:
-------------------------------------------------------
> @sudos,
>
> I agreed with most of what you said. Except for:
>
> > such, transfers requiring encryption (such as
> > SSH/SFTP) are going to eat at the CPU usage,
> > moreso if the speed is slow.
> > I've already come to
> > terms that the most I'll ever get out file
> > transfer-wise is going to be 7-8MB/s maximum on
> > any kirkwood device,
>
> That might be true for other things. But for
> normal file transfers don't use floating point
> arithmetics. Does it?
>
> Also, I have not used BitTorrent for a while so
> not sure, but I don't recall it uses encrypted
> connections. Please correct me if I'm wrong.
>
> For file transfers (NFS) in a local network
> environment, somebody in this forum has
> benchmarked a Kirkwood box and the rate was about
> 80 MBs, IIRC. And that was with an exported file
> on HDD.
For transfers over SFTP or SMB which is what I'm doing, transfers are slow and have a lot of CPU overhead. This is because for SFTP, it's file transfer over SSH. All SSH traffic is encrypted by default (and should never not be in my opinion.)
Was the system using NFS v2 or v3? Those do not have encryption available. v4.x has it available but I believe it has to be enabled with Kerberos v5 auth. Given NFS recently deprecated and removed the ability to use and create NFSv2/v3 compatible shares recently if memory serves, it would be interesting to see this sort of benchmark happen again.
-------------------------------------------------------
> @sudos,
>
> I agreed with most of what you said. Except for:
>
> > such, transfers requiring encryption (such as
> > SSH/SFTP) are going to eat at the CPU usage,
> > moreso if the speed is slow.
> > I've already come to
> > terms that the most I'll ever get out file
> > transfer-wise is going to be 7-8MB/s maximum on
> > any kirkwood device,
>
> That might be true for other things. But for
> normal file transfers don't use floating point
> arithmetics. Does it?
>
> Also, I have not used BitTorrent for a while so
> not sure, but I don't recall it uses encrypted
> connections. Please correct me if I'm wrong.
>
> For file transfers (NFS) in a local network
> environment, somebody in this forum has
> benchmarked a Kirkwood box and the rate was about
> 80 MBs, IIRC. And that was with an exported file
> on HDD.
For transfers over SFTP or SMB which is what I'm doing, transfers are slow and have a lot of CPU overhead. This is because for SFTP, it's file transfer over SSH. All SSH traffic is encrypted by default (and should never not be in my opinion.)
Was the system using NFS v2 or v3? Those do not have encryption available. v4.x has it available but I believe it has to be enabled with Kerberos v5 auth. Given NFS recently deprecated and removed the ability to use and create NFSv2/v3 compatible shares recently if memory serves, it would be interesting to see this sort of benchmark happen again.
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 07, 2024 12:20AM |
Admin Registered: 13 years ago Posts: 18,575 |
Hi sudos,
> For transfers over SFTP or SMB which is what I'm
> doing, transfers are slow and have a lot of CPU
> overhead. This is because for SFTP, it's file
> transfer over SSH.
> All SSH traffic is encrypted by
> default (and should never not be in my opinion.)
Mine too!
> Was the system using NFS v2 or v3?
Yes, it was NFS V3.
> Those do not
> have encryption available. v4.x has it available
> but I believe it has to be enabled with Kerberos
> v5 auth. Given NFS recently deprecated and removed
> the ability to use and create NFSv2/v3 compatible
> shares recently if memory serves, it would be
> interesting to see this sort of benchmark happen
> again.
Indeed! I'll wait till a rainy day and run them on my local network, if nobody has done it.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
> For transfers over SFTP or SMB which is what I'm
> doing, transfers are slow and have a lot of CPU
> overhead. This is because for SFTP, it's file
> transfer over SSH.
> All SSH traffic is encrypted by
> default (and should never not be in my opinion.)
Mine too!
> Was the system using NFS v2 or v3?
Yes, it was NFS V3.
> Those do not
> have encryption available. v4.x has it available
> but I believe it has to be enabled with Kerberos
> v5 auth. Given NFS recently deprecated and removed
> the ability to use and create NFSv2/v3 compatible
> shares recently if memory serves, it would be
> interesting to see this sort of benchmark happen
> again.
Indeed! I'll wait till a rainy day and run them on my local network, if nobody has done it.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 08, 2024 03:06PM |
Admin Registered: 13 years ago Posts: 18,575 |
Hi Peter,
Log in to Debian and
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Log in to Debian and
ethtool enp1s0 lspci -vv
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 09, 2024 02:40AM |
Registered: 5 months ago Posts: 13 |
Hi bodhi,
Here you go:
Here you go:
root@debian:~# ethtool enp1s0 Settings for enp1s0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: Symmetric Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: on master-slave cfg: preferred slave master-slave status: slave Port: Twisted Pair PHYAD: 0 Transceiver: external MDI-X: Unknown Supports Wake-on: pumbg Wake-on: d Link detected: yes
root@debian:~# lspci -vv 00:01.0 PCI bridge: Marvell Technology Group Ltd. 88F6281 [Kirkwood] ARM SoC (rev 03) (prog-if 00 [Normal decode]) Subsystem: Marvell Technology Group Ltd. 88F6281 [Kirkwood] ARM SoC Device tree node: /sys/firmware/devicetree/base/mbus@f1000000/pcie@82000000/pcie@1,0 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 10000-10fff [size=4K] [16-bit] Memory behind bridge: e0000000-e00fffff [size=1M] [32-bit] Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity+ SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [40] Subsystem: Marvell Technology Group Ltd. 88F6281 [Kirkwood] ARM SoC Capabilities: [60] Express (v1) Root Port (Slot+), MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag- RBE+ DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <256ns, L1 unlimited ClockPM- Surprise- LLActRep+ BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 128 bytes, Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1 TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt- SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- Slot #1, PowerLimit 0W; Interlock- NoCompl- SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- Changed: MRL- PresDet- LinkState- RootCap: CRSVisible- RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootSta: PME ReqID 0000, PMEStatus- PMEPending- Capabilities: [100 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 34000000 01000024 00000000 00000000 RootCmd: CERptEn- NFERptEn- FERptEn- RootSta: CERcvd- MultCERcvd- UERcvd- MultUERcvd- FirstFatal- NonFatalMsg- FatalMsg- IntMsg 0 ErrorSrc: ERR_COR: 0000 ERR_FATAL/NONFATAL: 0000 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03) Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 38 Region 0: I/O ports at 10000 [size=256] Region 2: Memory at e0014000 (64-bit, prefetchable) [size=4K] Region 4: Memory at e0010000 (64-bit, prefetchable) [size=16K] Expansion ROM at e0000000 [virtual] [disabled] [size=64K] Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [70] Express (v2) Endpoint, MSI 01 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0W DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 4096 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr+ TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <64us ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1 TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Not Supported, TimeoutDis+ NROPrPrP- LTR- 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- TPHComp- ExtTPHComp- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- 10BitTagReq- OBFF Disabled, AtomicOpsCtl: ReqEn- LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance Preset/De-emphasis: -6dB de-emphasis, 0dB preshoot LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete- EqualizationPhase1- EqualizationPhase2- EqualizationPhase3- LinkEqualizationRequest- Retimer- 2Retimers- CrosslinkRes: unsupported Capabilities: [ac] MSI-X: Enable- Count=4 Masked- Vector table: BAR=4 offset=00000000 PBA: BAR=4 offset=00000800 Capabilities: [cc] Vital Product Data pcilib: sysfs_read_vpd: read failed: No such device Not readable Capabilities: [100 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+ AERCap: First Error Pointer: 00, ECRCGenCap+ ECRCGenEn- ECRCChkCap+ ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 00000000 00000000 00000000 00000000 Capabilities: [140 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb: Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=ff Status: NegoPending- InProgress- Capabilities: [160 v1] Device Serial Number 00-00-00-00-00-00-00-00 Kernel driver in use: r8169 Kernel modules: r8169
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 09, 2024 02:25PM |
Admin Registered: 13 years ago Posts: 18,575 |
Thanks Peter! I'll build a new version.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 09, 2024 04:00PM |
Admin Registered: 13 years ago Posts: 18,575 |
Hi Peter,
Here is the new version. Please take your time, we are in no hurry (hacking should be leisurely done) :)
uboot.2023.04-tld-1.nsa310.kwb_mar_09_2024.tar
Extract the u-boot kwb and run this test.
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 03/09/2024 04:34PM by bodhi.
Here is the new version. Please take your time, we are in no hurry (hacking should be leisurely done) :)
uboot.2023.04-tld-1.nsa310.kwb_mar_09_2024.tar
md5: a2031a32395e5fac0d15c4b9692eeaf0 uboot.2023.04-tld-1.nsa310.kwb_mar_09_2024.tar sha256: f8ba65367176bd1ca487e0473777358a0264fa3b092f60efc5f28710a379b97c uboot.2023.04-tld-1.nsa310.kwb_mar_09_2024.tar
Extract the u-boot kwb and run this test.
Quote
Run kwboot with it, interrupt the u-boot countdown, and
dm tree
pci enum
pci
dm tree
ping <the router IP address>
dm tree
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
Edited 1 time(s). Last edit at 03/09/2024 04:34PM by bodhi.
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 10, 2024 10:58AM |
Registered: 5 months ago Posts: 13 |
I just want to keep the ball rolling, and help, where I can. :)
The outputs:
I have quickly googled the r8168 linux drivers, and see that there were some posts regarding if r8168 is fine with the r8169 drivers, and the results were mixed. Is this really an "unlucky" chip, with bad drivers/support?
The outputs:
root@raspberrypi:/home/pi# kwboot -t -B 115200 /dev/ttyAMA0 -b uboot.2023.04-tld-1.nsa310.kwb -p Sending boot message. Please reboot the target...\ Sending boot image... 0 % [......................................................................] 99 % [....................................] [Type Ctrl-\ + c to quit] U-Boot 2023.04-tld-1 (Mar 09 2024 - 12:45:36 -0800) ZyXEL NSA310 1-Bay Power Media Server SoC: Kirkwood 88F6281_A1 Model: ZyXEL NSA310 DRAM: 256 MiB Core: 15 devices, 12 uclasses, devicetree: separate NAND: 128 MiB Loading Environment from NAND... OK Resetting console stdin/stdout/stderr to serial... In: serial Out: serial Err: serial Net: No ethernet found. Error occured, error code = 64 Hit any key to stop autoboot: 0 NSA310> dm tree Class Index Probed Driver Name ----------------------------------------------------------- root 0 [ + ] root_driver root_driver simple_bus 0 [ ] simple_bus |-- mbus@f1000000 misc 0 [ ] pcie_mvebu_base | `-- pcie@82000000 pci 0 [ ] pcie_mvebu | `-- pcie0.0 simple_bus 1 [ + ] simple_bus |-- ocp@f1000000 gpio 0 [ ] gpio_mvebu | |-- gpio@10100 gpio 1 [ ] gpio_mvebu | |-- gpio@10140 serial 0 [ + ] ns16550_serial | |-- serial@12000 timer 0 [ + ] orion_timer | |-- timer@20300 usb 0 [ ] ehci_mvebu | |-- ehci@50000 rtc 0 [ ] rtc-mv | |-- rtc@10300 ahci 0 [ ] sata_mv_ahci | `-- sata@80000 simple_bus 2 [ ] simple_bus |-- regulators bootstd 0 [ ] bootstd_drv `-- bootstd bootmeth 0 [ ] bootmeth_distro `-- distro NSA310> pci enum pcie0.0: Link up NSA310> pci BusDevFun VendorId DeviceId Device Class Sub-Class _____________________________________________________________ 00.00.00 0x11ab 0x6281 Bridge device 0x04 01.00.00 0x10ec 0x8168 Network controller 0x00 NSA310> dm tree Class Index Probed Driver Name ----------------------------------------------------------- root 0 [ + ] root_driver root_driver simple_bus 0 [ + ] simple_bus |-- mbus@f1000000 misc 0 [ + ] pcie_mvebu_base | `-- pcie@82000000 pci 0 [ + ] pcie_mvebu | `-- pcie0.0 pci 1 [ + ] pci_bridge_drv | `-- pci_0:0.0 ethernet 0 [ ] eth_rtl8169 | `-- eth_rtl8169 bootdev 0 [ ] eth_bootdev | `-- eth_rtl8169.bootdev simple_bus 1 [ + ] simple_bus |-- ocp@f1000000 gpio 0 [ ] gpio_mvebu | |-- gpio@10100 gpio 1 [ ] gpio_mvebu | |-- gpio@10140 serial 0 [ + ] ns16550_serial | |-- serial@12000 timer 0 [ + ] orion_timer | |-- timer@20300 usb 0 [ ] ehci_mvebu | |-- ehci@50000 rtc 0 [ ] rtc-mv | |-- rtc@10300 ahci 0 [ ] sata_mv_ahci | `-- sata@80000 simple_bus 2 [ ] simple_bus |-- regulators bootstd 0 [ ] bootstd_drv `-- bootstd bootmeth 0 [ ] bootmeth_distro `-- distro NSA310> ping 192.168.1.1 Warning: eth_rtl8169 MAC addresses don't match: Address in ROM is 00:00:00:00:00:30 Address in environment is 52:3b:20:9c:11:51 pci_hose_bus_to_phys: invalid physical address pci_hose_bus_to_phys: invalid physical address pci_hose_bus_to_phys: invalid physical address pci_hose_bus_to_phys: invalid physical address pci_hose_bus_to_phys: invalid physical address pci_hose_bus_to_phys: invalid physical address Using eth_rtl8169 device pci_hose_bus_to_phys: invalid physical address pci_hose_bus_to_phys: invalid physical address pci_hose_bus_to_phys: invalid physical address pci_hose_bus_to_phys: invalid physical address ARP Retry count exceeded; starting again ping failed; host 192.168.1.1 is not alive NSA310> dm tree Class Index Probed Driver Name ----------------------------------------------------------- root 0 [ + ] root_driver root_driver simple_bus 0 [ + ] simple_bus |-- mbus@f1000000 misc 0 [ + ] pcie_mvebu_base | `-- pcie@82000000 pci 0 [ + ] pcie_mvebu | `-- pcie0.0 pci 1 [ + ] pci_bridge_drv | `-- pci_0:0.0 ethernet 0 [ + ] eth_rtl8169 | `-- eth_rtl8169 bootdev 0 [ ] eth_bootdev | `-- eth_rtl8169.bootdev simple_bus 1 [ + ] simple_bus |-- ocp@f1000000 gpio 0 [ ] gpio_mvebu | |-- gpio@10100 gpio 1 [ ] gpio_mvebu | |-- gpio@10140 serial 0 [ + ] ns16550_serial | |-- serial@12000 timer 0 [ + ] orion_timer | |-- timer@20300 usb 0 [ ] ehci_mvebu | |-- ehci@50000 rtc 0 [ ] rtc-mv | |-- rtc@10300 ahci 0 [ ] sata_mv_ahci | `-- sata@80000 simple_bus 2 [ ] simple_bus |-- regulators bootstd 0 [ ] bootstd_drv `-- bootstd bootmeth 0 [ ] bootmeth_distro `-- distro NSA310>
I have quickly googled the r8168 linux drivers, and see that there were some posts regarding if r8168 is fine with the r8169 drivers, and the results were mixed. Is this really an "unlucky" chip, with bad drivers/support?
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 10, 2024 07:17PM |
Admin Registered: 13 years ago Posts: 18,575 |
Quote
I have quickly googled the r8168 linux drivers, and see that there were some posts regarding if r8168 is fine with the r8169 drivers, and the results were mixed. Is this really an "unlucky" chip, with bad drivers/support?
It seems so! the Linux driver works fine. But there is something missing in u-boot (could also be I'm missing some thing).
-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)
|
Re: NSA310 + kirkwood 6.5.7 improve net performance March 14, 2024 02:55AM |
Registered: 9 years ago Posts: 50 |
y'know I just had a thought, coming back here to see how this is doing...
do you have non-free-firmware added to your apt sources and firmware-realtek installed?
Last I remember, the kernel-provided gigabit drivers weren't the best and the firmware was needed.
This wasn't really mentioned anywhere that it was installed so I'm just checking beforehand. I saw the failed firmware load messages above and I can only assume that's either from the driver not finding them or the firmware being there and failing to load. in this case I'm assuming the former and not the latter, but maybe it's being up at 4AM.
generally the first few packages I install on a kirkwood box, even though it doesn't need nearly any of it, is firmware-linux-free, firmware-linux-nonfree, and the usual suspects of WiFi manufacturers so I have them already, this includes firmware-realtek, firmware-ralink, and firmware-atheros.
If you don't have it...
pasting this into a blank /etc/apt/sources.list file will get you on the right track.
If you already have this set up, you can ignore this. but I'm sure someone else down the line having a PEBKAC situation will appreciate it.
do you have non-free-firmware added to your apt sources and firmware-realtek installed?
Last I remember, the kernel-provided gigabit drivers weren't the best and the firmware was needed.
This wasn't really mentioned anywhere that it was installed so I'm just checking beforehand. I saw the failed firmware load messages above and I can only assume that's either from the driver not finding them or the firmware being there and failing to load. in this case I'm assuming the former and not the latter, but maybe it's being up at 4AM.
generally the first few packages I install on a kirkwood box, even though it doesn't need nearly any of it, is firmware-linux-free, firmware-linux-nonfree, and the usual suspects of WiFi manufacturers so I have them already, this includes firmware-realtek, firmware-ralink, and firmware-atheros.
If you don't have it...
deb http://debian.csail.mit.edu/debian/ bookworm main contrib non-free non-free-firmware deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware deb http://debian.csail.mit.edu/debian/ bookworm-updates main contrib non-free non-free-firmware deb http://debian.csail.mit.edu/debian/ bookworm-backports main contrib non-free non-free-firmware
pasting this into a blank /etc/apt/sources.list file will get you on the right track.
If you already have this set up, you can ignore this. but I'm sure someone else down the line having a PEBKAC situation will appreciate it.
