Altaram
-
Posts
14 -
Joined
-
Last visited
Posts posted by Altaram
-
-
11 minutes ago, wjz304 said:
What about third-party software sources?
They don't work either, same error.
-
1
-
-
5 minutes ago, Orphée said:
@wjz304 Actually, I was curious so I tried DS423+ loader myself :
Same issue on my proxmox setup.
DS423plus synoscgi_SYNO.Core.Package.Server_2_list[15865]: SYNOPKGMGR: https://pkgupdate7.synology.com/packagecenter/v3/getList, Failed to request packages, httpResponseCode=504 DS423plus synoscgi_SYNO.Core.Package.Server_2_list[15731]: SYNOPKGMGR: https://pkgupdate7.synology.com/packagecenter/v3/getList, Failed to request packages, httpResponseCode=504 DS423plus synoscgi_SYNO.Core.Package.Server_2_list[15731]: list_onserver.cpp:270 Failed to load package list, syno=[1], lang=[fre] DS423plus synoscgi_SYNO.Core.Package.Server_2_list[15865]: list_onserver.cpp:270 Failed to load package list, syno=[0], lang=[fre]Well, it seems that we have found some common problem. The curious thing about this is what happens with the 3 loaders most used by the community.
Could it have been Synology deliberately blocking access?
If someone has a Synology, could they confirm if it works for them? -
18 minutes ago, wjz304 said:
Please on your PC
ping update7.synology.com
ping pkgupdate7.synology.com
Ping statistics for 18.154.48.24:
Packets: Sent = 4, Received = 4, Lost = 0
(0% lost),
Approximate round-trip times in milliseconds:
Minimum = 6ms, Maximum = 6ms, Average = 6msIt's not a communications problem, it's a problem with the new loaders, and there are several of us who have commented on it. What I don't know is if the authors have deliberately blocked access or it's a bug.
I understand that blocking automatic DSM updates is convenient, but blocking the application download center does not make much sense and forces you to install it manually.
-
On 7/28/2023 at 11:41 AM, Joe999 said:
I've updated my HP ProLiant Gen8 with APRL-i18n to DSM 7.2. Everything works wonderfully except the internet access through the package center and the update window:
Any ideas?
Same problem here.
Changing the DNS does not fix the problem. It seems that they have deliberately blocked access. I have the same problem since I updated to 7.2 and it happens to me with the latest versions of APRL-i18n, TCRP and ARC Loader.
With TCRP v0.9.4.0 and 7.1 I didn't have this problem, although the updates were already blocked.
-
On 3/22/2023 at 8:18 PM, apriliars3 said:
Rufus es para iso, en este caso siempre es mejor Win32 Disk Imager o lo que suelo usar Balena Etcher.
No tienes otro pendrive para descartar el problema? Por cierto, usa SD Card Formatter antes de grabar el pendrive, o sino elimina todos los volumenes con el administrador de discos antes de quemar con tu programa favorito.
Para el DS3622xs+ automatico, sin preocuparte de poner el pid/vid y compilar use este cargador basado en arpl
¿Ese cargador es seguro? Estoy leyendo que es un proyecto paralelo a ARPL, con mods que se escapan un poco de la legalidad.
-
12 hours ago, vbap said:
Thanks for the info.
I decided to run tests on my 2 systems (running old ARPL):
- HP Microserver Gen8, Intel Xeon E3-1265L v2, ARPL v0.4alpha4. Geekbench score is above average for the CPU, so good on this one - https://browser.geekbench.com/v5/cpu/19568279
- Supermicro MiniServer X10SDV-TLN4F, Intel Xeon D-1541, ARPL v0.4alpha6. Geekbench score is about 25% of the average, so really bad (and this is my main server that runs windows VMs - and it feels really slow). https://browser.geekbench.com/v5/cpu/19568321
I'm now going to try latest ARPL on the Supermicro and see what happens.
There is definitely a huge inconsistency with different hardware versions using ARPL. The results you get with your server with the Xeon D-1541 are very bad while the ones you get with the G8 are in adequate performance.
Try with another version of ARPL (I did all my tests with the latest one) and with TinyCore.
-
News with my build. I have upgraded the CPU to an Intel Xeon E3-1265L v3.
The results with ARPL DS3622xs+ were very bad, as with the previous CPU.
I switched to ARPL DS3617xs and couldn't even get access via IP.
I switched to the DS3615xs and the results were about 40% better, but still far from where I should be.
Finally I did a migration with TCRP 0.9 DS920+ and magic happened. The result is perfect, even better than expected.
https://browser.geekbench.com/v5/cpu/19560150
The next test seems obvious, try ARPL DS920+ and compare. Well, that's what I did and, surprise, again we weighed in on the results.
The conclusion in my case seems clear, ARPL has some kind of performance problem in some of its builds with certain hardware.
I think it should be revised for future updates because this performance difference is very noticeable. With TCRP I notice the system much more agile, as it should be with the hardware I have.
-
1
-
-
4 hours ago, Rick4 said:
Read my post before try migrate to other images. #1489
I don't quite understand what you're doing.
You go around various configurations, getting disparate results on all of them, and finally you go back to the first one and get a totally different result. I can't find the pattern anywhere. It's all very confusing.
-
4 hours ago, idaanx said:
You can read my first post about this, I've tested on ARPL, TCRP and Jun.
I've done a lot of tests and some research this week, and if got a pretty good idea what the issue is. Need a bit more data and I'll post my findings later.
Your contribution is very interesting. Waiting for your conclusions.
I will test with a Xeon E3 1265L V3 (35W) and an E3 1220-V3 (80W) and I will post the results. If these are not correct, I will try to migrate to 3617xs, which is the equivalent of my platform.
-
1
-
-
On 12/19/2022 at 5:00 PM, Rick4 said:
That benchark is terrible low, i think, you must try it with newer hardware. Thas uses old chipsets, low speed DDR rams, and the cpu wit T on end always significant slower than original. Do not but a T ended CPU.
It's not a CPU problem, the original Synology mount CPUs much less powerful than that. I think there must be some incompatibility problem with the hardware/software that causes a noticeable loss of performance.
To rule out the CPU in a few days I will build a Xeon 1256L V3 that I have at home.
Has anyone tried to perform these tests with TinyCore Redpill Loader to rule out that it is a loader problem?
-
1 hour ago, Rick4 said:
Later i wrote, bios settings and VT-d doesn't affected geekbench points, i get same result, but that triple point benchmark az j4105 motherboard will be enough to keep that hardware.
I get the following score with the latest version of ARPL 920+. I run the test with docker:
https://browser.geekbench.com/v5/cpu/19373659
They seem like very low figures to me, you should get something similar to this:
https://browser.geekbench.com/processors/intel-core-i5-4570t
Any suggestions?
-
Good morning everyone. First of all congratulate Trauma for creating the script.
I have a problem and I am not able to install / run it. I am quite noob in the use of DSM and I do not know if it is possible that a simple guide could be made explaining its installation step by step.
Thank you. -
- Outcome of the installation/update: SUCCESSFUL
- DSM version prior update: DSM 6.2-23739 Update 2
- Loader version and model: JUN'S LOADER v1.03b - DS3615xs
- Using custom extra.lzma: NO
- Installation type: BAREMETAL - Gigabyte ga-h97n-wifi
- Additional comments: On-board NIC Atheros no longer works after this update. On-board NIC Intel works OK.
Automated RedPill Loader (ARPL)
in Loaders
Posted
For no apparent reason the Application Package works correctly again.