Sean

On the 'Share results' page, when I click either the 'Copy URLs' or 'Copy 4 Forums' button, the generated code is missing the 'http' before the URLs: I first ran into this last week when posting a test result on a forum and got rather confused when the resulting post displayed code instead of an image. So I just edited my post and put the 'http' in, figuring the forum had a hiccup. After running into this again today, I checked the 'Share results' page code and indeed the 'http' is missing as shown above. What's interesting is that the IP forum here doesn't seem to mind the 'http' missing. However, on vBulletin it will just end up with the code in the resulting live post.

I noticed the Swedish server in the list on Saturday and was wondering whether I overlooked it all this time. The fastest connection I have access to is a 4G connection at home which I'm using alongside my 5Mb DSL connection. It normally peaks around 40Mbps on the UK server and seems to have no problem with the Swedish server also when the network is quiet: However, the upload test seems to have an issue with the Swedish server. 6MB is the largest block size that will work for me. If I try a 12MB or larger block, it reaches the "Be patient, uploading 12MB of random data..." page and then takes me to the server listings page, both on the desktop and mobile sites with the following in the address bar which appears to include an error code: When this happens, the upload result is not on the test results page either, so it appears to fail altogether when this happens.

On my computers, the top right avatar circle shows with a white gap, at least in Firefox: I had a look at the CSS code and it looks like the image needs to be vertically aligned to the bottom. For example, when I change the '#cUserLink .ipsUserPhoto img' block to the following in my browser's debugger: #cUserLink .ipsUserPhoto img { width:26px; height:26px; vertical-align: bottom; } The top-right bar becomes: I'm not sure if the avatar circles next to the posts are intentional. Personally I'm fine with them, although it cuts off bits from some avatars such as TriRan's avatar. If you wish to change them to square avatars while leaving them round everywhere else on the pages, comment out the 'border-radius:' line in the '.ipsUserPhoto_large img, ...' block as follows: .ipsUserPhoto_large img, img.ipsUserPhoto_large, .ipsUserPhoto_large:after { width:90px; height:90px; /* border-radius:45px; */ } From a quick test in the Firefox debugger, TriRan's avatar shows up as follows with all its text readable: The avatars remain round everywhere else such as in the indexes and widget bars as this code targets just that size used next to posts.

It's Showtime... Part 1 - Browsing the web and a 10MB download on Three (4G) and Meteor (3G): Part 2 - So what does Ookla Speedtest report? Can TestMy be run in a way to match it? Let's find out...

Thanks for that - Indeed there's still a clear difference between http and port 8080 on the Irish Three network, at least on a Smartphone. Three 4G vs Meteor 3G - Linear test with 6MB block: Three 4G vs Meteor 3G - Repeat test over port 8080: Three 4G vs Meteor 3G - Multithread test with 50MB block over port 8080: I've a video recording captured. If it recorded fine, I'll trying editing something to post. I also tested with Ookla Speedtest and Leaseweb's test download and got similar results, i.e. Speedtest was considerably quicker on Three as expected but Leaseweb's test file downloaded far quicker on Meteor 3G.

Over the past week or so, I'm no longer able to access TestMy over port 8080. HTTPS works fine. As of the 30th April 2016, the EU rules on net neutrality came into force. This means that all that traffic must be treated equally regardless of the source and destination and that ISPs are no longer permitted to block and throttle traffic. In previous tests I carried out on the Irish Three mobile network (mobile data on Smartphones) and the UK ISP Pulse8 broadband, there was a vast difference between the throughput I got over normal HTTP compared with port 8080 that Ookla's Speedtest uses. If port 8080 can be enabled again on TestMy, I'll have a go at making a video capture of running tests on TestMy compared to accessing it over port 8008 as well as two third party tests on my phone with the Three network, e.g. Leaseweb test file (normal HTTP download) against running Speedtest.net (which uses port 8080). If there's a clear variation, I'll put it on YouTube.

As far as I can tell, Linksys only do the Powerline up to AV500 (500Mbps over the house wiring). As their units do not have Wi-Fi, you'll need to connect the second unit to another Wi-Fi access point such as where you currently have a weak Wi-Fi signal. I haven't heard of the AV2500 standard or at least could not find any info about it. There are various manufacturers providing Homeplug powerline adapters using the faster AV1200 (1.2Gbps). TP-Link is the only brand I've used, which I haven't had any issues with. Unless you need a very fast connection where you need to boost the Wi-Fi signal, the AV500 should be sufficient as it will provide enough bandwidth for 1080p streaming to two or three devices depending on how fast it can connect over the electrical wiring to the other Homeplug unit.

If it's about extending the range of a Wi-Fi network, I recommend using a pair of AV500 or AV1200 capable HomePlugs, where one unit has Wi-Fi built in or with a Wi-Fi access point. The way these work is that the primary unit connects to the router providing the Internet connection and the second unit connects with the primary unit by sending data over the electrical wiring. I have had little luck with Wi-Fi range extenders in the past as while they seem to work great at first, after a few days they tend to crash out or lose connectivity with the main Wi-Fi access point. I've seen this happen across multiple brands such as TP-Link, D-Link and Netgear including with other people. Another significant issue with Wi-Fi range extenders is that they cut the bandwidth in half as everything is repeated back to the main access point over the existing Wi-Fi network. For comparison, a HomePlug or wired Ethernet based approach to bring Wi-Fi to another area can actually double the bandwidth as each Wi-Fi access point can operate on independent channel numbers. For example, a set-top box streaming in the area with the second Wi-Fi access point will not consume any bandwidth provided by the main access point, although obviously the overall bandwidth is physically limited by the main Internet connection.

These are my two lowest based on sorting by speed: - The left was a test over mobile data before 3G and 4G came to my area over the past month on the Three network. The right test result is from my previous ISP Bluebox Broadband and I had many uplink test results under 10Kbps. I was paying for a subscription with a 10Mbps uplink! Unsurprisingly, I've since changed provider after they kept insisting my connection was fine and they threatened to charge me for any further service calls that did not involve a complete outage.

Most ISPs that throttle traffic do so by throttling the port #s typically used by the applications they wish to throttle. For example, if an ISP wants to mainly throttle file sharing traffic, they'll likely throttle the ports mainly used by BitTorrent (6881-6889), Usenet (119 and 563) and so on. Unfortunately, such throttling will not show up in speed tests which are conducted over the normal HTTP port 80 (like TestMy) or port 8080 (Ookla's Speedtest). Generally the only time throttling shows up on TestMy is when an ISP either throttles by individual connection (like some Public Wi-Fi hostpots) or more cheekily where they throttle everything but port 8080. With individual connection throttling, streaming services such as YouTube are affected which only make a single connection to the server. With the throttling everything but port 8080 (which I know the odd ISP does), the speed Ookla's Speedtest delivers is not possible to achieve with realworld web access unless it can be delivered over port 8080. Until recently, I never knew why some Usenet providers offer port 8080 (instead of the more port 80) as an alternative port # for connecting over, but recently found out that it's difficult for an ISP to throttle Usenet traffic over port 8080 without affecting Ookla's Speedtest.

Surprisingly, this is exactly how my last ISP (NWE Bluebox) delivered its connectivity as this identical looking Ubiquiti antenna is installed on the gable of my house. It is really impressive just how far it sends the signal as I remember when an NWE technician was (unsuccessfully) diagnosing my connectivity issues and had the Air OS screen open on his laptop, it had a full signal reading (-65dBm if I recall right) even though their mast is about 4.5km direct line of sight. Now that I've cancelled their service, I'm curious if they will collect their dish. Otherwise it could be fun to play around with...

The main suggestion I have is to uninstall every app you don't plan using on the tablet, i.e. perform a factory reset to start with (i.e. wipe any user installed apps & left overs), then uninstall/disable any unneeded preinstalled apps that can be removed, such as the obligatory Facebook bloatware many manufacturers preinstall. The fewer apps installed, the the less chance there is of one running in the background causing the unit to become unstable. TeamViewer does not require any open ports, so no port forwarding is required. The way TeamViewer works is it makes a connection to its server, so when remote access is required, it is carried over that existing connection, similar to how Skype handles an incoming call. As for a Windows tablet, it in theory should be able to run anything an entry level Windows laptop can run. The crippled Windows version (Windows RT) is dead as far as I'm aware of and never made it to version 10, so if a tablet is advertised as having Windows 10, it is running the same full operating system as provided with a Windows 10 laptop. The only time to be wary is when buying a second hand Windows tablet to make sure it doesn't have Windows RT.

Another suggestion would be to get a basic Windows 10 tablet, which range around $80 to $120 or £60 to 80 in the UK. Although they have bare minimal hardware (32GB SSD, 1GB RAM, etc.), they do run the full Windows 10 installation, so you can run most diagnostics as with a full size Windows PC, such as Auto test here without it stopping if the Window is put in the background. Teamviewer also works great for remote desktop access. Most Windows 10 tablets are powered over USB also, so could be kept charged from the router's USB port if it supplies sufficient power. The internal battery also doubles up as a UPS, so a brief power interruption will not knock it out like a mains-only powered PC.

One small issue that catches me out from time to time is where TestMy chooses Dallas, Texas by default. This generally is not a problem on a PC as I can clearly see the chosen server at the top right. However, when testing on my mobile, it doesn't show the current server unless I go into the "Server Selection" page and I remember one day doing tests in one town only to realise it lost my Cookie and ran all the tests with the Dallas server. When I ask people to run a speed test, the main workaround I use is to ask them to use the URL http://uk.testmy.net/ which forces the use of the UK server. If it's straight forward enough to work out the country from the user's IP address, one nice feature would be to have TestMy automatically pick the nearest server when the user is not logged in and the cookie has no been set (i.e. first visit to TestMy). For example, if my cookie expires or I use a PC / browser for which I'm not signed in, it will generally switch back to the Dallas server, even though my nearest server is London, UK. The following is an example where I opened a private browser window and went to TestMy.net to simulate a first time visitor:

The best place to test for packet loss is on your computer. Most websites that test for packet loss run the test on their server, which is basically to test the host end for packet loss rather than your connection. Like speedtest.net, I never had much luck with pingtest.net either as I've run tests on a line that was giving a fairly consistent 7% packet loss and pingetest.net either failed to load or reported 0% packet loss. I wrote the following script which measures packet loss against Google's DNS server. Copy & paste the code into Notepad and save it as "pingtest.bat" on your desktop. To run the script, just double-click the pingtest icon. @echo off set /a PingCount=0 set /a PacketsLost=0 set tensec=%time:~6,1% :pingrepeat ping -n 1 8.8.8.8 >null &&goto pingreply set /a PacketsLost+=1 :pingreply set /a PingCount+=1 set /a Complete=PingCount/10 if not "%time:~6,1%"=="%tensec%" ( echo Test %Complete%^%% complete... set tensec=%time:~6,1% ) if not "%PingCount%"=="1000" goto :pingrepeat set /a PacketLoss=PacketsLost/10 echo Packet loss: %PacketLoss%.%PacketsLost:~-1,1%^%% echo. pause The script can take a few minutes to complete and shows a progress percentage roughly every 10 seconds. While it's also possible to run this test by typing "ping -n 1000 8.8.8.8" at the command line, normally the ping command waits 1 second per ping, which would take 15 to 20 minutes to complete.

I had my experience of a dreadful engineer visit for the fixed wireless ISP I've now cancelled, which were probably contractors. When they arrived, I tried explaining just how slow and intermittent my connection has been for the past couple of months, but they told me upfront - "If we see Internet connectivity from the antenna, there will be a service charge for this unnecessary visit!". They did not care that the connection was erratic, upload speeds dipping below 100kbps (for a "10Mb" package), etc. It was only for the fact I saw they had trouble loading up speedtest.net (page kept timing out) that I managed to escape the call out charge, where they basically accepted the connection as being fixed by a software upgrade on the antenna. After that, I wrote to cancel the service and recorded a 10 minute demo video of the connection acting up trying to do just basic web browsing and stuck it on YouTube. While visiting relatives in San Francisco, they asked if I could help them extend the Wi-Fi coverage through their long house. I suggested getting a pair of HomePlug adapters, where the second unit acts as a Wi-Fi access point, but they were convinced they would not work. So I asked why they think that. They said that Comcast told them that due to the length of their house and the limited Wi-Fi coverage, they will need a second Comcast Internet subscription to provide Wi-Fi coverage at the other end of their house.

As the Three mobile network here still gives traffic priority over both HTTPS and port 8080, I tried some experimenting with HMA's VPN to see if I can exploit it. I never thought of bringing my laptop at work, so was limited to running the HMA App directly on the phone. After about 4pm, Three was giving a fairly steady 2.0Mbps to 2.5Mbps over HTTP and 4.5Mbps to 5Mbps over both HTTPS and port 8080 based on a series of TestMy tests. The following was an example about 4:30pm, HTTP vs Port 8080: I established a VPN connection to the HMA's Irish server and got about 3.5Mbps with the plain HTTP test. Based on past testing with HMA, its London server for some reason has lower latency than its Irish server, so connected to London and got a HTTPS-like speed test with the plain HTTP test. With multi-threaded tests over port 8080 (no VPN connection), I was able to get between 10Mbps to 12Mbps, 4 x 50MB tests in a row. The Speedtest App for some reason couldn't hit 10Mbps even after a few runs using Three's own Speedtest server. While privacy concious people generally avoid HMA due to its logging policy, the main reason I use it is for its flexibility of connecting to its servers, such as over UDP and even different port numbers. So if I remember to take my laptop the next day I'm in and get a chance, I'll try to see if there's a way of to exploit any extra bandwidth. I remember being able to get around 2Mbps from a 512Kbps limited hotel Wi-Fi connection using a UDP connection. The Android VPN functionality is fairly limited, e.g. fixed port, no UDP support, etc.

That's a very nice improvement! It's very rare to get any sort of credit for degraded performance on any ISP here in Ireland. In fact, after countless complaining about my NWE Bluebox wireless connection, they finally sent a technician to have a look. The engineers planned charging me for a call out because the connection "worked" as all they cared about was that there was connectivity at their time of checking even though I mentioned it's been going steadily up & down with erratic speed. Thankfully after they ran a few tests, it threw up a few "Connection timed out" errors in a row. They updated the firmware on the antenna and said they would charge me for the call out after showing a 12Mbps down / 1Mbps up result on speedtest.net. I'm glad I watched over their back to see the timed out errors got them to accept the connection as being fixed by a firmware update. They were only out the door about 30 minutes before the connection went erratic again. I've now written to cancel it as it's practically useless having a connection that I can't stream or reliably upload files on.

I spoke to my work colleague last Friday that I was going to write an article about ISPs inflating their speedtest.net results. So he ran two 50MB multithread tests this time without any other network activity, i.e. no remote desktop or VoIP call traffic either. The port 8080 multithread test is on the right. Let's hope this article grabs some attention.

There is a Data Saver plug-in for the desktop Chrome browser, so that would be worth getting to make it easier to analyse what changes in the page source.

Thanks for clarifying that. After experimenting with HTTPS testing on my mobile with the multi-threaded test, I was able to replicate a similar test result by turning on "Data Saver" in the Android Chrome browser. Data Saver - Left: Off, Right: On As far as I can tell, the Data Saver strips comment tags from webpages, so in turn strips all the random test data. So maybe an idea to test if Data Saver is on is to have something like a piece of JavaScript check if a certain HTML comment tag is present in the page source. If it's missing, display an error message saying to disable Data Saver.

I remember reading somewhere here that the multi-threaded tests don't work over HTTPS as the test reads blocks across various domains, which runs into a problem with the self-signed security certificates. I just came across this post where a friend posted multi-threaded tests run over HTTPS with very high test result figures. He said this was over 3G, which normally tops out about 25Mbps with dual-channel HSPA+ here. What I suspect is that most of the requested test blocks gave a security certificate error page instead of the actual block tricking the test into detecting that the blocks as completed. The following is one of his test results where he run a multi-threaded test in HTTPS mode.

So far I haven't heard back from my work colleague and am sure he is wondering why I keep asking him to run more and more tests on his connection. However, by looking at previous results of his user ID, I got the previous multi-threaded test I ran a few weeks ago and it had a 51MB block. That was the one I remember that made it difficult to speak to him over VoIP until the test completed. The following is a better example from the Three mobile network on 4G, where I chose two equal size blocks for both up and down - http vs port 8080: My workplace connection does not discriminate between http and port 8080. There was no one else in at the time, so had the connection to myself:

I asked my work colleague in the UK to try - the port 8080 bait made a juicy catch! HTTP vs port 8080 - linear tests: HTTP vs port 8080 - multithreaded tests: HTTPS - linear:

I did another test today in roughly the same 4G spot, this time comparing HTTP, HTTPS and port 8080. HTTP vs HTTPS: The port 8080 test was somewhere between HTTP and HTTPS: With the Three network, the difference was not as great, but then again this time I ran these tests when I arrived at my workplace, so was about an hour later and a totally different location. HTTP vs HTTPS: Port 8080: