CA3LE

Don't eat the cost... sell it on Amazon. Still worth more than the 6141, even used. The SB6141 has a theoretical max of 343 Mbps down, 131 Mbps up. Even my old SB6121 (4 channel) did well over 100 Mbps, easy... but I seemed to max out around 130 Mbps (it's theoretical max is 172 Mbps). You might need a 16 channel modem to truly pull your full 300 Mbps but I think that the SB6141 is worth a shot. I'd try it... just make sure you can return it after your experiment. ... if you find it works better sell the other one online and you'll probably still break even after seller fees. Personally, even if I dropped 20+ Mbps off the top end, I'd rather have it initiate instantly. It's worth more to me if I was able to pull a consistent 260-280 Mbps vs having over 300 with that slow ramp up that you're displaying. If you try it out, after you try it out... please share your results here. You may help others in your same situation.

Ahhh, the Motorola Surfboard SB6183. I recently had one... actually two of them, returned them in favor of an 8 channel modem because the numbers here don't lie. Consistently slow starts on that modem. The 8 channel SB6141 initiates quicker and reaches full speed quicker. TestMy.net results were very clear and totally steered me to better performance. More channels don't always equal more performance. Read this topic that unfolded when this happened. You be the judge, which modem SB6141 or SB6183 SB6141, still kickin' butt. Saved money AND I'm faster. I suggest you hit up BestBuy and give it a try. Hopefully you're still within the return policy on the 16 channel modem. I recommend buying from BestBuy because of their return policy... no questions asked if you decide that it's not what you need. -- seriously, I just went through the same deal. I'm pretty sure you're experiencing the same idiosyncrasies that made me loose confidence in that modem. For what I do here, developing TMN, that kind of wildly unpredictable performance arch wasn't going to suit the job. Let me know how it goes. (btw, don't bother with extended warrantees, if it runs for a few days with no problem... chances are it will run for years that way. These are very reliable pieces of equipment... just don't cover the all important air vents or restrict the heat dissipation in any way. e.g. don't put it in a confined space or put anything on top of it or your router.)

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!