mudmanc4

@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.

@gmatv, Maybe run a few more tests here since this has been a few days, working with different test servers https://testmy.net/mirror Without more information it would be difficult to diagnose. Is there any reason not to segregate the networks? At least as a failover?

For comparison, here is a different BackupPC server, running Debian, which has been reporting correctly: root@lime-bak:~# pydf Filesystem Size Used Avail Use% Mounted on /dev/dm-0 1802G 123G 1596G 6.8 [##.................................] / /dev/sda1 235M 33M 190M 13.9 [#####..............................] /boot So it seems I've been elbow deep into the FreeBSD port, and will in time learn who the python script is getting their info from, and get it updated. Considering the following from the BSD box running df: root@bsd1:~ # df -h Filesystem Size Used Avail Capacity Mounted on zroot/ROOT/default 445G 284G 160G 64% / devfs 1.0K 1.0K 0B 100% /dev zroot/tmp 160G 120K 160G 0% /tmp zroot/usr/home 160G 144K 160G 0% /usr/home zroot/usr/ports 162G 1.1G 160G 1% /usr/ports zroot/usr/src 160G 88K 160G 0% /usr/src zroot/var/audit 160G 88K 160G 0% /var/audit zroot/var/crash 160G 88K 160G 0% /var/crash zroot/var/log 160G 480K 160G 0% /var/log zroot/var/mail 160G 128K 160G 0% /var/mail zroot/var/tmp 160G 96K 160G 0% /var/tmp zroot 160G 88K 160G 0% /zroot zroot/usr/vmtest 160G 88K 160G 0% /usr/vmtest

Does this help?

The question might be, what is the multiplier here, and where is it coming from, certainly not from the pydfrc file

FreeBSD 11.1 pydf reporting interesting disk usage. Anyone see anything at all /maybe-not so much here? {almost a litmus test} as in "Alex, I'll take what I would like to see rather than what I should see" for 500 root@bsd1:~ # pydf Filesystem Size Used Avail Use% Mounted on zroot/ROOT/default 111T 71T 40T 63.8 [####################............] / devfs 1024B 1024B 0 100.0 [################################] /dev zroot/tmp 40T 30M 40T 0.0 [................................] /tmp zroot/usr/home 40T 36M 40T 0.0 [................................] /usr/home zroot/usr/ports 40T 281G 40T 0.7 [................................] /usr/ports zroot/usr/src 40T 22M 40T 0.0 [................................] /usr/src zroot/var/audit 40T 22M 40T 0.0 [................................] /var/audit zroot/var/crash 40T 22M 40T 0.0 [................................] /var/crash zroot/var/log 40T 114M 40T 0.0 [................................] /var/log zroot/var/mail 40T 31M 40T 0.0 [................................] /var/mail zroot/var/tmp 40T 24M 40T 0.0 [................................] /var/tmp zroot 40T 22M 40T 0.0 [................................] /zroot

Welcome to testmy.net forum @mudman59 , Looks as if the connections speeds are rather sporadic, chances are there are a lot of other customers in the area.