Page 5 of 36
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Fri May 19, 2017 10:59 pm
by Distelzombie
It is so big it drops your FPS by 10 xD
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Sat May 20, 2017 4:12 am
by impetus maximus
Distelzombie wrote:It is so big it drops your FPS by 10 xD
had to zoom out to 0.1 and my Toaster graphics (HD 3000) didn't care for that.
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Sun May 21, 2017 3:19 pm
by Rapier31
I haven't been able to find any decent working designs of 8 lane 4 way intersections, so I spent a stupid amount of time designing my own. It should work fine(haven't tested yet), but I really don't like the look of it. It unfortunately resembles a swastika and I'd love to redo it, but there isn't enough room to make it work properly in the layout. It will have to be bigger or just completely different, and it is really big already, so.... Here are some pics and the BP's. I'm also throwing in the design for a T junction that was inspired from a reddit post that I saw.
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Sun May 21, 2017 5:08 pm
by Miravlix
I noticed an issue with the use of chain signals.
You have trains moving east<->west at the same time, if they perfectly overlap the signals, the north<->south train never gets access to reserving a route.
First the east->west train will reserve the route blocking a north/south train, before it clears, the west->east train arrives reserving the intersection, now a new east->west train arrives just as the west->east train leaves and again blocks north/south from reserving because it needs access past *both* trains to get a reservation.
Looks to me like many of these designs has what you may call a soft deadlock, but it is still a situation where two lanes with high traffic can prevent the two other lanes from accessing the intersection, so to me it's just as bad as a deadlock that can only be solved by player action.
I hate to admit it, but the roundabout design with a complete intersection lockdown, might actually be the best design here. Not that I would ever use something that creates a loop as this result in weird pathing.
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Mon May 22, 2017 9:12 am
by aaargha
Update on the multi-lane testing: I've started to do some initial runs and while 4-lane seems to work fine there is a bit of an issue with how the trains distribute themselves over the lanes for 8-lane intersections. Hopefully I can resolve it without having to update the schedule of all 160 trains involved.
Miravlix wrote:I noticed an issue with the use of chain signals.
You have trains moving east<->west at the same time, if they perfectly overlap the signals, the north<->south train never gets access to reserving a route.
First the east->west train will reserve the route blocking a north/south train, before it clears, the west->east train arrives reserving the intersection, now a new east->west train arrives just as the west->east train leaves and again blocks north/south from reserving because it needs access past *both* trains to get a reservation.
Looks to me like many of these designs has what you may call a soft deadlock, but it is still a situation where two lanes with high traffic can prevent the two other lanes from accessing the intersection, so to me it's just as bad as a deadlock that can only be solved by player action.
I hate to admit it, but the roundabout design with a complete intersection lockdown, might actually be the best design here. Not that I would ever use something that creates a loop as this result in weird pathing.
This issue is known as
starvation in computer science, in this case the trains are the processes and the intersection is the shared resource.
I've looked at the issue in multi-station stackers, where it can also happen, and there at least it can be solved in a good way with circuitry. I'll probably redo my tests for 0.15 and try to do a write-up about it once I've got the throughput tester working satisfactory and ran most of those tests.
As you say this can also happen in intersections and I've seen that a bit with the multi-lane intersections, once a direction gets going it can usually sustain itself for a few trains until there is a gap large enough for some other direction to squeeze in. The fact that the trains also have to clear the output block before another train can use the same path makes it more likely for large enough gaps to form though.
Single block intersections could be the answer depending on how the game decides which train gets to enter the block if there are multiple trains waiting on the same block. As far as I can tell the train with the lowest ID (can be seen in station with the read stopped train circuit condition) gets to go first. In the very small test I did the train with ID 1819 always got to go before 1820 no matter who arrived first or which train came from which lane. That means that if you for example have a situation with pretty heavy traffic going both N-S and E-W, once the train with the largest ID (that is using the intersection, not globally) reaches the intersection it will never get to enter as there is always a train with lower ID waiting to enter. This will effectively cut-off traffic in one direction. This situation is much less likely to arise in the intersections that allow traffic in multiple directions (at least for 2-lane systems) as the amount of traffic needed before it becomes an issue is in many cases more than twice as much.
So in short, to my knowledge, the only way to avoid starvation you'd need to make an intersection starvation free is by building some kind of circuit controlled traffic light system that ensures that no lane gets blocked for too long. Single block intersections do not help and may, in may situations, actually be worse. I'd also say that if this is becoming an issue it's most likely a sign that the train system is becoming overloaded and it's time to either upgrade the train system, better intersections/more lanes, to be able to handle more trains or re-plan some train routes to better spread traffic.
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Mon May 22, 2017 11:24 am
by Miravlix
aaargha wrote:So in short, to my knowledge, the only way to avoid starvation you'd need to make an intersection starvation free is by building some kind of circuit controlled traffic light system that ensures that no lane gets blocked for too long. Single block intersections do not help and may, in may situations, actually be worse. I'd also say that if this is becoming an issue it's most likely a sign that the train system is becoming overloaded and it's time to either upgrade the train system, better intersections/more lanes, to be able to handle more trains or re-plan some train routes to better spread traffic.
It doesn't matter for how long chain signal intersections is blocking, the problem is that they block at all and at any traffic level. A few trains synchronizing their movement and you have train stuck in a traffic jam and then the problem just worsen as everyone else will synch up with the traffic jam. Resulting in you having no clue if your copper train will arrive this week or the next.
The roundabout that has no signals inside it, allows all trains the same access to queuing up for crossing, but it's not very well explored in what order they will get to cross and it's entirely possible that it result in an uneven rotation and that a train can end up deadlocked.
That is why I use rail signal only t-sections, as train will nudge their way into the intersection, resulting in a predictable rotational access to pass through it and it's impossible for any two lanes to block access. If you need higher speed, use the circuit traffic light solution, but I'm pretty sure not a lot of us is running that kind of traffic, but most of us will get hurt by the chain signal issue as it doesn't take a lot of traffic and add a unpredictability to the network that you have to be an expert to even know is there..
Perhaps you should at least move every design out of the A category as I don't think many of them actually qualify as safe.
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Mon May 22, 2017 2:30 pm
by aaargha
Miravlix wrote:It doesn't matter for how long chain signal intersections is blocking, the problem is that they block at all and at any traffic level. A few trains synchronizing their movement and you have train stuck in a traffic jam and then the problem just worsen as everyone else will synch up with the traffic jam. Resulting in you having no clue if your copper train will arrive this week or the next.
It may not affect whether or not it can happen, though long enough output blocks may possibly even remove some cases of it, but it may affect the risk of it happening or reduce the amount of traffic needed for it to become a problem. Also why would all the other trains sync up just because one lane is unable to progress? If anything the other traffic should die down as buffers fill up/empty out and production grinds to a halt, this is obviously not desirable and what we want to avoid, but I currently have a hard time seeing this problem as self-reinforcing.
Miravlix wrote:The roundabout that has no signals inside it, allows all trains the same access to queuing up for crossing, but it's not very well explored in what order they will get to cross and it's entirely possible that it result in an uneven rotation and that a train can end up deadlocked.
That is why I use rail signal only t-sections, as train will nudge their way into the intersection, resulting in a predictable rotational access to pass through it and it's impossible for any two lanes to block access. If you need higher speed, use the circuit traffic light solution, but I'm pretty sure not a lot of us is running that kind of traffic, but most of us will get hurt by the chain signal issue as it doesn't take a lot of traffic and add a unpredictability to the network that you have to be an expert to even know is there..
Perhaps you should at least move every design out of the A category as I don't think many of them actually qualify as safe.
- no-chain_3-way.png (1.08 MiB) Viewed 20688 times
The result of throwing all rail signal 3-way intersections in the throughput tester. I really wish I could say that it at least took a few minutes but no, only two trains managed to get through before we ended up at total deadlock for all paths. (If you think it's incorrectly signalled please provide a blueprint string of how you think it should be signalled so we're on the same page. Current signalling is "2x 3-way" with chains replaced with rail signals.)
From a reliability standpoint it feels a bit like burning your own house down to prevent burglary.
So, unless you can show that access to the same block is done in such a way as to not cause starvation, the only workable solution at the moment is circuit controlled traffic lights?
No, I will not change the deadlock rating for all the intersections as starvation problems is not the same as deadlocking.
Currently I also do not see enough of a reason to include notes on starvation as there is no testing done, AFAIK, to verify what works and what does not, what is a good measurement, is there any solution that works, and how big of a problem is it? At the moment it looks like stop lights is the only option but we don't really know. If you decide to test/find these things out I'd be happy to link to your results though.
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Wed May 24, 2017 9:48 pm
by Honey.Badger
Hey OP thanks for posting the right hand drive "Compact" design. We were super bummed it wasn't included and nobody had the time to reverse it for right hand drive
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Wed May 24, 2017 11:13 pm
by Distelzombie
Here is a simple traffic light system that I put together for you to test stuff with. You can use it with every intersection.
You can change the time it takes to switch using the T value in the constant combinator. It is now set to 300 ticks = 5 seconds.
If you use it in other junctions you have to assign the following signals to these ... signals:
1=North
2=East
3=South
4=West
(I had the N, E, S, W variables set to signals before each entry of the junction to maybe read. But I ditched that idea for now. Still used 1234 though)
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Fri May 26, 2017 11:18 am
by pieppiep
Is the save game with the test setup downloadable somewhere?
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Mon May 29, 2017 1:08 pm
by aaargha
pieppiep wrote:Is the save game with the test setup downloadable somewhere?
Not currently, I'm planning on releasing it publicly once I've completed the multi-lane throughput tester and, as it turns out I still need more trains to get a good saturation, that is a bit further away.
Rapier31 wrote:I haven't been able to find any decent working designs of 8 lane 4 way intersections, so I spent a stupid amount of time designing my own. It should work fine(haven't tested yet), but I really don't like the look of it. It unfortunately resembles a swastika and I'd love to redo it, but there isn't enough room to make it work properly in the layout. It will have to be bigger or just completely different, and it is really big already, so.... Here are some pics and the BP's. I'm also throwing in the design for a T junction that was inspired from a reddit post that I saw.
As I've not got the multi-lane build but to where I want it I can't give you any real data on this but, from some of the early test runs some of the 4-lane intersections had higher throughput than what I saw for your design. I'll rerun the tests once the build is complete but I'd recommend trying to redesign your intersection so that the left turns don't cross.
Distelzombie wrote:Here is a simple traffic light system that I put together for you to test stuff with. You can use it with every intersection.
You can change the time it takes to switch using the T value in the constant combinator. It is now set to 300 ticks = 5 seconds.
If you use it in other junctions you have to assign the following signals to these ... signals:
1=North
2=East
3=South
4=West
(I had the N, E, S, W variables set to signals before each entry of the junction to maybe read. But I ditched that idea for now. Still used 1234 though)
I'm not really sure that design will actually prevent starvation, to do that I think you may need to only allow traffic from one entrance at a time, unless the system is more sophisticated.
It's also not deadlock safe at the moment for heavy traffic, see below, as the entrance signals are rail signals. If it was possible to control chan signals with circuits it would be much easier to make a good system, that is both deadlock and starvation free, while not totally butchering throughput.
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Mon May 29, 2017 6:46 pm
by Distelzombie
aaargha wrote:I'm not really sure that design will actually prevent starvation, to do that I think you may need to only allow traffic from one entrance at a time, unless the system is more sophisticated.
It's also not deadlock safe at the moment for heavy traffic, see below, as the entrance signals are rail signals. If it was possible to control chan signals with circuits it would be much easier to make a good system, that is both deadlock and starvation free, while not totally butchering throughput.
I dont understand how the circuit could cause this. Does this happen without circuits? You tested it before: It is "WIDE B" for RHD. Maybe your setup has changed?
Or... is it because there is no wait time between both green signals? I mean to stop trains that otherwise would have blasted through the junction on the last milisecond. Is that it?
One entrance at a time will limit throuphput too much, I think. Any Idea how to improve on this?
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Mon May 29, 2017 8:57 pm
by aaargha
Distelzombie wrote:I dont understand how the circuit could cause this. Does this happen without circuits? You tested it before: It is "WIDE B" for RHD. Maybe your setup has changed?
Or... is it because there is no wait time between both green signals? I mean to stop trains that otherwise would have blasted through the junction on the last milisecond. Is that it?
One entrance at a time will limit throuphput too much, I think. Any Idea how to improve on this?
It's that the entrance chain signals have been replaced with circuit controlled rail signals so the "wait point" is halfway through the intersection. It may work if you place the circuit controlled rail signals before the chain signals. I'm not really sure if that can guarantee that starvation is not possible though.
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Mon May 29, 2017 9:44 pm
by Distelzombie
aaargha wrote:Distelzombie wrote:I dont understand how the circuit could cause this. Does this happen without circuits? You tested it before: It is "WIDE B" for RHD. Maybe your setup has changed?
Or... is it because there is no wait time between both green signals? I mean to stop trains that otherwise would have blasted through the junction on the last milisecond. Is that it?
One entrance at a time will limit throuphput too much, I think. Any Idea how to improve on this?
It's that the entrance chain signals have been replaced with circuit controlled rail signals so the "wait point" is halfway through the intersection. It may work if you place the circuit controlled rail signals before the chain signals. I'm not really sure if that can guarantee that starvation is not possible though.
It was always rail signals.
Well, I made it for testing. You could change it and do more tests if you want.
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Tue May 30, 2017 5:00 am
by pieppiep
Just a random idea I haven't tried yet, you can use the pulse signal from the train counter to control inserters that will build a train in an assembling machine. That way you can use the production screen for graphs.
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Tue May 30, 2017 7:38 am
by aaargha
Distelzombie wrote:It was always rail signals.
Well, I made it for testing. You could change it and do more tests if you want.
I dunno, it does not match any of the blueprints available in the OP at least. It looks a bit like the LHD variant with the signals just moved to the other side of the rails. I'll probably take a look at it once the tester is up, but we'll see.
pieppiep wrote:Just a random idea I haven't tried yet, you can use the pulse signal from the train counter to control inserters that will build a train in an assembling machine. That way you can use the production screen for graphs.
That should work, it'd be easier to do with an item that did not require more than what a stack inserter can move per swing to build, but that's easy to fix by changing item to build. I'm not really sure how useful the graph will be but the production stats might be nicer to look at than reading circuit values from a power pole
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Tue May 30, 2017 8:08 am
by Distelzombie
aaargha wrote:Distelzombie wrote:It was always rail signals.
Well, I made it for testing. You could change it and do more tests if you want.
I dunno, it does not match any of the blueprints available in the OP at least. It looks a bit like the LHD variant with the signals just moved to the other side of the rails. I'll probably take a look at it once the tester is up, but we'll see.
It is "WIDE B" for RHD with one rail signal on the outside diagonal removed because I dont think thats necessary. It also has a rail signal on the output of the junction. This one should be there always.
Both changes were not the cause of this deadlock though.
Aynway I am hyped for the test results. xD
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Tue May 30, 2017 9:15 am
by Koub
[Koub] Stickied the topic : It's invaluable ressource for understanding better the rail part of the game.
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Tue May 30, 2017 11:14 am
by Odhrean
Hi,
can you test and meassure this RHD Cross with your Testbench?
It is Chunk-Aligned and I made it for a Chunk-Aligned Set-Up but am not sure if it is good enough.
The regular Rail-Signals are at the next Section, they are not part of this design.
I fear the Throughput is not good because the center is one block and trains going straight must wait for each other...
I think it is not possible to make a cross which fit into one chunk, is deadlock save and has reasonable throughput
- Chunk_Aligned_Cross.png (715.69 KiB) Viewed 23199 times
Re: 4-way intersection testing: Throughput and deadlocks
Posted: Tue May 30, 2017 4:34 pm
by aaargha
Added Chunk-aligned cross. I think that my tests may be a bit heavy on the right hand turns, as this one preformed surprisingly well, or it's the insane acceleration from the rocket fuel that does it.
Distelzombie wrote:It is "WIDE B" for RHD with one rail signal on the outside diagonal removed because I dont think thats necessary. It also has a rail signal on the output of the junction. This one should be there always.
Both changes were not the cause of this deadlock though.
Aynway I am hyped for the test results. xD
If you first build a copy from the blueprint in the OP and the hover your blueprint over that you'll see that some of the rail signals can't be built because they collide with existing chain signals, those are the ones I mean.
Anyway, hopefully my mod solution works and I don't have to go insane building stackers and setting schedules for 300 or so trains
Koub wrote:[Koub] Stickied the topic : It's invaluable ressource for understanding better the rail part of the game.
Woohoo! Thank you! The proof of my insanity shall forever be immortalized