Batbox uses 3 batteries. Thats 6 redstone.
So you are wrong about batbox not using redstone.
I think I meant as in a signal (EG switch/torch) and not literal redstone, but I'm not even sure since I hadn't built batboxes for a while when I'd made that post. (Then last night's login issue thing struck and I decided to start an SSP world too.... oooh joy do I know the batbox recipe now)
Actually better would be double-buffering (2x the highest side as buffer size; same 'only push/pull' full high-side packets; the low side would still give whatever was asked up to it's limit) since that could potentially simplify a lot of code if these were 1 tick delay small buffers.
As for your issue; was that possibly related to the SMP 'paint doesn't separate wires' issue? Or maybe 'face direction not preserved' issue (I hear they are the same root cause)?
If a redstone signal is sent the massfab does not process (or consume) energy (zero work).
Mass fabrication (creating uu mater to assemble in to other things) is /extremely/ expensive, and slightly less so with scrap.
If you've just built a massfab chances are good you could be serviced even better by building a quad OV miner and MFE/MFS unit + stepdowns to power it. I average a handful of diamonds per mining op (sometimes a lot, sometimes none; usually one or two per quad shaft) among the 18x18 grid mined; though the setup and handling the chests full of stuff is a growing headache.
I'm OK with all of that. There are usecases for this that are different from HV iron.
All experiments run with 64 cobble
600*64 = 38400
Lossful
Experiment 2.A: MFS, 41 glass wire, MVTF, gold wire (2x ins), LVTF, copper wire (ins), Macerator
101573 - 61973 = 39600
600*64 / 32 = 1200.000
600*64 + 1200 = 39600
101573 - 61973 = 39600
Lossless
Experiment 2.B: MFS, 39 glass wire, MVTF, gold wire (2x ins), LVTF, copper wire (ins), Macerator
61973 - 23573 = 38400
Additionally I observed the specific difference of 33 per update and 32 per update respectively. The MFS dequeued packets of 33eU.
This would actually be a more simple model if all TFs had a buffer (inductive capacity) of their high side and would only transfer if it were empty/full if stepping down/up respectively.
Additionally I noticed that the measuring tool when used on a TF counts both incoming and outgoing packets (divide measurements on TFs by 2 to get the correct value)
Except that experimental data disproves that idea:
I ran a test with 41 glass instead of 1 and the same stack of 64 cobble. The result:
Packets of 32 were sent from the MFS unit over the glass; loss was one unit per packet; 1200 packets later the operation was complete.
Conclusions: The Wiki and current documentation are wrong/misleading on various points.
If you apply redstone to a storage unit it only outputs power IF it's full.
When you place something in it would of course charge.
You will run in to at least these problems:
1) Teleporting is ruinously expensive at 2000 blocks. I did a rough estimate of me + a mostly full inventory and got a base cost of ~7.5k per block; you want to go 2000 blocks. You have just hit 15 million; that's 1.5 MFSUs; you will need your teleporter pad /touching/ 2 MFS units.
2) Massive problems in SMP; I tried setting it up for about 1/4th your distance and could not even get the two teleports to /lock/ let alone actually transit. When I use server mod tools to 'warp' to coords the block isn't even loaded and it treats me as if spawning at X,Z instead (only worse since I wound up within a freaking cave the first teleport).
3) 4X ins using HV (2048eU/pulse) still costs you roughly 1eV per block traveled. You'll spend ~100/2000 or 5% of all the energy used (15M again) over the project's lifetime of teleports and recharges. At the distance you are going it would take exactly ceil(100/6) diamonds (this is about 17) to just run glass there instead. I have >17 diamonds sitting in my chest from using a quad minor on a ~64x64 area right now (spare); however if you have the spare energy required to do this than I'd suggest massfabing diamonds instead or in parallel to mining. The cost in energy is about the same either way; though the mining actually gives you more of other things you crave.
PS: the loss distance for 'glass' is either 1/20 or 1/40 (I've not tested which is correct). In any event redstone placed properly near a pair of back to back MVTFs with their 512 faces outwards and 6 gold placed to connect the other three sides should more than suffice (again untested, but it creates 4x128 pathways between the two) Since you'd need 2/3 pairs anyway this also lowers the cost by one diamond and increases it by a handful of copper rubber, and a few machine blocks (the iron's actually the most costly part of the signal regeneration).
I ran my own experiment with an MFS, MVTF, LVTF, 1x glass 'wire', 2x gold wire (was out of copper wire at that moment).
The first run I got odd values, so I retested with a full stack of 64 cobblestone.
100312 - 99096 = 1216
1216/2 = 608
625*64 = 40000
98488 - 60088 = 38400
(98488 - 60088) / 64 = 600
Ignoring the initial charge (which apparently cost exactly 608 for wrench and replace), I observed a sporadic draw of 32eU/pulse that vaguely matches the 2eU/tick specification of the unit.
Strangely I also see that an operation costs 600 and not 625 as predicted.
Except I'm pretty sure the death ray (which couldn't be aimed but at install time) would punch a hole in the shield; if you're armored enough you could get through it. This is more to use against mobs than players. (It /would/ be nice if it paralyzed Endermen in the beam though; just like the Shadows in B5. 
)
For >= 2048 eV/t links a microwave power TX/RX unit that operates on (dead on) line of site only would be wonderful. The highly focused beam could be used as both a power transmission method and for building a wall of death.
Likely it would cost an HV-TF, a diamond, and an advanced circuit or two to construct; sending and receiving units would have (slightly) different recipes. The device would constantly send power (disabled via redstone signal), and the receiver would be optional. Possibly some kind of reflector could be added to divert the signal without regenerating it.
Currently there are five power levels:
0: - 1-3, tin wire.
1: 1-32, Copper wire (1x ins)
2: 128, Gold wire (2x ins)
3: 512, Glass/Diamond wire (3 rubber of ins)
4: 2048, ReIron - HV
Following the documentation on the wiki/forums the corresponding lossless distances; loss being determined /only/ by cable type and length.
0: 39
1: 4
2: 2
3: 19 or 39 (different values for each source)
4: 1
However in the real world when using a higher grade of cable losses only decrease for the same signal over the same run length. Thus I would think that this would be a more normalized result metric:
0: 1.25 @ 32eU * except this would burn/blow up first.
1: 4 @ <= 32eU
2: 8 @ <= 32eU
3: 128 @ <= 32eU ** 
This uses such a costly component in it's construction.
4: 64 @ <= 32eU
2: 2 @ 128eU
3: 64 @ 128eU ** This uses such a costly component in it's construction.
4: 16 @ 128eU
3: 19 @ 512eU ** This uses such a costly component in it's construction. (same as current value?)
4: 4 @ 512eU
4: 1 @ 2048eU
In other words, I think that the loss metric should be relative to a packet size, and that transferring a smaller packet should benefit proportionally to the change in packet size. (So transferring 32eU/t over 128eU/t rated cable would have 4x the blocks before loss distance; 1eU/t (solar panel as an example) would have 128x the loss distance)
I wanted to confirm some behavior I observed in game as being officially desired result.
Most machines have an internal buffer, though it's precise size is not documented (outside of the source code anyway) I suspect it is at least 128 and probably 512.
If I have an MFS unit, lossless lengths of cable, TFs and a machine, will the machine only draw a pulse of power when it can handle the full 512eU output of the MFS unit? (16 pulses of 32 in one tick)
(MVTF)(gold 2x ins) 
This is also present as a non-bug if the miner hits a fluid the pump is supposed to drain but which is not drained (EG due to being out of cells).
Obsidian, lava, water, etc, are not blocks with mining scanner values; and are thus not mined 
Getting any of those is the same as running across sand gravel dirt or cobblestone.
I'm going to expand this in to a generic mining wishlist.
1) To control what blocks are mined (whitelist/blacklist); possibly via detector programming.
2) Backfill more than the shaft; it would be awesome if I could have the miner fill in the places it digs through; a secondary level for filling in /any/ gap it encounters (eliminate all caves).
2.a) The backfill buffer would need to be several slots, and ideally if the miner comes across a material from one of the slots it would be deposited there first and then reused; empty slots would have '0' of the prior slot (so they could hold a whole new stack, or you could seed it with one cobblestone).
3) A more complex programmable backfill program. If it detects block X within Y spaces fill/nofill. This could be used with rail supports, chests, spawners, etc to prevent filling in abandoned mineshafts and strongholds.
It is also possible (with practice) to learn where the 'high' side of devices will be placed and thus mate it directly to the face of a different block. I do this all the time with stepdown TFs beneath floors (512 to 128 + 128 to 32); however the same trick can also be used with a boost up and boost down to rebuffer and regenerate the signal. However I still prefer to just use a batbox (for 32eU) since they're relatively cheep to make, do not take redstone, and provide a little fault tolerance related to upstream supply.
If you must use HV all the way to the machine then I'd just use the 'glass' (diamond) cable since it is lossless for 19 blocks while iron is only lossless for a single block (even at 4x insulation). The only time I'd use iron wire would be if there were no other choice, or if it's early in your development cycle and you can barely afford the HVTF but not a pair of MFS units and lapotron crystal (but it's better to wait for that).
