The reality is that the “extra” time is a static number made up by the ride ops with no input from real numbers of people actually in the VQ. Of course if the only people getting on the ride are the people in line the waits would be less. That’s not what I am saying.
Granted, ops should know the number of G+ slots being reserved so that number should be static(ish) but the addition of DAS as a variable number throws off the posted wait times.
Which is where the real number should drive the change. Which would mean that the people who try to select a ride would see a higher wait and a longer return time and thus reduce the crazy LL back ups which happen.
You're missing a core concept here.
As long as the LL is not empty... it's impact on standby is a CONSTANT. It does not matter how many people are in the LL.. as long as it's not depleted. The number of people in queue BEYOND the number of people needed for each merge batch is not relevant to the posted standby time. The merge ratio is a linear function normally.
The only impact is when the LL is depleted... so the impact on standby would then decrease... or when the merge ratio is changed.
The problem is when LL returns clog up the LL queue due to concentrations or other unreliable patterns.
I don't need to count every DAS assignment if statistically the usage is predictable and my other LL assignments account for it. The actual goal is to manage how deep the LL queue trends... which dictates how many scheduled LL/G+ they give out. That number is already accounting for a predicted # of unscheduled LL users... like returns, DAS, etc. A portion of their LL queue availability is already planned for these 'unscheduled' users.
The problems are when there are great spikes in demand that are not planned for... so the LL backs up, and operationally they use the relief value to bring the LL back in check... which causes an unplanned reduction in standby throughput... and would weaken your new estimates AT THAT TIME. You can't do anything about the people who were given an estimate 30mins ago when they got in line, and then standby slowed 30mins later.... because you aren't giving those people already in line a wait estimate. They had one estimate that was based on when they got in line.. it's not a running ETA.
The problem isn't giving out a DAS ... the problem is when you give out far more than you were expecting, or more come back at a time than you were expecting.
And assessing when that spike hits is fuzzy math because of large return windows.
The topic about LL merging changing and not reflecting in standby times is a topic of LAG. The fact it would take time between the change happening, and the frequency of when the new standby wait time would be updated.