FAQ по Rockwell Software. Общие вопросы

• В чем разница между "Utilization" и "Scheduled Utilization"?
• Что нужно сделать для повышения эффективности моделирования?

Вопрос: В чем разница между "Utilization" и "Scheduled Utilization"?

Ответ:

Arena может создавать статистику по двум различным уровням использования, называемым Utilization и Scheduled Utilization.

Utilization определяется по величине уровня использования (например, такой, как Number Busy / Number Scheduled (Количество занятых / Количество запланированных)) в каждый момент времени с последующим вычислением средне-взвешенного по времени. Такая практика наиболее подходит при анализе минимальных и максимальных значений или при отслеживании уровня использования по времени (например, с помощью графика). Но к среднему значению подобной статистики необходимо относиться достаточно осторожно, по приведенным ниже причинам.

Scheduled Utilization вычисляется с помощью деления среднего количества занятых на среднее количество запланированных, с формированием одиночного статистического показателя. Это наиболее подходит в случае работы с одиночным кумулятивным показателем уровня использования, в частности, если количество запланированных меняется со временем. Но так как в данном случае мы имеем дело с кумулятивной статистикой, промежуточные наблюдения для количества запланированных отсутствуют, в отличие от того, что представлено в таблице.

Эти два метода вычислений выглядят похожими, и на практике иногда дают идентичные результаты (см. приведенный ниже Пример A). Тем не менее эти методы различны и должны использоваться в соответствующих случаях.

Одним из различий является то, как подсчитывается меняющееся количество запланированных. Уровень использования не отражает относительной интенсивности изменений в количестве запланированных. Наиболее просто это проиллюстрировано в примере В. Когда количество занятых равно нулю, уровень использования тоже равен нулю, несмотря на интенсивность количества запланированных. Как проиллюстрировано на результатах примера B, в то время как этот показатель хорош для просмотра уровня использования в любой момент времени, критерий Utilization возможно не подойдет, если вам необходимо проверить кумулятивный средний уровень использования по отношению к цене ваших ресурсов во времени.

Сравните приведенные ниже примеры A, B и C. Даже в том случае, когда общее количество занятых рабочих часов равно количеству запланированных, критерий Utilization может различаться, так как он представляет среднее индивидуальных периодов. Это снова подтверждает, что если вам необходимо рассмотреть отдельный кумулятивный показатель уровня использования, особенно по отношению к общему потреблению ресурсов, то критерий Scheduled Utilization зачастую будет являться лучшим выбором.

Рассмотрите следующие примеры, приведенные с расчетом 8-ми часового разбиения по периоду из двух 4-часовых смен.

Пример A: У нас есть 150 рабочих, доступных во время 8-часового периода, а 50 из них заняты все 8 часов.

Пример B: У нас есть 200 рабочих, доступных на 4 часа, и затем 100 рабочих доступны на следующие 4 часа. Первые 4 часа все 100 рабочих находятся в состоянии ожидания, а затем заняты в последующие 4 часа.

Пример C: У нас есть 200 рабочих, доступных на 4 часа, и затем 100 рабочих доступны на последующие 4 часа. 50 рабочих заняты все 8 часов.

		Пример A		Пример B		Пример C
Сценарий:	4-часовая смена	1	2	1	2	1	2
	# Занятые # Запланированные Уровень использования	50 150 33.33%	50 150 33.33%	0 200 0%	100 100 100%	50 200 25%	50 100 50%
Общее количество занятых часов		(50*8) = 400		((0*4)+(100*4)) = 400		(50*8) = 400
Общее количество запланированных часов		(150*8) = 1200		((200*4)+(100*4)) = 1200		((200*4)+(100*4)) = 1200
Среднее число занятых		(50*8)/8 = 50		((0*4)+(100*4))/8 = 50		(50*8)/8 = 50
Среднее число запланированных		(150*8)/8 = 150		((200*4)+(100*4))/8 = 150		((200*4)+(100*4))/8 = 150
Scheduled Utilization		50/150 = 33.33%		50/150 = 33.33%		50/150 = 33.33%
Utilization		(33.33%*8)/8 = 33.33%		((0%*4)+(100*4))/8 = 50%		((25%*4)+(50%*4))/8 = 37.5%

Существует еще одно тонкое различие между критериями Scheduled Utilization и Utilization, которое может проявиться в одних и тех же ситуациях. В зависимости от выбранного Schedule Rule (правила планирования), можно указать, что в некоторые моменты времени у вас могут быть занятые ресурсы, не являющиеся запланированными. Если выбрано любое правило, исключая Wait (ожидание), то можно сделать так, чтобы ресурс был занят в конце своего запланированного периода, и оставался занятым в течение времени, требуемого для завершения обработки этой сущности. В этой ситуации показатель Utilization будет равен 100% и вследствие этого, этот показатель никогда не станет больше 100%. Так как Scheduled Utilization является кумулятивным, этот переходный период будет помечен как временно занятый, даже если он не запланирован. Это, в свою очередь, может привести к величине показателя Scheduled Utilization больше 100%.

23.03.06

Вопрос: Что нужно сделать для повышения эффективности моделирования?

Ответ:

Файлы SMARTs являются прекрасным справочным материалом как для новичков, так и для опытных пользователей системы Arena. Эти файлы, находящиеся в каталоге SMARTS системы Arena, были созданы Rockwell Software с целью предоставления примеров наиболее часто используемых сценариев моделирования. Они также предоставляют пользователю возможность быстрого ознакомления с некоторыми более сложными возможностями Arena, а также с VBA, функциональностью Module Data Transfer и т.д.

Эффективное моделирование

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

Режим выполнения

Выполнение с анимацией может быть довольно медленным.

• Увеличьте фактор масштабирования до максимально приемлемого значения (хотя это и сделает анимацию "грубой").
• Выполнение в режиме "fast forward" быстрее, но вместе с тем сохраняет анимационные данные.
• Выполнение с отключенной анимацией еще быстрее.
• Выполнение в командном режиме (без взаимодействия с графической подсистемой) является самым быстрым.

Статистика

• Отключите неиспользуемую статистику. Если вы не намереваетесь использовать статистику (или закончили работать с ней), не собирайте ее.
• Не собирайте статистику в выходной файл, если это не нужно для последующего анализа.
• DSTATS для выражений занимает больше времени, чем для общих системных переменных (таких как NQ, NR, MR, LT, …).
• FREQUENCIES для выражений занимает больше времени, чем для STATE ресурсов.
• Используйте OUTPUTS для выполнения отдельного вычисления в конце репликации вместо того, чтобы выполнять то же самое вычисление повторно во время выполнения.

Блоки

• Для замены множественных блоков используйте многострочные блоки. Например, оператор ASSIGN с тремя присваиваниями выполняется быстрее, чем три оператора ASSIGN, выполняющих три последовательных присваивания.
• SCAN - выражение scan вычисляется каждый раз, когда SCAN встречает сущность. Таким образом эффект SCAN зависит главным образом от того, насколько часто к нему обращаются, и в меньшей степени от сложности выражения. Одиночный оператор SCAN вряд ли окажет какое-либо ощутимое влияние на модель, но в модели с многими операторами SCAN со сложными выражениями замедление может быть ощутимым. Если вам необходимо заменить операторы SCAN, эта ситуация часто может быть промоделирована с использованием комбинации WAIT, SIGNAL и BRANCH.

Конвейеры

Накопительные конвейеры предоставляют значительно большую гибкость чем стандартные, но за это приходится платить некоторой скоростью выполнения.

• Не используйте накопительные конвейеры до тех пор, пока эта функциональность не будет по-настоящему необходима, но если это так, то не существует более быстрого пути накопления при моделировании.

Транспортеры

Управляемые транспортеры обеспечивают значительно большую гибкость, чем транспортеры со свободным путем, но за это приходится платить некоторой скоростью выполнения.

• Не используйте управляемые транспортеры до тех пор, пока эта функциональность не будет по-настоящему необходима, но если это так, то не существует более быстрого пути моделирования движения транспортных средств по сетям с ограничениями.

Использование выражений

• Использование фиксированных правил, имен или констант является более быстрым, чем использование атрибутов сущностей. Использование атрибутов сущностей является более быстрым, чем использование выражений.
• В качестве примера можно рассмотреть скорость выполнения очередей: LIFO или FIFO будет самым быстрым, LVF или HVF для атрибута немного медленнее, и LVF или HVF для выражения будет самым медленным.
• Например, в операторе SEIZE указание названия ресурса или константы является самым быстрым, использование атрибута или оператора SELECT с названием множества или константой немного медленнее, а использование переменной или выражения для идентификации ресурса или множества выполняется наиболее медленно.

Сущности

Число сущностей в системе влияет на производительность системы двумя сравнительно незначительными способами.

• Прежде всего, общее количество сущностей и ассоциированных атрибутов для своего размещения требуют памяти. Если это количество ставится чрезмерно большим, то может последовать сбрасывание страниц оперативной памяти на диск (т.н. своппинг, выполняемый операционной системой). Это редко вызывает какие-либо проблемы, так как требует чрезмерно большого числа атрибутов и/или сущностей, а у SIMAN есть специальные меры по минимизации своппинга.
• Второй способ относится к общему количеству сущностей в календаре событий (т.е. запланированных для последующих событий, а не ожидающих в очередях). По мере увеличения этого количества будет возрастать время, необходимое для манипуляции календарем, но у SIMAN есть собственный мощный календарь событий, минимизирующий эту проблему.

Запросы

• Внутренние запросы значительно более эффективны, но не могут быть ранжированы, анимированы или проверены.
• Стандартные очереди, ранжированные как LIFO или FIFO, также выполняются достаточно быстро.
• Очереди, ранжированные по атрибутам, выполняются медленнее.
• Очереди, ранжированные по выражению, являются наиболее медленными.

Файлы

• Чтение и запись из файла или в файл или консоль как правило выполняется медленно.
• Вы можете ускорить этот процесс, используя двоичные файлы (которые меньше, проще читаются компьютером, но трудны для чтения человеком).
• Вы также можете ускорить операции, объединив несколько действий в одно. Например, вместо записи трех строк заголовка, по одной строке за один раз, используйте один оператор WRITE для записи всех трех строк.
• Использование дискового кэша, предоставляемого средствами операционной системы вашего компьютера, тоже может ускорить выполнение.

Итог

Операции с интенсивным использованием процессора

• Поиск в очереди
• Поиск в календаре
• Использование функции SAQUE
• Анимация
• Ввод и вывод в файлы
• Нелинейные непрерывные системы (с дифференциальными уравнениями или уравнениями состояния)

Победители

• Календарь событий, имеющийся у SIMAN, признан лучшим в отрасли. Большое число событий в состоянии ожидания обрабатываются чрезвычайно эффективно. Чем больше событий находятся в состоянии ожидания, тем более отчетливой будет разница.
• Внутренние очереди очень быстры.
• Командный режим для неинтерактивных выполнений.
• WAIT & SIGNAL
• Блок SEIZE с именем или постоянным идентификатором ресурса на любой строке.
• Транспортеры свободного пути
• Непрерывные системы (такие как резервуары) с линейными отношениями.

02.03.06

За дополнительной информацией обращайтесь в компанию Interface Ltd.

Обсудить на форуме

INTERFACE Ltd. Телефон/Факс: +7 (495) 925-0049 Отправить E-Mail http://www.interface.ru

Ваши замечания и предложения отправляйте редактору По техническим вопросам обращайтесь к вебмастеру Дата публикации: 23.03.06