Satellite Internet forum
https://www.satsig.net/cgi-bin/yabb/YaBB.pl
VSAT technology and installation >> iDirect Forum: hubs and terminals >> Contention Ratios, TC Traffic Control, iD3100
https://www.satsig.net/cgi-bin/yabb/YaBB.pl?num=1212963234

Message started by slashnul on Jun 8th, 2008 at 11:13pm

Title: Contention Ratios, TC Traffic Control, iD3100
Post by slashnul on 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

Title: Re: Contention Ratios, TC Traffic Control, iD3100
Post by TDMAMike on 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

Title: Re: Contention Ratios, TC Traffic Control, iD3100
Post by slashnul on 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.

Title: Re: Contention Ratios, TC Traffic Control, iD3100
Post by TDMAMike on Jun 9th, 2008 at 2:19am
Legendary....lol.....not hardly.  Just trying to help out where I can. :)

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


Title: Re: Contention Ratios, TC Traffic Control, iD3100
Post by slashnul on 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

Title: Re: Contention Ratios, TC Traffic Control, iD3100
Post by TDMAMike on 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?  :)


Title: Re: Contention Ratios, TC Traffic Control, iD3100
Post by slashnul on 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

Title: Re: Contention Ratios, TC Traffic Control, iD3100
Post by TDMAMike on 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!  

Title: Re: Contention Ratios, TC Traffic Control, iD3100
Post by tunde300us on 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

Title: Re: Contention Ratios, TC Traffic Control, iD3100
Post by slashnul on 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.

Title: Re: Contention Ratios, TC Traffic Control, iD3100
Post by TDMAMike on Jun 11th, 2008 at 11:56am
tunde, Are you certain you are set up for iSCPC?  

Title: Re: Contention Ratios, TC Traffic Control, iD3100
Post by tunde300us on 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

Title: Re: Contention Ratios, TC Traffic Control, iD3100
Post by TDMAMike on 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.  :)

Powered by YaBB 2.5.2!
YaBB Forum Software © 2000-. All Rights Reserved.