I play on a SMP server that is fairly redstone heavy. We put a lot of effort into minimising lag, but it's still an issue.
For a while we've been discussing a redstone serial communications infrastructure. There are machines located in distant locations we would like to be able to control from a central point, and we'd like to get data back from those machines so we know which ones are in use, and other diagnostic information.
Encoding/decoding is relatively easy. There are several designs out there, and we've settled on Kessle Run's rather clever piston-less design (). It's got a lot of restone dust so it might make a little lag itself (if you have any suggestions on improving his design I'd like to hear it), but it's silent as it uses redstone repeaters' latching function (a much underutilised feature, I must say!), and every other design I have looked at also tends to have a lot of redstone dust.
The problem is the communication lines between encoder and decoder. 15 blocks of redstone dust and a repeater has a couple of advantages: it's simple, cheap, and if the repeater is at the chunk border it spreads load out a little, but restone dust is lag-tastic, producing block updates, lighting updates and all sorts of lag-heavy side effects. We'll be covering 8000 blocks in a couple of instances so there will be a fair amount of server load created if we use redstone dust.
We've looked into insta-wire setups. ilmango has some cool lag-friendly insta-wire designs (). They are fairly resource intensive (not such an issue when you have an iron farm, pigman farm and witch farm) but the big issue is the transmission of encoded data: triggering these setups multiple times in subsequent ticks can induce huge issues, and while insta-wire is cool it's not actually needed as we can tolerate some latency.
So, we're looking for a wiring setup that works with encoders/decoders and that keeps lag to a minimum. Our priorities are:
1 (highest) - tick encoding - as we're using a single wire encoder/decoder (and not a setup that uses a separate timing/clock wire) we can't have pulses combine or extend
2 - Lag - we need to keep server load as low as possible
3 (lowest) - resources - if there is a way to get 1 and 2 and make it a little cheaper that's awesome, but not critical!
Lag is an issue, and much more so than latency: as long as it's faster by serial than physically traveling there we've achieved our goals so some latency is tolerable. If there is a way to spread lag/load out over time I'd certainly listen.
We've also considered using the Nether. You can send data from the Overworld to the Nether (and back again) using a binary encoder: each bit is represented by a certain block type. You fire one of each block type through a portal, and the blocks are collected on the far side, parsed through item filters to drive an encoder, and the rest goes on from there. This will reduce total load by a factor of 8 (because you need an eighth as much wire to connect point A to point B), but it's tricky. The timing is finicky, and the serial comms must be slowed to a snail's pace to ensure that packets don't run together, and item duplication can really stuff you up. And clearing bits is tricky, too. You need to assign an 9th block type to be the reset block, or have another 8 block types to be the off signals for each bit.
Digging tunnels for redstone comms is easy: ilmango again to the rescue with his Overworld () and Nether () tunnel boring designs. We already have tunnels in both the Nether and Overworld we could utilise for wiring.
So, the perfect solution to the problem is comms wire that has low lag (low server processing costs), has perfect pulse encoding (essential to the encoder/decoder design we'd like to use) and is as cheap as possible. But the world is rarely perfect.
There is a reason why high speed serial comms in the real world have more than one wire. While we'd prefer a single redstone line (each extra line is possibly a linear growth in server load and resources required) that may just not be practical. A second clock/synchronisation line maybe a better option, or having RTS/CTS signalling maybe better.
Does anyone have any suggestions? Has anyone here ever built a long range comms system in vanilla Minecraft? If we included a clock line we could have the data and clock lines interact at regular intervals to prevent pulse contraction/spreading. Could/should we build repeater stations along the line to recieve data, clean it up and re-transmit it, or is that just more server load for no good reason?
Any suggestions are appreciated! I am sure that people have done all this before!
Hello Minecrafters!
[Warning: massive post in-coming!]
I play on a SMP server that is fairly redstone heavy. We put a lot of effort into minimising lag, but it's still an issue.
For a while we've been discussing a redstone serial communications infrastructure. There are machines located in distant locations we would like to be able to control from a central point, and we'd like to get data back from those machines so we know which ones are in use, and other diagnostic information.
Encoding/decoding is relatively easy. There are several designs out there, and we've settled on Kessle Run's rather clever piston-less design (). It's got a lot of restone dust so it might make a little lag itself (if you have any suggestions on improving his design I'd like to hear it), but it's silent as it uses redstone repeaters' latching function (a much underutilised feature, I must say!), and every other design I have looked at also tends to have a lot of redstone dust.
The problem is the communication lines between encoder and decoder. 15 blocks of redstone dust and a repeater has a couple of advantages: it's simple, cheap, and if the repeater is at the chunk border it spreads load out a little, but restone dust is lag-tastic, producing block updates, lighting updates and all sorts of lag-heavy side effects. We'll be covering 8000 blocks in a couple of instances so there will be a fair amount of server load created if we use redstone dust.
We've looked into insta-wire setups. ilmango has some cool lag-friendly insta-wire designs (). They are fairly resource intensive (not such an issue when you have an iron farm, pigman farm and witch farm) but the big issue is the transmission of encoded data: triggering these setups multiple times in subsequent ticks can induce huge issues, and while insta-wire is cool it's not actually needed as we can tolerate some latency.
So, we're looking for a wiring setup that works with encoders/decoders and that keeps lag to a minimum. Our priorities are:
1 (highest) - tick encoding - as we're using a single wire encoder/decoder (and not a setup that uses a separate timing/clock wire) we can't have pulses combine or extend
2 - Lag - we need to keep server load as low as possible
3 (lowest) - resources - if there is a way to get 1 and 2 and make it a little cheaper that's awesome, but not critical!
Lag is an issue, and much more so than latency: as long as it's faster by serial than physically traveling there we've achieved our goals so some latency is tolerable. If there is a way to spread lag/load out over time I'd certainly listen.
We've also considered using the Nether. You can send data from the Overworld to the Nether (and back again) using a binary encoder: each bit is represented by a certain block type. You fire one of each block type through a portal, and the blocks are collected on the far side, parsed through item filters to drive an encoder, and the rest goes on from there. This will reduce total load by a factor of 8 (because you need an eighth as much wire to connect point A to point B), but it's tricky. The timing is finicky, and the serial comms must be slowed to a snail's pace to ensure that packets don't run together, and item duplication can really stuff you up. And clearing bits is tricky, too. You need to assign an 9th block type to be the reset block, or have another 8 block types to be the off signals for each bit.
Digging tunnels for redstone comms is easy: ilmango again to the rescue with his Overworld () and Nether () tunnel boring designs. We already have tunnels in both the Nether and Overworld we could utilise for wiring.
So, the perfect solution to the problem is comms wire that has low lag (low server processing costs), has perfect pulse encoding (essential to the encoder/decoder design we'd like to use) and is as cheap as possible. But the world is rarely perfect.
There is a reason why high speed serial comms in the real world have more than one wire. While we'd prefer a single redstone line (each extra line is possibly a linear growth in server load and resources required) that may just not be practical. A second clock/synchronisation line maybe a better option, or having RTS/CTS signalling maybe better.
Does anyone have any suggestions? Has anyone here ever built a long range comms system in vanilla Minecraft? If we included a clock line we could have the data and clock lines interact at regular intervals to prevent pulse contraction/spreading. Could/should we build repeater stations along the line to recieve data, clean it up and re-transmit it, or is that just more server load for no good reason?
Any suggestions are appreciated! I am sure that people have done all this before!