Ive now set up a 3-way intersection testing thread
its still getting going but feel free to submit designs for me to test and add on to the list
4-way intersections: Throughput and deadlocks [image heavy]
-
hansjoachim
- Filter Inserter
- Posts: 252
- Joined: Wed Apr 26, 2017 7:03 pm
- Contact:
Re: 4-way intersections: Throughput and deadlocks [image heavy]
A high throughput 4 way intersection with 8 lanes
It works like a 4 way road intersection, and i have no chain signals in the senter.
I use circuit networks to manage signals
UPDATE
I added the new blueprint and the image is now outdated.
Blueprint
https://pastebin.com/LUhZNxwA
Flower MK4
8 lanes
6 cars
Right hand side
Set 1 15 min
350trains/3600 ticks
set 2
280trains/3600 ticks
It works like a 4 way road intersection, and i have no chain signals in the senter.
I use circuit networks to manage signals
UPDATE
I added the new blueprint and the image is now outdated.
Blueprint
https://pastebin.com/LUhZNxwA
Flower MK4
8 lanes
6 cars
Right hand side
Set 1 15 min
350trains/3600 ticks
set 2
280trains/3600 ticks
- Attachments
-
- Intersection cross 8 way.png (2.29 MiB) Viewed 13238 times
Last edited by hansjoachim on Sun Oct 08, 2017 8:13 pm, edited 3 times in total.
Re: 4-way intersections: Throughput and deadlocks [image heavy]
I don't know what you mean by an "8 way" road intersection... The contents of your blueprint string is a 4-way intersection (as are all versions of the MultiCross, and almost everything else in this thread). Using circuits to control the signals does sound interesting, though. I'll have to take a peek.hansjoachim wrote:A high throughput 8 way intersection
It works like a 8 way road intersection, and i have no chain signals in the senter.
When everything's hooked up and running properly, it does get approximately what's listed. Attempting to remotely troubleshoot your use of the test map would be an exercise in frustration. It could be as simple as some stuck trains, or missing / extra signals on the lanes leading to/from the spawners and deleters. But here's a map save with the 8-lane version of the 4-way MultiCross all set up and running. Maybe comparing that with your test of it will help you figure out what went wrong.hansjoachim wrote:I got 252 in set 1 and 206 in set 2 with Tallinus 8 way Multicross, why does it say 346+ and 292+ in the first post?
(If you're trying to convert it to right-hand driving, keep in mind that mirroring it with Foreman does not result in correct signal placement. The deliberately large chain signal exit blocks will end up as entry blocks and vice versa, for example.)
- Attachments
-
- aaarghas - MultiCross 8L 6C LHD.zip
- (16.79 MiB) Downloaded 212 times
Last edited by Tallinu on Fri Aug 04, 2017 10:05 am, edited 1 time in total.
Re: 4-way intersections: Throughput and deadlocks [image heavy]
That is a pretty interesting idea, I'll have to take a closer look at it. From the image at least it does not seem like there is any mechanism that ensures that the trains can actually make it through the intersection before they enter. If that is the case it means that this is almost guaranteed to deadlock if one output is blocked for a little while.hansjoachim wrote:A high throughput 8 way intersection
It works like a 8 way road intersection, and i have no chain signals in the senter.
I use circuit networks to manage signals
Like Tallinu said, you've probably got it set up incorrectly as both of us get about the same results.hansjoachim wrote:I got 252 in set 1 and 206 in set 2 with Tallinus 8 way Multicross, why does it say 346+ and 292+ in the first post?
Re: 4-way intersections: Throughput and deadlocks [image heavy]
You're right, a real use-case situation where any exiting traffic might possibly get blocked would absolutely trigger huge deadlocks. I managed to make that happen accidentally even, just by adding more signals on the left turn tracks to smooth them out while fiddling with the combinators right as a surge of right-turn traffic headed for the currently active exit. 
One of the left turn exit lanes backed up due to traffic fighting for the lane-swap crossings further along, and one cargo wagon was left sticking out, blocking a couple of through-traffic lanes. Those, in turn, blocked more traffic on the next cycle, and so on. And even though the original culprit was long gone, the result was a chain reaction that led to a complete CF of a deadlock. It took several minutes to delete all of the stuck trains without deleting any tracks or signals by accident!
(By the way, there is actually one chain signal left, very close to the center of the thing, not that it really makes much difference.)
In brighter news, I'm pretty decent with combinators, and I managed to simplify the logic from that complicated, hard to alter sprawl, down to just four deciders and two constants, not counting the one used to manually lock all entrances (although the output needed to do so is different with this setup, so I included it too). Changing the signals to respond to a number on one signal channel with the "not equal" condition lets them only turn green when the number matches. Just after resetting, the clock triggers a one-tick pulse out of the second decider that increments a third acting as a counter from zero to three (like a For loop), with a plus one added by another constant block (to get a 1 to 4 value for triggering green lights), and then a final decider acts as a gate to only allow that signal control value to pass through if the clock is over a certain value, to keep the short "all-way stop" period between green lights. The following small blueprint string can run stand-alone and includes a little group of four example signals that demonstrate what it's doing, and you can simply copy-paste their settings onto the real signals if you want to actually use it. The only values that should need modifying if you want to adjust the timings are the clock's max value (delay between each new green light) and the decider which checks if the clock is over a certain value, that value being the number of ticks to shut down the intersection between green light periods.
One of the left turn exit lanes backed up due to traffic fighting for the lane-swap crossings further along, and one cargo wagon was left sticking out, blocking a couple of through-traffic lanes. Those, in turn, blocked more traffic on the next cycle, and so on. And even though the original culprit was long gone, the result was a chain reaction that led to a complete CF of a deadlock. It took several minutes to delete all of the stuck trains without deleting any tracks or signals by accident!(By the way, there is actually one chain signal left, very close to the center of the thing, not that it really makes much difference.)
In brighter news, I'm pretty decent with combinators, and I managed to simplify the logic from that complicated, hard to alter sprawl, down to just four deciders and two constants, not counting the one used to manually lock all entrances (although the output needed to do so is different with this setup, so I included it too). Changing the signals to respond to a number on one signal channel with the "not equal" condition lets them only turn green when the number matches. Just after resetting, the clock triggers a one-tick pulse out of the second decider that increments a third acting as a counter from zero to three (like a For loop), with a plus one added by another constant block (to get a 1 to 4 value for triggering green lights), and then a final decider acts as a gate to only allow that signal control value to pass through if the clock is over a certain value, to keep the short "all-way stop" period between green lights. The following small blueprint string can run stand-alone and includes a little group of four example signals that demonstrate what it's doing, and you can simply copy-paste their settings onto the real signals if you want to actually use it. The only values that should need modifying if you want to adjust the timings are the clock's max value (delay between each new green light) and the decider which checks if the clock is over a certain value, that value being the number of ticks to shut down the intersection between green light periods.
Blueprint String
-
hansjoachim
- Filter Inserter
- Posts: 252
- Joined: Wed Apr 26, 2017 7:03 pm
- Contact:
Re: 4-way intersections: Throughput and deadlocks [image heavy]
Really nice done with those combinators! I wanted to make a controllsenter, but had not gotten to that yet.
The deadlock situation can be fixed, you just have to check every output lane and block the input lane if the output lane is full.
I am working on improving it to get 346 trains/min. I'll try to get it done this evening.
The deadlock situation can be fixed, you just have to check every output lane and block the input lane if the output lane is full.
I am working on improving it to get 346 trains/min. I'll try to get it done this evening.
Re: 4-way intersections: Throughput and deadlocks [image heavy]
Except that doesn't keep that last train which fills up the output buffer from sticking out and blocking some lanes of the crossing. Also, doing that on a per-lane basis would require a lot of expansion of the logic so that each signal could be controlled individually, which would also require one signal channel per lane.hansjoachim wrote:Really nice done with those combinators! I wanted to make a controllsenter, but had not gotten to that yet.
The deadlock situation can be fixed, you just have to check every output lane and block the input lane if the output lane is full.
I am working on improving it to get 346 trains/min. I'll try to get it done this evening.
It might be easier, and safer, to prevent the lights from advancing to the next green until all exit signals are green. That would be quite simple to set up. Change the clock to not reset itself, having it instead test an externally input condition, and have a decider spit out a value which satisfies it whenever the clock is over a certain value... and have another decider as a gate which only allows that value to pass through and reach the clock if all exit signals are green. Then change the gating of the green signal so that it only gets through while the clock is below a certain value, so the signals all go red when it exceeds that, basically flipping it around from its current logic (not allowing the signal through until the clock is over a certain value).
As for the throughput, I'm not sure you're going to be able to get it much higher with a four cycle crossing. One of the reasons the MultiCross gets such high throughput is that the crossing turns (right turns for LHD, left turns for RHD) don't conflict with the through traffic passing through the center because they've already swapped lanes prior to reaching that point, so the central crossing has only two cycles to get through -- North-South and East-West. The entire junction operates on two cycle crossings, in fact. The one you've based yours on has that four cycle crossing in the center, where to get every train where it's going, some of them have to wait for three other groups of trains to go first instead of just one. The way you've expanded the buffer zones and control the signals so that lots of trains go in a wave speeds things up considerably, but there's a limit imposed by the number of cycles required to let all trains get through.
Edit:
Here's a blueprint string with the changes I mentioned. I'd recommend deconstructing all the signals in this area with a filtered deconstruction planner before placing it, because circuit network settings don't get assigned correctly if an object already exists before you paste wires onto it. And the large power poles are no longer needed either. I used one rail signal on each side just to bridge the circuit wire across larger gaps, they are not to have the read or control boxes checked, as they are only being used as an anchor point to get the wire across. Also, the arithmetic combinators and wooden pole are just a diagnostic aid, filtering external and internal signals into one place for easy viewing without getting them mixed up internally. Those parts can be removed, as they (by design) don't affect the operation of the system at all.
Blueprint String
-
hansjoachim
- Filter Inserter
- Posts: 252
- Joined: Wed Apr 26, 2017 7:03 pm
- Contact:
Re: 4-way intersections: Throughput and deadlocks [image heavy]
The improved version lets 7,7 trains per lane/min pass. With a max throughput of 342 trains/min. But since the input is 346 the buffers will fill up and it won't get 6 trains ready in every lane before the next green light and the throughput will be lower. If it let's 7 trains pass through every green light it might get over 8per min/lane.
That was a nice way of dealing with deadlock, it is safe and easy. There are one problem though, it limits throughput in two ways. The output is limited as the signals are too far apart and the pause between every green light could be shorter.
I also have an idea to make the intersection more flexible.
Currently each line get 8 trains/min. But in set 2 the straight lanes gets 12 trains/min/lane, left gets 4 and the right turn gets 8.
If the straight lanes gets to pass more often then the left turn lanes the throughput with set 2 could be increased drastically.
Edit
If the intersection could switch between different setups it can maintain high throughput with different loads. It could be manually or it could count how the load is and adjust accordingly.
That was a nice way of dealing with deadlock, it is safe and easy. There are one problem though, it limits throughput in two ways. The output is limited as the signals are too far apart and the pause between every green light could be shorter.
I also have an idea to make the intersection more flexible.
Currently each line get 8 trains/min. But in set 2 the straight lanes gets 12 trains/min/lane, left gets 4 and the right turn gets 8.
If the straight lanes gets to pass more often then the left turn lanes the throughput with set 2 could be increased drastically.
Edit
If the intersection could switch between different setups it can maintain high throughput with different loads. It could be manually or it could count how the load is and adjust accordingly.
Re: 4-way intersections: Throughput and deadlocks [image heavy]
I built this intersection to be as low cost and easy to hand build as possible. It is cheap, especially in terms of signals, but does it perform well?
https://pastebin.com/GKy2jG0y
https://pastebin.com/GKy2jG0y
Re: 4-way intersections: Throughput and deadlocks [image heavy]
You're talking about the change I posted? Even with a longer delay, you're at the mercy of the random nunber generator when filling the input buffers -- you don't always get an even distribution of trains wanting to go all directions from all lanes, no matter how big you make them or how much time you allow.hansjoachim wrote:The improved version lets 7,7 trains per lane/min pass. With a max throughput of 342 trains/min. But since the input is 346 the buffers will fill up and it won't get 6 trains ready in every lane before the next green light and the throughput will be lower. If it let's 7 trains pass through every green light it might get over 8per min/lane.
That was a nice way of dealing with deadlock, it is safe and easy. There are one problem though, it limits throughput in two ways. The output is limited as the signals are too far apart and the pause between every green light could be shorter.
I also have an idea to make the intersection more flexible.
Currently each line get 8 trains/min. But in set 2 the straight lanes gets 12 trains/min/lane, left gets 4 and the right turn gets 8.
If the straight lanes gets to pass more often then the left turn lanes the throughput with set 2 could be increased drastically.
Edit
If the intersection could switch between different setups it can maintain high throughput with different loads. It could be manually or it could count how the load is and adjust accordingly.
If by "the signals are too far apart" you're talking about the ones which read whether the exit blocks are clear, those really need to be a train length long in order to ensure that the junction can't deadlock. Making them shorter so the lights cycle sooner would be unsafe in the same way it is for chain signal exit blocks. (They're basically performing the same job here.) Unless you wired up the entire row of signals along each lane for the length of a train, having them all report the presence of any train...
Hmm, now I can think of an optimization which would allow other phases to proceed even if the exit blocks for one set of lanes weren't clear, as long as none of the trains in them were blocking the crossing. It would need an extra row of rail signals, and each light phase would need to be able to return its own "block occupied" signal as well, without conflicting with the others. The first row of signals determines that the junction is clear, the second is placed as close as possible to that and has a train-length block after it for ensuring the exits are clear (or uses a series of signals all wired together, covering the same distance). Then it would need some logic to test whichever signal channel is associated with the lane it wants to activate next to ensure the exit area is clear. That would ensure it doesn't send trains into full blocks while also letting it cycle to the next phase as soon as the junction was clear for traffic going to other exits.
Your idea about making it adapt to traffic conditions is interesting, but I have a feeling it could be incredibly complex to implement. About the easiest way I can think of that wouldn't cause positive feedback is to estimate how many trains are waiting to go each direction using a whole LOT of wired up signals reporting their state on the entrance buffers, in eight groups, two for each entrance, one for going straight and one for turning. Each group reports on a different signal channel, and the logic is upgraded to handle eight different phases, some of which are capable of going at the same time (through traffic and double left turns for example).
The thing is, a lot of that extra complexity goes away just by making turns happen early, before you ever reach the central crossing, like I did in the MultiCross design. I've been thinking of expanding the buffer space near the center on that and setting up this control circuit to let more than one train go in each direction before switching, and seeing if that makes any significant difference in performance. That, and adding the Merge-O-Matic to all the exits.
Anything where all trains must pass through the same block is going to reduce throughput to about the lowest possible rate. A train cannot enter the junction until the previous train has completely exited, and if it wants to use the same exit as the previous train, it also has to wait for that train to clear the exit block before it can go (which, as usual, should be at least the length of the longest train in use to avoid the possibility of blocking the intersection). Cheap and/or compact are generally the opposite of high performance, sadly.lee1026 wrote:I built this intersection to be as low cost and easy to hand build as possible. It is cheap, especially in terms of signals, but does it perform well?
That said, you can actually make this even cheaper by removing the eight chain signals that are placed in pairs at the points of the diamond, cutting the number of signals in half. The junction's behavior will be exactly the same without them -- the chain and rail signals placed after the tracks split into one-way segments do the job just fine. If you're attaching one or more of the exits to a two-way track instead of a pair of one-way lanes though, then those chain signals are still necessary wherever such an attachment occurs, of course, but either way the number of signals required is always eight.
Re: 4-way intersections: Throughput and deadlocks [image heavy]
I like the progress that is being made on the traffic lights and the Merge-O-Matic. I'll make sure to add links to these kinds of improvements once they seem stable and easy to use/scale. I don't think I'll add variants using them in the OP though as that will A) basically double the amount of testing that needs to be done, and B) increase the post length by more than I'm comfortable with, it's already at about 50% of the character limit.
Added a throughput optimized variant as "Minimal" that allows some left/right turns to be taken at the same time. The signalling you provided will also get a deadlock rating of B (opposing trains turning left/right change to straight), but will have throughput comparable to/slightly better than "Direct cross": 23/23. The signalling Tallinu suggests will give it an A deadlock rating (truly single block) and throughput should only be very slightly lower than yours.lee1026 wrote:I built this intersection to be as low cost and easy to hand build as possible. It is cheap, especially in terms of signals, but does it perform well?
Re: 4-way intersections: Throughput and deadlocks [image heavy]
Aaargha,
On one of Xterminator's recent videos, I found a blueprint book of four 4-way junction designs by Captain Crumpet, and ran some tests on them. They come signaled for LHD. You can see them all well enough in the video so I'm not going to bother making my own screenshots of them, you'd probably do your own anyway if you want to catalog them.
I have a feeling all but the first might not get an A deadlock rating due to the way the right turns cross each other twice. I don't have your experience looking for deadlocks, so I'll leave it to you to figure out exactly what their ratings are, if you want to.
Xterm's video: https://www.youtube.com/watch?v=dBotQHoy818
Blueprint book link from the description: https://pastebin.com/g4FTgwWd
My results:
"2 lane square" set 1: 42 TPM, set 2: 45 TPM
"2 lane spiral" set 1: 31-32 TPM, set 2: 45 TPM
"4 lane spiral" set 1: 50 TPM, set 2: 59 TPM
"8 lane spiral" set 1: 54 TPM, set 2: Fluctuated far more than usual, in the 59-64 TPM range.
The 8-lane entry was particularly painful to watch. Right turns were the worst, as a single train attempting to make one would conflict with all other traffic except for another train making an identical right turn from one of the entry lanes right next to it. And when I shut off the spawners after the P1 test, it took over five minutes for all the trains to clear out. I really should've just saved before starting P1 and reloaded afterward, lol!
Perhaps they were basing their high opinions of these junctions on the fact that they were, gasp, properly signaled... and looked pretty? I guess they've never heard of this thread. XD
On one of Xterminator's recent videos, I found a blueprint book of four 4-way junction designs by Captain Crumpet, and ran some tests on them. They come signaled for LHD. You can see them all well enough in the video so I'm not going to bother making my own screenshots of them, you'd probably do your own anyway if you want to catalog them.
I have a feeling all but the first might not get an A deadlock rating due to the way the right turns cross each other twice. I don't have your experience looking for deadlocks, so I'll leave it to you to figure out exactly what their ratings are, if you want to.
Xterm's video: https://www.youtube.com/watch?v=dBotQHoy818
Blueprint book link from the description: https://pastebin.com/g4FTgwWd
My results:
"2 lane square" set 1: 42 TPM, set 2: 45 TPM
"2 lane spiral" set 1: 31-32 TPM, set 2: 45 TPM
"4 lane spiral" set 1: 50 TPM, set 2: 59 TPM
"8 lane spiral" set 1: 54 TPM, set 2: Fluctuated far more than usual, in the 59-64 TPM range.
The 8-lane entry was particularly painful to watch. Right turns were the worst, as a single train attempting to make one would conflict with all other traffic except for another train making an identical right turn from one of the entry lanes right next to it. And when I shut off the spawners after the P1 test, it took over five minutes for all the trains to clear out. I really should've just saved before starting P1 and reloaded afterward, lol!
Perhaps they were basing their high opinions of these junctions on the fact that they were, gasp, properly signaled... and looked pretty? I guess they've never heard of this thread. XD
Re: 4-way intersections: Throughput and deadlocks [image heavy]
Added them, except for "2 lane square" which is "Wide", with some slight signal optimizations (mostly for the 2- and 4-lane variants), and also an RHD variant of the 2-lane. The signalling that is used in the video and given in the blueprints gives a C deadlock rating, luckily there is room to place signals where needed so that it can be improved to B.Tallinu wrote:Aaargha,
On one of Xterminator's recent videos, I found a blueprint book of four 4-way junction designs by Captain Crumpet, and ran some tests on them. They come signaled for LHD. You can see them all well enough in the video so I'm not going to bother making my own screenshots of them, you'd probably do your own anyway if you want to catalog them.
I have a feeling all but the first might not get an A deadlock rating due to the way the right turns cross each other twice. I don't have your experience looking for deadlocks, so I'll leave it to you to figure out exactly what their ratings are, if you want to.
.....
The 8-lane entry was particularly painful to watch. Right turns were the worst, as a single train attempting to make one would conflict with all other traffic except for another train making an identical right turn from one of the entry lanes right next to it. And when I shut off the spawners after the P1 test, it took over five minutes for all the trains to clear out. I really should've just saved before starting P1 and reloaded afterward, lol!
Perhaps they were basing their high opinions of these junctions on the fact that they were, gasp, properly signaled... and looked pretty? I guess they've never heard of this thread. XD
That said, most intersections are actually mostly safe since the 0.15.27 patch. I've added some info on that in the OP and I'll do some planning for how to update my grading for that.
Yeah, that 8-lane design was a pretty perfect example of "more lanes is often not better", so thanks for the tip on saving
It sure seems like they've not seen this thread, it was pretty funny when they mentioned some of the "joke" submissions as they sure sounded a lot like your Multi-cross designs, or the derivatives that popped up on reddit
Re: 4-way intersections: Throughput and deadlocks [image heavy]
Yep, I was wondering if something like that might be the case too...
On a related note, I've been messing around with a long train version of the MultiCross, currently scaled for 14 car trains. To avoid making it incredibly unwieldy in length it has two of the less important buffer strips removed, compressing four lane-swap intersections into two. It still spills out of the grey tiled area slightly, but since it's a 4 lane the width is not too unreasonable. (It would have to be even longer as well as wider for 8 lanes, but I really don't see the point in making a 14 car version for that enormous scale. Even the 6 car 8 lane one was just an experiment, and that thing was massive enough.)
I found that I had to double the length of the split tracks leading to the paired train deletion stops, otherwise the exit tracks were backing up and throttling the max throughput of the junction. Any train more than a car or two longer than the defaults might experience a similar issue, and a train longer than 14 cars would undoubtedly require even more space on the deletion stops.
Also, I accidentally created infinitely growing trains (sorta). Turns out there's a reason the signal after the spawner is one tile out rather than immediately after it! Apparently they will attach the tail of the train that just left to the nose of the newly spawned train, and the combined train inherits the newly spawned one's schedule, eventually causing it to "no path" when the size of the train reaches a point where its nose is already beyond the track split it would need to turn at to reach its newly assigned destination. XD
I then put together a double spawner system which creates trains in two adjacent lanes and then merges them together with a short acceleration strip, but it turned out not to make any difference in the throughput I was getting, at least with this design.
Finally, I tried converting the test trains from 4-10-0 to 3-8-3 to see just how much difference it made, and it actually ended up reducing P1 throughput from 104 to 86. Noticeable even when simply watching the trains move... But not as big a difference as a 4/18 : 3/20 ratio would suggest (0.675). I'm not sure if this implies that acceleration is not directly proportional to the locomotive count to weight ratio, or if it's just "time required to enter and clear an intersection" that isn't proportional due to plain old physics math reasons that I haven't studied but which would apply equally to the real world, or if there's just enough leeway in the buffers and the timings that result from trains crossing paths to smooth things out.
Time to clear an intersection could easily be tested, though, using a timer that advances only while a specific small signal block crossing the train's path is red... Set up a lever to close the entrance signal, wait for a train to stop at it, reset the counter, then unlock and re-lock the signal (so another train can't zip through behind it and spoil the stored result)...
4-10-0: 238 ticks
3-8-3: 296 ticks
Repeating the measurement with multiple different trains of the same type resulted in the exact same result.
238/296 = 0.80405 So the terminal style train takes about 25% longer to cross through the intersection.
That's fairly close to 86/104 ~= 0.8269, enough so that the difference could be partially due to measurement inaccuracy in the TPM scores. So I have a feeling that intersection dwell time is the main culprit in slowing it down.
For reference, a 2-4-0 had a time of 148 ticks, a a 1-4-0 was 173, a 4-8-0 was 206, and a 2-4-2 was 211. All tests performed on a minimum width intersection aligned NS/EW using the following:
On a related note, I've been messing around with a long train version of the MultiCross, currently scaled for 14 car trains. To avoid making it incredibly unwieldy in length it has two of the less important buffer strips removed, compressing four lane-swap intersections into two. It still spills out of the grey tiled area slightly, but since it's a 4 lane the width is not too unreasonable. (It would have to be even longer as well as wider for 8 lanes, but I really don't see the point in making a 14 car version for that enormous scale. Even the 6 car 8 lane one was just an experiment, and that thing was massive enough.)
I found that I had to double the length of the split tracks leading to the paired train deletion stops, otherwise the exit tracks were backing up and throttling the max throughput of the junction. Any train more than a car or two longer than the defaults might experience a similar issue, and a train longer than 14 cars would undoubtedly require even more space on the deletion stops.
Also, I accidentally created infinitely growing trains (sorta). Turns out there's a reason the signal after the spawner is one tile out rather than immediately after it! Apparently they will attach the tail of the train that just left to the nose of the newly spawned train, and the combined train inherits the newly spawned one's schedule, eventually causing it to "no path" when the size of the train reaches a point where its nose is already beyond the track split it would need to turn at to reach its newly assigned destination. XD
I then put together a double spawner system which creates trains in two adjacent lanes and then merges them together with a short acceleration strip, but it turned out not to make any difference in the throughput I was getting, at least with this design.
Finally, I tried converting the test trains from 4-10-0 to 3-8-3 to see just how much difference it made, and it actually ended up reducing P1 throughput from 104 to 86. Noticeable even when simply watching the trains move... But not as big a difference as a 4/18 : 3/20 ratio would suggest (0.675). I'm not sure if this implies that acceleration is not directly proportional to the locomotive count to weight ratio, or if it's just "time required to enter and clear an intersection" that isn't proportional due to plain old physics math reasons that I haven't studied but which would apply equally to the real world, or if there's just enough leeway in the buffers and the timings that result from trains crossing paths to smooth things out.
Time to clear an intersection could easily be tested, though, using a timer that advances only while a specific small signal block crossing the train's path is red... Set up a lever to close the entrance signal, wait for a train to stop at it, reset the counter, then unlock and re-lock the signal (so another train can't zip through behind it and spoil the stored result)...
4-10-0: 238 ticks
3-8-3: 296 ticks
Repeating the measurement with multiple different trains of the same type resulted in the exact same result.
238/296 = 0.80405 So the terminal style train takes about 25% longer to cross through the intersection.
That's fairly close to 86/104 ~= 0.8269, enough so that the difference could be partially due to measurement inaccuracy in the TPM scores. So I have a feeling that intersection dwell time is the main culprit in slowing it down.
For reference, a 2-4-0 had a time of 148 ticks, a a 1-4-0 was 173, a 4-8-0 was 206, and a 2-4-2 was 211. All tests performed on a minimum width intersection aligned NS/EW using the following:
Blueprint String for Test Rig
Re: 4-way intersections: Throughput and deadlocks [image heavy]
You guys should do your own video where you talk about the tradeoffs that gain all of the throughput, how you test them, etc.aaargha wrote:Yeah, that 8-lane design was a pretty perfect example of "more lanes is often not better", so thanks for the tip on saving
It sure seems like they've not seen this thread, it was pretty funny when they mentioned some of the "joke" submissions as they sure sounded a lot like your Multi-cross designs, or the derivatives that popped up on reddit
Re: 4-way intersections: Throughput and deadlocks [image heavy]
I've been thinking of replacing them with instant stop stations but I don't think that the performance hit from all the extra path changing is worth it. For now, extending them is probably good enough.Tallinu wrote:I found that I had to double the length of the split tracks leading to the paired train deletion stops, otherwise the exit tracks were backing up and throttling the max throughput of the junction. Any train more than a car or two longer than the defaults might experience a similar issue, and a train longer than 14 cars would undoubtedly require even more space on the deletion stops.
That behaviour threw me for a loop when I was building the mod, so damn confusing. I thought that you would need to manually make the attachments when placing wagons with scripts, so I had already put code in for that, so when this happened I started debugging code that was not only bug free, but also redundant. As you can surely guess, it didn't help muchTallinu wrote:Also, I accidentally created infinitely growing trains (sorta). Turns out there's a reason the signal after the spawner is one tile out rather than immediately after it! Apparently they will attach the tail of the train that just left to the nose of the newly spawned train, and the combined train inherits the newly spawned one's schedule, eventually causing it to "no path" when the size of the train reaches a point where its nose is already beyond the track split it would need to turn at to reach its newly assigned destination. XD
But as the game apparently automatically attaches the carts to anything in the vicinity there is nothing I can do, as far as I know, to make it possible to place the signal directly after the station without messing with the previous train.
It might be that for the longer trains the current setup gives good enough saturation as it is. Anyway I'd probably try this out on a single stretch of rail first just to see if it works.Tallinu wrote:I then put together a double spawner system which creates trains in two adjacent lanes and then merges them together with a short acceleration strip, but it turned out not to make any difference in the throughput I was getting, at least with this design.
This is pretty interesting when you start to compare effective throughput (cargo wagons/minute), using 2-4 you get about 668 wagons/min, with 4-10 you get 1040, and with 3-8-3 you get 688. The terminus style train only gets about 66% of the RoRo train, that is pretty significant.Tallinu wrote:Finally, I tried converting the test trains from 4-10-0 to 3-8-3 to see just how much difference it made, and it actually ended up reducing P1 throughput from 104 to 86. Noticeable even when simply watching the trains move... But not as big a difference as a 4/18 : 3/20 ratio would suggest (0.675). I'm not sure if this implies that acceleration is not directly proportional to the locomotive count to weight ratio, or if it's just "time required to enter and clear an intersection" that isn't proportional due to plain old physics math reasons that I haven't studied but which would apply equally to the real world, or if there's just enough leeway in the buffers and the timings that result from trains crossing paths to smooth things out.
I'm not sure if the acceleration formulas are fully known yet, there was a post on the subreddit a few days ago that had some formulas that seemed pretty accurate, if you want to take a closer look at it.
That sounds pretty likely, it also seems to fit the measurements for the 2-4. Some of the variance can perhaps also be explained by the different braking distances, but I'm not sure if that's significant enough.Tallinu wrote:Time to clear an intersection could easily be tested, though, using a timer that advances only while a specific small signal block crossing the train's path is red... Set up a lever to close the entrance signal, wait for a train to stop at it, reset the counter, then unlock and re-lock the signal (so another train can't zip through behind it and spoil the stored result)...
4-10-0: 238 ticks
3-8-3: 296 ticks
Repeating the measurement with multiple different trains of the same type resulted in the exact same result.
238/296 = 0.80405 So the terminal style train takes about 25% longer to cross through the intersection.
That's fairly close to 86/104 ~= 0.8269, enough so that the difference could be partially due to measurement inaccuracy in the TPM scores. So I have a feeling that intersection dwell time is the main culprit in slowing it down.
For reference, a 2-4-0 had a time of 148 ticks, a a 1-4-0 was 173, a 4-8-0 was 206, and a 2-4-2 was 211. All tests performed on a minimum width intersection aligned NS/EW using the following:
Perhaps, but just thinking about the amount of work it would take to make that not a total mess makes the prospect a bit ... unappealingdb48x wrote:You guys should do your own video where you talk about the tradeoffs that gain all of the throughput, how you test them, etc.
I'll probably leave the video making to those that have more of an interest in that and stick to text, at least for now, it takes long enough for me to structure my things anyway Re: 4-way intersections: Throughput and deadlocks [image heavy]
I feel i should chime in here as ive spent the last week building a mathematical model that trys to predict the tpm of a junction based on its clear length (which is usually the trains length in tiles + a constant for the junction) and a saturation multiplier (which works out to be the average number of trains exiting the intersection at any single point in time). the multiplier is independent of train type/size only on pathing probabilities, while clear length is independent of traffic.Tallinu wrote:
Finally, I tried converting the test trains from 4-10-0 to 3-8-3 to see just how much difference it made, and it actually ended up reducing P1 throughput from 104 to 86. Noticeable even when simply watching the trains move... But not as big a difference as a 4/18 : 3/20 ratio would suggest (0.675). I'm not sure if this implies that acceleration is not directly proportional to the locomotive count to weight ratio, or if it's just "time required to enter and clear an intersection" that isn't proportional due to plain old physics math reasons that I haven't studied but which would apply equally to the real world, or if there's just enough leeway in the buffers and the timings that result from trains crossing paths to smooth things out.
Time to clear an intersection could easily be tested, though, using a timer that advances only while a specific small signal block crossing the train's path is red... Set up a lever to close the entrance signal, wait for a train to stop at it, reset the counter, then unlock and re-lock the signal (so another train can't zip through behind it and spoil the stored result)...
4-10-0: 238 ticks
3-8-3: 296 ticks
Repeating the measurement with multiple different trains of the same type resulted in the exact same result.
238/296 = 0.80405 So the terminal style train takes about 25% longer to cross through the intersection.
That's fairly close to 86/104 ~= 0.8269, enough so that the difference could be partially due to measurement inaccuracy in the TPM scores. So I have a feeling that intersection dwell time is the main culprit in slowing it down.
For reference, a 2-4-0 had a time of 148 ticks, a a 1-4-0 was 173, a 4-8-0 was 206, and a 2-4-2 was 211.
so far ive only been testing it on a simple 2->1 lane merge, but its accurate to 1.5% on those (also conveniently giving the maximum throughput of a single track without using combinator controlled merging [22.92tpm for 2-4-0, 16.07tpm for 3-8-3 and 3.10tpm for 10-90-0])
i would like to extend the testing to actual junctions, but i need to choose which junction as a test bench (if possible one thats already in heavy use by the community)
Re: 4-way intersections: Throughput and deadlocks [image heavy]
Well, even the extended length I gave the deletion stations has been overwhelmed!aaargha wrote:I've been thinking of replacing them with instant stop stations but I don't think that the performance hit from all the extra path changing is worth it. For now, extending them is probably good enough.Tallinu wrote:I found that I had to double the length of the split tracks leading to the paired train deletion stops, otherwise the exit tracks were backing up and throttling the max throughput of the junction. Any train more than a car or two longer than the defaults might experience a similar issue, and a train longer than 14 cars would undoubtedly require even more space on the deletion stops.
Blueprint String
This upgraded spawner I've been working on now should be able to handle variable length trains, and automatically resets if traffic backs up and causes a spawned train to stop before the merge point. I've been testing it with 4-10-0 trains so far and it handles them beautifully, so well in fact that the amount of traffic put out across a straight left-to-right connection is more than the pair of deletion stops can handle, even though they're about 25% longer than the trains are. Traffic across the line becomes gradually slower, until trains leaving the spawner aren't even able to hit top speed at all, eventually causing the spawners to begin occasionally resetting just because traffic can't quite exit fast enough to keep up!Screenshot of Traffic Congestion
Screenshot of Super Spawner
I've now tested it with 2-4-0 trains as well, on default length deletion tracks, and the same problem occurs.So, those "instant stop stations"... How does that work?
I don't know for sure, but the only alternative I can see is to make three or four copies of each deletion stop instead of two and put them much, much further down each of the forks so trains don't start slowing down until they have fully entered one fork...
Further Edit: I decided to find out exactly how many duplicate deletion stops would be required to handle saturated high-speed traffic without causing slowdowns, so I tore out one of the regular set, took the tracks about 50-60 tiles past the template area, and had each of the four tracks make a branching right angle turn into eight more 140 tile tracks, ending with the deletion stops. 2-4-0 trains being launched by my fast spawner appear to only require five of them... but no harm in leaving in extras, just in case!
Screenshot of Super Deleter
Aaand a few more tweaks made, splitting the branches into several smaller blocks instead of a big one leading to all eight tracks. While it improved results, it didn't improve it as much as I expected. But I think I've figured out why.Trains try to reserve longer sections of track as their speed increases, and when they can't reserve as much track as they want (due to a train ahead of them) they won't accelerate until they can. Or to be more precise, they enter braking mode until the block becomes free, then reserve it and, if that gives them enough extra room, they switch back to accelerating... but when blocks are small, this switching back and forth happens rapidly and they maintain approximately the same speed.
When the distance between a series of trains is more or less steady, the amount of track each train can reserve is also steady, meaning that each train cannot reserve any more track than it already is, which in turn means that they won't go any faster. No tailgating allowed!
It's like trains effectively grow in length the faster they are traveling!
It also seems like the distance a train tries to reserve may not have a linear relation to its speed. I'm not sure how to go about accurately measuring this to determine the exact relationship. Wiring up an entire length of track with minimally spaced signals and measuring how many yellows it counts wouldn't be hard to set up, but it would be a little tricky to associate yellow counts with exact speeds except for the three top speeds granted by different fuel types. Finding a way to calculate the speed of a train based on the pulses of signals turning red or green might also be possible... Getting correct conversions between rate of signal pulses per, say, kilotick and the displayed top speed values would require some testing.
Oh, and some speed measurements from the straight-through spawner to deleter tests I've been running between the east and west stations...
Turning onto straight track right after the spawner/deleter side-swap grid: About 200kph
Passing first (opposing) counter, heading toward middle: About 225-230kph
Middle of map: 235kph
Passing far counters (and being counted): 255-260kph
They continue accelerating to top speed as they approach the branches to the deletion tracks. The moment the train ahead of them clears the part of the branches they want to use, their path is no longer blocked and they can reserve as much as they want.
It's reading about 263 TPM for eight lanes of 2-4-0 traffic doing this (all four lanes from each of two spawners). 4-10-0 is getting about 164 TPM. If it was a four-way instead of two-way test, that would be the equivalent of 526 TPM and 328 TPM, but without tunnels or bridges...
Not gonna happen.Some more interesting results...
Train size, tiles physically occupied, tiles reserved at top speed (not counting whatever other tiles are part of the last block reserved), total track required at top speed:
2-4-0: 20-21, 58-59, 79
4-10-0: 48-49, 59-60, 108
Since the number of tiles reserved is virtually identical, the larger train makes far better use of the track by dramatically increasing the cargo to track ratio...
Last edited by Tallinu on Tue Aug 08, 2017 1:00 pm, edited 2 times in total.
Re: 4-way intersections: Throughput and deadlocks [image heavy]
From a physics/maths perspective, if braking is a constant deceleration, then doubling the trains speed means they take twice as long to stop, and need 4 times as much space.
For constant deceleration, stopping distance is proportional to speed squared, so a 10% increase in speed is a 21% increase in braking distance. (1.1 x 1.1 = 1.21)
For constant deceleration, stopping distance is proportional to speed squared, so a 10% increase in speed is a 21% increase in braking distance. (1.1 x 1.1 = 1.21)
-
ridesdragons
- Inserter
- Posts: 28
- Joined: Sun Feb 05, 2017 9:30 am
- Contact:
Re: 4-way intersections: Throughput and deadlocks [image heavy]
I'm guessing anything you've tested/looked at is in the OP? anyway, I made a design a ways back that as far as I can see works fine, though I guess with pathing bugs that could change things. think you could rate/test my intersection? it's a 2-lane roundabout.
also, my roundabout design was made quite a while ago. as far as I can see, it works identical to one that uses proper signalling habits, but just in case, I remade it with proper signalling habits. sorry they're right-handed. neither of them utilize a buffer. either you pass through or you wait at the entrance.
also, my roundabout design was made quite a while ago. as far as I can see, it works identical to one that uses proper signalling habits, but just in case, I remade it with proper signalling habits. sorry they're right-handed. neither of them utilize a buffer. either you pass through or you wait at the entrance.
roundabout old
roundabout proper
