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

www.satsig.net

Satellite Internet Forum.

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

Contention Ratios, TC Traffic Control, iD3100

(Read 9891 times)
slashnul
Member
★★
Offline



Posts: 5
Jun 8th, 2008 at 11:13pm  
Im on a package with TS2, reported to be at 3072/768 20:1.  I have an iDirect 3100, which I have root (console) and admin (ssh/telnet) access to.  Behind the modem I have a linux router with tc (traffic control) running, with about 25 users doing various things.  TC does a good job of ensuring individual activities (web surfing, gaming, voip) each has their fair share of upload bandwidth.  But the problem is that the upstream bandwidth is so dynamic I never know what to tell TC I have.  I regularly fall below my contention ratio, and should probably complain to the ISP.  Actually, Id be happy if I was always at 38kbit (768/20).  While SSH'd into the modem I see the error messages:

eth0: TxQueue Saturated! [49/198 packets dropped]
or
eth0: TxQueue Saturated! [9/606 packets dropped]

So I assume this is me having my upstream bandwidth throttled.

And the packets dropped error messages are usually in conjunction with:

[438F] /tmp/3100.8838.pkg (7666) - Ignored (target-list).

From another post this last message is described as a package being pushed down to a client other than myself.  Maybe their bandwidth is being increased, and it shrinks mine?

Anyways, so my question is, is there any way of finding out what bandwidth my modem is currently allocated?  Im talking real-time factual, not ISP contention ratio, best effort stuff.

I want to write a script on the modem that'll signal my linux TC firewall to slow or speed my users up according to my modem's current capabilities.

Thanks in advance
Back to top
 
 
IP Logged
 
Ex Member
Ex Member


Reply #1 - Jun 9th, 2008 at 1:21am  
As you probably know, your modem requests BW based on application demand, therefore it is never constant.

There are certainly ways of dissecting your options file to determine your MIR and CIRs (shaping limits)....but they are just that: configed rate shapes....and have little to do with demand and allocation.  Therefore, that is pretty much a waste of time (unless you want to know your max or committed info rates).

Actual Demand and Allocation are fulfilled by two Linux processes on the protocol Processor blades at the Hub (namely the SADA and SANA processes).  Your modem requests BW and the processes issue the BW (using a couple different algorithms...ie, legacy fairness, etc).  Those alg's are configs that are on the Hub and cannot be implemented by the end user (no help there, hope your ISP is on top of his game).

Your complaint (fair share of upload BW) is the very reason why QoS should be implimented on the satellite router (if possible) as it is the only appliance in the chain that KNOWS the true utilization on the link at any given time (one of the challenges of the the dynamic allocation we speak of in a TDMA environment).  The ISP is the keeper of such QoS and it is up to them to design those traffic profiles accordingly.

As for your question: There are certainly tools to observe near real-time allocation but they are normally only used at the Hub (iMonitor) and are not handed out to the end user.  The one thing that you may be able to do is use iSite (for your iDS version) and view the IP stats there (if you have admin privs to use iSite).  That will get you close to the real time values that you are looking for.

Also, in the past when I have observed TX Queue Saturation, there were several possibilities as to what it could be,  but the first thing I would check are your physical connections.  That error is common with a bad piece of Cat-5 prior to your 3100 (in your baseband).  There are a few other possibilities but I would start there and see if it goes away.  If it doesn’t, reply to this thread and we will dig deeper.  

As for that .pkg, that is a config that is being pushed to another 3100 customer (via multicast) in the same network as you.  As you can see it is being ignored by your 3100.  

Have a good one...

r/
M
Back to top
« Last Edit: Jun 9th, 2008 at 11:36am by N/A »  
 
IP Logged
 
slashnul
Member
★★
Offline



Posts: 5
Reply #2 - Jun 9th, 2008 at 2:02am  
Wow such a quick reply, and from the legendary TDAMike of all people (=

Thanks for the information.  I think I have a version of iSite, iMonitor, and iBuilder somewhere.  Ill fire them up.  On my ToDo list is get SNMP enabled on the iDirect modem, that'll integrate better when the tools I use.

Currently to estimate my upstream bandwidth is with a simple ping.  If I ping the first hop after the satellite (the hub?), and the latency is high, then Ill turn down the upstream.  Im not sure how to do it yet, but I can probably get the output of ping to effect some numbers in the TC configuration.

Im going on leave for 30 days and wanna get things hardy before I go.

Thanks for the info.
Back to top
 
 
IP Logged
 
Ex Member
Ex Member


Reply #3 - Jun 9th, 2008 at 2:19am  
Legendary....lol.....not hardly.  Just trying to help out where I can. Smiley

Are you an ADMIN for the network you are on?  I am assuming you have login credentials for iMonitor and/or iBuilder?  If so, you are golden!  Let me try to understand this.  You are using ICMP to gauge throttling for the TC?  So if your RTTs increase you back it out?  (be advised, if your RTTs are increasing you are more than likely running out of BW....ICMP will take a backseat in priority to operational traffic....that combined with you probably bouncing off your MIR is the result of the high latency...read: RTTs in excess of 600-700....maybe higher).

iMonitor should give you a snapshot of bw utilization across all of the nodes in your network.  Although it is a monitoring tool, it is still quite powerful.  

That first ping in your path back is more than likely is the Protocol Processor Blade handling your remote.  Also, you will want to troubleshoot that Queue saturation issue soon, as you are dropping packets like crazy.

Have fun with it....

M

Back to top
« Last Edit: Jun 9th, 2008 at 11:46am by N/A »  
 
IP Logged
 
slashnul
Member
★★
Offline



Posts: 5
Reply #4 - Jun 9th, 2008 at 10:40pm  
Dropped packets from eth0:
I have a suspicion that the dropped packets from eth0 tx is due to the relationship between my firewall and iDirect's TCP Acceleration.  I see dropped packets coinciding on both devices.  Just a hunch though.

I have login credentials for iSite, but not iMonitor or iBuilder.  I guess the ISP wouldnt want their customers that much control (=  Probably wise.  I was wondering why I couldnt login, I thought they were apps that went as far as my modem only.

To gauge my connection I use a script that executes ping 10 times with a 500 byte packet to my first hop, and MRTG graphs the RTT and packet loss %.  My RTT is usually 600-700ms, like you guessed.  When I get home from work, I check the graphs to see how the latency has been for everyone while I was gone.  If the latency goes over 1500ms, the gamers start to riot (thanks WoW).  Ive discovered that high latency is pretty much due to excessive upstream traffic, and very little downstream related.  So Ill just have the ping script I use change the TC variables, maybe at 10 minute intervals.

So you said ICMP will probably take a back seat to operational traffic?  Are there any other generalities that I should know about about satellite ISPs?  Sorry, this is my first.  Do they give a damn about TCP, UDP, or p2p stuff?

Thx
Back to top
 
 
IP Logged
 
Ex Member
Ex Member


Reply #5 - Jun 9th, 2008 at 11:14pm  
In previous iDS's (pre-8.0) ICMP would often take a backseat to the operational traffic, but in the more current iDS's (specifically in the GQoS iDS environments) iDirect has given NMS traffic the highest priority in the traffic queues (P1).  Therefore, you dont see ICMP stumbling in iDS's 8.X and above.

As for the GUIs (software tools).  Most ISPs would not even fathom handing out credentials to iMonitor (let alone iBuilder).  I am actually shocked they gave you admin privs with iSite (btw, did you see the IP stats in iSite?).   That is about as close as you are going to get to (near) real time utilzation on your 3100 (short of getting into iMonitor).

Regardless, it sounds like you have your stuff together.  Is that place going to survive without you for 30 days?  Smiley

Back to top
 
 
IP Logged
 
slashnul
Member
★★
Offline



Posts: 5
Reply #6 - Jun 10th, 2008 at 12:24am  
Thats the challenge, to last 30 days.  The modem and dish are my last worries, the bigger worry is from inside my network.  About 10 of my 25 users are 33Ws, the army's best trained in electronic warfare.  A few of them try to make names for themselves, by disrupting, spoofing, DOSing, etc.  Its all for fun, cause were on the same team.  So my TC/IPTables firewall is mostly concerned with the inside.

So in another post, someone asked for the best FAQs on iDirect/VSAT, and you pointed them to iDirect's TAC website.  It looked like a member only resource, and I didnt see a way to create an account.  Do you have to take one of their courses to gain access?  Id really like to know more about TDMA, and Id love to be able to tweak the iDirect modem.  It has support for QoS but I dont want to touch it unless I have some reference material.

Thanks
Back to top
 
 
IP Logged
 
Ex Member
Ex Member


Reply #7 - Jun 10th, 2008 at 11:57am  
The QoS you speak of has to be built on the Hub side and then applied to your satellite router.  So, the user is dependent on the provider to integrate and implement such policies to prioritize traffic before it is placed on the wire (naturally only effective in congested networks).

Access to the TAC is obtained through an iSupport agreement (you have to pay iDirect for it).  There is an incredible amount of data on that website (somewhat overwhelming) but all of the documentation for the network tools (iBuilder, iMonitor), firmware, etc is on that site.  There are also patches for the software (to fix certain bugs).  It is a pretty good site overall...just needs to be organized differently (it needs filtering tools to help you find pertinent info as there are so many iDS's these days).

I hear ya (regarding the 33Ws).  When people get bored, they have a mysterious way of finding something to do!  
Back to top
 
 
IP Logged
 
tunde300us
Senior Member
★★★
Offline



Posts: 62
Reply #8 - Jun 11th, 2008 at 8:17am  
Hi guys,
Please i need some clarification here,if i get a 128/64 dedicated SCPC bandwidth from my ISP.When i am on my laptop alone and i want to do a download,please what download speed should i expect from my download manager at all times especially when  am  connected to the modem alone.
Thanks
Back to top
 
 
IP Logged
 
slashnul
Member
★★
Offline



Posts: 5
Reply #9 - Jun 11th, 2008 at 9:09am  
128/64 = 16.384 kBytes a second down, 8.192 kBytes a second up. 

Add in protocol overhead and you might see 13kB/s down, 4kB/s up.

If youre downloading from  a website or ftp site, I'd guess you could expect 13kB/s down.  But less is doing bittorrent.

Thats my guess.
Back to top
 
 
IP Logged
 
Ex Member
Ex Member


Reply #10 - Jun 11th, 2008 at 11:56am  
tunde, Are you certain you are set up for iSCPC?
Back to top
 
 
IP Logged
 
tunde300us
Senior Member
★★★
Offline



Posts: 62
Reply #11 - Jun 11th, 2008 at 2:04pm  
Hi mike,
Y did u ask if i was on an SCPC link,i tut when you are on a dedicated link it is referred to as SCPC,please correct me if i am wrong
Back to top
 
 
IP Logged
 
Ex Member
Ex Member


Reply #12 - Jun 12th, 2008 at 12:59am  
Dedicated SCPC in iDirect lingo (read: you use an iDirect satellite router for SCPC) is normally referred to as iSCPC.  Smiley
Back to top
 
 
IP Logged
 
Pages: 1