I came across this while experimenting with power transfer limits of the universal cable using RF.
The limit of the transfer speed was dependent on the amount of cables used. 1 basic cable between the Source and the load would provide a transfer rate of 1280 RF/t while 2 would double it to 2560 RF/t. I believe this is the same with EU as well.

Intentional :)

Ok I recommend explaining this in your wiki. Its kinda silly and isn't really intutive.

While I think I knew of this before reading this issue, but I agree that it is really unintuitive. Why would making your cable arbitrarily longer make it transfer more power?

I assume that the main reason is so that people can pull power from the Reactor without making every spare spot a power extraction point. However, this strategy seems quite weird.

It's also sounds insanely unbalanced. It only takes 20-25 Basic Universal Cables (6-8 Steel and 3-4 Redstone) on a line to beat all of Ender IO's power conduits and the best, non-infinite Resonant Fluxducts from Thermal Expansion. Upgrade to Advanced Universal Cables and you make it only need SEVEN (2 steel, 1 redstone, 1 Enriched Alloy = 3 Iron Ingots, 2 charcoal, 2 redstone dust, and a Metallurgic Infuser).

I'm curious, what would happen if you happened to make a line exceed INT_MAX? I think that's a little over 6,700 Ultimate cables in the Joules power system. That's an extremely large number, but isn't impossible.

I agree with @VT-14.
I don't get it... Why is it intentional? If you state a throughput of 1.28krf/t shouldn't it limit it then to max that? I've noticed indeed that the throughput is way more then expected, which is why I came here. All other cables don't work this way so it's not intuitive...

@aidancbrady could you please explain why it's working like this and why not act exactly like EnderIO Energy Conduits for example?

is that the actual transfer rate or is that the buffered state of the grid since each node stores power?

Both. As you can see in the original post, adding a random cable to the grid will increase the transfer rate. Each Basic Universal Cable will allow you to transfer 1280 more RF/t. Each cable also adds itself to the possible stored energy capacity of the grid.

That said, I'm not sure if it's per connection or a grid total. For example, Ender IO goes by per connection. You can have a line of Ender IO's top tier conduits and hook both machines to 2 sides (4 total connections, 2 in, 1 out). Each connection can transfer 20k RF/t (and change), so having 2 connections on a machine allows 40k rf/t. The actual layout of the conduits don't matter (though more conduits does increase the capacitance of the grid).

What I would mean by grid total would be that adding conduits increase the transfer rate of the entire network. if you had multiple connections, the same transfer rate would have to share between them. Say, if you added a second input and second output to the picture in the begining, would each output receive 640 rf/t with a single cable (1/2 of the grid transfer rate)?

@VT-14 it would be per grid total not per connection

The "correct"/"best" way to implement energy distribution is something I've put quite a bit of thought into over the years - the solution we've ended up with can be a bit weird and counterintuitive at times, and I might consider changing the mechanic before we go stable on MC 1.8.9/1.9 - I'd prefer to keep such a change to a major breaking version update, to avoid confusing people using the current version with existing worlds. As far as I can see it, there are several ways of reasoning about the problem, and several potential solutions present themselves.

Our problem is balancing: sensible-seeming and understandable mechanics, intuitiveness of these mechanics, server-friendliness and computational complexity, user-friendliness, and programming effort to implement/maintain. It is also worth considering the effects on other mods' mechanics, as we can interface with most common energy systems, though as has been asserted by many developers in the past, it is not usually worth compromising the aims/design of a mod in the pursuit of total inter-mod balance as this is often an intractable problem anyway.

The system we currently use treats the network (as a representation of all the cables connected together into one entity) as a single buffer (of eg. energy) with a capacity calculated as the "harmonic sum" (i.e. the number of cables × the harmonic mean; this is to prevent domination of the capacity of the network by a single high-capacity transmitter) of the capacities of all cables on the network. Any inputs feeding energy into the network do so during their TE tick (the cables have the ability to attempt to draw power from the network as well, this is done in their TE tick) and this energy is contributed directly to the network buffer (losing all information about where it came from), then distributed to all acceptors in a single invocation of a function on the network at the end of the tick.

This method presents itself naturally as a result of the network system we use, and is designed to optimise (in terms of tick time) the distribution of energy by the network and avoid slowing down the tick times of tiles feeding into the network (as our very old system, 3+ years ago, did; it ran a distribution calculation each time energy was fed into it, and did not directly store any energy, which was bad for servers). However, as has been pointed out, it seems strange and counterintuitive, partially as a result of the loss of any information about the source of the power between it entering the network and being distributed, and partially due to no limits being placed on the throughput of individual cables.

Some ways I can think of, of improving this system: Impose a limit on how much energy can enter the network in one go (or in one tick; this would be more difficult to implement), through (each side of) each transmitter, and/or on how much energy can leave the network through each transmitter (same comments apply). I believe that implementing the latter of these might be a good idea for making the networks more sensible and easier for users to reason about, and would come at negligible costs of computational complexity and (probably, but would need to look over the code to be sure) programmer time/effort and maintainability. It may decrease user-friendliness and break existing builds (so should be done at a time we're already making breaking changes), but I believe this is a cost worth taking to increase intuitiveness and avoid compromising the mechanics of many other mods. I imagine some would support introducing the limit on per-cable input rate as well, but I feel it would be excessive and would potentially compromise our own mechanics re: the reactor, so I would be reluctant to do so.

A final point that I think may be worth mentioning: when I was first working on the transmitter systems (~2 years ago, I think?), I did consider the feasibility of implementing a system based on the actual physical mechanics of circuit theory. I came up with a theoretical method for using tons of linear algebra to distribute power using nodal analysis of the network, but abandoned the idea due to various concerns. The system would provide mechanics that would hopefully be intuitive (due to being physically grounded) and behave in a way that makes the most sense, but would come at the cost of far more complex (both to program and to run) transmitter network code, and I decided not to put the effort in to implementing that much linear algebra just to probably have it set your server on fire and burn down your house if you made a network sufficiently big. I believe that Calclavia may have independently had a similar idea, as (if I remember correctly) one of his mods made shortly after I gave up on the idea was based around DC power transport and used ejml, which is the linalg library I had considered using. I'm not sure how it turned out, but I might consider looking back at my earlier plans for this if people seem keen on the idea. (EDIT: I think IC2exp might use ejml as well; maybe they also use a similar system?)

Sorry for the unexpected essay; anyone would think I'm a humanities student rather than a physics one. 😜