Так как почему-то эти вопросы по статиститике приводят студентов в замешательство, я подумал дать еще дополнительную задачу по расчету среднего времени нахождения транзактов в очереди или устройтве и средней длине очереди. Смотрите видео внимательнее. Попробуйте повторить расчеты сами. Сравните результаты с выводом GPSS.
Что-то я, честно говоря, так и не понял к чему это видео. Проблему сбора данных - понял, да, транзакты сбрасываются после моделирования. Решение через цепи пользователя или там другими способами - ок, хотя это, мне кажется, важнее. Дальше много-много ре-инжиниринга работы транзактов и GPSS. В итоге как работают транзакты и взаимодействуют с очередями - понятно. Но, всё-таки, а как статистику собирать с модели корректно? Вот мы сделали сразу две очереди - а зачем?
Тут то как раз и беда, что модель мы делаем в первую очередь для получения результатов - статистики по чему-то там. А стандартные средства сбора статистики в GPSS могут приводить к ложным проблемам. В видео пытался описать эти проблемы и почему они возникают. В общем виде лучше собирать статистику самостоятельно. Создавать переменные и изменять в них значения, чем полагаться на стандартные методы в GPSS. Если только у Вас не длинная реализация и показанные ошибки могут быть учтены как случайность, например прошло 1000 транзактов, то один транзакт на среднее время влиять будет слабо. Видео про правильный сбор статистики я не сделал еще. А это видео делаю потому, что студенты часто просто слепо верят что им выдал GPSS, хотелось бы привить им желание покопаться и разобраться откуда появились те или иные числа.
Господи, если ты есть, дай мне сил
Полностью Соледарен
Так как почему-то эти вопросы по статиститике приводят студентов в замешательство, я подумал дать еще дополнительную задачу по расчету среднего времени нахождения транзактов в очереди или устройтве и средней длине очереди. Смотрите видео внимательнее. Попробуйте повторить расчеты сами. Сравните результаты с выводом GPSS.
Что-то я, честно говоря, так и не понял к чему это видео. Проблему сбора данных - понял, да, транзакты сбрасываются после моделирования. Решение через цепи пользователя или там другими способами - ок, хотя это, мне кажется, важнее. Дальше много-много ре-инжиниринга работы транзактов и GPSS. В итоге как работают транзакты и взаимодействуют с очередями - понятно. Но, всё-таки, а как статистику собирать с модели корректно? Вот мы сделали сразу две очереди - а зачем?
Тут то как раз и беда, что модель мы делаем в первую очередь для получения результатов - статистики по чему-то там. А стандартные средства сбора статистики в GPSS могут приводить к ложным проблемам. В видео пытался описать эти проблемы и почему они возникают. В общем виде лучше собирать статистику самостоятельно. Создавать переменные и изменять в них значения, чем полагаться на стандартные методы в GPSS. Если только у Вас не длинная реализация и показанные ошибки могут быть учтены как случайность, например прошло 1000 транзактов, то один транзакт на среднее время влиять будет слабо. Видео про правильный сбор статистики я не сделал еще. А это видео делаю потому, что студенты часто просто слепо верят что им выдал GPSS, хотелось бы привить им желание покопаться и разобраться откуда появились те или иные числа.
Халява приди