Balancing - Revision history

Benny: Redirected page to Merging Tracks

2013-12-03T14:09:02Z

Redirected page to Merging Tracks

Benny: Added {{update}}

2013-12-03T13:56:51Z

Added {{update}}

Benny at 07:15, 7 November 2013

2013-11-07T07:15:20Z

RexConnors: /* Priorities on BBHs */

2013-09-04T07:42:03Z

‎Priorities on BBHs

Zxbiohazardzx: /* Multi-track to multi-track: 2+2->2 */

2013-06-21T15:08:51Z

‎Multi-track to multi-track: 2+2->2

Zxbiohazardzx: /* Multi-track to multi-track: 2+2->2 */

2013-06-21T15:07:33Z

‎Multi-track to multi-track: 2+2->2

Mark at 14:43, 8 January 2012

2012-01-08T14:43:23Z

Mark at 14:43, 8 January 2012

2012-01-08T14:43:01Z

Bodo Thiesen: fixed and/or improved inter guides linking

2010-07-19T16:22:24Z

fixed and/or improved inter guides linking

KenjiE20: Add category

2009-11-08T17:02:12Z

Add category

@@ Line 1: / Line 1: @@
-{{Merge|Merging Tracks}}
+#REDIRECT [[Merging Tracks]]
-{{update}}
-−
-[[Priority|<< Priority]] | [[Guides:Presignals|^^ Back to Presignals Guides Index]] | Complex Junctions
-----
-−
-In our networks we often have lots of tracks that want to join to other lots of tracks. Often the load on the tracks is unequal, so you want to provide incoming tracks with the choice to pick any outgoing line, otherwise you might end up having pretty much empty lines joining to other pretty much empty lines and full lines trying to join to other full lines. The first is obviously fine but you can see the latter might be problematic. Enter: balancing.
-−
-==Single-track to multi-track: 2+1->2==
-This is a situation you'll often come across in our games; a sideline joining a mainline at a sideline hub. This is also pretty straight forward, you just want the sideline to be able to pick from every mainline. A potential issue when you start joining to multiple tracks is blocking.
-Blocking happens when the block between the mainline and the joining line is not large enough to hold an entire train and a mainline train enters the priority section while a train is joining, which then gets stopped and also blocks other trains trying to join. Got that? The image below shows a blocked train.
-−
-[[File:Block.PNG|400px|thumb|none|A train that got blocked while joining]]
-−
-The solution to this is to eliminate the combo signal, meaning you want every block to be able to hold at least one train.
-−
-[[File:noblock.PNG|400px|thumb|none|Non-blocking 2+1->1 join.]]
-−
-It's pretty easy to repeat this process when you have more than 2 original tracks.
-−
-[[File:4_1_4.PNG|400px|thumb|none|A 4+1->4 balanced merge]]
-−
-==Multi-track to multi-track: 2+2->2==
-This is where it gets interesting. These kinds of joins usually occur at backbone hubs and main station hubs. The easy way to balance these is to just repeat the single-track to multi-track merge for every incoming track, as seen below.
-−
-[[File:ugly.PNG|400px|thumb|none|A 2+2->2 join that actually consists of a dual 2+2->1 join]]
-−
-There is however an issue with this approach. The track that joins first has an advantage over the later joins, because the later joins also have to cope with the added load added by trains joining from the merges before. When you use this technique for larger joins the problem becomes bigger too:
-−
-[[File:even_uglier.PNG|400px|thumb|none|Showing ProZone Game 05's massive 8+8->8 join, joins like these magnify the problem described above]]
-−
-This can be solved by adding a cross allowing trains to switch the joining track, as you can see below:
-[[File:crossjoin.PNG|400px|thumb|none|A 2+2->2 join using a cross to allow trains to switch, non-blocking, of course]]
-−
-[[File:crossjoin_full.PNG|400px|thumb|none|The same join, with trains occupying the reserved blocks]]
-−
-This cross-joining style can be used for wider tracks relatively easily:
-−
-[[File:snowycross.PNG|400px|thumb|none|Showing a 3+2->3 merge in Public Server Game 146]]
-−
-alternative for the 2+2->2 where all trains join in 1 point:
-[[File:slightly_pretty.png|400px|thumb|none]]
-−
-==Priorities on BBHs==
-It is often said that priorities are not needed in BBHs, because the loads have equal priority anyway. Priorities on backbone hubs, however, don't actually serve the purpose of giving priority; they are only there to disrupt ML traffic as little as possible. Often the priorities are nowhere near long enough to allow for full acceleration, unlike those at SLHs, and it's no problem to shorten them if the joining track seems to be jamming because of the long prios.
-−
-----
-[[Priority|<< Priority]] | [[Guides:Presignals|^^ Back to Presignals Guides Index]] | Complex Junctions
-[[Category:Guides]]
-[[Category:Advanced Networking]]

← Older revision		Revision as of 13:56, 3 December 2013
Line 1:		Line 1:
	{{Merge\|Merging Tracks}}		{{Merge\|Merging Tracks}}
		+	{{update}}

	[[Priority\|<< Priority]] \| [[Guides:Presignals\|^^ Back to Presignals Guides Index]] \| Complex Junctions		[[Priority\|<< Priority]] \| [[Guides:Presignals\|^^ Back to Presignals Guides Index]] \| Complex Junctions

← Older revision		Revision as of 07:15, 7 November 2013
Line 1:		Line 1:
		+	{{Merge\|Merging Tracks}}
		+
	[[Priority\|<< Priority]] \| [[Guides:Presignals\|^^ Back to Presignals Guides Index]] \| Complex Junctions		[[Priority\|<< Priority]] \| [[Guides:Presignals\|^^ Back to Presignals Guides Index]] \| Complex Junctions
	----		----

@@ Line 40: / Line 40: @@
 ==Priorities on BBHs==
-It is often said that priorities are not needed an BBHs, because the loads have equal priority anyway. Priorities on backbone hubs, however, don't actually serve the purpose of giving priority; they are only there to disrupt ML traffic as little as possible. Often the priorities are nowhere near long enough to allow for full acceleration, unlike those at SLHs, and it's no problem to shorten them if the joining track seems to be jamming because of the long prios.
+It is often said that priorities are not needed in BBHs, because the loads have equal priority anyway. Priorities on backbone hubs, however, don't actually serve the purpose of giving priority; they are only there to disrupt ML traffic as little as possible. Often the priorities are nowhere near long enough to allow for full acceleration, unlike those at SLHs, and it's no problem to shorten them if the joining track seems to be jamming because of the long prios.
 ----

← Older revision		Revision as of 15:08, 21 June 2013
Line 37:		Line 37:

	alternative for the 2+2->2 where all trains join in 1 point:		alternative for the 2+2->2 where all trains join in 1 point:
		+	[[File:slightly_pretty.png\|400px\|thumb\|none]]

	==Priorities on BBHs==		==Priorities on BBHs==

← Older revision		Revision as of 15:07, 21 June 2013
Line 35:		Line 35:

	[[File:snowycross.PNG\|400px\|thumb\|none\|Showing a 3+2->3 merge in Public Server Game 146]]		[[File:snowycross.PNG\|400px\|thumb\|none\|Showing a 3+2->3 merge in Public Server Game 146]]
		+
		+	alternative for the 2+2->2 where all trains join in 1 point:

	==Priorities on BBHs==		==Priorities on BBHs==

← Older revision		Revision as of 14:43, 8 January 2012
Line 3:		Line 3:

	In our networks we often have lots of tracks that want to join to other lots of tracks. Often the load on the tracks is unequal, so you want to provide incoming tracks with the choice to pick any outgoing line, otherwise you might end up having pretty much empty lines joining to other pretty much empty lines and full lines trying to join to other full lines. The first is obviously fine but you can see the latter might be problematic. Enter: balancing.		In our networks we often have lots of tracks that want to join to other lots of tracks. Often the load on the tracks is unequal, so you want to provide incoming tracks with the choice to pick any outgoing line, otherwise you might end up having pretty much empty lines joining to other pretty much empty lines and full lines trying to join to other full lines. The first is obviously fine but you can see the latter might be problematic. Enter: balancing.
−
−	~~Let us clear out some misunderstandings first.~~
−
−	~~:''"The goal you want to achieve by balancing is to have equal loads on every track."''~~
−
−	This is not true. Mainlines are built for 100% capacity so it's not a problem when you have a two-track mainline with one track that is 40% loaded and one that is 90% loaded. The problem emerges when you try to join a 70% loaded track to an 80% loaded track.
−
−	~~:''"I don't have to balance this join, traffic is already balanced."''~~
−
−	~~The point I made before also shows this assumption is wrong; balancing is ''not'' about achieving equal loads. This is also why constructions such as the one below are completely pointless.~~
−	~~[[File:inline_balancing.PNG\|400px\|thumb\|none\|Inline balancing. Pointless and bound to cause problems once you get dense traffic running]]~~
−
−	~~==Balancing in text==~~
−	~~If you want to describe what kind of merge you're talking about, use this format:~~
−	~~:Amount of original tracks + Amount of incoming tracks -> Amount of outgoing tracks~~
−	~~So if you'd have a sideline joining a two-track mainline, you'd have 2+1->2.~~
−
−	~~So much for the theory, let's get building.~~
−
−	~~== Single-track to single-track: 1+1->1==~~
−	Of course this is not actual balancing; there is only one outgoing track so you can't provide choice. If you do want to have some control you could add a simple [[priority\|priority]] line. Or if you're feeling really adventurous you could even throw in a [[compressor\|compressor]]
−	~~Now let's move on to some more relevant stuff.~~

	==Single-track to multi-track: 2+1->2==		==Single-track to multi-track: 2+1->2==