CA3LE

I see what you're saying. I guess there was a dual issue. When I hit retest on the auto test each time it flopped back and forth -- linear, multi, linear, multi -- give it a try again, should be resolved. ... that is, unless there's a third way I messed it up.

No problem, happy to help. Spread the word.

Very nice. Do the same to de.testmy.net ... and then to uk.testmy.net.

I get better results from DE than GB here at my house in Colorado. (again, it will show up as London, GB for now) This is against the new DE server ... and against the London, GB server

Response on your other topic How to Test upload to Frankfurt/Amsterdam

Here you go... http://de.testmy.net/SmarTest/up (initiates an automatic upload test to Frankfurt DE) http://de.testmy.net/SmarTest/down (initiates an automatic download test to Frankfurt DE) You can manually change the size by using the following url format... http://de.testmy.net/ul-1MB [or in kB] http://de.testmy.net/ul-1024 (download test urls) http://de.testmy.net/dl-1MB or http://de.testmy.net/dl-1024 Hope this helps. Keep in mind that I've only quickly added this for you, it will appear in the logs as London, GB until I really add it. As long as it says de.testmy.net in the bowser while it's testing... you're testing to Deutschland. I may integrate it later if the server proves worthy. This is outside of my normal Softlayer network on Linode but it should serve your purpose. Testing against the server wasn't totally ideal but that may have to do with the outbound peers leaving Germany. I'd have to test within DE outside of the host network to know for sure. This is downloading from the server. de.testmy.net to eu.testmy.net [root@uk tmp]# wget http://de.testmy.net/dl-200MB --2015-08-15 13:12:47-- http://de.testmy.net/dl-200MB Resolving de.testmy.net... 85.90.245.112 Connecting to de.testmy.net|85.90.245.112|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: “dl-200MB.1” [ <=> ] 209,793,956 14.0M/s in 13s 2015-08-15 13:13:01 (15.7 MB/s) - “dl-200MB.1” saved [209793956] and then in the other direction, from eu.testmy.net to de.testmy.net [root@de tmp]# wget http://eu.testmy.net/dl-200MB --2015-08-15 18:05:35-- http://eu.testmy.net/dl-200MB Resolving eu.testmy.net (eu.testmy.net)... 159.8.149.164 Connecting to eu.testmy.net (eu.testmy.net)|159.8.149.164|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘dl-200MB’ [ <=> ] 209,793,956 90.5MB/s in 2.2s 2015-08-15 18:05:38 (90.5 MB/s) - ‘dl-200MB’ saved [209793956] So uploading to the DE server is definitely not going to be an issue. But coming out of the server, at least when going to my server in London, it's not as fast as I'd like to see. Ideally I'd like to see at least 75-100 MB/s (600-800 Mbps) in both directions. In testing out to dallas2.testmy.net both the EU and new DE servers performed well for me. [root@uk tmp]# wget http://dallas2.testmy.net/dl-200MB --2015-08-15 13:17:47-- http://dallas2.testmy.net/dl-200MB Resolving dallas2.testmy.net... 108.168.210.66 Connecting to dallas2.testmy.net|108.168.210.66|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: “dl-200MB.2” [ <=> ] 209,793,960 57.8M/s in 5.2s 2015-08-15 13:17:53 (38.5 MB/s) - “dl-200MB.2” saved [209793960] [root@de tmp]# wget http://dallas2.testmy.net/dl-200MB --2015-08-15 18:15:36-- http://dallas2.testmy.net/dl-200MB Resolving dallas2.testmy.net (dallas2.testmy.net)... 108.168.210.66 Connecting to dallas2.testmy.net (dallas2.testmy.net)|108.168.210.66|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘dl-200MB.2’ [ <=> ] 209,793,960 53.3MB/s in 7.6s 2015-08-15 18:15:44 (26.2 MB/s) - ‘dl-200MB.2’ saved [209793960] Testing de to dallas... root@home [/tmp]# wget http://de.testmy.net/dl-200MB --2015-08-15 11:20:20-- http://de.testmy.net/dl-200MB Resolving de.testmy.net... 85.90.245.112 Connecting to de.testmy.net|85.90.245.112|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: “dl-200MB” [ <=> ] 209,793,956 14.2M/s in 15s 2015-08-15 11:20:36 (13.0 MB/s) - “dl-200MB” saved [209793956] Not bad given the distance but again not what I really like to see from a test server. Other routes to different people and different times of day may have better or worse results, I'm not sure yet. In other words... it's ready for testing but you're the first to use it so let me know what you think of the results that come off it.

I'm putting a machine online for you in Frankfurt DE. Give me a few minutes.

Yesterday I made it so that if you're selected on a different server than you actually initiate a test on, it automatically switches your settings to the server you're testing from. I happened to forget about multithread, which internally is handled a little different. Correction has been made and it shouldn't have that issue again. I also test posted a couple of images. Under my own account and under a test account with regular privileges. I was able to post images without problems... the first time. Then when I retried with the flash uploader it didn't work... switched to the basic uploader and it worked. I have no idea why the flash uploader wouldn't work all of a sudden but I'll look into it. This is why there's a backup basic uploader (link right below the attach button), because flash is stupid. -- funny thing is, first two times I tried, it worked... it wasn't until after a preview was posted that it broke. (sigh, I'd rather that it was just broken... much harder to figure out when it works sometimes.) I'll either fix it or make the basic uploader default. ... I'm working on a new forum anyways, IPB (the forum software used now) is probably on its way out. Thank you for reporting this. Please keep your eyes out for anything else out of the ordinary, I'm currently making improvements. First with things in the backend that you may not notice, then as time goes on the changes will be more noticeable.

Right on. Good to hear. It may be a mystery that will never be solved. lol

Unplug it for 10 seconds and plug it back it. Do the same with your router if you have one.

Hi sourcejedi, welcome! Yes, I'm very aware. I also have a new test that I'll hopefully feel comfortable releasing soon. It's a latency test but different. It's already been run on you. On the 27th for instance you had an average Response Time of 30ms to the London, GB server. The best being 21ms and worst being 105ms. The system is so passive and requires so little that it's finished before you even notice it's even done anything. I'd like to understand its output better before releasing it. I built it and I don't even fully understand it. It may take help from my users to figure out its personality and quirks. In which case I'll just have to release it, as usual.. with no documentation. Then let everyone figure it out and help me understand what I just built. lol --- all I know right now is that its output directly correlates with the connection performance. It's hard to know exactly why that is in each situation because something like this hasn't been built yet. I have no point of reference. -- cool thing about that test is that it can be run every few seconds and use almost no bandwidth. By the way. I have 150/20 from Comcast. Not uncommon for me to see 180 Mbps. Even on this connection when I max it out my latency spikes way up to 600-1000+ms.

So you'd want the same test but you'd like to be able to set a threshold. Then when it drops below the threshold the system emails you?

According you your results your connectID has changed twice. Meaning that your public IP address has changed twice. The connectID is a play on your IP address, when the IP changes the connectID changes. For those who have IPs that change frequently I highly recommend signing up and staying signed in while you use TMN. I'm working on a new version of the auto test that will correct itself when the connection drops. What's most likely happening is that your connection is dropping out completely causing the test to timeout and lose its connection. If your signed in your results are saved by your username... these stats remain in the database unless you or I remove them. Under your results saved by username look at the connectID column. Click on the IDs to display all tests taken by that ID. 1105968299952 1105965731040 You'll see that there are actually results where you may not have been signed in under both of those IDs. If you had yet another IP address and didn't sign-in and log a result then it's much harder to track back and figure out what the connectID was. Your username, being signed in, helps keep track of everything. Even if it fails, when a result is shown it's logged and can be retrieved later from the database. In the future the auto test will correct itself and continue the test as soon as the connection is back online.

Hi Nostalgic_Link, welcome. When you enable multithread currently it only affects the download test. The upload test doesn't reference any of the variables related to enabling multithread. Your issue is odd. Do you have any new Internet security or other programs that may affect the output of websites in your browser? Have you tried a different browser? The odd part is that you're able to trigger this by disabling multithread. It really shouldn't be possible. Clear your browser cache and cookies and try a different browser. That may provide more clues.

Thanks -- I'm CA3LE, nice to meet you. Very nice speed. -- Welcome to TestMy.net!

You're welcome. If you like what I'm building tell your friends!

TiP measurements are times taken while the test is running. So the 10% TiP for instance you're measuring the time from start to 10%. Example from your results :: So, at 10% you downloaded 20 MB and you did it in 7.32 seconds so your speed is 23.96 Mbps. They are sub-times but in the end those times do not affect the overall result, they're a reference and aid to help you understand how the test data flowed.

Thanks for reporting this, you've given great information that I can use to make the test better. I'll try to break it the same way in development and work to make it throw an error instead of calculating a result in that instance. The result has been removed from the database, so your stats look clean again. Thank yo so much for the support.

Nobody ever requested a forum addition for those providers. We used to add them as they were requested. I'll be restructuring the forums soon anyways. There may not even be individual forums for providers like that anymore. I'm still thinking about it... it's a huge change so I can't be too hasty.

The browser doesn't seem to be a major limiting factor. Although, on faster connections the max (TiP readings) may read higher than your line is capable of. This doesn't affect the outcome of the final result, only the TiP reading. Only one of my results below displayed this. Furthest point inside the house from the router. Line of sight, 20 ft from router. 50MB test re-testing 65 MB Multithread 84 MB These tests purposely tax your device and browser, it can be too much. Note that Safari (mobile) crashes on classic linear tests over 120 MB, multithread can do any size. So that's the only limitation of the mobile browser I've seen. The readings you get from it however will be consistent with what you'd expect to see downloading and uploading over the Internet through any other application on your device. Your test results will reflect your real-world use. Become aware of how your device handles TMN and use the test accordingly. Just keep in mind that if you see extraordinary TiP readings... like this... it's actually due to the device lagging, then updating quickly. In this case pay more attention to the final number which calculated separately. Even though that reading isn't what we'd expect to see... it's actually indicating an issue. If the device was processing the test more smoothly as it runs on most desktops it would result in a smoother TiP reading. I'd expect future devices to process more smoothly.

I could make you a custom tool that will only grant access to a URL once a user has logged a certain speed on TMN. The client would click the button to enter your program, I assume you have some kind of program that you only want people to access if their speed is fast enough. If they have already logged a result over X Mbps then they pass on to the destination of your choice, if not they are given a message explaining that they must validate speed first... and are forwarded to TMN for testing. If the client is able to log a speed of X Mbps they move on. If they fail to meet requirements they're shown a message set by you explain why they MUST have the minimum speed and give the option to re-test or go somewhere else. Will a solution like that help you out? Should be easy work to piggyback something like that on the existing system.

I don't know how the other guys do it. When I test with speedof.me I get 197 Mbps... yeah right. That would be nice if that was reality. I was watching the activity monitor (polling at 1sec) while the test was running. Which isn't perfect but can give you a good general idea. The test is reading 197 Mbps live in the browser when in reality it's running around 180 Mbps. TestMy.net results are calculated from start to finish taking the entire test into account. Peaked at 189 Mbps but the overall result was knocked down to 173 Mbps when you consider how quickly (or slowly) the test initiated and any fluctuations during. Take this result for instance. Sure, you achieved 21 Mbps but it ramped up really slow and then... ...died out in the middle. So, would you call that 21 Mbps? I wouldn't. The numbers here might not correlate with other tests because other tests may only be considering the best portions of your result. First thing I'd do if I were you. Update OSX and all of your software. Then, reset your modem and router... leave them unplugged for at least 10 seconds. Then, if you're on wifi try to connect with ethernet. If that's not an option then test close to the router. Sometimes my laptop (new macbook pro) will throw low numbers, I then test on one of my wired iMacs and I'm rockin' at full speed. Sometimes in that scenario just turning wifi off and back on will result in the speed falling back in line with what I'd expect to see. Other times I have to reset the router. Run a few more multithread tests. I see that you were able to get up to 57 Mbps in multithread. That may be a clue. Run a few multithread tests, then disable multithread and run a few normal download tests. After turning multithread on and off navigate to the download test page and manually select your test size. A longer test will tell us more so select 100 MB. Select the same size each time manually to keep the variables consistent. You can also manually select the size on the auto test. Let me know when you're done and I'll take a look at your results again.

Thank you for the update. I'll have to dig deeper and see why this happened. I forced the system to give me the same connection ID and I was able to log a result so it's really weird that it wouldn't do it for you. I can't think of any reason that would happen but I'll keep my eyes peeled and let you know if I find anything. Glad it's working for you now, thanks for the heads up. Happy Testing!

It could have started slow... resulting in an overall slower speed. If there's a large lag as the test start, or any time during... it can dramatically affect the results. You may have reached 28 Mbps but you had to wait longer than someone who's able to POP up to 28 Mbps instantly. That's reflected in your end result.

very odd. missinglincoln is missing results... the irony. What happens if you sign out and test? Please also take a test then click on the share tab and share some of the stuff you see there in this thread. We'll figure out what's going on.