Two faulty assumptions:
1) The number of passing loops and/or stations. There will be many more stations than what you indicate, whether certain trains stop at each is a variance. Most if not all will encompass both passing and stopping loops. And posters such as Urban Sky have pointed out many times the 'insertion loss' (the term used in my field of engineering) for intermediary stops is in the region of five minutes.(That's both the actual platform stop time and deceleration and acceleration back to speed included. I leave it to him to detail further)
My assumption was that most trains will operate with few or no stops other than Toronto, Peterborough and Ottawa (hundreds of kilometres apart), while a handful of trains per day serve the intermediate communities (which would get stations otherwise we'd never get the line built). Indeed it would be possible to schedule all of the recovery time on the train in one direction, allowing the train in the opposite direction to proceed unimpeded. For example, you could schedule a stopping train to sit in the station for 10 minutes, which provides a 10-minute window for an express train in the other direction to pass by. But again, my assumption is that there would be a fairly large number of express trains, which would still need to encounter each other.
From what I've seen comparing train schedules with varying numbers of stops, VIA trains lose about 3-5 min per stop. In comparison, the 'lost time' as I call it, is about 2-3 minutes per station for GO Transit, due to the lower speeds and more efficient loading (more doors, fewer steps).
2) You completely overlook modern communication systems. Like the latest variances of CBTC, both track transponder and radio based. They not only signal trains and control switches, they *determine the speed and the dynamics of that speed* on the trains. (This includes TASS *) In a sense, other than actual human flesh on controllers, these will be robotic. Also keep in mind that *sizable segments* will run at well above the present 110 mph for non-grade separated sections. One of the advantages of using such a 'lowly populated route' is the ease in which to grade separate the line, and being electric traction, the ramp grades for bridges can be far greater than for freight, for which run-arounds at grade can be built, as the San Diego Trolley does combining the passenger flyovers with the night time (temporally separated) freight operations, done, btw, by an independent freight operator.
Correct. I took no account of communications systems - I assumed an idealized situation with perfect communication and no signal-related speed restrictions. Because I'm talking about the basic principles of railway scheduling, not a particular example. If a siding is 4 minutes long and you schedule the meet in the middle of it, a train that is more than 2 minutes late will cause the other train to be delayed. No matter how good your signalling is, and no matter how fast your train can accelerate, you cannot change this fact.
The question we're all trying to answer is:
How do we schedule a service as close as possible to its maximum possible speed, without causing a complete catastrophe when things don't go according to plan. The key word here being 'schedule'. Sure, we could just set a bunch of trains on their way and let them meet where they may, but that would result in a low average speed because inevitably some trains will tend to meet in locations where there are no sidings.
Railway scheduling 101:
There is a certain speed profile that is the best-case scenario, where a train accelerates up to the speed limit as quickly as possible, travels exactly at the speed limit through all the segments, decelerates at the maximum possible rate at the very last moment leading up to any speed limit decreases or station stops, and spends a short time at each station. This provides the 'best-case' travel time, with no delays. Any deviation from that is a delay in the context of trying to achieving the highest possible average speed.
In an ideal situation, it would be possible to schedule trains exactly at the best-case travel time, by placing passing sidings exactly in the locations the opposing trains will be. Note that this ignores any possible delay due to slowing down to change tracks.
So let's say we've got perfectly-located sidings exactly the length of the trains, located such that when everything runs according to schedule, trains pass at full speed because our signalling is perfect and there is no speed restriction on the switches. If one of those trains is is ten seconds late, the meet will occur 10 seconds later than scheduled and the opposite train will be delayed by 10 seconds as well. Not that this is purely the 'stopped' delay, which is in addition to any delay caused by decelerating and accelerating, or travelling at a restricted speed due to a signal system. And since in this hypothetical scenario all trains are already scheduled at the 'best-case' speed, that train will be 10 seconds late for its next meet causing another other train to be 10 seconds late, and so on. All trains on the line will be delayed by 10 seconds.
So schedules include 'padding', which is extra time above the 'best-case' travel time, which allows delays relative to schedule to be neutralized by driving faster than scheduled. This is absolutely necessary in order to run a service in the real world where there are external sources of delay, like weather, passengers etc. But in our context, (
how to schedule a train as fast as possible), schedule padding is still a delay (relative to the best-case travel time). A train scheduled at the best-case speed which is 10 seconds late, is the same speed as an on-time train scheduled at 10 seconds above the best-case travel time.
Basically, the more trains impact each other, the more schedule padding is required in order to maintain a reasonable service reliability. And the shorter the siding, the more impact trains have on each other and therefore the slower the service needs to be
scheduled. This is regardless of the switches, acceleration, signaling etc.
A more sophisticated control system can accurately predict running times and optimise meets between passenger trains because these trains have sufficient horsepower to maintain full track speed. Running times will therefore be consistent. This means that meets can be planned fairly exactly. A ten mile siding spacing means at worst a six minute wait for one train to reach the meet. If the sidings are fairly short, their cost is affordable.
How do you 'optimise meets'? By definition, you can't speed up trains relative to the 'best-case' travel time, so the only thing the signal system can do is slow trains down such that the meets occur at the right places. This avoids the delay from decelerating to a stop to wait for another train, but does nothing for the intrinsic 'stopped' delay I'm talking about here. In this scenario, that delay is transferred to the train by the signalling system. The train doesn't stop per se, instead the time lost from slowing down as directed by the signals is equal to the time that would be spent sitting at a standstill in the ideal scenario with infinite acceleration/deceleration and no safety buffer on the control system.
The current VIA operation on the Smiths Falls and Brockville Subs certainly demonstrates that a service can be run with a single track line at 100 mph with very short sidings.
No one is denying you can operate a single-track service at 100mph with short sidings. My point is that sidings create a potential for delay (and therefore an increased demand schedule padding), which reduces the scheduled average speed. If you look at the schedules on those lines, I expect that you will find that trains with more scheduled meets have lower average speeds than trains with fewer, just as trains with more stops have lower average speeds than trains with fewer.
And all of this adds up to say that the scheduled travel times on the Havelock sub will be nowhere near the 'best-case' travel times that VIA seems to be publishing. Sure it's possible to schedule certain trains like that by putting all the schedule padding onto the trains in the other direction, but you can't base a bi-directional service pattern around that.
