mudmanc4

@Doned , First place to look would be the crash logs in firefox. You can get to said logs by typing: about:crashes If that does not work, you can visit the logs outside of Firefox: If you can't use the above method because Firefox crashes when it starts, you can also view the reports in files on your computer with the following steps: Press +R on the keyboard. A Run dialog will open. In the Run dialog, type %APPDATA%\Mozilla\Firefox\Crash Reports\ and press Enter. The Crash Reports folder will contain two subfolders: pending and submitted. The submitted folder contains text files for each crash report submitted, with each file containing a crash report ID. For example, a file named bp-031b02bb-26b6-4168-ac0e-2de492090531.txt will contain the following text: Crash ID: bp-031b02bb-26b6-4168-ac0e-2de492090531 Visit: https://crash-stats.mozilla.com/ and copy the Crash ID into the search field to view the report. Per Firefox site

To simplify this, simply find the setting in the router called UnNP, or Plug and play, this will auto open and close ports as requested. Granted this does not always function properly. Otherwise, locate and set the 'set static IP' for the MAC or device aka PS4 in this instance, within the router. Then locate port forwards in the router, and forward the following ports to the MAC or device 'PS4': TCP ports 80, 442, 1935, and 3478 through 3480 UDP ports 3478 and 3479 Restart the PS4

@Chris Morgan , The test will be taken as you have selected, such as 20MB 50 MB 100MB or whatever you click. Normal test will 'forward' to a larger test file, until the test time takes n seconds, which I believe is seven seconds (that does not seem correct and I cannot locate the correct answer) At any rate, this all just means you'll test one file, the one you chose, and no more. As for deciding how to set auto tests, 100MB would be fine in your case, since you've explained the ISP could have a 'burst' on initial startup. This would be helpful for smaller data movement. Where the aperture opens up past the set standard momentarily, once a set data threshold is reached, closes back to standard (allocated package, or what you contract from the ISP.)

Why did the throughput get lowered, was this your decision or intervention such as a suggestion by the ISP? There is obviously an issue, if your getting the same results after rewiring inside the residence, several different modems, and plans, the ISP should be well aware, and working to either resolve the issue, or at the very least inform you of the situation. Is this connection inside or outside of what could be considered a heavily populated area?

Honestly now, I've used ~100+ PSI through a 1/4" nozzle for cleaning out the funk, for years. Could that pressure find ill soldered components, absolutely. Have I encountered this, no.

@29930130

@pondpaul1 , Without further examination this appears to be a difference in local timezone, to UTC server time. I don't have a solution for you at the moment. As the forum software will auto set time, where I am not sure about the test servers coordination. Edit: I would imagine each test server uses NTP from the main test server, that said are your post times you see on the forum equal to your timezone? If so that could mean the test servers are out of sync with the forum server time.

@stanleytpig , Please don't mistake kbps for Mbps, which is what appear to be what you are seeing

Yea, it is isn't it

@Hypopyon, If this were myself, I would run the auto test, example for a two hour movie scenario: This test will run for 125 minutes, once every five minutes, testing upload and download minimum 1MB per test run, 'nfw' is selected to reserve bandwidth as were simply getting as close to a connectivity test as we can. (This means the tests will not forward to a larger test size until the test takes seven seconds. Although I'm not up on the TTL (how long the test server will wait for a response before giving up) therefore the two hour test every five minutes, if your getting eight droputs per movie, you should catch several, in theory. Though in your case, I might be running wireshark , (packet capture) to view the responses during the loss, which can be a bit overwhelming to learn.

@barney79, Welcome to testmy.net forum. If your testing to a specific server such as the testmy.net Australian server, and the test is originated from the same continent, that is where the test is run. Full stop. The reporting server has no bearing on the test results. The test has already been completed before results are sent anywhere, the Australian test server simply reports findings to the main testmy.net server, records them into the database, and reports back to you, after the test has been taken. If you were to run the multi threaded test ( selecting more than one server, then yes there would obviously be more variables involved) but that is not your question or case it seems. Not sure where the provider is getting this information, but generally speaking, that theory would not be viable in any test environment. As you may well already be aware of.

@daronmal , I look for specific results when I test, and believe me I've used everything you can think of out there. But we learn, and we begin to understand what is and what is not realistic and steady. If I don't use TMN, then I'm running a command line test such as a known file size using wget, iperf, or various combinations of many different variables, for any number of testing reasons. Hell you can spin up a VM at any number of high flow datacenters around the world, paying attention to their overall connectivity to a backbone, get an iperf server up in minutes and start testing to that location. Shoot, even testmy.net has a command line test (chuck the GUI and it's limitations if your so inclined), grab the wget for windows binary: https://www.gnu.org/software/wget/ Here are a few links to get you started: https://www.gnu.org/software/wget/faq.html#download And run : wget -O /dev/null https://testmy.net/dl-100MB There should be a progress bar (never used it on windows so maybe you can tell me) Here, I just ran the test on FreeBSD in a terminal: $ wget -O /dev/null http://testmy.net/dl-100MB --2017-11-06 13:25:18-- http://testmy.net/dl-100MB Resolving testmy.net (testmy.net)... 104.28.23.102, 104.28.22.102, 2400:cb00:2048:1::681c:1666, ... Connecting to testmy.net (testmy.net)|104.28.23.102|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://dallas3.testmy.net/dl-100MB [following] --2017-11-06 13:25:18-- http://dallas3.testmy.net/dl-100MB Resolving dallas3.testmy.net (dallas3.testmy.net)... 173.255.138.52 Connecting to dallas3.testmy.net (dallas3.testmy.net)|173.255.138.52|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘/dev/null’ /dev/null [ <=> ] 100.07M 5.82MB/s in 19s 2017-11-06 13:25:37 (5.38 MB/s) - ‘/dev/null’ saved [104936417]

Actually this is the exact reason for various testing sites, it is performing precisely as intended. Showing you where the issue is. There is a routing issue between your ISP, and the New York test server, likely due to the fact the ISP has changed their schema to IPV6 on your modem, and they are likely working out new routes for this block. Of course you could have gotten bumped to a different ISP level network for various other reasons as well. Therefore the tool is doing it's job, letting you know your connection is not proper from the ISP, to the New York area, yet proper to Florida. See, if a site has a CDN (Content Delivery Network) you will not notice pageload issues, considering you will pull from the available resource in line, on the other hand, if a site is not static (like a blog) and is in the New York area, you will load slowly, if at all. If the 'blog' is located in Florida, and not on any CDN, then you'll load quickly. Testmy.net is a tool not just to check for throughput, or what speeds you are paying for, but for geographical connectivity as well.

The results to the new york server are due to ISP issues, nothing we can do about that, I'm sure they will get it right when they are capable of doing so. That said, testing to various geographical area's is the best way to ascertain how your ISP is conducting their peering (how they transfer your data over networks they do not own) Therefore never stick to just one test server for any reason other than local connectivity issues (intrastate or ISP to your desktop connectivity)

Correct, this proves an ISP routing issue. Especially when you can test over 1000 Miles away and get better results than several hundred.

No, I don't think so. This is about routing, it appears considering the IPV6 change, your route has also changed. The IP detection (not showing the provider) is simply due to the IP database not currently in the database here, which would have no bearing on your route to here. Test to other testmy.net/mirror s and see what changes.

Well there is your answer. IPV6! It would appear this does not reside in the current database at testmy.net , let me raise this with @CA3LE And networking is complex, I am always looking for answers (including currently in my own situation) so no worries there. No one knows it all or even half of it.

@daronmal, have you run a traceroute to testmy.net? Your routing could be skewed in the middle of this (possible) process mentioned above

Yea that would likely have no effect on this issue. I'm going out on a limb and claim Comcast is doing some block movement, and or in the middle of moving you to IPV6, the latter more likely from what I can see, considering they are now issuing special purpose blocks

I can only assume you changed the NIC, however this does not account for the provider not being recognized, which may or may not be anything on your end. Depending on how you may have as well changed your network , ie: firewall, VPN, proxy ect physically or software. I believe maxmind is still the GEOIP source testmy.net uses, which is by far always correct, (due to advances as well as the ever changing topology in networking as a whole) so it could be anywhere between you and or the ISP as well. The next thing to look at might be, did this occur before, or after your hardware change. As well I might ask if there were extending circumstances as to the reasoning behind the hardware change.

@iamdw @daronmal Both of these account resolve to the same root servers: fyi AUTHORITY SECTION: . 3600 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2017110501 1800 900 604800 86400

@daronmal , I see you have changed devices since obtaining the higher throughput values. Although the most recent provider is not being detected. This could be a DNS or geoip issue, not excluding maxmind. Go back to the previous device and retest please.

This appears to be a recurring event , is the rheostat faulty?

I use libreoffice, simply by adding separation via space, as well as comma the field is split vertically, example: As downloaded: Then changing to 'space': You can edit the fields however you wish to define them.

That is a good suggestion. However interesting the problem solving of the local query might be to sort out, considering the same time happens each day, including the seconds.