DietPi version | cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=8
G_DIETPI_VERSION_SUB=22
G_DIETPI_VERSION_RC=3
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’
Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
Bookworm
Kernel version | uname -a
Linux AsusTinkerBoard 6.1.50-current-rockchip #1 SMP PREEMPT Wed Aug 30 14:11:13 UTC 2023 armv7l GNU/Linux
Architecture | dpkg --print-architecture
armhf
SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
ASUS Tinker Board (armv7l)
Power supply used | (EG: 5V 1A RAVpower)
microusb 5v 2.5a
SD card used | (EG: SanDisk ultra)
SanDisk ultra
Additional Information (if applicable)
Software title | Samba
Was the software title installed freshly or updated/migrated? Freshly
Can this issue be replicated on a fresh installation of DietPi? Yes
← If you sent a “dietpi-bugreport”, please paste the ID here →
Bug report ID | echo $G_HW_UUID
Steps to reproduce
Connect to a samba share and try copying a file “huge file” video to my PC or mobile.
…
Expected behaviour
Files should transfer normaly without losing connection.
Actual behaviour
It start to transfer at high speed and after few seconds it drops to 0 and lost connection.
Extra details
I was able to have a stable connection but slow if I set my ethernet negotiate speed to 100 mbps. If I set ethernet negotiate speed to AUTO, I have this issues.
Does the drive you are reading/writing too work thru a USB hub on the board itself? Sometimes the USB hub is overheating after heavy reads/writes and cause slowdowns…
Which version of the tinkerboard??
Have you run a hdparm -tT /dev/sdX to see actual thruput?
Have you run a iperf test to see if the network, or the card is the bottleneck?
I will try to mount on my raspberry the tinker board share see if it happen. I have mount a raspberry share on the tinker board and I was able to transfer without problem ( using the raspberry share on the tinker board to the usb hdd)
same problem with my raspberry. It crash when the tinker board is “uploading” a file via samba.
smartctl -a /dev/sda1
smartctl 7.3 2022-02-28 r5338 [armv7l-linux-6.1.50-current-rockchip] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Vendor: Samsung
Product: STORY Station
Revision: 1302
Compliance: SPC-4
User Capacity: 500,107,862,016 bytes [500 GB]
Logical block size: 512 bytes
Physical block size: 4096 bytes
LU is fully provisioned
Logical Unit id: 0x3057962792111719
Serial number: E7962G921A17J9
Device type: disk
Local Time is: Tue Oct 3 16:53:39 2023 EDT
SMART support is: Unavailable - device lacks SMART capability.
=== START OF READ SMART DATA SECTION ===
Current Drive Temperature: 0 C
Drive Trip Temperature: 0 C
Error Counter logging not supported
Device does not support Self Test logging
I tried forcing negotiate speed to 100. It works but initial speed transfer is 2 MB/s and go down to 0 and go back to initial speed 2 MB/s and go down again but connection is not lost and keep going.
Forcing ethernet speed 1000, it won’t connect.
Auto negotiate : Files transfer is fast but go down to 0 and freeze.
Via WIFI it’s stable too but a little bit slower than ethernet 100.
Did you upgrade the kernel to latest version in Armbian as well?
uname -a
Since we use the same kernel package and Samba userspace tools, I can hardly imagine how they can behave any different, as long as the /etc/samba/smb.conf is the same.
One thing, can you check SMP affinities:
cat /proc/interrupts
And a little unrelated question. Can you please check this on the ASUS Tinker Board?
grep CONFIG_RD_ZSTD /boot/config-*
It is about whether we can ZSTD-compress the initramfs on this board/with this kernel. I am sure we can, but was never able to verify.
Okay, does it help to only move Ethernet interrupts to another CPU?
echo 8 > "/proc/irq/$(mawk '/eth0/{print $1;exit}' /proc/interrupts | sed 's/://')/smp_affinity"
The dev version of the installer should have the base-files issue solved. There were two conflicting workarounds inside, an older and a recent one, which did not work well together.
Ah really? That is strange. The “ondemand” governor switches CPU clocks mostly from lowest to highest and back to lowest in a single step based on a given threshold. Our default “schedutil” aims to be the modern successor for “ondemand”, is directly tied to the CPU scheduling driver and does faster but smaller more fine grained frequency steps, i.e. uses all frequencies below lowest and highest as well, depending on CPU usage and other means given by the scheduling driver. Overall it is hence more efficient and should not reduce performance. But probably the scheduling driver does not work well with this governor on the ASUS Tinker Board for some reason .
.