Comments (8)
+1 for queue_size_strict
.
The preempted arrival is inserted in the normal queue, which handles the situation. So it may be rejected, or maybe another one with lower priority.
from simmer.
This behaviour is deliberate. Think about an emergency service where some patients are being attended, and the waiting room is full. Then, an extremely urgent case arrives and several patients need to be preempted. You simply cannot throw out anybody.
We can discuss the convenience of a new option to avoid exceeding the maximum capacity and how to implement it (should we reject the preempted ones or those waiting in queue?), but first we need use cases.
from simmer.
I think your hospital example is a good case for explicitly modelling the queueing space required to accommodate preempted patients, rather than hiding it in the background, but a more concrete example is routing phone calls through the exchange during high demand (e.g. national emergency), when urgent calls must cause other calls to be dropped altogether -- electronics can't be compressed to accommodate more calls in a finite space!
from simmer.
As for the hospital example, your metric should be the percentage of time in which the total capacity exceeds certain threshold. So you are not hiding anything, but making it explicit!
As for the phone call service, it seems a reasonable use case. But I'm not sure whether there is preemption (or even priorities) in such a case... I mean, if the system is saturated, you have no circuits available, nor for normal calls nor for urgent ones.
from simmer.
I think this might be touching on similar matters to the reneging issue. The seize
step is handling two events, entry to the queue and entry to the server, which makes preemption and reneging difficult to express.
You're correct that, if the system is saturated, you have no circuits available even for urgent calls, but a high-priority arrival could be allowed preemption into the queue just as they are allowed preemption into the server. It would mean ejecting a lower-priority arrival from the queue, just as they can be ejected from the server. In the telephone exchange example, that would mean dropping someone's call and playing them the dial tone.
from simmer.
The seize step is handling two events, entry to the queue and entry to the server
That's not correct according to simmer's architecture. Queue and server are integral parts of a resource, and seize
handles only one event: the entry to the resource. If it's successful, the resource manages the arrival, putting it either in the queue or in the server. If it's not, it means that the resource is full (server + queue, if exists), and the arrival is rejected. An ifseize
would cover that cases in which you want to do something else if the seize fails.
a high-priority arrival could be allowed preemption into the queue just as they are allowed preemption into the server.
Again, we are starting from different definitions. For me (and in the literature about simulation in general I think), preemption refers to postpone a task already being served. A queue may have priorities (in fact, all queues are priority queues in simmer), but that's not preemption. SimPy adopts the same nomenclature, since you have priority customers with and without preemption.
Following the discussion above, the telephone exchange case is the typical example in which there is no queue. In fact, it is modelled traditionally as an M/M/c/c system (Erlang-B and all that stuff). So there are calls being served or no calls at all. And, if the system is saturated, there is no circuits available to even start a new call.
Don't get me wrong: I see the point of avoid exceeding the maximum capacity. But I need clear use cases, because preemption is hard, and I don't want to waste my time in something never used, you know... 😉
Moreover, if you perform a quick search, you only got simulators that don't drop preempted customers. Here one example, another and another.
from simmer.
I've taken a look at this issue and I think it should be more or less easy to implement this option to keep the queue size limit. But I have to pick a good name for it. For instance:
add_resource("name", capacity=1, queue_size=1, preemptive=TRUE, queue_hard_limit=TRUE)
More ideas are welcome.
from simmer.
Looks good to me. Maybe queue_size_strict = TRUE
would be more intuitive, as it's associated with queue_size
.
What is the implementation? To drop pre-empted arrivals, or not to serve priority arrivals until there is room in the queue?
from simmer.
Related Issues (20)
- Renege-timer error "not previously seized" HOT 4
- Implement arithmetic for schedules
- Use 'given' in CITATION
- Ability to deep-copy simulation environments
- synchronize() not work as expected HOT 3
- Monitors do not register the finalizer
- Dangling environment prevents object destruction HOT 1
- Bank Tutorial Part II: Balking - finished=TRUE even though balked HOT 1
- Batch cloning doesn't clone individual arrivals
- Caller misidentification
- Add support for vectors of capacities, queue sizes... HOT 2
- Airport control security HOT 1
- Option to add wait() time to activity_time
- Option to trap() "all" signals instead of "any"
- Possible Bug? `per_resource = T` drops the `finished` variable in `get_mon_arrivals()` HOT 3
- download version from CRAN does not recognise "tag" argument. HOT 6
- Output options are too limited HOT 2
- Ability to remove embeded attribute dataframes from simmer environment HOT 1
- Add getter for the arrival time
- Subset by tag
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from simmer.