Update throughput model, add shared disk with perf degradation

[kuskarov]

No description provided.

[osukhoroslov]

Отрефакторил код здесь. Избавился от клонов, в throughput model хранятся DiskActivity, отдельные события на завершение активностей, обработка событий вынесена в функции, приватные функции размещены после публичных. Если все ок, заберите в PR.

[kuskarov]

Еще раз посмотрел, почему отличаются результаты в примере network_shared. Все-таки дело во floating point арифметике. Там при планировании девятой по счету задачи в throughput model приоритет получается не 0.1, а 0.09999999999999999, из-за чего нарушается ожидаемый порядок активностей и плывет остальная симуляция.

Реализация fair_sharing_slow тоже не лишена этой проблемы - только она возникает уже в pop / next_time при делении volume / throughput_per_item и порядок будет ломаться уже в ядре в порядке событий.

Варианты, что делать:

1. Считать такое нормой. Floating point вычисления формально детерминированные, но при изменениях в каком-то коде результаты могут меняться. И не факт, что не возникнут еще более серьезные проблемы - например, NaN/INF могут быть при большом числе операций.
2. Внедрять fixed-point арифметику в симуляторе, сходу нашел такой крейт например. Может быть, где-то можно перейти к целым числам, и если брать их достаточно большими, то симуляция не потеряет смысла?

[kuskarov]

Провел эксперименты с вышеупомянутым крейтом fixed, не помогло - все равно на том же самом месте портится деление. Вместо этого перешел на рациональные числа из крейта. Перевел на них целиком simcore, throughput-model, network, storage и примеры storage-shared-disk, network_shared. Теперь проблем с ошибками округления нет.

Код, связанный с рациональными числами, пока положил в simcore/src/component.rs, но надо будет место получше найти.

На первый взгляд кажется, что и другие крейты перевести будет несложно. Вижу только две потенциальные проблемы:

1. в serverless используется операция sqrt в ARIMA-модели. Из контекста не очень понятно, насколько это важно для дальнейшей симуляции.
2. в примере ping-pong используется генерация случайных дробных чисел от 0 до 1 (единственное такое место, в остальных интервалы целочисленные). Но тут можно как-то переписать на генерацию рационального числа из сетки значений.

[maksim1744]

Протестировал переполнение. Достаточно такого кода (внутри examples/network_shared::main():

let mut sim = Simulation::new(123);

let shared_network_model = rc!(refcell!(SharedBandwidthNetwork::new(
    Fractional::from_integer(10),
    Fractional::one() / Fractional::from_integer(10)
)));
let shared_network = rc!(refcell!(Network::new(shared_network_model, sim.create_context("net"))));
sim.add_handler("net", shared_network.clone());

let receiver_name = "receiver";
let receiver = DataReceiver::new(shared_network.clone(), sim.create_context(&receiver_name));
let receiver_id = sim.add_handler(&receiver_name, rc!(refcell!(receiver)));

let sender_name = "sender";
let sender = DataTransferRequester::new(shared_network.clone(), sim.create_context(&sender_name));
let sender_id = sim.add_handler(&sender_name, rc!(refcell!(sender)));

let mut client = sim.create_context("client");
for _ in 0..50 {
    let size = client.gen_range(1..1000);
    let time = client.gen_range(1..1000);
    client.emit(
        Start {
            size: Fractional::from_integer(size),
            receiver_id: receiver_id,
        },
        sender_id,
        Fractional::from_integer(time)
    );
}

sim.step_until_no_events();

То есть 50 случайных передач, и Rational падает с ошибкой переполнения

[osukhoroslov]

Надо добавть тесты для проверки корректности FairThroughputSharingModel, в т.ч. с dynamic_throughput. https://doc.rust-lang.org/book/ch11-00-testing.html

[osukhoroslov]

Еще раз посмотрел, почему отличаются результаты в примере network_shared. Все-таки дело во floating point арифметике. Там при планировании девятой по счету задачи в throughput model приоритет получается не 0.1, а 0.09999999999999999, из-за чего нарушается ожидаемый порядок активностей и плывет остальная симуляция.

Реализация fair_sharing_slow тоже не лишена этой проблемы - только она возникает уже в pop / next_time при делении volume / throughput_per_item и порядок будет ломаться уже в ядре в порядке событий.

Варианты, что делать:

1. Считать такое нормой. Floating point вычисления формально детерминированные, но при изменениях в каком-то коде результаты могут меняться. И не факт, что не возникнут еще более серьезные проблемы - например, NaN/INF могут быть при большом числе операций.

2. Внедрять fixed-point арифметику в симуляторе, сходу нашел [такой крейт](https://docs.rs/fixed/latest/fixed/) например. Может быть, где-то можно перейти к целым числам, и если брать их достаточно большими, то симуляция не потеряет смысла?

Предлагаю пока оставить вариант 1, и сделать отдельное issue про это, где обсудить возможные варианты решения.

[kuskarov]

• Убрал из PR все эксперименты с Rational в ветку
• Добавил тесты
• Улучшил пример storage-shared-disk

[osukhoroslov]

Предлагаю пока оставить вариант 1, и сделать отдельное issue про это, где обсудить возможные варианты решения.

Сделал #83