Contention Ratios, TC Traffic Control, iD3100

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

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

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? 

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!  

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.

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