The plan to make all networks optical is about to take two big steps forward In December 2024, Japanese tech giant NTT revealed two impressive feats of high-speed networking. Working with Hitachi Vantara, the company virtualized a pair of storage arrays into a single logical unit that achieved real-time data synchronization. That's a neat trick in the datacenter, but NTT and Hitachi pulled it off …
I'll be jiggered if I'm ever gonna pay any streaming service a single solitary cent. Oh, I'll use your damn optical network at the same price it was last time, or maybe a little more.
But instead of streaming anything, I'll just torrent download the full Bob Burger series and watch it off the Android box.
(Oh, hush. I was gonna borrow it from the library and dub it off anyway.)
The link to their 2019 work seems to have foreshadowed a bright future.
I am curious how the latency between the two data centres 600km apart (> 600 km/c ~ 2 ms => rtt > 4 ms)† was handled in their real time synchronisation tests.
I imagine a fair bit of filthy AI lucre might be thrown in this direction as it would appear to solve some of the current LLM bottlenecks.
† I think the refractive index of glass is ~1.5 so probably > 3 ms and > 6 ms
I remember mainframes like that in the late 1960s. Usually strung around in just the one big room, with the codies sat at card or tape punchers next door, and the power supplies through the door on the other side.
SoC is inherently 1000 times faster because the signal paths are 1000 x shorter. Given that the speed of EM waves through copper is over half that of fibre, I am puzzling how this 500 times extra acceleration comes about. Presumably lots of clever stuff they aren't telling us, so maybe us hoi polloi could apply all that to copper and settle for a slightly smaller reach and a vastly smaller bill?
Here is an idea to discuss:
How about using the optical network as high speed serial ram.
If it takes 40ms to send data from Cal to NY and back, how much data can you store in the stream?
Need more data? Send it via multiple fibers.
Want it all local? Build a layered nano fiber crystal block.
What do you guy’s (and gals) think?
Serial RAM is a contradiction in terms. Serial memory is FIFO - first in, first out. For your given block of memory, you have to wait until your tape/photon loop comes around. RAM is Random Access Memory: just point to the block you want, and there it is.
Wikipedia reckons that optical serial memory is already a thing in some niche apps. And it's on Wikipedia, so it must be right!
Scotty famously pointed out that "you cannot change the laws of physics." Unless they've got something in there that can make a fiber optic network go faster than the speed of light, latency relative to distance is a constant.
Asynchronous replication, or eventual consistency. At 600 KM you have to pick one or the other.
I've worked with long distance replication back in my consulting days, the way it works is that if you store a piece of data it is stored in the local array (more likely in its cache at first) and sent to the remote array, when it stores it in its cache it reports back to the local array and THEN the local array reports to the OS that the data is stored. But there are tricks.
You might think "but wait, 1200 km adds a lot of latency". Well that's nothing compared to the latency hard drives used to have. It is tricky for longer distances because if you have e.g. a database that has to write stuff in order and be sure that the last write completed before doing the next one it affects performance. Which is why databases used to be really slow if running on local hard disk drives, and people would spend a lot of money for arrays with big NVRAM caches on them. But there are tricks you can use via hooks inside the database, which get trickier and trickier the longer the distance. So yes they've supported it at 600 km, but it isn't something that will work for EVERYTHING - not unless you take that round trip latency hit.
EMC supports this type of synchronous behavior, but also supports asynchronous. When using the latter you it reports the data written when it hits the local array so you don't take the latency hit. The array handles shifting the data over to the other array and making sure it is consistent (i.e. the same order it was written locally so your database works etc.) So if a disaster wipes out your local array the remote array has a consistent copy but slightly out of date. For most cases that's good enough, and there are facilities in place to write something "synchronously" which waits for the remote array to get it, which you can use for e.g. critical financial transactions, without forcing that level of synchronization for writes where that doesn't matter.
