3 ms·

A large proportion of the workstations at the company I work for are using Teradici (I'm not affiliated with this company at all) to implement the machines-in-t

by wdfx 9y ago

A large proportion of the workstations at the company I work for are using Teradici (I'm not affiliated with this company at all) to implement the machines-in-the-machine-room idea you mentioned. They basically are remote units for providing keyboard/mouse/display connections over ethernet. In our setup each desk is always connected to the same machine in the rack, but I guess you could have them configured to change machine if you are changing physical location but want to use the same machine.

exikyut 9y ago
I just started wondering how effective a dumb HDMI-over-Cat6 system could be. (I have no idea how Teradici works.) The main hassle would be switching everything; you could build a signal switcher(/multiplexer!) using FPGAs, but that would be expensive and take ___quite___ a while to do.
- isostatic 9y ago
  We do that in broadcast. We can have a matrix on the order of 1000 inputs 1000 outputs, with any source and destination routes to another. These tend to be really pricey, even before factoring in the miles of coax cable. In fact as an industry we're moving to IP - a modern video stream is in the 12gbit range, so that's a backplane of about dozen terabit, so that's not cheap either. On top of that, 1 lost packet and it's a big problem, so we dual stream it all.
  - exikyut 9y ago
    Oh _wow_. I remember looking at tiny 16>2 HDMI multiplexers a while back, IIRC they were a couple hundred. I think I've seen the coax pools for 1k>1k units in cabling pictures online... these would _start_ at 5 figures, I presume, with full installations probably even rolling into 6 figures? And... double wow, 12Gbps. Is there nothing like a realtime, lossless, zero latency compression scheme that works for video? Hmm, Huffman coding would probably only chew off a few Mbps, and not make much of a dent. It sounds like video transmissions run over UDP. That's kinda insane... but TCP wouldn't work either, I'm guessing the transmission format is probably so closely tied to the wire protocol that repeated frames would give everything major indigestion too. This has been a cool TIL
    - isostatic 9y ago
      UDP yes. Repeated frames introduce latency. Broadcasters are used to latency measured in lines -- that's microseconds. In the analog days an extra foot on your cable would mean the difference between out of sync or not in the chroma domain. We use SDI rather than HDMI, but fundamentally it's a container, with an active picture frame in 4K video of 2160 lines, with 3840 samples per line. Each sample is a 10 bit sample of the luma, and every other sample gets 2 extra 10 bit samples of chroma (The eye being less sensitive to chroma). This is 4:2:2 sampling. This means that a single 4K frame is 2160x3840x20 bits, and in the americas there are about 60 lots of 165mbit, every second. SDI adds various things like blanking thanks to it's legacy of a digitised version of PAL/NTSC. Audio is tiny, <15mbit/sec. Normal HD, with interlacing, is far more reasonable, at 1080x1920x20x30ish, 1.2gbit (less in 25fps countries), but SDI adds another 300mbit a second on top of that (UDP/RTP also adds overhead too). The cheapest SDI routers you can get tend to be blackmagic ones, which are fine. There's a lot of people in the industry that remember the days of analog routers, where they were legitimatly expensive. Since SDI came out thought the electronics is little more than a switch chip. A 40x40 matrix will cost about $1300, but prices increase exponentially. On wan links we tend to use compressed video in the 5-30mbit range (5mbit from somewhere skanky with poor internet). We have forward error correction on that, but the standards aren't great at high bit rates (only coping with 25 lost packets). A 20ms outage on a line with that type of error correction causes on air disruption. Using something like ARQ which allows missing frames to be repeated adds latency, on a link from Europe to Singapore for example it could add 600ms. That's on top of the c. 100ms propagation latency and 400ms encode/decode, pushing the latency from half a second to over a second, and people start getting grumpy. There's still no guarentees either - as if you were to lose 100ms of traffic at 30mbit, you end up peaking your traffic far higher than the 30kbit/ms that you normally send -- to retransmit that 100ms in 100ms, you need to peak at 60mbit. As an example of how important latency is for two-way communication, I'm currently investigating replacing our 12 frame (480ms) latency encoders from a couple of locations in London with ones that run at about 1-2 frames (40-80ms). With wan links sending the same packet on two links doesn't even work. I've seen outages of 20ms on both a private wire and two separate internet paths in the past -- presumably some common router in the subsea cable system does something. Currently using temporal shifting (and some receive buffering) as well. The expectations that the broadcast industry place is somewhat different to the IT industry. 3 second end-to-end latency is nearer 'store and forward' than 'low latency'. Compression in a production facility is unacceptable, and increasingly we're moving away from things like 5:1 compression on wan links and bandwidth becomes cheaper. One broadcaster in the UK has just replaced the main in-country network with an uncompressed network based on multi-path 100gbit wavelengths running over dark fibre. Another has replaced it's core switching network with multi-terabit backplanes. Just getting 10gbit/second in/out through the kernel is a challange - doing it with nanosecond packet timing that the next SMPTE standard currently requires is proving even harder.

by wdfx 9y ago

exikyut 9y ago

I just started wondering how effective a dumb HDMI-over-Cat6 system could be. (I have no idea how Teradici works.) The main hassle would be switching everything; you could build a signal switcher(/multiplexer!) using FPGAs, but that would be expensive and take ___quite___ a while to do.

isostatic 9y ago
We do that in broadcast. We can have a matrix on the order of 1000 inputs 1000 outputs, with any source and destination routes to another. These tend to be really pricey, even before factoring in the miles of coax cable. In fact as an industry we're moving to IP - a modern video stream is in the 12gbit range, so that's a backplane of about dozen terabit, so that's not cheap either. On top of that, 1 lost packet and it's a big problem, so we dual stream it all.
- exikyut 9y ago
  Oh _wow_. I remember looking at tiny 16>2 HDMI multiplexers a while back, IIRC they were a couple hundred. I think I've seen the coax pools for 1k>1k units in cabling pictures online... these would _start_ at 5 figures, I presume, with full installations probably even rolling into 6 figures? And... double wow, 12Gbps. Is there nothing like a realtime, lossless, zero latency compression scheme that works for video? Hmm, Huffman coding would probably only chew off a few Mbps, and not make much of a dent. It sounds like video transmissions run over UDP. That's kinda insane... but TCP wouldn't work either, I'm guessing the transmission format is probably so closely tied to the wire protocol that repeated frames would give everything major indigestion too. This has been a cool TIL
  - isostatic 9y ago
    UDP yes. Repeated frames introduce latency. Broadcasters are used to latency measured in lines -- that's microseconds. In the analog days an extra foot on your cable would mean the difference between out of sync or not in the chroma domain. We use SDI rather than HDMI, but fundamentally it's a container, with an active picture frame in 4K video of 2160 lines, with 3840 samples per line. Each sample is a 10 bit sample of the luma, and every other sample gets 2 extra 10 bit samples of chroma (The eye being less sensitive to chroma). This is 4:2:2 sampling. This means that a single 4K frame is 2160x3840x20 bits, and in the americas there are about 60 lots of 165mbit, every second. SDI adds various things like blanking thanks to it's legacy of a digitised version of PAL/NTSC. Audio is tiny, <15mbit/sec. Normal HD, with interlacing, is far more reasonable, at 1080x1920x20x30ish, 1.2gbit (less in 25fps countries), but SDI adds another 300mbit a second on top of that (UDP/RTP also adds overhead too). The cheapest SDI routers you can get tend to be blackmagic ones, which are fine. There's a lot of people in the industry that remember the days of analog routers, where they were legitimatly expensive. Since SDI came out thought the electronics is little more than a switch chip. A 40x40 matrix will cost about $1300, but prices increase exponentially. On wan links we tend to use compressed video in the 5-30mbit range (5mbit from somewhere skanky with poor internet). We have forward error correction on that, but the standards aren't great at high bit rates (only coping with 25 lost packets). A 20ms outage on a line with that type of error correction causes on air disruption. Using something like ARQ which allows missing frames to be repeated adds latency, on a link from Europe to Singapore for example it could add 600ms. That's on top of the c. 100ms propagation latency and 400ms encode/decode, pushing the latency from half a second to over a second, and people start getting grumpy. There's still no guarentees either - as if you were to lose 100ms of traffic at 30mbit, you end up peaking your traffic far higher than the 30kbit/ms that you normally send -- to retransmit that 100ms in 100ms, you need to peak at 60mbit. As an example of how important latency is for two-way communication, I'm currently investigating replacing our 12 frame (480ms) latency encoders from a couple of locations in London with ones that run at about 1-2 frames (40-80ms). With wan links sending the same packet on two links doesn't even work. I've seen outages of 20ms on both a private wire and two separate internet paths in the past -- presumably some common router in the subsea cable system does something. Currently using temporal shifting (and some receive buffering) as well. The expectations that the broadcast industry place is somewhat different to the IT industry. 3 second end-to-end latency is nearer 'store and forward' than 'low latency'. Compression in a production facility is unacceptable, and increasingly we're moving away from things like 5:1 compression on wan links and bandwidth becomes cheaper. One broadcaster in the UK has just replaced the main in-country network with an uncompressed network based on multi-path 100gbit wavelengths running over dark fibre. Another has replaced it's core switching network with multi-terabit backplanes. Just getting 10gbit/second in/out through the kernel is a challange - doing it with nanosecond packet timing that the next SMPTE standard currently requires is proving even harder.