The vast majority of unauthorized immigration is not illegal. It's only a misdemeanor the first time you're caught, and you can get a temporary stay while you apply for residency. Nearly every "illegal" immigrant is involved with drugs, weapons, or is otherwise violent. Almost everyone else is legal, even if they get in trouble.
From the holistic view, it changes who holds the most risk. Instead of school getting paid no matter what, they most likely only get paid and get paid the most if they create decent employees.
know of life that exists in deep sea conditions and some life that can survive crazy radiation, no oxygen and no sunlight, etc
Extremophiles do not make do not result in a wide range of life and they'll never be very intelligent, any may not ever have brains just simple nervous systems. "Life" my survive on earth in many different conditions, but life that can get off the planet before it's swallowed by the sun cannot.
Depends on what you mean by "market rate". Only about 30% of price per kwh is actually the energy. The rest is infrastructure costs, which is relatively fixed. As a source, you don't get the infrastructure value.
Solar reduces the volume of load on coal, but exacerbates the rate at which peak load on coal increases. Just as solar is dropping off, peak usage is ramping up. Coal has issues keeping up. The solution is to throw more fuel at it, which greatly reduces efficiency.
I'm in the Midwest with very cheap power, $0.10/kwh flat pricing that hasn't changed in 15+ years now, I can opt in for peak pricing, which drops off-peak price to about $0.045/kwh and on-peak of $0.16. This is enough difference in pricing to purchase a zero install cost load shifter that will pay itself off is ~10 years. Unlike a solar install where I have to get someone to hook it up and all of the other annoyances, I can literally just plug in one of these load shifters into any outlet in the house and start saving money instantly without any configuration. Of course configuring the device is required to maximize savings if you want to pay off within 10 years. Another benefit is at least one of the devices supports acting as a UPS for all devices on the breaker circuit. In the case of a power outage, it flips the breaker, which disconnects it from the grid, and continues to operate.
Most of the devices are relatively dumb, but can be scheduled. You can configure charging, discharging, and idle times. And the charging and discharging can be configured to certain charge rates, like maybe you want it to charge at 800watts but discharge at 400watts, or whatever range and granularity it supports. Some also support pulling data from the internet and can adjust to dynamic changes in pricing. This is only useful where your location has some sort of "smart grid" with dynamic pricing.
You make the assumption that the power plant output the same amount of pollution per kwh. This is only true during steady load and the plant at a stead state. If load changes, efficiency drops like a rock and emissions skyrocket. The point of batteries is to stability and smooth out the load, allowing power plants to be more efficient.
Some years ago, GE announce hybrid natural gas hybrid turbines that had batteries hooked into the system. Normally they have to keep some number of turbines running idle in order to react to load changes in a timely fashion. By adding batteries, they can turn off the turbines instead of idling them because the batteries give enough hold over to spin up the turbines if they're actually needed. This reduced overall fuel consumption by something like 20%.
There was a recent case study of some smaller country that was poorer, which resulted in greater difference between on and off peak demand and could not afford separate peaker plants. They added a multi-megawatt hour battery bank to their power grid to smooth out demand and paid off the entire battery bank in 6-8 months just from fuel savings for the coal power plants. The other major benefit of the battery bank is unlike a normal power plant, it could be brought online pieces at a time and upgraded in small chunks over time, unlike normal power plants that require much up-front capital and many many years before the come online.
But much less efficient when it causes a coal power plant trying to spin down. On the whole, blindly dumping power from solar onto the grid is less efficient.
If I owe them a debt, then I must be a debtor, which makes them a creditor. I have rights as a debtor, like paying within 30 days of notice that I have to pay without penalty.
By law, I cannot be arrested for not paying a debt unless it's by court order. I can be sued for non-payment and be garnished, but that's it. There are laws around debt repayment. If it's a debt I owe, then I guess I can walk off and pay later.
I've always been interested in all aspects of the lifetime of software services. I am part of a small team in my company that deal with one-off custom projects, typically driven by SLA'd large contracts. We get district, state, and national level requests. We need to deal with many aspects of these demands. Our company does not specialize in contracted work, the work is all value add, it has to be treated as being throw away work, but at the same time we cannot train up Ops or any other team. Due to all of the requirements, it is impractical to get too many people involved.
We analyse, design, implement, deploy, and operate our custom services as a 5 person team, in a multi-billion dollar company with hundreds of software engineers. We have tens of millions of users who tend to hit the myriad of services hard at roughly the same few times every year, and a low constant rate throughout the year. The systems need to be stable, performant, easy to configure, easy to diagnose, and difficult to not understand. It must lead you to doing the correct thing. Make it easy to do the right thing and difficult to do the wrong thing.
Our team has several years of backlog, primarily in tooling enhancements to better support ourselves. Our biggest pain point is we're dependent on nearly every other services in the company. This means our services break when other services are not working to spec, assuming we're graced with a spec. We constantly deal with undocumented unreliable systems that are liable to change without warning. When we design a system, we go over nearly every possible case and either handle them or make it blatantly obvious what the issue is.
I get peeved when I hear someone from ops putting in 60 hour weeks because the general services are constantly needing to be hand-tuned with a seemingly chaotic load pattern because of the.... "intricate"... inter-service dependencies and unreliable performance characteristics. I just want to tear out someone's throat when I ask "how many concurrent requests should I be making to your service and how long should we wait before considering it a timeout?" and getting "Measure it and see what's fastest. If you're getting timeouts, try increasing your timeout setting and see if that helps. If you're still having performance issues, open a defect." Yeah.. please find another line of work you code monkey. The best part is when someone responds like this, we almost invariably overload their services and ops yells at us. And boy do I hate making ops' life any harder than it needs to be.
We quickly found that we needed to add multiple forms of rate limiting to our services. Engineering "load tests" their services and they claim everything is fine, but for some reason we blow their crap out of the water. It's been an interesting exercise in system design to make sure our systems are very gentle with the snow flake services because they seemingly spontaneously go from steady-ish response times to timing out every request for a minute or so without warning. Generally feels like garbage collection issues, but we never know.
I found out ops has to manually scale many of the AWS services up and down because certain negative scaling characteristics. No AWS auto-scaling here. Adding more nodes to many of the clusters barely gives any increase to throughput, and response time jitter increases as the number of nodes goes up. The main benefit of adding more nodes is there are more instances to buffer events. Other services expect an event to be "serviced" in a reasonable time, so pulling an event out of the event queue makes it look like they are. Of course, if one of these nodes goes down while holding onto all of these events, the events are effectively lost without lots of manual intervention. And each additional node increases the risk of race conditions, to which they have created hundreds of scripts that walk the data during off hours to make educated guesses on how to fix data in an unknown state. But whatever, it's ops' issue now, right?
Owing money for a service is not being in debt. It is considered a singular transaction, even if the service is provided prior to expected payment. If it was real debt, you would have at least verbally acknowledged that you'd be going into debt, like asking to put the bill on your tab.
Most of the buzzwords are real things that someone implemented very successfully, but the general population likes to treat it like magic and if they do some rain dance, all of their problems will go away. Of course they don't understand anything about the dance and just follow the path of least resistance, which is nearly guaranteed to be wrong. Devops and Agile are very real processes to dealing with certain types of problems. There is no one process for these. They're a class of processes. You need to tweak the process for your current issue. If you don't understand the process, you'll end up using the claw end of the hammer to hit nails.
Technology, aka tools, can never fix human problems, like incompetence. Incompetence in the work force is reinforced by incompetent people hiring others more incompetent than themselves.
Devops the concept is great, "devops" the buzzword is just adding more complexity with little or no benefit. The idea of devops is the devs design their projects such that they maintain the operations. This leads to the desirable outcome of a moral feedback that forces the devs to actually care. Without it, devs just throw the responsibly to operate over the wall and divorces them from the consequence of poor design.
Without devops, devs tend to product projects that are brittle and need to be micromanaged. Why would devs care if ops gets called at 1am on a Saturday? If the devs are getting called in the middle of the night, they'll start to care.
Ops should be limited to maintaining infrastructure services like VMs and creating tools to allows devs to deploy to prod on their own in a controlled way.
Saturation can happen at any timescale, it doesn't need to be constant. About 5 years ago I was having issues where all of the streaming services were sending at least 1Gb/s at me. The streaming services use HTTP over TCP and transfer in 250KiB chunks, which fit in most network buffers. Since no packets were dropped, the TCP window kept opening up. Since the streaming services only need to average around 8Mb/s per stream, this resulted in the TCP connection being idle for most of the duration. With the connection being idle and the window was large enough to fit the entire 250KiB chunk and the 250KiB chunk fit in all of the buffers without causing packet loss, every time a chunk needed to be transferred, it resulted in the sender sending at max rate. If I was gaming while someone was streaming, about every 20-30 seconds, I would get a 200ms+ latency burst and loss in some cases.At the time the ISP was using normal FIFO buffering, which results in the fat flows monopolizing the buffers and sparse flows getting their packets dropped. This is the opposite of what you want. At some point in the last few years, my ISP can switched to using an AQM and this is no longer an issue.
My anecdote raises several issues. 1) TCP packet pacing is important 2) TCP shouldn't go from idle to full rate, probably do a slow start all over 3) Fair queuing is important because FIFO buffers reinforce bad behavior by statistically rewarding fat flows
Data is literally linearly scales with the number of frames displayed. Double the viewed frames, double the amount of data. An object that shows for 1 frame at 120hz has a 50/50 chance of displaying at all at 60hz .
PFSense using FairQ+Codel is pretty decent and really easy to setup. Many Linux firewalls support fq_codel, which has a fair queue algorithm baked in. If you're ISP has an AQM, like mine, depending on the algorithm you can potentially have zero packetloss, within reason, while under a DOS. I've tested up to a 500Mb/s DOS over 32 streams against my 250Mb connection and suffered zero packets lossed and unaffected latency. My bandwidth was severely reduced, but the AQM was mostly fairly distributing the bandwidth among all of the data streams, including the "unwanted" DOS streams. If I set the DOS to emulated a DDOS by making each packet look like it was coming from a different sender, that overwhelmed the AQM and I started to suffer loss and 20-40ms of latency.
Unless someone is DDOSing me, I can let any device attempt to hog as much bandwidth as it wants and not care. Zero configuration outside of enabling the AQM. No setting priorities, no marking traffic, nothing. Just enable and forget.
Of course the DOS packets were being dropped, but the main point is that other traffic was unaffected by the fat flows.
That's an issue with current client and server prediction. I was playing games that didn't have prediction. That means if I had packet loss, I looked like I was standing still to others, and you also look like you can't move on your end. It wasn't until a later version of Half-life that you saw the whole gaming the prediction system with artificial latency and loss.
5ms network RTT to remote VM, not input delay. The 90ms input delay was using all decent quality mid-grade gaming components with a 60hz name brand "gaming" monitor with out of the box Win10 settings.
That link was awesome. 20ms difference in input delay just because of the model keyboard. Don't forget the test was done with 180hz monitor. The 90ms test I watched was with a typical mid-grade 60hz gaming monitor.
I found the person who never played Quake style deathmatch games. Fast paced close quarter action. 60hz and 120hz is the difference between seeing something and not seeing something when an object is only in your field of view for less than 1/60th of a second. Humans can react to objects below 1/300th of a second.
Human reaction time is around 250ms for primitive visual stimuli. Humans treat 80-100ms as "instant" because of how the brain works. Audio on TV is about 100ms out of sync but it seem in sync because the brain makes it seem that way. It takes nearly 150ms for information to get incorporated into your consciousness.
In competitive FPS games when dealing with the upper percentile, latency differences all the way down to 10ms can make a statistical difference over many games. My guess is what most people complain about "high latency" isn't the latency, but the jitter of a crappy route that is highly correlated with latency. Stability of latency is the most important below 80ms.
I actually am lucky to have a less than 10ms ping to most FPS game servers that I play. And a very stable 6-10ms with less than 0.1ms of jitter. I actually have noticed more issues with ultra-low latency servers than higher latency servers, all the way into the 80ms range. Client side prediction seems to have a a strange interaction at such low latencies. Around 20-30ms seems to be optimal where I'm not noticing strange micro-stuttering of player locations caused by what I assume is the server correcting what I'm seeing. It's like I'll see players making frequent location corrections of very small amounts instead of infrequent corrections of marginally larger amounts.
I'm very sensitive to these oddities because I grew up playing games like Quake over unstable dialup where there was no prediction logic of any kind and I had to in near real time identify changes to network quality by the way the game was acting in order to adjust my input compensations. I was a very competitive player and could mop the floor against most LPBs with their ISDNs and T1 dorm connections over my 250-500ms dialup over staticy lines.
I'm trying to look into this. I've seen some tests with gaming machines where the input lag was around 90ms from keypress to screen. Someone was testing input lag between their local machine and Shadow Play and got the exact same results when they had a 5ms ping to the remote. The network latency was not accumulative with the other latencies. This indicates that some portion of the total input latency is relatively fixed in some fashion and as long as the effective round trip is below this value, there is no difference.
I don't know how Geforce Now is implemented, but accumulative latency is not a fundamental issue.
Slashdot Mirror
The vast majority of unauthorized immigration is not illegal. It's only a misdemeanor the first time you're caught, and you can get a temporary stay while you apply for residency. Nearly every "illegal" immigrant is involved with drugs, weapons, or is otherwise violent. Almost everyone else is legal, even if they get in trouble.
From the holistic view, it changes who holds the most risk. Instead of school getting paid no matter what, they most likely only get paid and get paid the most if they create decent employees.
The biggest problem I have with a grocery list is remembering it and finding it. If it's not on my phone, it may as well not exist.
know of life that exists in deep sea conditions and some life that can survive crazy radiation, no oxygen and no sunlight, etc
Extremophiles do not make do not result in a wide range of life and they'll never be very intelligent, any may not ever have brains just simple nervous systems. "Life" my survive on earth in many different conditions, but life that can get off the planet before it's swallowed by the sun cannot.
Depends on what you mean by "market rate". Only about 30% of price per kwh is actually the energy. The rest is infrastructure costs, which is relatively fixed. As a source, you don't get the infrastructure value.
Solar reduces the volume of load on coal, but exacerbates the rate at which peak load on coal increases. Just as solar is dropping off, peak usage is ramping up. Coal has issues keeping up. The solution is to throw more fuel at it, which greatly reduces efficiency.
I'm in the Midwest with very cheap power, $0.10/kwh flat pricing that hasn't changed in 15+ years now, I can opt in for peak pricing, which drops off-peak price to about $0.045/kwh and on-peak of $0.16. This is enough difference in pricing to purchase a zero install cost load shifter that will pay itself off is ~10 years. Unlike a solar install where I have to get someone to hook it up and all of the other annoyances, I can literally just plug in one of these load shifters into any outlet in the house and start saving money instantly without any configuration. Of course configuring the device is required to maximize savings if you want to pay off within 10 years. Another benefit is at least one of the devices supports acting as a UPS for all devices on the breaker circuit. In the case of a power outage, it flips the breaker, which disconnects it from the grid, and continues to operate.
Most of the devices are relatively dumb, but can be scheduled. You can configure charging, discharging, and idle times. And the charging and discharging can be configured to certain charge rates, like maybe you want it to charge at 800watts but discharge at 400watts, or whatever range and granularity it supports. Some also support pulling data from the internet and can adjust to dynamic changes in pricing. This is only useful where your location has some sort of "smart grid" with dynamic pricing.
You make the assumption that the power plant output the same amount of pollution per kwh. This is only true during steady load and the plant at a stead state. If load changes, efficiency drops like a rock and emissions skyrocket. The point of batteries is to stability and smooth out the load, allowing power plants to be more efficient.
Some years ago, GE announce hybrid natural gas hybrid turbines that had batteries hooked into the system. Normally they have to keep some number of turbines running idle in order to react to load changes in a timely fashion. By adding batteries, they can turn off the turbines instead of idling them because the batteries give enough hold over to spin up the turbines if they're actually needed. This reduced overall fuel consumption by something like 20%.
There was a recent case study of some smaller country that was poorer, which resulted in greater difference between on and off peak demand and could not afford separate peaker plants. They added a multi-megawatt hour battery bank to their power grid to smooth out demand and paid off the entire battery bank in 6-8 months just from fuel savings for the coal power plants. The other major benefit of the battery bank is unlike a normal power plant, it could be brought online pieces at a time and upgraded in small chunks over time, unlike normal power plants that require much up-front capital and many many years before the come online.
But much less efficient when it causes a coal power plant trying to spin down. On the whole, blindly dumping power from solar onto the grid is less efficient.
If I owe them a debt, then I must be a debtor, which makes them a creditor. I have rights as a debtor, like paying within 30 days of notice that I have to pay without penalty.
By law, I cannot be arrested for not paying a debt unless it's by court order. I can be sued for non-payment and be garnished, but that's it. There are laws around debt repayment. If it's a debt I owe, then I guess I can walk off and pay later.
I've always been interested in all aspects of the lifetime of software services. I am part of a small team in my company that deal with one-off custom projects, typically driven by SLA'd large contracts. We get district, state, and national level requests. We need to deal with many aspects of these demands. Our company does not specialize in contracted work, the work is all value add, it has to be treated as being throw away work, but at the same time we cannot train up Ops or any other team. Due to all of the requirements, it is impractical to get too many people involved.
We analyse, design, implement, deploy, and operate our custom services as a 5 person team, in a multi-billion dollar company with hundreds of software engineers. We have tens of millions of users who tend to hit the myriad of services hard at roughly the same few times every year, and a low constant rate throughout the year. The systems need to be stable, performant, easy to configure, easy to diagnose, and difficult to not understand. It must lead you to doing the correct thing. Make it easy to do the right thing and difficult to do the wrong thing.
Our team has several years of backlog, primarily in tooling enhancements to better support ourselves. Our biggest pain point is we're dependent on nearly every other services in the company. This means our services break when other services are not working to spec, assuming we're graced with a spec. We constantly deal with undocumented unreliable systems that are liable to change without warning. When we design a system, we go over nearly every possible case and either handle them or make it blatantly obvious what the issue is.
I get peeved when I hear someone from ops putting in 60 hour weeks because the general services are constantly needing to be hand-tuned with a seemingly chaotic load pattern because of the.... "intricate"... inter-service dependencies and unreliable performance characteristics. I just want to tear out someone's throat when I ask "how many concurrent requests should I be making to your service and how long should we wait before considering it a timeout?" and getting "Measure it and see what's fastest. If you're getting timeouts, try increasing your timeout setting and see if that helps. If you're still having performance issues, open a defect." Yeah.. please find another line of work you code monkey. The best part is when someone responds like this, we almost invariably overload their services and ops yells at us. And boy do I hate making ops' life any harder than it needs to be.
We quickly found that we needed to add multiple forms of rate limiting to our services. Engineering "load tests" their services and they claim everything is fine, but for some reason we blow their crap out of the water. It's been an interesting exercise in system design to make sure our systems are very gentle with the snow flake services because they seemingly spontaneously go from steady-ish response times to timing out every request for a minute or so without warning. Generally feels like garbage collection issues, but we never know.
I found out ops has to manually scale many of the AWS services up and down because certain negative scaling characteristics. No AWS auto-scaling here. Adding more nodes to many of the clusters barely gives any increase to throughput, and response time jitter increases as the number of nodes goes up. The main benefit of adding more nodes is there are more instances to buffer events. Other services expect an event to be "serviced" in a reasonable time, so pulling an event out of the event queue makes it look like they are. Of course, if one of these nodes goes down while holding onto all of these events, the events are effectively lost without lots of manual intervention. And each additional node increases the risk of race conditions, to which they have created hundreds of scripts that walk the data during off hours to make educated guesses on how to fix data in an unknown state. But whatever, it's ops' issue now, right?
Owing money for a service is not being in debt. It is considered a singular transaction, even if the service is provided prior to expected payment. If it was real debt, you would have at least verbally acknowledged that you'd be going into debt, like asking to put the bill on your tab.
"Graceful degradation" is the unsung hero of properly engineered systems.
Most of the buzzwords are real things that someone implemented very successfully, but the general population likes to treat it like magic and if they do some rain dance, all of their problems will go away. Of course they don't understand anything about the dance and just follow the path of least resistance, which is nearly guaranteed to be wrong. Devops and Agile are very real processes to dealing with certain types of problems. There is no one process for these. They're a class of processes. You need to tweak the process for your current issue. If you don't understand the process, you'll end up using the claw end of the hammer to hit nails.
Technology, aka tools, can never fix human problems, like incompetence. Incompetence in the work force is reinforced by incompetent people hiring others more incompetent than themselves.
Devops the concept is great, "devops" the buzzword is just adding more complexity with little or no benefit. The idea of devops is the devs design their projects such that they maintain the operations. This leads to the desirable outcome of a moral feedback that forces the devs to actually care. Without it, devs just throw the responsibly to operate over the wall and divorces them from the consequence of poor design.
Without devops, devs tend to product projects that are brittle and need to be micromanaged. Why would devs care if ops gets called at 1am on a Saturday? If the devs are getting called in the middle of the night, they'll start to care.
Ops should be limited to maintaining infrastructure services like VMs and creating tools to allows devs to deploy to prod on their own in a controlled way.
Saturation can happen at any timescale, it doesn't need to be constant. About 5 years ago I was having issues where all of the streaming services were sending at least 1Gb/s at me. The streaming services use HTTP over TCP and transfer in 250KiB chunks, which fit in most network buffers. Since no packets were dropped, the TCP window kept opening up. Since the streaming services only need to average around 8Mb/s per stream, this resulted in the TCP connection being idle for most of the duration. With the connection being idle and the window was large enough to fit the entire 250KiB chunk and the 250KiB chunk fit in all of the buffers without causing packet loss, every time a chunk needed to be transferred, it resulted in the sender sending at max rate. If I was gaming while someone was streaming, about every 20-30 seconds, I would get a 200ms+ latency burst and loss in some cases.At the time the ISP was using normal FIFO buffering, which results in the fat flows monopolizing the buffers and sparse flows getting their packets dropped. This is the opposite of what you want. At some point in the last few years, my ISP can switched to using an AQM and this is no longer an issue.
My anecdote raises several issues. 1) TCP packet pacing is important 2) TCP shouldn't go from idle to full rate, probably do a slow start all over 3) Fair queuing is important because FIFO buffers reinforce bad behavior by statistically rewarding fat flows
Data is literally linearly scales with the number of frames displayed. Double the viewed frames, double the amount of data. An object that shows for 1 frame at 120hz has a 50/50 chance of displaying at all at 60hz .
PFSense using FairQ+Codel is pretty decent and really easy to setup. Many Linux firewalls support fq_codel, which has a fair queue algorithm baked in. If you're ISP has an AQM, like mine, depending on the algorithm you can potentially have zero packetloss, within reason, while under a DOS. I've tested up to a 500Mb/s DOS over 32 streams against my 250Mb connection and suffered zero packets lossed and unaffected latency. My bandwidth was severely reduced, but the AQM was mostly fairly distributing the bandwidth among all of the data streams, including the "unwanted" DOS streams. If I set the DOS to emulated a DDOS by making each packet look like it was coming from a different sender, that overwhelmed the AQM and I started to suffer loss and 20-40ms of latency.
Unless someone is DDOSing me, I can let any device attempt to hog as much bandwidth as it wants and not care. Zero configuration outside of enabling the AQM. No setting priorities, no marking traffic, nothing. Just enable and forget.
Of course the DOS packets were being dropped, but the main point is that other traffic was unaffected by the fat flows.
That's an issue with current client and server prediction. I was playing games that didn't have prediction. That means if I had packet loss, I looked like I was standing still to others, and you also look like you can't move on your end. It wasn't until a later version of Half-life that you saw the whole gaming the prediction system with artificial latency and loss.
5ms network RTT to remote VM, not input delay. The 90ms input delay was using all decent quality mid-grade gaming components with a 60hz name brand "gaming" monitor with out of the box Win10 settings.
That link was awesome. 20ms difference in input delay just because of the model keyboard. Don't forget the test was done with 180hz monitor. The 90ms test I watched was with a typical mid-grade 60hz gaming monitor.
I found the person who never played Quake style deathmatch games. Fast paced close quarter action. 60hz and 120hz is the difference between seeing something and not seeing something when an object is only in your field of view for less than 1/60th of a second. Humans can react to objects below 1/300th of a second.
Human reaction time is around 250ms for primitive visual stimuli. Humans treat 80-100ms as "instant" because of how the brain works. Audio on TV is about 100ms out of sync but it seem in sync because the brain makes it seem that way. It takes nearly 150ms for information to get incorporated into your consciousness.
In competitive FPS games when dealing with the upper percentile, latency differences all the way down to 10ms can make a statistical difference over many games. My guess is what most people complain about "high latency" isn't the latency, but the jitter of a crappy route that is highly correlated with latency. Stability of latency is the most important below 80ms.
I actually am lucky to have a less than 10ms ping to most FPS game servers that I play. And a very stable 6-10ms with less than 0.1ms of jitter. I actually have noticed more issues with ultra-low latency servers than higher latency servers, all the way into the 80ms range. Client side prediction seems to have a a strange interaction at such low latencies. Around 20-30ms seems to be optimal where I'm not noticing strange micro-stuttering of player locations caused by what I assume is the server correcting what I'm seeing. It's like I'll see players making frequent location corrections of very small amounts instead of infrequent corrections of marginally larger amounts.
I'm very sensitive to these oddities because I grew up playing games like Quake over unstable dialup where there was no prediction logic of any kind and I had to in near real time identify changes to network quality by the way the game was acting in order to adjust my input compensations. I was a very competitive player and could mop the floor against most LPBs with their ISDNs and T1 dorm connections over my 250-500ms dialup over staticy lines.
I'm trying to look into this. I've seen some tests with gaming machines where the input lag was around 90ms from keypress to screen. Someone was testing input lag between their local machine and Shadow Play and got the exact same results when they had a 5ms ping to the remote. The network latency was not accumulative with the other latencies. This indicates that some portion of the total input latency is relatively fixed in some fashion and as long as the effective round trip is below this value, there is no difference.
I don't know how Geforce Now is implemented, but accumulative latency is not a fundamental issue.
I see what you did there