Incase anyone cares here is the path test clearly stopping at the NOC.
Yes sir that TR doesn't lie.
Incase anyone cares here is the path test clearly stopping at the NOC.
Well I ain't busy and just for the heck of it I just ran three speed test on IP geeks and Hughes.
I never had much for speed test and still don't. My plan says I get 1000 down 128up.
So Ip Geeks:
1070/105
1016/105
1083/117
Hughes server
1016/151
1008/160
990/140
Don't think it proves anything.
I think the VOIP test might be valid can't really tell but it might be a good place to send the Hughes folks who don't understand why VOIP don't work on Hughes. Dazzel em with charts.
Very obviously we have totally different concepts of what constitutes "flaming". Besides being a member of several satellite and satellite internet related sites, I'm also a moderator at one of them. I'm having a hard time rectifying those credentials - with your seemingly unfounded accusation.This is not YOUR house, this is Scott's house. Either leave the guy alone or I will take the issue up with Scott myself admin to admin if bwporker doesn't. Got it Greg? or do I need to spell it out for you? Now enough of the flaming!
You are correct in that most consumer grade satellite internet connections do not support VoIP. A North American exception is in Canada, where VoIP can sometimes be more a matter of survival - rather than one of convenience like it often is here in the US. Some TeleSat resellers purposefully reconfigure their servers to prioritize VoIP packets for requesting subscribers.On the Voip thing, I'm making a custom version of the test just for satellite ppl to at least attempt. I'm tossed between codecs at the moment and need to get some information back from Skype and a couple of others before it's available. For what it's worth I don't think they will pass any reasonable Voip test but willing to give it a try anyway.
Everything you've stated above is correct. Let's answer most of the concerns you've raised and see if you're happy with the answers. The speedtest mini applet that Scott uses for his general test can be obtained from the Ookla website and is intended for webmasters. There is no charge and it must be installed on a decent server and broadband pipe (meaning no bandwidth limitations or issues). Scott's server peformed well in several tests that I performed and I told him so. We also offer the applet on several servers throughout the country but we discourage use of them for diagnostic purposes. They are intended to give you instant feedback on your approximate bandwidth capability at that moment.
The speedtest mini applet was not intended to benchmark satellite or hybrid broadband connections and honestly shouldn't be relied upon too much. For many broadband users, especially those using any form of acceleration technology the tests would also not be appropriate.
With regards to our site, unfortunately bwporker posted the wrong test, results and link to information. Because the test is labled as SPEED people assume this is what the test does. This is a common mistake and we've tried to educate users since making the tests available to the public. Similar limited versions of the tests on other sites also are being misused. The webmasters at each of those sites are no doubt confused about the purpose of that test. Admittedly I think we could have done a better job of explaining the difference and proper use and we'll work on that in the coming days.
The proper test in our case is the ISP Capacity Test located under Diagnostic Tools > ISP Capacity Test. As it's offered TODAY this test is not optimized for satellite however this is about to change much in part due to this thread. Until then we're confident the test will provide consistent results that certainly can be relied upon. Your concern about rate, overhead, burst and test duration are all addressed in this test. Burst and cache detection are inluded and noted on the results where applicable.
Hopefully we can put this behind us and move forward. We encourage anyone to provide feedback and will always respond to comments regarding any of the tests. Thanks again for the opportunity to clear this up.
I am not finding or seeing any test numbers. The very first test I ran I got a test # of 1073 but have not got one since. I am not registered at the site.
Capacity test statistics
------------------------
Download capacity: 4851192 bps
Download packets per second: 606
Upload capacity: 15240 bps
Upload packets per second: 1
Quality of service: 55 %
Packet size: 1000 Bytes
The VOIP test apperas to be making it past the NOC I can't tell for sure but the modem is responding tothe test.
VoIP test statistics
--------------------
Jitter: you --> server: 164.1 ms
Jitter: server --> you: 49.4 ms
Packet loss: you --> server: 0.0 %
Packet loss: server --> you: 0.0 %
Packet discards: 0.7 %
Packets out of order: 0.0 %
Estimated MOS score: 3.6
Ok to stir the pot some more the previous test were run on a Hughes 9000 modem on spaceway III. These test are run on a Hughes 7000s modem on Satmex 5. The VSAT terminals are setting side by side less than 10 ft apart.
Capacity test statistics
------------------------
Download capacity: 807688 bps
Download packets per second: 100
Upload capacity: 135104 bps
Upload packets per second: 16
Quality of service: 90 %
Packet size: 1000 Bytes
VoIP test statistics
--------------------
Jitter: you --> server: 51.6 ms
Jitter: server --> you: 11.2 ms
Packet loss: you --> server: 0.0 %
Packet loss: server --> you: 0.0 %
Packet discards: 0.1 %
Packets out of order: 0.0 %
Estimated MOS score: 3.6
Speed test for the 7000 about right upload seems too fast.
Speed test statistics
---------------------
Download speed: 799392 bps
Upload speed: 137016 bps
Download quality of service: 95 %
Upload quality of service: 92 %
Download test type: socket
Upload test type: socket
Maximum TCP delay: 70 ms
Average download pause: 12 ms
Minimum round trip time to server: 4 ms
Average round trip time to server: 4 ms
Estimated download bandwidth: 1760000bps
Route concurrency: 2.2016733
Download TCP forced idle: 0 %
Maximum route speed: 131070000bps
You are correct in that most consumer grade satellite internet connections do not support VoIP. A North American exception is in Canada, where VoIP can sometimes be more a matter of survival - rather than one of convenience like it often is here in the US. Some TeleSat resellers purposefully reconfigure their servers to prioritize VoIP packets for requesting subscribers.
But down here below the 48th, those packets typically get sent to the back of the bus. The satellite connections can in fact (technically) support VoIP, but the providers simply don't want to supply the bandwidth (to consumer grade subscribers). For those diehards that really and truly MUST have VoIP (over consumer grade satellite), they have to select a hardware solution - and at least a G.729 codec. Software solutions simply don't work. As such, I believe you'd be wasting your time testing for anything lesser.
//greg//
Two things: it's not the satellite that dictates subscriber performance, it's the gateway server. Hughes leases multiple transponders on 13 satellites over North America alone. And each transponder supports probably half a dozen or more gateway servers. Each gateway represents a network loop. If any gateway equipment is acting up - or is oversubscribed - service to subscribers of that specific loop is affected.Unless things have changed there have always been significant performance differences between birds. Must admit though those results especially the QOS surprise me. .
Two things: it's not the satellite that dictates subscriber performance, it's the gateway server. Hughes leases multiple transponders on 13 satellites over North America alone. And each transponder supports probably half a dozen or more gateway servers. Each gateway represents a network loop. If any gateway equipment is acting up - or is oversubscribed - service to subscribers of that specific loop is affected.
Secondly, Hughes does in fact offer genuine QoS for business and enterprise customers. But what we consumer grade pukes get is a QoS mimic - I think they call IPoS (IP over Satellite). For Q0S to be meaningful, it has to be a function of the subscriber modem. I can email you a dump of my entire modem stat file, you won't find QoS anywhere.
I'm guessing that's what your system may be interpreting as QoS, may be little more than IPoS spoofing
/greg/
Well, that may well be your interpretation of QoS. But within the satellite infrastructure there is a defined QoS architecture. WRT your definition then, we return to the inarguable fact that your upload test files are too short. Download speeds have seldom been an issue with satellite VoIP. Where they fail is almost exclusively on the upload side.QOS is a rating of the providers ability to provide a consistent download capacity
Well, that's the simple explanation. But from that perspective, it goes back to the inarguable fact that your upload test files are too short. Download speeds have seldom been an issue with satellite VoIP. Where they fail is almost exclusively on the upload side.
//greg//
Well, one of us is missing something - that's for sure. What I'm seeing is about a 5 second transfer time, I'm guessing no more than one 30k file.If you're using the correct test those values are dynamic, not fixed. You'll notice the upload portion goes through a number of attempts with varied payload sizes (each increasingly larger).
Well, that's your interpretation of QoS. But from that perspective, it goes back to the inarguable fact that your upload test files are too short. Download speeds have seldom been an issue with satellite VoIP. Where they fail is almost exclusively on the upload side.
//greg//
Well, one of us is missing something - that's for sure. What I'm seeing is about a 5 second transfer time, I'm guessing no more than one 30k file.
//greg//