Hacker News Reader

Comment by yingw787 | Hacker News Reader

If this comes to pass, I'm all for it. If we could take the demand we saw for oil, and put it into demand for high-speed Internet, we could see completely new, blue ocean markets.

Imagine a surgeon being able to control a robotic surgery tool from the comforts of his/her home, where you have to have extremely low-latency or guaranteed low-latency networks. Or imagine mecheng offices running simulation jobs in the cloud or an on-premises instead of each having a workstation, and being able to cluster that compute together. All these have been possible to some degree with existing technology, but now we have a paradigm shift and market acceptance that unlocks new business possibilities.

View on HN

Nice to imagine, but the speed of light is too slow for a lot of low latency applications. After you allow the infrastructure some latency. A dedicated line might work, but without the network that is expensive.

If last-mile network is too much, you could have a colocated office park / operations center next to a hospital with a dedicated high-speed network. Then each surgeon can schedule / manage a patient without having to walk to a different OR, change scrubs, or be exposed to contagious viruses.

Mecheng tasks could be async / queue-based and latency wouldn't matter too much.

Regardless, I think it's really important to keep your bias for action high during this period of time.

How common are robotic surgeries today? Are there benefits to having a machine do the cutting?

It’s common enough not to be a gimmick, but the real advantage is allowing surgery to be done by a limited pool of specialists that can cover wide areas.

So potentially the next step is specialists covering whole regions where the latency of fiber is still acceptable. Then as the equipment and training for telesurgery becomes more available/costs come down, you might see it used for smaller benefits of sterilization and travel/cleaning time within a hospital, even for more common/less specialized surgeries, and even if it's just a surgeon located at the same building or facility.

>Nice to imagine, but the speed of light is too slow for a lot of low latency applications.

Is it? Looking around, it seems average visual reaction times (VRTs) are on the order of 250 ms, and even the fastest VRTs are well over 100 ms. A study looking specifically at medical students for auditory and visual reaction times ("A comparative study of visual and auditory reaction times on the basis of gender and physical activity levels of medical first year students" [1]) also seems to support those numbers in the medical context, and while experienced surgeons could be expected to be somewhat faster that paper also links to research indicating hard biological minimums:

>"Researches by Kemp show that an auditory stimulus takes only 8–10 ms to reach the brain, but on the other hand, a visual stimulus takes 20-40 ms."

If we want to be quite conservative and aim to keep latency to single digit ms, so sub-10ms, then the speed of light in standard fiber gives us an RTT limit of around 1300 miles. Going more conservative and assuming actual route having to essentially follow the legs of a right triangle, that still gives a radius of around 460 miles, with a set of reasonably conservative assumptions. That seems plenty good enough to cover an enormous amount of work-from-home (or at least work-from-different-location) when it comes to actual existing medical practices, where I doubt most doctors at hospitals live >460 miles away.

I would agree that there are real issues with the idea, but more in terms of the risks events like network disruptions than the speed of light.

----

1: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4456887/

I think you've mixed up your logic a bit. A slow visual reaction time means that surgeons are already reacting slower in the real world. Any latency added (!!) by a network further adds to the delay between surgeon reaction and real world stimulus.

You argued that when we compare the average VRT additional latency is not large. But you should have argued that there was enough buffer between average VRTs and the time needed for a surgeon to react to allow adding to average VRT.

i.e. If we imagine driving a car with a video camera, we don't really care about latency vs reaction time. We care whether latency + reaction < accident threshold.

>You argued that when we compare the average VRT additional latency is not large. But you should have argued that there was enough buffer between average VRTs and the time needed for a surgeon to react to allow adding to average VRT.

If you look at the paper I linked, it includes not just the mean but the standard deviation, which is on the order of 10-20ms. That means we are already by definition accepting that kind of variability regardless does it not? If +/- 10ms was critical, it'd imply we should be filtering for that already but it doesn't appear that's the case at all. Furthermore, hunting around for other research on the subject indicates far higher variability than that is also introduced by standard stress factors (lack of sleep, overload, distractions, etc). All of which are strongly present in existing medical practice as well. To the extent working remotely might reduce some of those it could in principle even effectively cancel out a 10ms penalty.

I stand by saying it's not at all clear that sub-10ms (or potentially even higher) would at all be the critical factor preventing remote work. Speed of light seems to be far less important then factors like total network disruption, robotics reliability, etc.

> mecheng offices running simulation jobs in the cloud or an on-premises instead of each having a workstation, and being able to cluster that compute together

that's totally a thing. worked on low-latency, high resolution remoting software for this purpose exactly. Buy a bunch of beefy servers and have scientists remote in from a laptop to run graphic intensive simulations, rather than buy a workstation for everyone.

I never understood why as a company you wouldn't prefer an on-premises computer cluster with some overhead and give employees thin clients, rather than give everybody MacBook Pros. Thin clients + servers make much more sense to me from a business perspective. They seem much easier to secure (just revoke some keys if you need to fire somebody), much easier to give everybody a reproducible dev env and avoid a lot of shenanigans, and saves money.

I wonder how much this costs: https://aws.amazon.com/outposts/

One recurring issue was the customer's network latency. A corporate vpn that bounces traffic around adds enough latency to make a really good solution feel comparable to using vnc. Reorganizing the network adds to the cost of the solutions.

I'm currently experiencing this. I live near my office and have sufficiently fast home internet. But connecting to the company network and attempting to work on a machine remotely is very painful. Working locally and commiting or accessing mail is still painful, but managable.

I worked for a financial company that ran a private cloud. They provided everyone with beefy workstations (16 physical cores, 32 GB of RAM). 3/4 of those resources were allocated to a VM that ran a custom compute platform that took jobs off of a queue. The explanation was simple. it was easier/cheaper to leverage the workstations than it was to build out the same compute in the datacenter. Granted, there was about a 5 degree temperature differential between under and over my desk, but I didn't complain. Kept me nice and toasty while I worked. This was +10 years ago. Each workstation had 2 Intel Xeons plus an nVidia Quadro for GPU work. Not sure if they've kept up with the tech, but I imagine they have. $10k/workstation wasn't a problem then, and from what I hear, it's probably not a problem now.

That's pretty cool. Sounds to me like a corporate SETI@home.

This also means depending on the internet. In the near future even isolated regional ISP outages would have bigget impacts on the economy

Reply on news.ycombinator.com