r2u access slow from New Zealand
kendonB opened this issue · comments
Hi Dirk,
Hope all is well - I recently upgraded a machine to 22.04 and successfully installed a large number of packages very quickly. A huge improvement over the previous system.
However the last couple of days I've noticed it has been quite slow. I'm currently switching over another machine to r2u and it's crawling:
Many thanks for a great system!
What time of day was that? I had to reboot the machine briefly -- it is also my desktop / server and the NVidia modules where out of sync so OpenGL apps no longer work. It should be fine otherwise.
Here is a quick demo right now from an AWS instance fetching just four packages (and an index update, of course):
root@aws:~# time install.r quantmod
Install system packages as root...
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Ign https://dirk.eddelbuettel.com/cranapt jammy InRelease
Hit https://dirk.eddelbuettel.com/cranapt jammy Release
Hit http://archive.ubuntu.com/ubuntu jammy InRelease
Hit http://security.ubuntu.com/ubuntu jammy-security InRelease
Hit http://archive.ubuntu.com/ubuntu jammy-updates InRelease
Hit http://archive.ubuntu.com/ubuntu jammy-backports InRelease
Hit https://ppa.launchpadcontent.net/marutter/rrutter4.0/ubuntu jammy InRelease
Fetched 0 B in 0s (0 B/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Get:1 https://dirk.eddelbuettel.com/cranapt jammy/main amd64 r-cran-curl amd64 4.3.2-1.ca2204.1 [446 kB]
Get:2 https://dirk.eddelbuettel.com/cranapt jammy/main amd64 r-cran-zoo amd64 1.8-10-1.ca2204.1 [1007 kB]
Get:3 https://dirk.eddelbuettel.com/cranapt jammy/main amd64 r-cran-xts amd64 0.12.1-1.ca2204.1 [853 kB]
Get:4 https://dirk.eddelbuettel.com/cranapt jammy/main amd64 r-cran-ttr amd64 0.24.3-1.ca2204.1 [503 kB]
Get:5 https://dirk.eddelbuettel.com/cranapt jammy/main all r-cran-quantmod all 0.4.20-1.ca2204.1 [1010 kB]
Fetched 3818 kB in 0s (0 B/s)
Selecting previously unselected package r-cran-curl.
(Reading database ... 21766 files and directories currently installed.)
Preparing to unpack .../r-cran-curl_4.3.2-1.ca2204.1_amd64.deb ...
Unpacking r-cran-curl (4.3.2-1.ca2204.1) ...
Selecting previously unselected package r-cran-zoo.
Preparing to unpack .../r-cran-zoo_1.8-10-1.ca2204.1_amd64.deb ...
Unpacking r-cran-zoo (1.8-10-1.ca2204.1) ...
Selecting previously unselected package r-cran-xts.
Preparing to unpack .../r-cran-xts_0.12.1-1.ca2204.1_amd64.deb ...
Unpacking r-cran-xts (0.12.1-1.ca2204.1) ...
Selecting previously unselected package r-cran-ttr.
Preparing to unpack .../r-cran-ttr_0.24.3-1.ca2204.1_amd64.deb ...
Unpacking r-cran-ttr (0.24.3-1.ca2204.1) ...
Selecting previously unselected package r-cran-quantmod.
Preparing to unpack .../r-cran-quantmod_0.4.20-1.ca2204.1_all.deb ...
Unpacking r-cran-quantmod (0.4.20-1.ca2204.1) ...
Setting up r-cran-curl (4.3.2-1.ca2204.1) ...
Setting up r-cran-zoo (1.8-10-1.ca2204.1) ...
Setting up r-cran-xts (0.12.1-1.ca2204.1) ...
Setting up r-cran-ttr (0.24.3-1.ca2204.1) ...
Setting up r-cran-quantmod (0.4.20-1.ca2204.1) ...
real 0m4.854s
user 0m3.606s
sys 0m0.540s
root@aws:~# All that said ... you are of course 'further away' so many things could drive that. I am at the end of standard retail fiber cable -- amazing compared to what was / is common but clearly not 'internet2'. And I currently offer only one path so it is possible for it get clogged.
I will try to find some time to maybe see if a caching solution can help, but I cannot make promises that it will happen or when.
This was just a few minutes before I submitted the issue - not sure of the time of day yesterday. It remains slow now.
The location aspect may account for it. I'm at the end of a retail fiber cable as well with no ISP limits - I get ~500Mbps down from local servers and I just got 80 Mbps down from a Chicago server on speedtest.net. Is it feasible to use the ubuntu archive mirrors?
I was travelling in Washington, DC when I got the very fast update.
Well you should have said you compared access between DC and NZ :) That explains a lot. And duly noted that it is slow to too slow from your neck of the woods.
We currently only occupy about 40gb, or nothing. I would appreciate it if you found a mirror in the Asia-Pacific region. I may not have time to look for one, nor do I have much contacts. We will have to keep this ticket open as a reminder.
University of Auckland Stats hosts a CRAN mirror I believe so they may agree to hosting an r2u mirror. I will also try to get a colleague to confirm it's also slow for them.
Launchpad may agree to giving you more space on a PPA? It says here https://help.launchpad.net/Packaging/PPA that you can request it here: https://answers.launchpad.net/soyuz
It does not use Launchpad.
It does not use Launchpad.
but could it I mean
I'm also assuming that by using launchpad you automatically get a bunch of mirrors but that may be a false assumption
Michael's cran2deb is on launchpad. My r2u is not using launchpad, and will not be using launchpad. That is documented.
Is there another mirror network you're aware of that would be feasible to distribute on?
"Maybe" -- that is what I had in mind in the comment above where I also noted that I may not have time to work on it.
If you wanted to step forward and experiment so that you could help, it would probably be a big step forward. I do have a few DNS domain or two that could be use for this.
I think simpler to revert back to c2d4u - other than coverage, are there other advantages of r2u over c2d4u? If I understand correctly, the remaining key features are also features of c2d4u?
c2d4u is a great service which we all used or still use, and it may have better connectivity at your end. While r2u has three times the coverage that may not be the most important factor to you. It's good to have a choice.
it is fast now fyi - may have just been a bit of congestion somewhere in the pipes
@eddelbuettel the pipes are slow again for me - back at the extremely low numbers I was seeing before. You may want to test again from aws to see if it is indeed the international connection causing the issue.
fast again now
@kendonB : Possibly good news for you -- we now have a mirror site we announced 'officially' in a talk yesterday and I updated the docs. Replace the existing apt sources entry with one for https://r2u.stat.illinois.edu/ubuntu followed by either focal or jammy as before. Should be very fast and solid as it is on the well-connected academic backbone.