| Welcome to SatelliteGuys.US - America's Most Popular Satellite Information Forum!!
You are currently viewing our forums as a guest which gives you limited access. By joining our free community you will have access to post & reply messages in our forum, play in our fun arcade and communicate privately with other members as well as enjoy many other members only features.
Also as a registered member you will also see much less advertising!
Registration is fast, simple and absolutely free so please, join our community today!
If you have any problems with the registration process or your account login, please contact us.
CLICK HERE TO REGISTER! |  | | 
05-11-2009, 06:15 PM
|  | SatelliteGuys Regular | | Join Date: May 10th, 2009 Location: Tampa Florida
Posts: 56
| | Quote:
Originally Posted by grohgreg 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// | For the purpose of testing I've changed the codec to G.729 and will leave it that way until I can spend a few minutes and build a sat only test late tonight. I'll also post the codecs we can switch to on the fly (without building them later, kind of busy atm)
| 
05-11-2009, 06:35 PM
|  | SatelliteGuys Regular | | Join Date: May 10th, 2009 Location: Tampa Florida
Posts: 56
| | |
Here are the codecs can instantly change to without a build.
G. 711 (64 kbps)
G. 729 (8 kbps)
G. 723.1 (6.3 kbps)
G. 723.1 (5.3 kbps)
G. 726 (32 kbps)
G. 726 (24 kbps)
G. 728 (16 kpbs)
Now to decide which would be more appropriate. Also need to check if single audio channel or concurrent sep. channels is best. The test duration has been increased from 10 to 25 seconds. For satellite users I may increase that to 45 seconds for grins.
| 
05-11-2009, 06:51 PM
| | SatelliteGuys Regular | | Join Date: Aug 21st, 2008 Location: Dawson Springs, KY
Posts: 205
| | Quote:
Originally Posted by Bandwidth 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/
| 
05-11-2009, 07:05 PM
|  | SatelliteGuys Regular | | Join Date: May 10th, 2009 Location: Tampa Florida
Posts: 56
| | Quote:
Originally Posted by grohgreg 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/ | Some clarification...
From the standpoint of calculation QOS is simple to calculate.
QOS is a rating of the providers ability to provide a consistent download capacity which is the minimum speed observed during a large download divided by the maximum speed observed, the result in percent being 0 to 100. Variation in the download rate will result in a lower QOS. QOS is independent of line speed and measures line quality not line speed. Where it becomes complex is trying to add in variables for satellite exclusive.
| 
05-11-2009, 07:36 PM
| | SatelliteGuys Regular | | Join Date: Aug 21st, 2008 Location: Dawson Springs, KY
Posts: 205
| | Quote:
Originally Posted by Bandwidth QOS is a rating of the providers ability to provide a consistent download capacity | 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.
//greg//
| 
05-11-2009, 07:37 PM
|  | SatelliteGuys Regular | | Join Date: May 10th, 2009 Location: Tampa Florida
Posts: 56
| | |
After mulling this QOS will be left alone. If this one metric isn't acceptable nothing else matters. To make exceptions for satellite with this metric invalidates the remaining tests.
| 
05-11-2009, 07:40 PM
|  | SatelliteGuys Regular | | Join Date: May 10th, 2009 Location: Tampa Florida
Posts: 56
| | Quote:
Originally Posted by grohgreg 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// |
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).
| 
05-11-2009, 07:49 PM
| | SatelliteGuys Regular | | Join Date: Aug 21st, 2008 Location: Dawson Springs, KY
Posts: 205
| | Quote:
Originally Posted by Bandwidth 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, 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//
| 
05-11-2009, 07:54 PM
|  | SatelliteGuys Regular | | Join Date: May 10th, 2009 Location: Tampa Florida
Posts: 56
| | Quote:
Originally Posted by grohgreg 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// | Almost forgot. Thats not my interpretation. That's in fact how the QOS is derived for these tests. These factors were selected by experts in the broadband industry far more intelligent than the two of us and integrated into this engine.
I disagree on your statement about download speeds. It's not speed that is the issue with satellite voip. It's the quality of the available data, jitter, loss etc. Hate to say it but satellite may be great for surfing but it doesn't provide a consistent long term stream of data. I bet once the tests are done this will be proven quickly. Flipping this around if the last results posted in this thread can be consistent for that bird then yes, a voip conversation of some flavor is reasonable if you can tolerate the latency.
| 
05-11-2009, 08:04 PM
|  | SatelliteGuys Regular | | Join Date: May 10th, 2009 Location: Tampa Florida
Posts: 56
| | Quote:
Originally Posted by grohgreg 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// | Greg please don't play games. I just pulled the connection logs and the only tests recently peformed were two 6:52pm and 6:55pm from the the previous poster who posted his results here. No other satellite originated tests have been issued to anyone else in the recent since 4:47pm today. I can post the link to the reporting engine and everyone can see as well if you want.
Now pull some legit tests and lets have an honest discussion. Otherwise please stop wasting everyones time.
| | Thread Tools | Search this Thread | | | | | Display Modes | Linear Mode |
Posting Rules
| You may not post new threads You may not post replies You may not post attachments You may not edit your posts HTML code is Off | | | All times are GMT -5. The time now is 06:51 PM. |