Yes, they do not have a correct location -- the city they determined for me was also in the wrong state. I am on the edge of the beam, and the city they selected as my location seemed to be toward the center of my beam. I came in with a different connection and got the same city an so I wondered how consistently they were choosing that city and more generally if others on the beam would get that same city. After digging through some tests I ran over a year ago, I see they had a different city chosen for my location -- also in a state different from me, but also toward the middle of the my beam, so it is not consistent.
So obviously since it does not consistently choose a city based upon the beam, it is impossible to compare a score against the average and know how your bandwidth compares to the beam in general -- as maratsade demonstrates by getting two different cities with different accounts. The gateways handle multiple beams in different time zones, but I did not see a city chosen based upon the location for one of those other beams, so it seems like they can narrow it down to a general geographic location based upon the beam, but can still be 100 miles off from the true location.
I was doing the bandwidth test -- I agree the TestMy.net latency test is fairly pointless especially as the HT2000W records average latency for every 5 minute and 1 hour period anyway.
The average score even for the bandwidth test would also not be an accurate measure not only for the reason you mention, but also because there are a lot of tests done on small test sizes which will not be accurate with satellite.
If you don't mind, what city did you get? Mark, I think you were beam 68 -- so did your city land toward to middle of beam 68 in northern VA?
Maratsade, would you mind sharing the cities you saw along with your beam? Or at least give a rough impression of how far the cities were from the center of your beam?
I dug through a bunch of cities this way, and the average seems to be around 35Mbps for what I thought were selected from J2 beams, and 25Mbps for J1 beams (which might be a combination of gen 4 and gen 5 services if I understand correctly), which is considerably better than what I imagined based upon reading posts on this site! It seems the great performance I get is not out of line with the areas I combed through. I did see a city on the edge between beam 68 and 69--far from the center of a J2 beam--that had an average of around 50Mbps, and they had run a lot of tests.
Thanks!
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
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>
thanks, Mark. I thought maybe the center was somewhere around Culpeper.
