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.
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.
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....
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>
As anyone that has followed the thread above may have noticed, there is a button to display the data behind the median and average shown. So you can review the individual test results and copy them to exclude the suspicious results created by miscreants, nefarious individuals, dirty birds, or friendly flounder that may have been engaged in salting the beam with wild scores for fun or profit.
Ah! Netflix time! Personally, I like buffering because birds are incontinent by nature and I can use the breaks, so prime time here I come! HD
MrBuster wrote:So you can review the individual test results and copy them to exclude the suspicious results created by miscreants, nefarious individuals, dirty birds, or friendly flounder that may have been engaged in salting the beam with wild scores for fun or profit.
Or the more likely reason, which is a legitimately faulty test and result, which many HughesNet subscribers who use testmy.net on a regular basis will eventually see. I've had them myself, and when they happen I always delete them.
