cancel
Showing results for 
Search instead for 
Did you mean: 

Using TestMy.net to compare your speed to others on your beam

Highlighted
Distinguished Professor III

Re: Using TestMy.net to compare your speed to others on your beam

"if the average is good, then the beam can not possibly be over sold"

 

But there may be other reasons for speed issues -- in 2017 there were problems with Bean 68 and the speed was pretty bad for a while and didn't get better until the engineers fixed whatever the issue was. 

Highlighted
Senior

Re: Using TestMy.net to compare your speed to others on your beam


@maratsade wrote:

"if the average is good, then the beam can not possibly be over sold"

 

But there may be other reasons for speed issues -- in 2017 there were problems with Bean 68 and the speed was pretty bad for a while and didn't get better until the engineers fixed whatever the issue was. 


Yes, absolutely.  When there was that problem, presumably all recent tests run when the problem existed would have been bad and the recent average would be low. 

 

Just because the recent average is bad does not imply the beam is oversold.  But if the average of recent tests is good, then how can anyone say the beam is experiencing poor performance because it is oversold?  

 

If I have repeated bad test results recently, but the average of recent tests is good as shown in the DB, then I think the following are implied:

  • The entire beam is not having problems
  • The beam is not over sold

I think this can be a useful way to say beam X is *not* oversold, and appears to be running good recently.  It is not a demonstration that beam X is oversold.  It also lets us know approximately how we are doing compared to others in our area.  This kind of test does not offer proof the beam is oversold -- it simply provides evidence it is not.

 

 

Highlighted
Distinguished Professor III

Re: Using TestMy.net to compare your speed to others on your beam

[Sorry, deleted something by mistake -- I had asked if there is evidence that an oversold beam functions poorly. Since we don't know what beams are oversold, if any, we can't really test, so all of this seems to be just speculation). 

 

EDIT: other reasons for poor performance could be issues with specific servers (such as web acceleration), and gateway issues.  Performance issues were present in several beams towards the beginning of Gen 5, and the beams were not even close to oversold.  Congestion happens very easily too, especially at prime time, and it doesn't take that many people to clog the beam. If memory serves, without optimisation, clogging happens with just 64 subscribers using the system at the same time.  I imagine optimisation raises this number, but since the amount of data to go around is not all that much, the quality can deteriorate pretty quickly, especially when those 64 or so people are all trying to stream. 

 

EDIT 2: This is where I got the 64 figure. 

Highlighted
Associate Professor

Re: Using TestMy.net to compare your speed to others on your beam

Beam 68 is centered somewhere on the line between Culpeper and Rapahannock County, Virginia. TestMy keeps thinking I'm in Boyce, which is way up in Clark County, east of Winchester. So, I don't think it's that. More likely it's using some combination of geoip and whatever location your browser thinks it's at.

 

Here's a link to the footprint for beam 68: https://satbeams.com/footprints?beam=10175


* Disclaimer: I am a HughesNet customer and not a HughesNet employee. All of my comments are my own and do not necessarily represent HughesNet in any way.
Highlighted
Distinguished Professor III

Re: Using TestMy.net to compare your speed to others on your beam

thanks, Mark. I thought maybe the center was somewhere around Culpeper.

Highlighted
Senior

Re: Using TestMy.net to compare your speed to others on your beam


@maratsade wrote:

Is there evidence that an oversold beam always functions poorly? 


Of course not.  But it is unlikely that an oversold beam will have an *average of many* recent tests above 25Mbps and therefore probable that the beam is not oversold, and so it looks to me to be evidence the beam is not oversold.

 

Of course, I laugh pretty hard at the idea of trying to figure out when I can run 50 tests when everyone else is asleep so as to make an oversold beam look good :-)

 

Maybe we can coin a term for it -- "salting a beam" haha

 

 

 

Associate Professor

Re: Using TestMy.net to compare your speed to others on your beam

Incidentally, latency is usually the real tell that congestion exists because it will show delayed packets in the buffer. A beam could becoming congested and you'd not know it from looking at speed until the congestion becomes extreme. Then it's not just speed, but dropped packets as well, just because the system can't keep up with the buffered requests/responses.


* Disclaimer: I am a HughesNet customer and not a HughesNet employee. All of my comments are my own and do not necessarily represent HughesNet in any way.
Highlighted
Distinguished Professor III

Re: Using TestMy.net to compare your speed to others on your beam

"I  can run 50 tests when everyone else is asleep so as to make an oversold beam look good :-)"

 

LOL. 

Highlighted
Senior

Re: Using TestMy.net to compare your speed to others on your beam


@MarkJFine wrote:

Incidentally, latency is usually the real tell that congestion exists because it will show delayed packets in the buffer. A beam could becoming congested and you'd not know it from looking at speed until the congestion becomes extreme. Then it's not just speed, but dropped packets as well, just because the system can't keep up with the buffered requests/responses.


I agree -- if I download the log and graph the column of numbers behind the RTT flag, during normal week days for my beam it rises briefly at 2am, 3am, then rises 6:30am-7:30am, and does the big rise from 6:30pm to 11pm.  The highest numbers usually are around 8:30pm.  Other times it is at the minimum.  This number appears to only include the time for the queueing up and ride over the satellite, as they have some other columns that look at the time past that.  There is also a column for lost packets and %.  If this number goes above 2000ms average for a 5 minute period, you get a red X on the 5 minute chart.  If the 5 minute chart records 2 Xs (or maybe 3?) it gives a red X on the hourly chart -- simple and useful, I thought.

 

But while this seems to give some insight about my own beam and how busy it is at different times a day, it does not tell me anything about your beam.

 

5.png

 

If I was moving or considering Hughesnet, I think this gives me some idea what it is like around beam 68 recently.  If this is way off from your expectation and experience, please do let me know.  This score is not too shabby!   This score looks decent since a bunch of these tests would  have been run from phones over 2.4Ghz WiFi with small test blocks that lower the average!

 

Now on the other hand, if we find that 40 of these 109 tests were run from a beam in Idaho, and that the people shown here are not in beam 68, then this tells us very little.

 

I am running some more tests on my beam to see how much "salting" of the beam I can do since I am pulling around 50Mbps at the moment....

 

 

 

 

 

Highlighted
Associate Professor

Re: Using TestMy.net to compare your speed to others on your beam

Your data sounds about right:
More and more people are making use of the Bonus period to do heavy lifting (sofware updates, etc.). The ones you see at 0230 are likely automated while people are sleeping, and the ones at 0630 are likely manual as people are getting up. I personally do all mine at 0500 to beat the 0630-0700 rush hour.

I'd be willing to bet the evening rise actually starts around 1630 and continues to ramp to a frenzy between 20-2100, then becomes normal again between 22-2300. That's always been the trend, and almost always when people are trying to stream something.

 

Streaming always puts the biggest load on the system because of the number and consistency of the packets, as well as the potential need for unecessary resends due to the delays in a streaming server getting an ack that a segment was received correctly, and in the proper sequence. It puts a tremendous load on system resources, which is not good when resources are limited.

 

In a situation where latency increases with congestion, all these people that say they keep getting buffering yet continue to let it keep loading, playing, and buffering just make it worse. It's like holding a mic to a 1,000w amp speaker and wondering why the feedback just keeps getting louder and more intense until it can't take anymore and it just clips. Repeated buffering is the system's way of telling them "this isn't working, you're killing me, please stop" but they don't get the hint because god forbid they miss their Netfilix show, so everyone on the beam and ultimately the gateway suffers. Then they blame the network for something they did (Modern entitlement problems). </soapbox>


* Disclaimer: I am a HughesNet customer and not a HughesNet employee. All of my comments are my own and do not necessarily represent HughesNet in any way.