merve04

I've tried installing sabnzbd natively on DSM rather than in container, first screen shot would be downloading to volume1, second shot is downloading to volume3 which is a 120GB SSD drive setup as a basic volume, ext4. I also tried NZBget, same results.

Bonjour, je suis a la recherche a pourquoi la vitesse de telechargement est tellment lent. J'utilize sabnzb dans container manager, je force des vitesse de 20MB\s. Ma connexion est 1GB\s fibre optique. Maime ficher et serveur news sure mon client desktop, sa roule at 105~110MB\s. Mon setup est 8x 12TB Exos X16 et 2x 12TB Exos X14 en forme de SHR-2. Jutilize ARC loader DVA1622 et DSM 7.2.1 U4. J'ai aussi un RAID0 compris de 2x 4TB barracuda (CMR). Peut importe quelle volume justilize, sa change pas la vitesse. Jai fait des benchmark pour le volume, puis le vitesse d'ecriture est environ 700MB\s. Quand je transfer des fichier de mon client desktop vers le NAS ou le desktop, sa roule at +100MB\s. Mon client Transmission pour des torrent telecharge plus rapidement que SAB. Quoi d'autre que je peut essayer ou vefifier? Merci.

Hi all, I'm been struggling trying to find out what the cause of this issue is. I have Sabnzbd installed in container manager, no resource limits, but my transfer speeds are horrendous. I have a 10x12TB SHR-2 built with Exos X14 and 16's. I also have a small 2x4TB Raid0. It doesnt matter which volume I point Sab to download too, marginal speed difference between the two. I've tried running a sudo dd bs=1M count=256 if=/dev/zero of=/volumeX/share/testx conv=fdatasync and I'm pulling 1.1~1.2Gbps. What else should I be on the look out for?

Outcome of the update: SUCCESSFUL - DSM version prior to update: DSM 7.2.1-69057-U3 - DSM version after update: DSM 7.2.1 69057-U4 - Loader version and model prior to update: ARC 23.10.2 (DVA1622) - Loader version and model after update: ARC 24.3.17 (DVA1622) - Using custom extra.lzma: NO - Installation type: BAREMETAL - Gigabyte B365-DS3H, i5-8400, 10x12TB, 2x4TB - Additional comments: Reboot to update loader then update DSM via GUI, final reboot required.

- Outcome of the update: SUCCESSFUL - DSM version prior to update: DSM 7.2.1-69057-U1 - DSM version after update: DSM 7.2.1 69057-U3 - Loader version and model prior to update: ARC 23.10.2 (DVA1622) - Loader version and model after update: ARC 23.10.2 (DVA1622) - Using custom extra.lzma: NO - Installation type: BAREMETAL - Gigabyte B365-DS3H, i5-8400, 8x12TB, 2x4TB - Additional comments: Updated via DSM GUI, reboot required.

- Outcome of the update: SUCCESSFUL - DSM version prior to update: DSM 7.2.1-69057 - DSM version after update: DSM 7.2.1 69057-U1 - Loader version and model prior to update: ARC 23.10.2 (DVA1622) - Loader version and model after update: ARC 23.10.2 (DVA1622) - Using custom extra.lzma: NO - Installation type: BAREMETAL - Gigabyte B365-DS3H, i5-8400, 8x12TB, 2x4TB - Additional comments: Updated via DSM GUI, reboot required.

- Outcome of the update: SUCCESSFUL - DSM version prior to update: DSM 7.2-64570 U3 - Loader version and model prior to update: Peter Suh's TCRP v0.9.4.3-2 w\Friend 0.0.8 (DVA1622) - Loader version and model after update: ARC 23.10.2 (DVA1622) - Using custom extra.lzma: NO - Installation type: BAREMETAL - Gigabyte B365-DS3H, i5-8400, 8x12TB, 2x4TB - Additional comments: Updated via DSM GUI, rebooted, login to TCRP, let it auto update, initiate 7.2.1 loader build, no go. Rebuild USB with latest Peter Suh's v0.9.5.0 w\Friend 0.0.9 (DVA1622), no go, rebuild loader several times, different USBs, never would complete building loader, always failed on backup. Rebuild loader with latest ARC, booted back in DSM sucessfully.

- Outcome of the update: SUCCESSFUL - DSM version prior to update: DSM 7.2-64570 U2 - Loader version and model prior to update: TCRP v0.9.4.3-2 w\Friend 0.0.8 (DVA1622) - Loader version and model after update: TCRP v0.9.4.3-2 w\Friend 0.0.8 (DVA1622) - Using custom extra.lzma: NO - Installation type: BAREMETAL - Gigabyte B365-DS3H, i5-8400, 8x12TB, 2x4TB - Additional comments: Updated via DSM GUI, no reboot required, DSM operating normally.

- Outcome of the update: SUCCESSFUL - DSM version prior to update: DSM 7.2-64570 U1 - Loader version and model prior to update: TCRP v0.9.4.3-2 w\Friend 0.0.8 (DVA1622) - Loader version and model after update: TCRP v0.9.4.3-2 w\Friend 0.0.8 (DVA1622) - Using custom extra.lzma: NO - Installation type: BAREMETAL - Gigabyte B365-DS3H, i5-8400, 8x12TB, 2x4TB - Additional comments: Updated via DSM GUI, rebooted back to DSM normally.

Pretty sure all these loaders have been written to support 16 drives. DVA1622 natively only has 2 drives, I’m currently running 10.

So prior to DVA1622 being made available, I found out about DVA3221 which supported 8 cameras. I was using DS918+ running a VM within DSM as each instance provided 2 licenses for cameras, but this started getting heavy running DSM and 2 VM's. I tried DVA3221 which was awesome but due to the lack of discreate video card, I could no longer support HW transcoding for plex. When DVA1622 came around, I jumped on it and its been great ever since. The one things I've mentioned a few times around is ever since I moved on from using DS918+, my download speeds have suffered, to the tune of nearly 30MB\s. I suspect a network driver issue. I've tried several loaders, but always the same result. If I rebuild with DS918+ image, I get full 95-105MB\s. I believe the NIC is realtek 8118. I've thought about buying a NIC and put it in a PCIe slot, just never bothered.

I run a Gigabyte B365-DS3H with an i5-8400. I’ve the years I’ve tried DS3622, DS918+, DS920+, DVA3221, and currently been using DVA1622. The reason I settled on 1622 is for the ability to support HW transcode with Plex utilizing intel quickset, this is only supported on 918/920/1622. H.265 is decoded perfectly fine with using nearly no CPU resources. Second reason is I have 5 cameras and surveillance station with the DVA series includes 8 licenses natively. I don’t use video station or photos, therefore I have no desire to try and activate HVEC encoding/decoding for those packages.

- Outcome of the update: SUCCESSFUL - DSM version prior to update: DSM 7.2-64570 - Loader version and model prior to update: TCRP v0.9.4.3-2 w\Friend 0.0.8 (DVA1622) - Loader version and model after update: TCRP v0.9.4.3-2 w\Friend 0.0.8 (DVA1622) - Using custom extra.lzma: NO - Installation type: BAREMETAL - Gigabyte B365-DS3H, i5-8400, 8x12TB, 2x4TB - Additional comments: Updated via DSM GUI, rebooted back to DSM normally.

- Outcome of the update: SUCCESSFUL - DSM version prior to update: DSM 7.1.1-42962 Update 5 - Loader version and model prior to update: TCRP v0.9.4.3-2 w\Friend 0.0.6 (DVA1622) - Loader version and model after update: TCRP v0.9.4.3-2 w\Friend 0.0.8 (DVA1622) - Using custom extra.lzma: NO - Installation type: BAREMETAL - Gigabyte B365-DS3H, i5-8400, 8x12TB, 2x4TB - Additional comments: Updated via DSM GUI, rebooted, Synology Assistant reported "not installed". I suspect its because TCRP w\Friend reports NO IP during boot and cant perform the upgrade. Booted in TCRP and let it update to latest version, looks like it brought me up to 0.0.8, and let it reboot again, back in DSM now. *It seems odd that the loader builder screen has no problems obtaining an IP but when it boots, no IP . Is this a driver issue?

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 7.1.1-42962 Update 5 - Loader version and model: TCRP v0.9.4.3-2 w\Friend 0.0.6 (DVA1622) - Using custom extra.lzma: NO - Installation type: BAREMETAL - Gigabyte B365-DS3H, i5-8400, 8x12TB, 2x4TB - Additional comments: Updated via DSM GUI, rebooted, Synology Assistant reported "not installed". I suspect its because TCRP w\Friend reports NO IP during boot and cant perform the upgrade. Booted in TCRP and let it update to latest version, looks like it brought me up to 0.0.8, and let it reboot again, back in DSM now. *It seems odd that the loader builder screen has no problems obtaining an IP but when it boots, no IP . Is this a driver issue?

This has been a problem for quite some time, when I used to use 918+ loader my usenet downloaded would peak near or hit 100MB\s, but with DVA1622 I seem to hit mid 60's. Here's the same nzb file with same server setup on my mac vs in xpenology. Any thoughts? I suspect its a network driver issue, as this also follow file transfer speed. I highly doubt 8x Exos X16 is SHR-2 is a bottleneck in speed. I've also tried running DVA1622 on a different machine but its a different NIC and I get full transfer speeds. This is on a Gigabyte B365M-DS3H (RTL8118) vs Asus B85M-g (RTL8111G)

I'm already using your fork of TCRP and wondering if theres a quick way to update the loader or do I need to download latest and recreate usb?

That fixed it, I guess your build supports CPU scaling. Thanks for your support.

Likely your SN has ****SJR******* You need one that has ****UBR****** I built a key using latest TCRP and wrote down the generated SN from it and imputed in my choice of loader.

- Outcome of the update: SUCCESSFUL - DSM version prior update: DSM 7.1.1-42962 Update 4 - Loader version and model: TCRP v0.9.4.3-2 w\Friend 0.0.6 (DVA1622) - Using custom extra.lzma: NO - Installation type: BAREMETAL - Gigabyte B365-DS3H, i5-8400, 8x12TB, 2x4TB - Additional comments: Updated via DSM GUI

For sure its a possibility, I'd imagine at POST, such warning would be presented. The reason I bring this up as I'm using @Peter Suhloader, prior I was using TCRP 0.9.0.2 i think??

No idea, will need to look, havent touched bios settings for years and this is a first I see it running at this speed, was always 2800 before.

Is there a reason why my cpu is running at 800mhz?

Is your version compatible to upgrade to 42962-U5?

Well I used pocopico's tcrp to generate a UBR serial# and inputed it in your build, happy it booted in DSM but just like last time in July '22, it wiped all my personal settings without prompting me if I wanted or not. Its frustrating but i guess the important thing is my data is intact. Thanks for the support.