When I said "the above paragraph" I meant the previous two sentences in the paragraph. My mistake.

Try downloading another copy of Firefox and run it from the folder. Do not sign into your Firefox account and see if you have the same issue.

https://www.mozilla.org/en-US/firefox/all/#product-desktop-release

Provide the steps to replicate your issue and screenshots. What do you get in other browsers and how are you testing your speed? Are you on WiFi or are you plugged in? What speed internet service are you paying for? Who is your DNS provider? Where are you? Here are my speed test in New Jersey via Google and Speedtest.net. There are so many possibilities...

Try downloading another copy of Firefox and run it from the folder. Do not sign into your Firefox account and see if you have the same issue. https://www.mozilla.org/en-US/firefox/all/#product-desktop-release Provide the steps to replicate your issue and screenshots. What do you get in other browsers and how are you testing your speed? Are you on WiFi or are you plugged in? What speed internet service are you paying for? Who is your DNS provider? Where are you? Here are my speed test in New Jersey via Google and Speedtest.net. There are so many possibilities...

Some new info: -Increasing the thread count in multithreaded download manager and increasing max server threads in about:config managed to increase my download speed to 750KB/s. I was not able to increase the thread count of the download manager any higher than 12 without it not working. -While writing this, I tried downloading the file which led me to posting this question to begin with and the download speed reached ~50MB/s. Literally moments earlier it was the ~200KB/s speed which made me post this question. I did not change anything nor restart my computer nor restart Firefox nor did I have some downloads going on in the background or someone else on my network hogging the download speed. -Based on the above, and I apologize for not mentioning this in my original question (my memory did not serve me well), it seems clear that this is a problem that seems to come and go at random. I tried downloading something else from a website that I remember having this same problem with before and the problem appeared yet again (with even worse speeds this time). -My best guess for this occurring is that the file that was downloading at 50MB/s in-browser began doing so almost exactly as the download manager finished downloading the same file as well (it had been doing so for the entire night at this point), which would not solve my problem at all, but I felt it was worth mentioning just to be safe.

The exact steps I took when using a new download of Firefox: -I downloaded "firefox-94.0.2.tar.bz2" from the Mozilla website. -On the command prompt, I ran "cd ~/Downloads" and then "tar -xvf ~/Downloads/firefox-94.0.2.tar.bz2". -I then opened Firefox directly from the executable in the folder that was created from tar -xvf. -I did not log into my account. -I copy-pasted the download link for the file I was attempting to download last night (the one which just had 50MB/s download speeds) and the problem appeared yet again. -I then attempted to download the same file for a second time on my original copy of Firefox (not on the copy I just downloaded) and the download was, again, at 200KB/s. It would seem my guess from the above section is wrong, then, but I cannot think of any reason why it would randomly have this problem at one moment and not have it at another (To reiterate: I have never had this problem with Steam, as an example).

To answer your questions: -There's nothing in particular that I'm doing that replicates the issue, any download of any large file from any website I have tried to download it from and of any kind of file will cause this problem -I'm using speedtest.net to test my speeds. The speeds I am getting are consistent with my internet plan and my Ubuntu settings (the latter of which lists my wired connection as 100Mbps). Attempting the same download on Google had the same download speed as it did on Firefox without the download manager. -I am using a wired connection. I'm connected to a hub with 4 ethernet cables (one for my printer, one for my PC, one for the TV box in the other room, and one that is connected to the modem downstairs). -I'm with Rogers and the plan for the house is the most expensive internet plan that they offer. I'm not sure the specifics, but I know that the plan offers download speeds of at least 75MB/s. -"systemd-resolve --status", which I found from the AskUbuntu forums, lists my DNS domain as phub.net.cable.rogers.com -I'm located in the Greater Toronto Area in Southern Ontario, Canada

Thank you for your time. Please let me know if you need additional information.

I suggest you test 1.1.1.1 or 8.8.8.8 to see if it improves your performance. Also, check out this tool to compare DNS providers. https://www.grc.com/dns/benchmark.htm I use it Windows, but the site states that it will work with Wine in Linux. I'll have try it myself. What do you get when you traceroute to your dns? see screenshot

I suggest you test 1.1.1.1 or 8.8.8.8 to see if it improves your performance. Also, check out this tool to compare DNS providers. https://www.grc.com/dns/benchmark.htm I use it Windows, but the site states that it will work with Wine in Linux. I'll have try it myself. What do you get when you traceroute to your dns? see screenshot

I attempted to run "tr 8.8.8.8", but the console returned "two strings must be given when translating". I also attempted to run "tr [my IP address] 8.8.8.8" and the console never finished executing the command (no output, and cannot enter any new commands. This is usually what happens when you run a command that takes a minute to process/load, but it never finishes loading in this case). The same problem of the command never finishing happened when I replaced 8.8.8.8 with phub.net.rogers.cable.com. This is probably a Linux specific issue and I should look into it after this.

DNS Benchmark does indeed work on WINE here are the results:

More than 20% of the resolvers were unreliable? Such a high percentage is suspicious: As you may have noticed, a relatively large number of the resolvers (76) benchmarked (more than one in every five) had apparent reliability problems. Since this is a suspiciously high number, it is more likely that the local network was busy and congested while the benchmark was running. Since this will produce unreliable timing results, you should probably attempt to re-run the benchmark at a time when the local network is quiet. Until then, you should consider these timing results to be invalid.

Only the built-in default resolvers were benchmarked (this one's just about how it uses a generic list that does not necessarily include the fastest DNS's for me. Since they said it takes over 30 minutes and also I'm located very close to the US [which the generic list is designed for], it's not something I intend to do right now, but I am willing to if you think it would help.)

More than 20% of resolvers were unreliable? Such a high percentage is suspicious: As you may have noticed, a relatively large number of the resolvers (76) benchmarked (more than one in every five) had apparent reliability problems. Since this is a suspiciously high number, it is more likely that the local network was busy and congested while the benchmark was running. Since this will produce unreliable timing results, you should probably attempt to re-run the benchmark at a time when the local network is quiet. Until then, you should consider these timing results to be invalid.

Only the built-in default resolvers were benchmarked. Please consider taking the time to create a custom resolver list. This is a reminder about the tremendous benefits to be gained from benchmarking the "Top 50" resolvers that are found for you by the Benchmark's custom resolver list builder. When you have time, don't forget to give that a try. The results will astound you! You can find the option to do this on either the application's System Menu (Alt-Spacebar) or on the Add/Remove nameservers dialog on the Nameservers page.

System has only ONE remote nameserver configured. It appears that only one remote nameserver, with the IP address of (not sure if I should share this), is currently providing all DNS name resolution services for this system. This is not recommended, because a temporary outage, inaccessibility, or overload of this single remote nameserver could prevent or hamper this system's required DNS name resolution.

Recommended Actions: Unless you have a specific reason not to, you should consider adding one or more additional fast ISP or fast public nameservers for use by this system's currently active network interface. Until and unless this is done, you may experience intermittent apparent Internet outages, failures, and slowdowns. (I do not know how to do this)

System's sole nameserver is alive and replying to queries. Although this system has only one DNS resolving nameserver, at least it is alive and replying to DNS queries. (If it were not, you would likely be painfully aware, since it would be difficult to accomplish anything requiring Internet access.)

System nameserver is faster than ALL public alternatives. The DNS resolver your system is using is responding faster than any of the 100% reliable publicly available alternative DNS nameservers this benchmark utility just tested. Therefore, there would be no performance benefit from switching to any of those publicly available nameservers. However, since you only have a single system nameserver configured, it might be useful to use some of the fastest public nameservers as backups if that's possible in your situation. Please also note that this best performance appraisal assumes that this system's nameserver is 100% reliable. See the next item below for an appraisal of your nameserver's reliability.

Note: If there appeared to be one or more faster public alternative nameservers, there was enough uncertainty created by the spread of benchmark timing results that it was not possible to be at least 95% confident that any of those faster seeming nameservers really were reliably faster than the nameserver this system is currently using. So it made no sense to alarm you about the need to change things when there was insufficient evidence.

One or more system nameservers is NOT 100% reliable! DNS reliability is extremely important, since lookup requests that are dropped and ignored by nameservers cause significant delays in Internet access while the querying system waits for a reply. The system is then finally forced to reissue the query to the same or to backup nameservers. While your system is patiently waiting for a reply, you are impatiently waiting to get on with your Internet access.

During this benchmark test, the nameserver being tested did not reply to some of the DNS queries it was sent.

So the question now is: Did the benchmark discover alternative nameservers having superior performance and reliability to which you could switch in order to obtain more performance and reliability?

Important Note: Incorrect warnings of low reliability nameservers can arise if (1) DNS benchmarking is being performed while the local network is busy performing other work such as file downloading, or (2) the benchmark is running over a wireless (WiFi) link with low signal strength or high interference. Please try to minimize any other local network activity while the benchmark is running, and use a wired (not wireless) LAN connection if possible.

Recommended Actions: Before you make any changes, you should probably run the benchmark a few more times at differing times of day to make sure that the troubling reliability is an ongoing problem and not just a brief occurrence.

You may also wish to consult the "Tabular Data" page which summarizes all benchmark results in numeric tables. The numbers make it easier to see exactly how unreliable your system's nameserver is compared with the available alternatives. (And also how the alternatives' performance compares.)

This system nameserver returns errors. This is a GOOD thing! Some DNS providers, such as OpenDNS and even the Earthlink, Roadrunner and Comcast ISPs, redirect incorrectly entered URLs to their own advertising-laden marketing-driven interception page instead of simply returning an error to the web browser. But this system's nameserver is returning errors when asked to lookup non-existent domain names.

System nameserver is replying to all query types. During the development of this DNS Benchmark we discovered that the routers used by some pre-release testers were not returning results for the benchmark's Uncached and/or Dotcom testing queries. Even though these queries are admittedly unusual, they are completely valid. So the only conclusion was that those few routers were inherently defective. The good news here is that your nameserver is replying to these unusual but valid queries.