Page 3 of 36

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Sun May 14, 2017 8:59 am
by aaargha
AndrewIRL wrote:I was wondering how throughput would be affected with 1-4-1 trains. In theory the lower speed of 1-way vs 2-way trains should mean a significant decrease in throughput.

Code: Select all

LL-CCCC,  ratio = 2, top speed = 259.2
L-CCCC-L, ratio = 6, top speed = 134.6
The 1-4-1 train has only 52.93% the speed of the 2-4-0 so I would predict that the maximum throughput will be somewhere in the range: 20-26 down from 64 for the highest throughput intersection.

Maybe you would be willing to test just one intersection, the big 64 throughput cross?
I don't know which version those numbers are from but in 0.15.10 both setups have a top speed of 298.1 km/h when rocket fuelled, the 1-4-1 just takes longer to get there. I'd guess this means that intersections that already have low throughput will be hit harder than the cross one as trains are less likely to have to stop in that design, compare that to the low throughput roundabout or something where the trains are always sitting at the intersection and waiting their turn.

I might be willing to run some tests once the theory seems at least plausible :) In the current setup changing train type is far more manual work than changing intersection. Hmmm, I should look into some kind of automatic train deployment mod...

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Sun May 14, 2017 9:53 am
by AndrewIRL
aaargha wrote:I don't know which version those numbers are from but in 0.15.10 both setups have a top speed of 298.1 km/h when rocket fuelled, the 1-4-1 just takes longer to get there.
I got the numbers from here:
https://www.reddit.com/r/factorio/comme ... comotives/
One year old, I think they apply to 0.13/0.14

aaargha wrote:I might be willing to run some tests once the theory seems at least plausible :)
My theory isn't plausible if the trains achieve the same top speed as the fundamental assumption (dramatically different top speeds) doesn't hold true and thus the entire thing falls apart.


Currently I don't have 0.15, waiting for stable release. I have a bad tendency to throw my toys out of the pram when there are game-breaking changes so I stay away from experimental releases.

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Sun May 14, 2017 10:51 am
by Distelzombie
This is so easy to test with combinators. Make a course with several different train setups on a straight line, place a signal infront where all of them are as far away from the finish as the others, connect those signals to a switch, place a signal on the destination train station that you read its red value from with a combinator, have a logic that measures the ticks since you pressed the switch and then either more logic to convert ticks to minutes and seconds or do it yourself.

Do this with different fuels and different trains and your good to go ( lcl, lccl, lccccl, llccccll, llcccccc, lllcccccclll, cl, ccl, ccccl, ccccll, ccccccll, cccccclll)

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Sun May 14, 2017 12:49 pm
by Shokubai
I see a lot of common signaling issues in some of these and regularly on "accepted" junctions throughout the forums. Missing start signals, missing end signals, and crosses which are too small to adequately break up each block. Ideally, Every crossing makes a shape (Triangle, square, etc...). This shape requires a chain signal in every direction. As long as the gap between crossing rails is big enough for signal on each path then deadlocks will be minimized. Anywhere a track crosses leaving little or no gap for signaling will always be a problem. Note the triangle on the left is impossible to signal internally.
1.png
1.png (795.28 KiB) Viewed 20180 times
*No this is not two way rail just emphasizing room for signals in the shape.

While I have long since left roundabouts behind in favor of large crosses, they do simplify this principle.
Mehve wrote:I used this particular roundabout implementation for quite some time without a single hiccup. I'm curious how it stacks up in the tester...

Image
Another common error I see is one of too few signals on longer stretches of track in a junction. Note that the right hand turns only have a chain signal at the end of the path. This means a train must PASS this signal before the strait path will open. By placing a signal at the start of the right hand turn the train only needs to clear the turn to open the path again. Again, Ideally, right hand turns should be long enough to hold an entire train between signals but this isn't strictly required just a nice feature. Also in this picture note the unsignalable triangles.

*Ignore the red circles.
Distelzombie wrote:Ok. How do you see that without testing??
Image
Here is an example of what i am talking about that easily shows the difference in block mechanics and internal signaling.
11.png
11.png (1.35 MiB) Viewed 20173 times
22.png
22.png (1.36 MiB) Viewed 20173 times

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Sun May 14, 2017 9:33 pm
by Distelzombie
Shokubai wrote:Another common error I see is one of too few signals on longer stretches of track in a junction. Note that the right hand turns only have a chain signal at the end of the path. This means a train must PASS this signal before the strait path will open. By placing a signal at the start of the right hand turn the train only needs to clear the turn to open the path again. Again, Ideally, right hand turns should be long enough to hold an entire train between signals but this isn't strictly required just a nice feature. Also in this picture note the unsignalable triangles.
Makes sense. It doesnt save even a second, but OCD. XD The "WIDE B" setup seems to be ok though.
Do you have a good junction that you use often?

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Sun May 14, 2017 11:48 pm
by Shokubai
Distelzombie wrote:Makes sense. It doesnt save even a second, but OCD. XD The "WIDE B" setup seems to be ok though.
Do you have a good junction that you use often?
Just like cars...1 second of slow down can cause a caterpillar effect down the line.

Lately I've been working toward avoiding Crosses and limiting junctions to T's wherever I can. This (or variations of it) is my go to standard 2 lane T. In busier intersections I will create a stop zone on the right hand turns as sort of a waiting bay so as to not hinder through traffic. Honestly my best trick for train management has always been to plan my routes carefully and avoid sending everything down the same highway.
1.png
1.png (978.79 KiB) Viewed 20151 times
I've even played with the idea of a Double T junction in lieu of a cross and it isn't bad.

One other trick I like it to place my normal signals closer together at the exits of stations and junctions. It simply helps each successive train start accelerating a little bit sooner.

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Mon May 15, 2017 1:11 am
by AndrewIRL
Distelzombie wrote:
Shokubai wrote:Note that the right hand turns only have a chain signal at the end of the path. This means a train must PASS this signal before the strait path will open. By placing a signal at the start of the right hand turn the train only needs to clear the turn to open the path again.
Makes sense. It doesnt save even a second, but OCD.
It isn't about OCD, it is about throughput. Every delay in the intersection affects multiple lines and you get a traffic wave effect if the intersection is nearing capacity. If you only have one train every few minutes then it won't save even a second.

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Mon May 15, 2017 1:33 am
by Aeternus
Additionally, a backlog of traffic can cause traffic to back up, requiring the intersection to function at peak capacity for longer stretches of times. It's smart to keep this into consideration as well when laying tracks and determining which stations go where. If you've got a ton of small ore hoppers for instance, it's smart to try to avoid sending those on the same general route as your main factory trains, or have transfer stations transfer the ore to longer trains before sending them on congested parts of your rail net. If you do this consistently, you can get away with much simpler designs, such as that direct cross I posted, but I agree with sentiments posted earlier: Avoid 4 way crosses in favor of T junctions with at least 4 or so train lengths between any intersections that involve the parallel tracks simultaneously - much better throughput that way.

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Mon May 15, 2017 1:46 am
by Distelzombie
AndrewIRL wrote:It isn't about OCD, it is about throughput. Every delay in the intersection affects multiple lines and you get a traffic wave effect if the intersection is nearing capacity. If you only have one train every few minutes then it won't save even a second.
Dude. It is literally OCD. Everything HAS TO BE PERFECT!!! :x :twisted: AAAAAAAAAAAAHH!
Aeternus wrote:Avoid 4 way crosses in favor of T junctions with at least 4 or so train lengths between any intersections that involve the parallel tracks simultaneously - much better throughput that way.
Now I remember hearing that somewhere. You're right. But it doesnt really matter unless you have a megabase.

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Mon May 15, 2017 12:44 pm
by aaargha
Tested: 2x high-perf-3-way, no RHD blueprint as it's basically just for comparison.
Shokubai wrote:Lots of signalling advice
Most of this is what I do when optimizing the signalling before testing a junction. If you see anywhere in the OP where I've missed something please let me know.
Shokubai wrote:I've even played with the idea of a Double T junction in lieu of a cross and it isn't bad.
Aeternus wrote:but I agree with sentiments posted earlier: Avoid 4 way crosses in favor of T junctions with at least 4 or so train lengths between any intersections that involve the parallel tracks simultaneously - much better throughput that way.
Distelzombie wrote:Now I remember hearing that somewhere. You're right. But it doesnt really matter unless you have a megabase.
Do any of you have a source on this with some actual data on this? It's starting to feel like this is some kind of urban legend, I see it here and there but so far no one has had anything to back it up with. I'd be most interested to see if it actually has some merit.

I will say though that none of my testing on the matter points toward it being the case. So far for the different classes of in-/output dependencies I've tested a proper 4-way has performed better than two 3-way junctions. The reason being that two 3-way junctions have more path dependencies than a good 4-way. If we use the ones in the OP as an example (see "2x 3-way"): trains going W->S share a path with trains going N->E, trains going E->N share a path with trains going S->W. This dependency does not exist in the better 4-way junction of the same class: Wide, Wide B, Compact Celtic knot and Compact. This is likely why they perform about 10% better than a 2x 3-way solution.
Shokubai wrote:One other trick I like it to place my normal signals closer together at the exits of stations and junctions. It simply helps each successive train start accelerating a little bit sooner.
Note that this may cause trains to stop while still in the junction unless you've got full control of where trains may stop due to getting backed up.

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Mon May 15, 2017 1:01 pm
by Shokubai
aaargha wrote: Note that this may cause trains to stop while still in the junction unless you've got full control of where trains may stop due to getting backed up.
I understand what you are saying. This works best in true exits that don't immediately intersect some other cross. The idea is simply that an accelerating train clears each evenly spaced signal at a different rate. Simply adding a half-stop signal between your first two exit signals gives you another check to allow the next train to begin accelerating.

Here is an example.
1.png
1.png (247.21 KiB) Viewed 20123 times
aaargha wrote: Do any of you have a source on this with some actual data on this? It's starting to feel like this is some kind of urban legend, I see it here and there but so far no one has had anything to back it up with. I'd be most interested to see if it actually has some merit.
No, purely anecdotal or personal experience and I've done some games with hundreds of trains. I am interested in the math but it either works or doesn't in my particular setup and outside of the odd trick or tip to improve responsiveness any good junction can work if it has space to be signaled properly.

To add to your testing. Here is one I am a fan of in principle but have only used in limited quantity due to my aversion of 4-way crosses. If you do test it, you may play with adding a second signal to the longer stretches of internal track. Also I'm sure i missed a signal in there somewhere scratching this together. I think this is a bigger version of the R-Twister you tested and with more signaling.
2.png
2.png (1.58 MiB) Viewed 20117 times
What I found I liked most about this is that on left hand turns you can make the track longer before intersecting the right turn. This makes the junction bigger but means you could add stopping for left turns to clear your strait paths. The junction becomes bigger but also more fluid.

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Mon May 15, 2017 3:40 pm
by Distelzombie
aaargha wrote:Do any of you have a source on this with some actual data on this? It's starting to feel like this is some kind of urban legend, I see it here and there but so far no one has had anything to back it up with. I'd be most interested to see if it actually has some merit.
Well, Xterminator and his guys (Youtube/Twitch guys) have made a map with >350 trains (2-4-2, 1k science packs per minute) They said this several times, even in a tutorial they said this. They are pretty much professionals, thats why i trusted them. XD
Well if you are testing this you can settle this once and for all. Try different train lenghts and 4 lane systems. What lenght are you using anyway?

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Mon May 15, 2017 5:57 pm
by aaargha
Shokubai wrote:I understand what you are saying. This works best in true exits that don't immediately intersect some other cross. The idea is simply that an accelerating train clears each evenly spaced signal at a different rate. Simply adding a half-stop signal between your first two exit signals gives you another check to allow the next train to begin accelerating.
Yeah, as long as you design with it in mind you should have no problems.
Shokubai wrote:No, purely anecdotal or personal experience and I've done some games with hundreds of trains. I am interested in the math but it either works or doesn't in my particular setup and outside of the odd trick or tip to improve responsiveness any good junction can work if it has space to be signaled properly.
Oh well, the search continues.
Shokubai wrote:To add to your testing. Here is one I am a fan of in principle but have only used in limited quantity due to my aversion of 4-way crosses. If you do test it, you may play with adding a second signal to the longer stretches of internal track. Also I'm sure i missed a signal in there somewhere scratching this together. I think this is a bigger version of the R-Twister you tested and with more signaling.
2.png
What I found I liked most about this is that on left hand turns you can make the track longer before intersecting the right turn. This makes the junction bigger but means you could add stopping for left turns to clear your strait paths. The junction becomes bigger but also more fluid.
From a quick look I'd guess it's worse than the twister with regards to throughput and deadlocks. However, if you drop a blueprint string I'll run it through the gauntlet and also compare it with how I'd signal it. I'm not sure I'll be able to measure a difference but we'll see :)
Distelzombie wrote:Well, Xterminator and his guys (Youtube/Twitch guys) have made a map with >350 trains (2-4-2, 1k science packs per minute) They said this several times, even in a tutorial they said this. They are pretty much professionals, thats why i trusted them. XD
Well if you are testing this you can settle this once and for all. Try different train lenghts and 4 lane systems. What lenght are you using anyway?
Ah, that would explain why it's such a common notion. I'll have to look around and see if they have some results to share.

Info about the test setup is in the OP. I don't have multi-lane support yet but I'm working on a setup for testing up to 8 lane intersections, it's a bit tricky to get it flexible enough though.

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Mon May 15, 2017 6:40 pm
by Distelzombie
aaargha wrote:Ah, that would explain why it's such a common notion. I'll have to look around and see if they have some results to share.

Info about the test setup is in the OP. I don't have multi-lane support yet but I'm working on a setup for testing up to 8 lane intersections, it's a bit tricky to get it flexible enough though.
Just ask in his newest youtube video. He usually answers.
Twitch is more chaotic though. Best thing - if it has to be twitch - is asking ColonelWill in his stream of their game because he has chat visible on his screen. And there are many skilled people and sometimes devs around to answer stuff.

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Tue May 16, 2017 12:32 am
by iceman_1212
I have noticed that many folks overuse chain signals. For a "cleanly" signaled 3-way intersection, I would refer folks to aaargha's 2x 3-way intersection in the first post of this thread.

In this intersection, for example, the circled signals can be replaced with rail signals:

Image

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Tue May 16, 2017 12:38 am
by Distelzombie
Rail signals give a track priority over a chain signalled track, I heard. This could cause issues.
Hm. aaargha, could you test if this does increase troughput?

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Tue May 16, 2017 1:01 am
by iceman_1212
Distelzombie wrote:Rail signals give a track priority over a chain signalled track, I heard. This could cause issues.
Hm. aaargha, could you test if this does increase troughput?
Yes, this "priority" effect does works to a certain extent and is particularly useful in multi-train stations if we want to give priority to trains exiting the stations (over trains entering the stations). In this example, however, the split-offs coming from all 3 directions start with chain signals.

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Tue May 16, 2017 8:30 am
by aaargha
Yeah, rail signals can be used to give paths priority over other, chain signalled, paths in a merge. However, the priority is only decided by the signals closest to the merge.
merge_prio.png
merge_prio.png (402.25 KiB) Viewed 20234 times
In this picture trains coming from below have priority over trains coming from above because the trains from below are only waiting for block A to clear. For trains coming from above both blocks A and B need to be clear, so if two trains are waiting for a train currently in the merge the ones from below will occupy A as soon as it's free while the ones from above are still stick waiting on B.

The way I and Shokubai have signalled the intersections do not give any lane priority like this. The signalling you suggest, iceman_1212, does give priority to the outer lanes (turning right, or going straight from the east) to avoid this, if you want to, I'd remove the last rail signal on each output and replace the chain signals coming from the crossings with rail signals.
Distelzombie wrote:Rail signals give a track priority over a chain signalled track, I heard. This could cause issues.
Hm. aaargha, could you test if this does increase troughput?
I think that whether or not this will increase throughput depends on how you've planned your traffic. For example you might want to give priority to trains already on a heavily trafficked main line instead of trains trying to enter said main line. I don't really think it makes sense to try to add that to the current suite though as it's too dependent on the rest of the rail system, also, each intersection can be made in probably 10+ variants. It might be useful for 2x 3-way configurations though, to give priority to trains in the central part, so I may do some tests on that to see if there is any difference.

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Tue May 16, 2017 12:56 pm
by Shokubai
iceman_1212 wrote:I have noticed that many folks overuse chain signals. For a "cleanly" signaled 3-way intersection, I would refer folks to aaargha's 2x 3-way intersection in the first post of this thread.

In this intersection, for example, the circled signals can be replaced with rail signals:

Image
The entire point of using chains exclusively is to prevent a train stopping and blocking the intersection. It's exactly like preventing gridlock in the city. Stop at the red light not in the middle of the intersection. There is no need to add priority UNLESS i wanted , for instance, to make the East to West Left turn have priority at the expense of my West to East traffic. This is generally no desirable reason for me to ever intentionally gridlock a junction.

By making them standard you intentionally allow a train to stop AT that signal...in the middle of your junction. Again, this may be desirable if priority is really what you are after but I've never designed a system where I needed to block one direction to let another train move.

Standard signals should be used if your track segment is long enough to hold an entire train. This junction will allow traffic through but not stopping for my standard 2-4 or 1-4-1 trains.

Re: 4-way intersection testing: Throughput and deadlocks

Posted: Tue May 16, 2017 8:11 pm
by aaargha
Here are the results on your variant Shokubai:
Blueprint string
Deadlock rating B
Throughput: 30

To preserve the A deadlock rating for right hand drive you need to twist it the other way, if that makes sense (the blueprint in the OP should make it obvious if not).

The reason for the throughput reduction is that the intersection distance (from first chain to rail signal at the beginning of the output block) is more than twice as long as the one in the OP for any path meaning that trains will block the intersection for longer.

I though I'd also post a step by step of the throughput part of the signal optimizations I do before testing. This just covers final adjustments, the intersection should already be sufficiently signalled beforehand (placing chains everywhere usually does a sufficient job :) ), so you should probably be pretty comfortable with signalling before you start with this. I'll explain the steps below the picture, just open it in a new tab if it's too small. Also if anyone could provide me with some sample code for a working numbered list I'd be most grateful, I can't seem to get it to work.
The picture
  • 1 Remove redundant chain signals: along a single stretch piece of track any chain signal after the first one encountered by a train can be removed*.
  • 2 Optimize chain signal placement within the intersection: push chain signals as far back along the track they're on as possible so that trains clear the previous block as soon as possible.
  • 3 Optimize output signals: push the rail signals as far back along the tracks as possible, stop when you hit a track you couldn't reach with a train (crossing/merge), go each way on a split, and remove any chain signals you pass. Signals marked with orange are the ones to size the output block after.
  • If you value trains being able to change paths while waiting highly stop here. I don't as they almost never have the time to anyway.
  • 4 Remove/replace entrance chain signals (only do this if there are other chain signals before any rail crossings!): any chain signal before the one by the by the crossing can be removed/replaced with rail signals.
  • 5 Optimize new entrance chain signals: push them forward as close to the crossings/merges as possible.
  • 6 Optimize paths that go directly from input to output blocks: these paths should only have a rail signal on them now, add as may as you like as long as you don't start to cut into the output for paths with chain signals, limit is marked in purple.
7 is the finished result, orange signals are the only ones that limit the output blocks as it does not matter if a train stops halfway through the outer lanes.
* There are exceptions for this that have to do with path changing deadlocks but that is not relevant in this case, it's mostly of "academic" interest anyway.

Hopefully that is understandable and of interest for someone looking to get those last 5-10% extra throughput out of their intersection :)