Может быть дело вот в чем… При равных скоростях потоков заказа и клиентов все равно остается вероятность отказов, и зависит она в том числе от среднего размера буфера. Фактически это значит, что поток коров превышает поток продаж. Именно поэтому нельзя заказывать со скоростью потока клиентов, а нужно со скоростью потока продаж. В принципе, это решающий и, по-моему, единственный важный аргумент в пользу заказа по факту продажи. Рассчитать равновесия поток через поток клиентов с учетом вероятности отказов сильно сложнее.
Но я по-моему по прежнему вижу проблему. Похоже, что возникнет положительная обратная связь: больше отказов — меньше заказов; меньше заказов — больше отказов. Хорошо бы сформировать отрицательную обратную связь. Это сильно сложнее, но можно рассчитать, например, оптимальный поток заказов с учетом вероятности отказов из-за конечного буфера. Именно с такой фиксированной скоростью и следует делать равномерный заказ. Это сформирует отрицательную обратную связь. При отказах формируется избыток коров и это влечет уменьшение отказов, что, в свою очередь уменьшает избыток, отчего растут отказы и так все саморегулируется.
Резюмирую гипотезу:
1) заказ по факту продажи формирует положительную обратную связь, ведущую к росту отказов;
2) заказ со скоростью потока клиентов формирует положительную обратную связь, приводящую к постоянному росту буфера;
3) наверно можно вычислить фиксированную скорость заказов, при которой буфер будет в среднем одной длины.
4) наверно можно сформулировать закон адаптивного изменения скорости регулярных заказов на основе текущей статистики процесса, чтобы эта скорость регулировалась отрицательной обратной связью.
Ага. Тоже была такая мысль, но потом решил сделать на питоновских генераторах по отдельности и сливать потоки тоже генератором. Так можно будет при необходимости другие распределения использовать и даже роутить реальные события из какого-нибудь API
Изоляция. Мы можем один раз передать в деревню интервал и не слать больше сигналов туда, коровы сами пойдут.
Равномерность и предсказуемость нагрузки на дереаню. Ъотя этот плюс компенсруется непредсказуемостью роста (пусть даже краткосрочно и маловероятно) буфера, что, явно, минус
В принуипе можно и в вашей стратегии найти плюсы. Типа, поток один и постоянно спит между прерываниями от клиентов.
Но ок. Что там, что там доводы не решающие. Ценность их зависит от конкретной задачи и реализации.
Похоже на то. Но заказ через интервал проще же и прозранее.
Надо тестовый стендик закодить для статистической проверки на днях.
Но я теперь знаю какую задачу задать студентам=).
Так а если они равны в долгосрочной перспективе, то почему не выбрать тот, что проще? Равномерный интервальный заказ проще же. Ну и насчет равнсти в перспективе… надо бы проверить аналитически или экспериментально.
Пусть у вас на некотором сколь угодно малом интервале, отличном от нуля пул меньше N
Это почему?
Дв и не так важен сам факт наличия расходов, или прибыли, как их положительный баланс. Его нужно максимизировать. Пул можно зафиксировать только сверху. Снзу его невозбранно время от времени будут расхватывать клиенты. Если пул ограниен сверху,, то больше вероятность опустошения пула.
Вопрос что перевесит, недополученная прибыль при лишних опустошениях или расходы на кормёжку.
Вернее вопрос в том, как найти оптимальный средний размер пула, чтобы макимизировать баланс.
Отказ в обслуживании так или иначе неизбежен. Вопрос в том, какая стратегия окажется объективно выгоднее. Не понятно где больше потеряем при каждом размере буфера: при отказах или при кормёжке
Понимаю, что филигранно подобранным примером можно доказать все что угодно. Я даже сам в этом неслабо так преуспел доказывая себе=).
Не очень понятно откуда 1/60. А насчет ситуации, когда ща 40 минут придет много клиентов, которые обычно ходят с мат-ожиданием раз в час, то вероятность (вернее частота) таких ситуаций довольно мала. И ее надо сравнивать с настолько же неудобными и вероятными случаями для вашей стратегии.
Короче, надо либо формулы уже начинать писать, либо имитационную модель для статистической проверки стратегий.
Ок. похоже и я был предвзят в выборе примеров. Тогда получается нет разницы когда заказывать коров, лишь бы это происходило в среднем со скоростью потока? Надо обдумать. Но вы меня не убедили, что вариант с заказом во время покупки эффективнее.
В чем ошибка? Коровы поступают в среднем со скоростью сбыта. С постоянной скоростью. Размер буфера симметрично случайно колеблется относительно оптимума, а в вашем лучае буфер ограничен сверху, а значит больше склонен к опустошению.
Уж несколько раз приводил такие примеры. Еще раз. Без краевого случая. У нас есть некое расчетное N — оптимальный размер пула для заданных a, T и вектора l. Оставим а скобками методику расчета этого N.
Мы постоянно заказываем коров со средней скоростью потока, то есть если средняя скорость потока 1/мин, то и коров мы заказываем по одной строго каждую минуту. Одно исключение. не заказываем очередную корову, если случилось, что пул опустел и клиент ушел без коровы, Очевидно, что если средняя скорость потока верна, то буфер в среднем будет держаться около N. Иногда он будет пустеть и мы будем пропускать клиентов, а иногда будет вырастать, возможно очень сильно больше N/
Почему вы так старательно держите меня за идиота. КОнечно я не считаю, «что если первые полчаса никто не приходил, то все ожидаемые клиенты повалят во вторые пол часа».
Я просто сказал, что в бесконечном пуассоновском потоке с указанными характеристиками наверняка (100%) когда-то случаится такой час, когда в первой половине никого, а во творой 60. Вероятность, что следующий час будет именно таким не нулевая. Я просто привел это как пример. Если кто-то с вами не согласен, надо допускать всё же что это вы чего-то не поняли, а не собеседник тупит.
Меня бомбит. Либо я дупак, либо лыжи не едут. Только не исчезайте, докажите мне что я не прав.
Под словом «пример» я подразумевал интервалы: минута и месяц. Это позволяет сделать проблему более интуитивно понятной.
Буфер делать в этом примере можно и нужно.
Давайте рассмотрим стационарную ситуацию.
Клиенты приходят примерно раз в минуту, коровы добираются по месяцу и буфер,, скажем, из 10 коров полон. Также в пути дофигища коров, они поступают тоже со скоростью примерно раз в минуту.
Рассмотрим ваш вариант. Пуассоновский процесс допускает вероятность, что случится «затишье» на пол часика, когда ни один клиент не придет, хотя мат-ожидание 1 минута.
Все эти пол часа ни одной коровы не вызвано из деревни. Ровно через месяц выдаются пол часа, когда коровы не приходят из деревни. За это время пусть пришло примерно 30 человек. Первые 10 выбрали пул, остальные 20 ушли. Это не прогноз, а просто один из вполне вероятных вариантов развития событий.
Теперь представьте, что при прочих равных коров мы заказываем строго раз в минуту, это значит, что пул вырастет за пол часа тишины на 30 коров (получится их 40 у нас), потом они постепенно будут рассасываться неопределенно долгое время. Но через месяц не будет полу часа без коров. Всё будет в штатном режиме.
Ваша схема фактически апрещает рост пула сверх некоторого числа, а моя никак не ограничивает его, но за счет фиксированного интервала заказа равного мат-ожиданию прихода покупателей скорость прихода коров получается в среднем равной скорости их сбыта.
Меня бомбит. Либо я дупак, либо лыжи не едут. Только не исчезайте, докажите мне что я не прав.
Под словом «пример» я подразумевал интервалы: минута и месяц. Это позволяет сделать проблему более интуитивно понятной.
Буфер делать в этом примере можно и нужно.
Давайте рассмотрим стационарную ситуацию.
Клиенты приходят примерно раз в минуту, коровы добираются по месяцу и буфер,, скажем, из 10 коров полон. Также в пути дофигища коров, они поступают тоже со скоростью примерно раз в минуту.
Рассмотрим ваш вариант. Пуассоновский процесс допускает вероятность, что случится «затишье» на пол часика, когда ни один клиент не придет, хотя мат-ожидание 1 минута.
Все эти пол часа ни одной коровы не вызвано из деревни. Ровно через месяц выдаются пол часа, когда коровы не приходят из деревни. За это время пусть пришло примерно 30 человек. Первые 10 выбрали пул, остальные 20 ушли. Это не прогноз, а просто один из вполне вероятных вариантов развития событий.
Теперь представьте, что при прочих равных коров мы заказываем строго раз в минуту, это значит, что пул вырастет за пол часа тишины на 30 коров (получится их 40 у нас), потом они постепенно будут рассасываться неопределенно долгое время. Но через месяц не будет полу часа без коров. Всё будет в штатном режиме.
Ваша схема фактически апрещает рост пула сверх некоторого числа, а моя никак не ограничивает его, но за счет фиксированного интервала заказа равного мат-ожиданию прихода покупателей скорость прихода коров получается в среднем равной скорости их сбыта.
А вы, похоже, неверно поняли условие задачи. А своей аналогие и вовсе себя запутали. Если задумаетесь как следует, поймёте, то оригинальная задача допускает ситуации, недопустимые в вашем примере, иначе число касс можно было бы варьировать. Пример с кассами нормально иллюстрирует только недостатки плохого решения с заказом коровы в момент покупки.
Если заказывать коров независимо от покупок равномерно со скоростью их потока, то получится эффективнее. Могу доказать, если еще сами не поняли.
Отлчно я это всё понимаю. Просто проиллюстрировать хотел именно то что вы сказали. Но добился прямо противоположного эффекта. Я не утверждаю, что если первые пол часа тишина, то вторые пол часа обязательно придут 60 человек. Но такой расклад вполне возможен. Он не невозможен. Именно эту ситуацию, которую, конечно, никак не спрогнозировать, я и привел в качестве примера.
Я отлично понимаю распределение Пуассона.
Вы забываете, что поток пуассоновский и описывается грубо говоря средним количеством на 1 времени. Это 1 в минуту = 60 в час и т.д., но интервалы между приходам это случайные величины и существует ненулевая вероятность сколь угодно долгого "затишья" независимо от мат ожидания. По затишье я имею в виду, что обычно люди идут 60 в час, но может статься, что и в течении получаса никто не появится. Почитайте мой коммент выше про это. Там про месячную доставку и ежеминутный поток.
Но я по-моему по прежнему вижу проблему. Похоже, что возникнет положительная обратная связь: больше отказов — меньше заказов; меньше заказов — больше отказов. Хорошо бы сформировать отрицательную обратную связь. Это сильно сложнее, но можно рассчитать, например, оптимальный поток заказов с учетом вероятности отказов из-за конечного буфера. Именно с такой фиксированной скоростью и следует делать равномерный заказ. Это сформирует отрицательную обратную связь. При отказах формируется избыток коров и это влечет уменьшение отказов, что, в свою очередь уменьшает избыток, отчего растут отказы и так все саморегулируется.
Резюмирую гипотезу:
1) заказ по факту продажи формирует положительную обратную связь, ведущую к росту отказов;
2) заказ со скоростью потока клиентов формирует положительную обратную связь, приводящую к постоянному росту буфера;
3) наверно можно вычислить фиксированную скорость заказов, при которой буфер будет в среднем одной длины.
4) наверно можно сформулировать закон адаптивного изменения скорости регулярных заказов на основе текущей статистики процесса, чтобы эта скорость регулировалась отрицательной обратной связью.
Какие ваши соображения, коллеги?
Ага. Тоже была такая мысль, но потом решил сделать на питоновских генераторах по отдельности и сливать потоки тоже генератором. Так можно будет при необходимости другие распределения использовать и даже роутить реальные события из какого-нибудь API
В питоновском пакете numpy нашел такую штуку:
Вроде даёт интервалы с мат-ожиданием 100.
Вопроса сразу два:
По второму пункту я полагаю как-то так:
В принуипе можно и в вашей стратегии найти плюсы. Типа, поток один и постоянно спит между прерываниями от клиентов.
Но ок. Что там, что там доводы не решающие. Ценность их зависит от конкретной задачи и реализации.
Надо тестовый стендик закодить для статистической проверки на днях.
Но я теперь знаю какую задачу задать студентам=).
Это почему?
Дв и не так важен сам факт наличия расходов, или прибыли, как их положительный баланс. Его нужно максимизировать. Пул можно зафиксировать только сверху. Снзу его невозбранно время от времени будут расхватывать клиенты. Если пул ограниен сверху,, то больше вероятность опустошения пула.
Вопрос что перевесит, недополученная прибыль при лишних опустошениях или расходы на кормёжку.
Вернее вопрос в том, как найти оптимальный средний размер пула, чтобы макимизировать баланс.
Не очень понятно откуда 1/60. А насчет ситуации, когда ща 40 минут придет много клиентов, которые обычно ходят с мат-ожиданием раз в час, то вероятность (вернее частота) таких ситуаций довольно мала. И ее надо сравнивать с настолько же неудобными и вероятными случаями для вашей стратегии.
Короче, надо либо формулы уже начинать писать, либо имитационную модель для статистической проверки стратегий.
Мы постоянно заказываем коров со средней скоростью потока, то есть если средняя скорость потока 1/мин, то и коров мы заказываем по одной строго каждую минуту. Одно исключение. не заказываем очередную корову, если случилось, что пул опустел и клиент ушел без коровы, Очевидно, что если средняя скорость потока верна, то буфер в среднем будет держаться около N. Иногда он будет пустеть и мы будем пропускать клиентов, а иногда будет вырастать, возможно очень сильно больше N/
Я просто сказал, что в бесконечном пуассоновском потоке с указанными характеристиками наверняка (100%) когда-то случаится такой час, когда в первой половине никого, а во творой 60. Вероятность, что следующий час будет именно таким не нулевая. Я просто привел это как пример. Если кто-то с вами не согласен, надо допускать всё же что это вы чего-то не поняли, а не собеседник тупит.
Под словом «пример» я подразумевал интервалы: минута и месяц. Это позволяет сделать проблему более интуитивно понятной.
Буфер делать в этом примере можно и нужно.
Давайте рассмотрим стационарную ситуацию.
Клиенты приходят примерно раз в минуту, коровы добираются по месяцу и буфер,, скажем, из 10 коров полон. Также в пути дофигища коров, они поступают тоже со скоростью примерно раз в минуту.
Рассмотрим ваш вариант. Пуассоновский процесс допускает вероятность, что случится «затишье» на пол часика, когда ни один клиент не придет, хотя мат-ожидание 1 минута.
Все эти пол часа ни одной коровы не вызвано из деревни. Ровно через месяц выдаются пол часа, когда коровы не приходят из деревни. За это время пусть пришло примерно 30 человек. Первые 10 выбрали пул, остальные 20 ушли. Это не прогноз, а просто один из вполне вероятных вариантов развития событий.
Теперь представьте, что при прочих равных коров мы заказываем строго раз в минуту, это значит, что пул вырастет за пол часа тишины на 30 коров (получится их 40 у нас), потом они постепенно будут рассасываться неопределенно долгое время. Но через месяц не будет полу часа без коров. Всё будет в штатном режиме.
Ваша схема фактически апрещает рост пула сверх некоторого числа, а моя никак не ограничивает его, но за счет фиксированного интервала заказа равного мат-ожиданию прихода покупателей скорость прихода коров получается в среднем равной скорости их сбыта.
Под словом «пример» я подразумевал интервалы: минута и месяц. Это позволяет сделать проблему более интуитивно понятной.
Буфер делать в этом примере можно и нужно.
Давайте рассмотрим стационарную ситуацию.
Клиенты приходят примерно раз в минуту, коровы добираются по месяцу и буфер,, скажем, из 10 коров полон. Также в пути дофигища коров, они поступают тоже со скоростью примерно раз в минуту.
Рассмотрим ваш вариант. Пуассоновский процесс допускает вероятность, что случится «затишье» на пол часика, когда ни один клиент не придет, хотя мат-ожидание 1 минута.
Все эти пол часа ни одной коровы не вызвано из деревни. Ровно через месяц выдаются пол часа, когда коровы не приходят из деревни. За это время пусть пришло примерно 30 человек. Первые 10 выбрали пул, остальные 20 ушли. Это не прогноз, а просто один из вполне вероятных вариантов развития событий.
Теперь представьте, что при прочих равных коров мы заказываем строго раз в минуту, это значит, что пул вырастет за пол часа тишины на 30 коров (получится их 40 у нас), потом они постепенно будут рассасываться неопределенно долгое время. Но через месяц не будет полу часа без коров. Всё будет в штатном режиме.
Ваша схема фактически апрещает рост пула сверх некоторого числа, а моя никак не ограничивает его, но за счет фиксированного интервала заказа равного мат-ожиданию прихода покупателей скорость прихода коров получается в среднем равной скорости их сбыта.
Если заказывать коров независимо от покупок равномерно со скоростью их потока, то получится эффективнее. Могу доказать, если еще сами не поняли.
Я отлично понимаю распределение Пуассона.
Вы забываете, что поток пуассоновский и описывается грубо говоря средним количеством на 1 времени. Это 1 в минуту = 60 в час и т.д., но интервалы между приходам это случайные величины и существует ненулевая вероятность сколь угодно долгого "затишья" независимо от мат ожидания. По затишье я имею в виду, что обычно люди идут 60 в час, но может статься, что и в течении получаса никто не появится. Почитайте мой коммент выше про это. Там про месячную доставку и ежеминутный поток.