Advertisment: Broadband via satellite
Advertisment: Worldwide satellite services from Ground Control Company

Satellite Internet Forum.

Welcome, Guest.        Forum rules.
      Home            Login            Register          
Pages: 1

iDirect 3000 Modem setting for dedicated service?

(Read 3964 times)

Posts: 2
Apr 17th, 2009 at 1:08pm  
Our satellite provider currently has us on a dedicated service of 512 Kbps Down and 512 Kbps Up.  While connected through iSite (version into the iDirect 3000 modem, I have done several "IP Stats", View, to check our total bandwidth.  While I have our client machines downloading  as much as possible, we show a total (HTTP, UDP, and TCP) of about 512 Kbps.  So I know we are good there with our dedicated Down.

However, while I have our client machines uploading as much as they can (files, pictures, videos) to web sites, the upstream, as seen in iSite, only totals at a maximum of about 350 Kbps!

Also, I have noticed that when I go into iSite, "Settings and Statistics", Modem Parameters, the "Demodulator" mode is set to SCPC (single channel per carrier) which is correct since that is what is advertised here

However, the "Modulator" mode is set to TDMA (time division multiple access).  And I don't have the ability to change the field to see the other options (grayed out).

Could this be something that was overlooked by our provider?  We should be getting SCPC on both the UP and the DOWN if I am not mistaken.  That is what the website linked above suggests.  And that might explain why we don't get the full 512 Kbps UP yet the DOWN is fine.

Any suggestion on how I might proceed?  Upstream is very important to us because we have several clients using VOIP (skype, MSN, Yahoo) with video.


Back to top
IP Logged
Ex Member
Ex Member

Reply #1 - Apr 17th, 2009 at 1:36pm  
Joe, if you are using a 3100 iDirect modem you are using an SCPC (TDM) Downstream carrier (hence your demod is set to SCPC) and your upstreams are MF-TDMA (D-TDMA). The 3100 will not do iSCPC.

Your upstream throughput is probably falling short in Kbps due to the satellite overhead required for TDMA.  The iDirect uses a certain amount of overhead for the satellite transport (TDMA trailers, unique words, SAR, PAD, etc).  So, it is quite possible that the bit rate of your ISPs upstream carrier is 512k, but you will more than likely not see that kind of throughput due to coding.  You can get CLOSE to that bit rate (90%) with the proper coding (long block 4096...ex .793 FEC) but it is unlikely you will see the full 512.  

The actually rate (observed throughput) will vary depending on the type of upstream coding they  are using (.5, .66, .793).  With 350k of observe throughput (and you state you have a CIR of 512 for dedicated service) I am guessing that your upstream coding is .5 or .66 (short block).

Look at your options file and provide me with the following blocks (cut and paste):


Please do not provide me with your entire options file with IPs, etc.

If your options file reflects .793 and your bit rates reflect better than 512k then there is obviously something else going on, but we will take it one step at a time.
Back to top
IP Logged

Posts: 2
Reply #2 - Apr 17th, 2009 at 10:20pm  
Thanks for the prompt and detailed response.  Here is the requested data.

       data_port = 0
       loopback = 0
       interface_type = 0
       rx_freq = 1107620000
       rx_acqrange = 1800000
       rx_bitrate = 8579389
       rx_mode = 2
       rx_modtype = 1
       rx_fecrate = 15
       rx_scram = 1
       rx_diff = 0
       rx_specinv = 0
       tx_freq = 1000000000
       tx_bitrate = 1690000
       tx_mode = 0
       tx_modtype = 1
       tx_clksource = 0
       tx_fecrate = 5
       tx_scram = 1
       tx_diff = 0
       tx_specinv = 0
       tx_power_in_dbm = -8.000000
       rx_fsd = 147865
       tx_spreading_factor = 1
       rx_spreading_factor = 1
       is_demod2_active = 0

       fsd = 118834

       power_uplink_control_processing = 1
       max_power_level_in_db = -2.000000

       music_present = 0
       odu_rx_dc_power = 1
       odu_rx_10_mhz = 0
       odu_tx_dc_power = 1
       odu_tx_10_mhz = 1
       odu_disable_tx_pwm = 0

       tx_watchdog_timeout_in_frames = 2

       fec_blocks_per_outroute_frame = 330
       unique_word_len_downstream = 32
       symbols_per_inroute_frame = 159969
       outroute_fec_block_len = 512
       outroute_fec_type = 793
       inroute_fec_block_len = 128
       inroute_fec_type = 660
       unique_word_len = 32
       symbols_per_outroute_frame = 675871
       num_acq_slots = 1
       aperture_traffic = 8
       aperture_acq = 2196
       num_traffic_slots = 284
       payload = 512
       skip_slots = 3

and I am looking at Intelsat 10-02 with +56 degrees polarization.
Back to top
IP Logged
Ex Member
Ex Member

Reply #3 - Apr 17th, 2009 at 10:58pm  

Your Upstream coding is .66 and your return carrier bit rate is 1690 Kbps (entire carrier).  Unsure of just how many returns (and customers) your ISP has in the returns.  Of that 1690Kbps, you are payloaded for 512k of it (with your CIR).  I am not exactly sure why you are having trouble achieving the full 512k of that bit_rate when you are a CIR customer.  If the return was 512k in size and you were coded at .66, I could easily blame the coding but with a larger inbound (1690K) that is ruled out.  It is tough to diagnose/assess your issue without visibility of the network.

When you were throughput testing the upstreams, what protocols were you using to stretch that pipe?  RTP (video or voice)?  FTP?  Give me some background on what you were using to "load" your upstreams (attempting to achieve your CIR).  

Technically, with the proper tcp acceleration/enhancement, a single 20MB file transfer should take you to your upstream CIR threshold of 512k.  Are you using an acceleration (software or hardware) other than that provided by the iDirect? Using GRE tunnels?

You should also be aware that when you are using iSite to view IP stats, you are seeing BW stats collected/queried from the upstream side of the protocol processors.  Those stats are sampled AFTER the satellite overhead is stripped/removed.  If you want to see what you are truly putting over the air, you need visibility of the SAT Traffic (found in iMonitor at the Hub).  Cant remember if iSite allows you to look at SAT TRAFFIC, please check.  SAT Traffic BW stats (unlike IP Stats) are sampled/collected on the tunnel side (eth1) of the PPs at the hub...thus giving you visibility of your IP traffic with TDMA satellite overhead.
Back to top
« Last Edit: Apr 18th, 2009 at 1:56pm by N/A »  
IP Logged
Pages: 1