Have there been changes in Upload test speed calculations since mid July?

[Pgoodwin1]

My test results lately for Upload speeds have consistently been about 1/2 of what they were July 15th and earlier. The Download speeds show about the same as they were before that date. I was curious if there were any changes to the calculation or test method.

I get about 1/2 the Upload speeds of previous tests on all my devices.

When I check the speeds using Time Warner's SpeedTest, the results are about what they used to be. Their upload test shows me getting about 0.9 Mbps and TMN tests used to show about 0.8. Now it's consistently about 0.4.

[Pgoodwin1]

I just talked to Time Warner Roadrunner support and they detect a signal power out of range low problem, so forget this post

[CA3LE]

Glad you figured it out... nothing changed on this end.

... at least you know that my tests do what they're intended to do.

[Pgoodwin1]

I was getting intermittent web page loads. What bothers me is that when you test the connection with their SpeedTest.ohio.rr test, you can watch the analog meter wander around between 0.4 and 1 Mbps upload during the speed test, and even when the need stabilizes at about 0.5 Mbps for the last 1/2 of the test or so, the digital readout at the end indicates 0.97 Mbps. There should be a class action lawsuit against them for that BS.

The TMN upload test was presenting a reasonable result showing about 0.4 and at time much worse than that. I tried 3 other speed test sites, and the only one that displayed the Upload speed being low was SpeedTest.org (showed about 0.5 Mbps). All the rest of them showed some distorted result that made the system appear good at 1Mbps.

Thanks TMN for having a good test system.

You can close this thread. Or if I can, how do I close it?

[mudmanc4]

No need to close it imo , it's a great example of how ISP internal network testing servers are really no good to anyone other then a level 1 tech , to see if your connection is working .

And to see real world testing done, and compare the ISP peering and there actual capability to supply an internet connection or not.

[CA3LE]

Thanks... I just hope more people realize that this is the REAL speed test.

I rarely close threads... thanks for the concern though

[Pgoodwin1]

Even after Time Warner came out and fixed the signal level problem, after they left, I was still only getting about 0.4 Mbps upload speed per TMN tests. Then about a week later, all of a sudden, it went back up to about 0.8 Mbps where it normally is. Their speed tests showed the same 1Mbps at a real 0.4 AND at 0.8. How worthless.

[CA3LE]

Even after Time Warner came out and fixed the signal level problem, after they left, I was still only getting about 0.4 Mbps upload speed per TMN tests. Then about a week later, all of a sudden, it went back up to about 0.8 Mbps where it normally is. Their speed tests showed the same 1Mbps at a real 0.4 AND at 0.8. How worthless.

I knew there was another topic on this I needed to reply to... I just lost track of where it was.

Actually, I hate to say it but there was in fact a bug that was discovered. Had had to do with the character set being misinterpreted. I should have caught it sooner.

The thing is, if the browser interprets the data using the wrong character set the data being sent or received becomes jumbled... resulting in more data than was actually there... because it replaces 8 bit characters with it's own representation of the characters I intended... always resulting in more data. That's the best way I can explain it.

https://testmy.net/ip...ad/#entry336113

It doesn't mean that you didn't have an issue... but it was definitely being exaggerated in the results because of the character set issue.

What actually helped to catch this bug was that the member who posted the topic above tested on old.testmy.net and compared the results. Which were out of line. That site is static and doesn't change... the main site however is constantly being developed and bugs are bound to happen during that process. This one was such a small thing but the impact was great. When you contacted me I wasn't expecting to see a bug because there no heavy development on the upload test since my last waiting period. I start and stop development on different sections and put them under a period of waiting so that any bugs can surface... in this way I can know, "okay... no bugs... keep building." or "I've got a bug, much be something to do with the last round I did on that script." -- I have a lot of code and I've found that's the way that works best for me... with the smallest impact on my users when there is a bug. ​I dismissed it as a problem with your connection because nobody else had said anything. The problem was that the character set wasn't being necessarily changed by the code... some kind of update to the apache server was fooling with it also. This was only effecting the upload test by the way. And I don't think it effected everyone... under some circumstances it may have been defaulting to the intended character set.

Apparently I had some reading to catch up on about some new standards that were coming down the pipe regarding character sets... programming is constantly evolving and adjustments need to be made, this is why I can never stop building. Other websites out there wouldn't have big a problem with this issue, they might have a few characters on the page show up incorrectly but not really a big deal. Only hackers and geeks use 8bit characters when they type. But because of the nature of what TMN is doing to your browser during the test something like that had a big impact in this situation. The cumulative difference of all the characters of the test information being misinterpreted by your browser obviously impacted results. This is now being basically hardwired into the configuration via .htaccess so it can never happen again... unless I accidentally delete that file, but trust me... if that happened the whole site would be messed up and it would be a very obvious problem.

I'm really sorry if the results confused you or caused you any trouble. I make mistakes sometimes but I always learn from them.

[Pgoodwin1]

Interesting. Glad you found it. When I look in my test results, I can see exactly when the fix went in. I was a bit puzzled when the upload speed showed low but I didn't notice any performance hit. Because of that, I didn't push it with Time Warner. Their fix of the download speed wild variation due to the signal level made the performance right again.

Software bugs are tough. Before I retired I worked at GE Aircraft Engines in Evendale OH. I was an electronic engine control circuit designer. In the 1980s we transitioned from purely analog controls to digital controls. Each engine control had two independent channels of hardware running the same OS and AS. In those days there weren't very good software design and validation tools and standards. We were always terrified of the subtle software bugs that could lock up the Software and cause an engine shutdown. Commercial airlines always have a minimum of two engines and the ability to fly with one engine out. But both engines (4 control channels) run the same software. So there was always that small probability of a bug that would take out all of the engines at the same time. Miraculously (due to a lot of SW engineers checking code) it never happened. We had a couple of control channel shutdowns due to subtle software errors or hardwarevfailures over the years, but never a common mode one that took everything down. Back then the software was a lot simpler, and the engine controls had hydro mechanical backups. These days, there are no hydromechanical backups because they are very heavy, and the software is orders of magnitude more complex. But the design and validation process tools are also orders of magnitude more sophisticated.

But every time there is a new set of requirements that result in a software change, there's always the potential for something to slip by. Thankfully, a simple core of hardware and software safety nets that were developed that could be ported to new processors, memory, and control chips, and the wheel didn't have to be reinvented. Subtle software glitches are very tough to catch.

On Sun Aug 19 2012 @ 1:10:48 pm the world was right again.

[CA3LE]

Interesting. Glad you found it. When I look in my test results, I can see exactly when the fix went in. I was a bit puzzled when the upload speed showed low but I didn't notice any performance hit. Because of that, I didn't push it with Time Warner. Their fix of the download speed wild variation due to the signal level made the performance right again.

Software bugs are tough. Before I retired I worked at GE Aircraft Engines in Evendale OH. I was an electronic engine control circuit designer. In the 1980s we transitioned from purely analog controls to digital controls. Each engine control had two independent channels of hardware running the same OS and AS. In those days there weren't very good software design and validation tools and standards. We were always terrified of the subtle software bugs that could lock up the Software and cause an engine shutdown. Commercial airlines always have a minimum of two engines and the ability to fly with one engine out. But both engines (4 control channels) run the same software. So there was always that small probability of a bug that would take out all of the engines at the same time. Miraculously (due to a lot of SW engineers checking code) it never happened. We had a couple of control channel shutdowns due to subtle software errors or hardwarevfailures over the years, but never a common mode one that took everything down. Back then the software was a lot simpler, and the engine controls had hydro mechanical backups. These days, there are no hydromechanical backups because they are very heavy, and the software is orders of magnitude more complex. But the design and validation process tools are also orders of magnitude more sophisticated.

But every time there is a new set of requirements that result in a software change, there's always the potential for something to slip by. Thankfully, a simple core of hardware and software safety nets that were developed that could be ported to new processors, memory, and control chips, and the wheel didn't have to be reinvented. Subtle software glitches are very tough to catch.

On Sun Aug 19 2012 @ 1:10:48 pm the world was right again.

Well, I feel better knowing that there was an issue with your download speed as well... because this bug didn't effect the download test.

... dang, scary time to fly. I think I would have rather flown in an analog plane at that time. I guess having two redundant software systems only helps if one completely fails... not if there's a bug, because if there's a bug in one, there will be a bug in the other one too. Right?

Sometimes I wonder how much more a comercial airliner, for instance a 737, weighs due to it's redundancy... and how much extra fuel is spent each year for unnecessary redundant systems... systems only in place to make the consumer feel safer. You worked in that industry... do you feel that it's a little over redundant or do you think it's just right because of the nature of what's being dealt with. I mean... does everything really need a backup? Is it, to a point, being done to make consumers feel safer about airline travel?

In all fairness, you caught this bug before anyone else... I've promoted your account to sophist. I'm going to tell you the same thing I told Smith6612...

... see I sensed that you were knowledgeable. That title is well deserved and I don't just hand those out. Out of 86,000 registered members only 23 24 hold that title and only 35 have a higher title. I hope you stop by from time to time and provide your insite... lots of people with connection problems and we're much smarter and can solve much more as a collection of minds.

-D

Cheers!

-D

[Pgoodwin1]

Thanks so much. I'm both surprised and honored.

Yes, you are right, a true bug in one means that there's a bug in all. And as for it being a scary time to fly, amazingly, the reliability and safety of the aircraft is way better than in the old analog days. Mostly because the size and weight of those old systems wouldn't allow you to put redundancy everywhere you needed it. Now the probability of a catastrphic failure due to electronics or software failure is extremely low because with a redundant system, the probability is the product of the failure rates. So if one channel has a probability of catastrophic failure of 1.0 E-06 per flight hour, then the probability of having both channels go out is 1.0 E-12. These numbers are really small, but with thousands of aircraft flying all the time, they are racking up millions of hours a month, so the numbers have to be incredibly small or there'd be planes falling out of the sky regularly. The safety critical flight control systems on the planes are usually triple channel redundant. Engine systems are dual redundant because there are two engines. So as for is there too much redundancy, economics keeps it to a minimum, but as the number of aircraft flying increases, better safety numbers are always being sought.

As for the weight of that redundancy, it's all about gas mileage (making money). The aircraft design weight is set by competition amongs the plane manufacturers; each one wanting to earn more money with better mileage and lower ticket costs to steal sales away from the other guy. So in order to get the weight down with the added redundancy, smaller lighter electronics and new stronger lighter hardware in the control systems is required. It's usually more expensive. So redundancy usually only goes into the real safety critical systems. It's getting to be the same in cars.

Well enough rambling about the aircraft world. Thanks again for the promotion. I do test regularly using your tools, and check in the forums every week or two.

[Pgoodwin1]

Oh, and your test results thing didn't cause me any real trouble. I was kind of just waiting to see if the upload speed ever got better after Time Warner fixed the signal level problem, and there wasn't any noticeable difference in performance from what it had been in the past at 0.8Mbps. I was a little worried that a new Gigabit Ethernet switch (that I put in just prior to this issue) had gone flakey on me, but again, everything seems to be working right, so I kind of just ignored it. I didn't have a good feel about how much upload speed affects web performance when no really huge files are involved. Obviously the effect is around an order of magnitude smaller than the effect of download speed since, since the download is roughly an order of magnitude faster than the upload speeds at many ISPs.

I had forgotten what a Greek Sophist was and had to go look it up. Hopefully I can help on another day. I'm a retired engineer so I'm always looking for interesting tech stuff.

[CA3LE]

Thanks so much. I'm both surprised and honored.

Yes, you are right, a true bug in one means that there's a bug in all. And as for it being a scary time to fly, amazingly, the reliability and safety of the aircraft is way better than in the old analog days. Mostly because the size and weight of those old systems wouldn't allow you to put redundancy everywhere you needed it. Now the probability of a catastrphic failure due to electronics or software failure is extremely low because with a redundant system, the probability is the product of the failure rates. So if one channel has a probability of catastrophic failure of 1.0 E-06 per flight hour, then the probability of having both channels go out is 1.0 E-12. These numbers are really small, but with thousands of aircraft flying all the time, they are racking up millions of hours a month, so the numbers have to be incredibly small or there'd be planes falling out of the sky regularly. The safety critical flight control systems on the planes are usually triple channel redundant. Engine systems are dual redundant because there are two engines. So as for is there too much redundancy, economics keeps it to a minimum, but as the number of aircraft flying increases, better safety numbers are always being sought.

As for the weight of that redundancy, it's all about gas mileage (making money). The aircraft design weight is set by competition amongs the plane manufacturers; each one wanting to earn more money with better mileage and lower ticket costs to steal sales away from the other guy. So in order to get the weight down with the added redundancy, smaller lighter electronics and new stronger lighter hardware in the control systems is required. It's usually more expensive. So redundancy usually only goes into the real safety critical systems. It's getting to be the same in cars.

Well enough rambling about the aircraft world. Thanks again for the promotion. I do test regularly using your tools, and check in the forums every week or two.

Very interesting...

I had forgotten what a Greek Sophist was and had to go look it up. Hopefully I can help on another day. I'm a retired engineer so I'm always looking for interesting tech stuff.

Yeah... about 8 years ago I was reading something and saw that word. I wanted a deeper understanding of what it meant so I looked it up... then I thought, that would be a cool title to give to cool people. Been using it ever since.

[mudmanc4]

Congrats on the promotion Pgoodwin1 !!!!!

It's not just a title, ca3le does not just toss out that one bud. Iv'e followed your thread, great intuition, questioning an anomaly is a very good trait .

[CA3LE]

Congrats on the promotion Pgoodwin1 !!!!!

It's not just a title, ca3le does not just toss out that one bud. Iv'e followed your thread, great intuition, questioning an anomaly is a very good trait .

People like him keep me on my toes... but as I said before, I can debug for days on end and it's never as good as the bug checking that putting it into production does. My users are awesome. I'm glad that people take time out of their day to report issues when the arise. ...and there's no getting around bugs... it's the nature of software development. I've even seen Google bug out many times over the years... I even saw a 404 error on Google a couple weeks ago. That just proves that nobody is perfect.

[TriRan]

People like him keep me on my toes... but as I said before, I can debug for days on end and it's never as good as the bug checking that putting it into production does. My users are awesome. I'm glad that people take time out of their day to report issues when the arise. ...and there's no getting around bugs... it's the nature of software development. I've even seen Google bug out many times over the years... I even saw a 404 error on Google a couple weeks ago. That just proves that nobody is perfect.

i wonder who got remanded for that one

[CA3LE]

i wonder who got remanded for that one

Embarrassing for any website.. but even more so for Google. As long as humans are in the equation errors will happen.

[Pgoodwin1]

Speaking of human error

I had an engineering prof that once gave our class a test where only the answer mattered; no credit for showing the work and though process. He said "Someday you'll have to get the right answer or you could kill somebody". Hahaha the class average on that test was 39%.