search

bb-qq / r8152

Synology DSM driver for Realtek RTL8152/RTL8153/RTL8156 based adapters
GNU General Public License v2.0
2.07k stars 184 forks source link

Not armadaxp package anymore? #143

Closed dreimer1986 closed 2 years ago

dreimer1986 commented 3 years ago

Description of the problem

I skip a bunch of the template, just wanted to ask if there is a special reason for not having a armadaxp package anymore.

Description of your products

  • the product name of your NAS model
    • and output of uname -a command
    • DSM version x.x
  • the product name of the ethernet dongle

DS414

bb-qq commented 3 years ago

I uploaded 2.15.0-4 release which includes the armadaxp support. I would appreciate it if you report whether it works and its stability.

dreimer1986 commented 3 years ago

No big test yet from my side as I still look for a nice way to backup my BIG DS420+ to my two old DS414 split evenly, but some things I already can confirm: Installation on both worked as expected with SSH console command added after first failed installation. Both NAS are connected by 2.5 GBit now and both can copy and can be copied files to. I copied a few bigger files on both of them and both are fine. Of course you can't expect any wonders from these old chipsets, so I am @ about 133 MB/s when it's in good mood. Still the reaction times feel a lot better, even though you only get about 10-15% speed increase. (My new NAS now does >>200 MB/s with your drivers!) Longer stability test will follow with a nice backup solution. Until then.... YES, you can use that build ^^ Thx for making it!

bb-qq commented 2 years ago

Thank you for your report. I close this issue.

dreimer1986 commented 2 years ago

Sorry, this took a while... Time for a REAL report. I successfully sent a rsync job from my DS420+ (geminilake driver from you used ^^) to one of my DS414 (armadaxp used) Both 2.15.0-6. No problems at all. To be fair. There was a completely outdated copy of the files on the target and I used the "start the rsync, wait a bit, stop and then move all files to the new folder before starting again" trick to minimize the load, but still it had to transfer about 1.9 TB of data. All was fine. Speed wise rsync is a problem of course as it seems to be a CPU hog, And the DS414 is a better calculator with muuuch save space, but the transfer with about 65 MB/s was constant and flawless. It took about 9.5 hours with all the rsync calculating in bckground. I still am thinking about the Jumbo Frame speedup way here, but my problem is that all needs to be set to the same size in my network and it seems like the sizes Synology allows are not what I can select in Windows too. If someone stumbles upon a good howto here, tell me please...

iiaiiappa commented 2 years ago

Were you guys able to use latest r8152 2.5g driver on DS414 (armada xp), latest version of DSM 7.0.1 ? As I found out the two usb ports at the back is recognized as USB 2.0 instead of 3.0 (checked with lsusb). I have plugged in a ugreen 2.5gb adapter and lsusb does not detect the adapter. I had a successful case with the same adapter, on latest DSM 7.0.1 on apollolake DS918.

My home network is on 2.5gbe LAN switches so I know which device is on 2.5gbe.

bb-qq commented 2 years ago

If someone stumbles upon a good howto here, tell me please...

It is often confusing because Linux and Windows use different terms for MTU length. (MTU 9014@Windows = 9000@Linux) This is due to the different handling of Ethernet headers.

However, TCP has a function to adjust the MTU size, so it is unlikely to be a problem even if different MTUs are actually mixed.

bb-qq commented 2 years ago

I have plugged in a ugreen 2.5gb adapter and lsusb does not detect the adapter.

This phenomenon indicates a problem with device operation at the hardware layer. Please check the USB cable connection or try to use a self-powered USB adapter with a power supply. If that doesn't seem to solve your problem, create a new issue.

dreimer1986 commented 2 years ago

Well, my speed is above the limits of USB 2.0, so I think I am fine here. Here the limit was the rsync tormented CPU. it always ran above 90%. It is the most recent driver here on the most recent OS from Synology, yes.

"However, TCP has a function to adjust the MTU size, so it is unlikely to be a problem even if different MTUs are actually mixed." Sure, but wouldn't this cause a speed decrease again?

bb-qq commented 2 years ago

Sure, but wouldn't this cause a speed decrease again?

Yes, large packets are split according to the result of negotiation by MSS at the TCP layer. This process will slow down the speed, but there is only a difference in the behavior between splitting at the application layer and at the IP layer, so there should be no further slowdown from the case without Jumbo frames.

This means that, in theory, we can expect to benefit from increased throughput and a slight reduction in CPU processing costs when communicating between hosts with Jumbo frames enabled, and almost no disadvantages when they are not.

Sjekke commented 2 years ago

Jumbo Frames have little added value in a home environment. I would not use it.