Дорогие товарищи меридианщики, у некоторых из вас емкость станции постоянно раширяется, как и у меня. Лично я сталкиваюсь с проблемой правильного анализа трафика.
1. Есть поток в город, визуальные наблюдения дают понять что направление надо расширять, но анализируя отчеты трафика в LD 2, где в ЧНН нагрузка достигает всего лишь до 0,65 Эрл на одну СЛ в среднем мне кажется что добавлять СЛ-ки нет надобности. Может кто-нибудь объяснить причину столь малых количественных показателей, и как правильно понимать эти отчеты.
2. Еще есть такие штуки как CR. Визуальное наблюдение за ними ни к чему не приводит. Они то занимаются на 90 процентов и более, то тут же освобождаются до 5 процентов. Можно ли как нибудь с помощью отчетов в LD 2 анализировать их достаточность.

Лучше всего поставить билинговую програму и проанализировать CDR. Демку можно взять здесь http://atlas.itl.net.ua/Billing/demo/absp3.zip. Работает месяц, заточена под Меридиан

CDR не дает реальной картины т.к., не показывает звонки, соединение по которым не прошло (не no aswer).
Как-то делали тест - анализировали нагрузку на PRI по сообщениям DCH - от сетапа до релиза. Тест показал, что и CDR занижает нагрузку, а LD2 врет еще сильнее - до 2 раз!
Если найти нужный "коэффициент вранья" для LD2, то можно подсчитать и реальную нагрузку, но он имеет такую специфику - фиксировать данные по транку после его освобождения - точность растет с уменьшением продолжительности звонков и увеличением их числа.

Пардон!
А какие неуспешные и НЕ неотвеченные звонки должен показывать CDR, особенно на PRI?
И какую нагрузку на каналы они создают,
чтобы ее учитывать в траффик репортах?

1. Если настроено и анализируется правильно, то врать не должно. Прецедентов не было.
2. Лучше всего, чтобы CR было более чем достаточно. Какой тип машины, какой софт, что в промте NCR? Да, и в TFS004 - есть "CR overflow peg count"...

Например ошибки протокола, или сетевой коммутации. Кроме того, звонок в CDR начинается после поднятия трубки, или, для time to aswer и no answer, после прихода цифр и выбора ТА для звонка. На R1.5, к примеру, ошибок протокола бывает много, а каналы это занимает. А еще lockout - звонить по такому транку все равно нельзя.

2Karter:
что понимать под "настроено" по отношению к LD2? В доке всего пару параметров, таких как "trunk seizer option". После установки ошибка уменьшилась, но не исчезла. Пример.: есть городской канал R1.5 (MFS*2+DP*3). Бывают времена, когда заняты все каналы и это сохраняется несколько часов (шквал звонков в техподдержку). В LD60 как не посмотришь, не найти ни одного IDLE и прозвониться по этому каналу сложно, а LD2 говорит, что в те часы была нагрузка ~0.5 (по CCS) от теоретического придела. Как это объяснить?

Цитирую свой вопрос: "...особенно на PRI?".
Хотя, судя по ответу, намек и так понят и тема аккуратно замята...

Цитата:
"CDR не дает реальной картины т.к., не показывает звонки, соединение по которым не прошло (не no aswer). Как-то делали тест - анализировали нагрузку на PRI по сообщениям DCH - от сетапа до релиза...CDR занижает нагрузку...". Первое утверждение черезвычайно слабо коррелирует со вторым.
Если бы было заявлено, что: "Как-то делали тест - анализировали нагрузку на DTI...CDR занижает нагрузку..." - вопроса бы, естественно, не было.

Да, эта "пара параметров" - очень нужная.
Важен еще и анализ.
CCS из TFS001?

Похоже, что мы друг друга где-то не поняли.

> Пардон!
> А какие неуспешные и НЕ неотвеченные звонки должен показывать CDR,
> особенно на PRI?
1) "Неуспешные": а) пришли цифры, которые неудается промаршрутизировать; б) при транзите какая-либо ошибка произошла на другом коммутаторе в цепи.
Они, конечно, в CDR не попадут.
2) Разве неотвеченый звонок на ТА нельзя фиксировать в CDR?
>> CDR не дает реальной картины т.к., не показывает звонки, соединение
>>по которым не прошло (не no aswer).
Читать стоит так: звонки с несостоявшимся разговором, исключая тех, что дошли до ТА (на этой станции), но не были отвечены.

> И какую нагрузку на каналы они создают,
> чтобы ее учитывать в траффик репортах?
По логике, небольшой процент от общего...

Теста было два:
1) Описанный мной DTI на R1.5: по TFS002 получалось меньше чем по CDR.
2) PRI: вычисляли нагрузку по сообщениям DCH (время бралось из текста сообщения) и сравнивали с CDR и TFC002 - по сообщениям получается несколько больше чем в CDR и еще больще чем LD2. В маршруте ABAN yes. В CFN TPO и TSO yes.

Да TFS001 дает немного другие цифры, но не всегда большие чем соотв. им в TFC002. Видимо специфика.

Тема ведь определении реальной нагрузки, а получается, что CDR занижает, TFC002 тоже.
Насчет TFS001 у меня тоже есть сомнения - при тех же забитых входящих транках показывал 0.4-0.5 от теор.максимума. После устанновки TPO и TSO цифры увеличились, но все равно выглядят нереальными.

Отсюда вывод:

1. TFC002 верить нельзя, или можно, если известен поправочный коэффициент вранья для своей АТС. И никаких точных цифр для анализа загруженности направления невозможно получить.
2. Для анализа CR может поможет отчет TFS004. Я пробовал выключать половину CR, для того чтобы создать нехватку этих приборов, но постоянно забывал вовремя распечатать этот отчет. (Для разового случая не хотел его включать в расписание отчетов). Поэтому пока не могу точно сказать что он действительно покажет нехватку CR.

Почему "не поняли"?
Началось все с поста, в котором понятие DTI не фигурирует СОВСЕМ, а упоминается ТОЛЬКО PRI. При этом утверждается, что CDR не даст картины загруженности из-за отсутствия в нем "сбойных" звонков. Но смешивать мух и котлеты не нужно: данное утверждение справедливо для DTI. В следующем посте ты и поправился, уже не упоминая PRI АБСОЛЮТНО, зато разжевывая мне и так совершенно очевидные вещи.
Еще раз повторю вопрос: зачем биллингу попытки соединения, даже не занимавшие Б-канал? Очевидно - незачем. Траффику эти данные по PRI тоже не интересны. Для этого существует отдельный репорт по загруженности Д-каналов.
Для сигнализаций, использующих акустический канал для обмена, неуспешные (сбойные) звонки, естественно, интересны создаваемой ими нагрузкой.
Но, в приведенном случае с PRI, CDR может занижать нагрузку только по двум абсолютно корректным причинам:
- не учитываемость времени между alert и connect, например;
- настройка обмена на трансляцию акустических busy, fastbusy. Вторая причина - устранима. Соответственно: в случае с PRI неуспешные не неотвеченные звонки не являются основной причиной неточности CDR, как инструмента анализа нагрузки.

Что касается traffic report'ов. Обвинение в их неточности - очень серьезное. Имея опыт контроля нагрузки на паре тысяч потоков, осмелюсь утверждать, что случаев занижения нагрузки не отмечается.
Очень хочется взглянуть на TFC002 по подозреваемому в перегрузках маршруту.
Особенно на:
- trunks equipped;
- trunks working;
- inc usage;
- ogt usage;
- ogt overflow;
- all trunks busy.

Выводы делать рано.

1. Выложи TFC002 по проблемному маршруту.
2. Не "может", а ТОЧНО поможет.
Что значит "выключачать половину CR"? Как делал?
Сокращение количества Call Registers в два раза - совершенно не означает, что их станет не хватать. Их у тебя может быть запрограммировано раз в пять больше, чем надо. Посему спрошу еще раз: какая станция, какой софт, какое значение NCR в PARM в LD 22?

Кстати CR - это не приборы. Это область оперативной памяти.

Насчет мух... К примеру, если Меридиан послал в dch setup с указанием 30-го канала, то канал физически еще не занят, но и логически не свободен. Разве станет посылать Меридиан еще один setup с тем же каналом? Сомневаюсь что и ответная сторона, после приема этого setup-а будет так поступать (коллизии не всчет). Т.е., физической коммутации еще нет, а канал уже зарезервирован.

===========

Вот по этому маршруту сегодня были перегрузки. Loop 48, route 102 (R2 DTMF). Перегруженных PRI, к сожалению, нету.
------
0001 TFS102

048 0000642 00540

------ TFS001:
048 TERM 00000 0000000 00000 00000 0000642 00587

----- TFC002:
102 TIE

00030 00030

0000458 00672
0000174 00127
00000 00000
00000
0000000 00000
--------

Использую простую формулу: (inc_usage + ogt_usage)/(trunks*36).
По TFS001 получается 0.5944, а по TFC002 получается 0.5851.
Поток был сильно нагружен. TFS102 говорит, что он был "all trunks busy" 54% времени, иными словами на 0.54 часа пришлось 100% нагрузки.
0.5944-0.54=0.0544
0.5851-0.54=0.0451
Что-то малова-то. Т.е. на остальные 46% времени пришлось всего 4-5% нагрузки?

Немного не в тему, но давно хотел спросить. CR используются только в процессе проключения звонка или еще для чего то? В частности увеличивается ли кол-во используемых CR при включении монитора D-канала?

Прошу прощения за ламерство, но я попутал две вещи, это CR и Приемники тонов. Мне очень стыдно за себя. Они оба для меня остаются неизученной областью и тем не менее оба меня инетересуют.

Выключал половину - это Тон детекторы, а затем смотрел в TFS004 перегрузку CR. Анекдот просто какой-то... :)


1. ld22 - PARM - NCR 10000
Станция 81С опция, 25.15 релиз
Мне кажется что это много для моей станции, когда аналоговых окончаний около 900 портов, и цифровых СЛ около 600 портов.

Вот TFS по проблемному маршруту:
004 TIE

00180 00180

0002257 02140
0001502 01363
00000 00000
00000

Получается 0,58 Эрл на одну СЛ в среднем за час

Когда я разговаривал с тех.поддержкой мне сказали что на системные отчеты смотреть не надо так как они кроме разговоров могут показывать еще много чего. А вот пользовательские и сетевые - это то что нам следует смотреть.

Мухой :))
Пошли в Д-канал сетап с вызовом на несуществующий номер и посмотри как долго будет "логически не свободен" Б-канальчик.
==============
"TFS102 говорит, что он был "all trunks busy" 54% времени" - это, простите, откуда?

Много для чего. При формировании CDR, при различных видах мониторинга итд итп...

В общем-то, совершенно верно. Системные почти всегда завышают нагрузку.

1. Лучше довести количество тысяч до 15.
На CP4, например, и 30000 - не упор.

2. Перегрузок здесь быть не должно. Каналов 140 должно хватать.
Как делаются "визуальные наблюдения"?
Лучше всего в LD 80 пользовать команду
trac 0 <ACOD маршрута>.

Каюсь, с TFS102 напутал... Видимо жара ;)
Тогда тот последний абзац неверен.
Там остается только вопрос - почему на постоянно перегруженном (в тот замер в LD60 от был целиком занят - и до часа проверки, и после) лупе нагрузка всего ~0.59?

А про мух: при звонке между двумя станциями ответ придет быстро.
При транзите же прийдет позже. А при транзите в другие, не ISDN, сети - еще позже.

Коллеги подскажите пожалуйста. Как и по какой формуле считать эти Erlang-и и на сколько процентов он был загружен пик нагрузки. Перелапатил целую кучу документации и ничего не понял ( опыта нехватает), а начальство строгое.
118 TIE

00030 00030

0008496 05721
0006786 05271
00164 00000
00000

И какое соотношение PRI потоков и Erlang-ов.
А то скоро в городскую станцию втыкаться а я даже примерно не могу сказать начальству сколько потоков надо готовить, а сеть у нас большая 8-ем станций и все в город будут вклиниватся через 61C узловую.

150 абонентов на поток. При увеличении количества абоненов, пропорция изменяется в сторону увеличения количества абонентов на поток.

Ну почитав на форуме это я уже понял, а вот с нагрузкой наканалы уже действующих потокав я не как ни могу определится начальство хотит знать. По этому большая просьба КОЛЛЕГИ помогите разобраться в Erlangs-ми да c формулами по которым их считают.

Зайди в ПОИСК по форуму АТС, набери TFC002.