To be honest, I only commented on this because seeing the mention of <0.01ms latency, I couldn't help putting it into some perspective (as someone who works on networking stack and has basic idea about other software and hardware layers involved). Personally, I have no interest playing any type of game where a latency of, say, 250ms would be an issue. But if you can find someone able and willing to put together a setup satisfying your requirements, good for you.
@mkubecek said in #21:
> To be honest, I only commented on this because seeing the mention of <0.01ms latency, I couldn't help putting it into some perspective (as someone who works on networking stack and has basic idea about other software and hardware layers involved). Personally, I have no interest playing any type of game where a latency of, say, 250ms would be an issue. But if you can find someone able and willing to put together a setup satisfying your requirements, good for you.
Sure, but you seem to be mostly a classical/rapid chess player, where 250ms or even 1s latency would be perfectly acceptable and not change the outcome of the game.
The issue with hyper and ultra bullet games is that 100ms of latency is enough to significantly change the distribution of outcomes of the game. We all wish to play a clean game of bullet while we are here, but there are times where an opponent goes from 40ms to suddenly 199ms during time trouble, simply abusing the lag compensation lichess provides to the fullest, to give themself a mini-increment so that they have turned a losing bullet/timing position into an equal one simply for enabling their lag switch. Lag compensation is necessary to make something that works for most people, but the issue are people who abuse this system. So for those of us who are passionate about fast chess, well, the latency indeed becomes a huge problem, in the sense that the distribution of outcomes of a latency-based quick chess game have significant differences to that of a system with no lag compensation whatsoever. And yes, I was a bit dreaming when I wrote 0.01ms latency -- I think we can all be happy with, let's say <7ms latency, so that a 144hz screen would always show the move on the very next frame. Cheers.
> To be honest, I only commented on this because seeing the mention of <0.01ms latency, I couldn't help putting it into some perspective (as someone who works on networking stack and has basic idea about other software and hardware layers involved). Personally, I have no interest playing any type of game where a latency of, say, 250ms would be an issue. But if you can find someone able and willing to put together a setup satisfying your requirements, good for you.
Sure, but you seem to be mostly a classical/rapid chess player, where 250ms or even 1s latency would be perfectly acceptable and not change the outcome of the game.
The issue with hyper and ultra bullet games is that 100ms of latency is enough to significantly change the distribution of outcomes of the game. We all wish to play a clean game of bullet while we are here, but there are times where an opponent goes from 40ms to suddenly 199ms during time trouble, simply abusing the lag compensation lichess provides to the fullest, to give themself a mini-increment so that they have turned a losing bullet/timing position into an equal one simply for enabling their lag switch. Lag compensation is necessary to make something that works for most people, but the issue are people who abuse this system. So for those of us who are passionate about fast chess, well, the latency indeed becomes a huge problem, in the sense that the distribution of outcomes of a latency-based quick chess game have significant differences to that of a system with no lag compensation whatsoever. And yes, I was a bit dreaming when I wrote 0.01ms latency -- I think we can all be happy with, let's say <7ms latency, so that a 144hz screen would always show the move on the very next frame. Cheers.
@snared said in #22:
> Sure, but you seem to be mostly a classical/rapid chess player, where 250ms or even 1s latency would be perfectly acceptable and not change the outcome of the game.
Exactly. That's why I wanted to clarify that my interest in this topic is purely technical.
> Sure, but you seem to be mostly a classical/rapid chess player, where 250ms or even 1s latency would be perfectly acceptable and not change the outcome of the game.
Exactly. That's why I wanted to clarify that my interest in this topic is purely technical.
@mkubecek said in #23:
> Exactly. That's why I wanted to clarify that my interest in this topic is purely technical.
Excellent - so there's some gaming technology that partially demonstrates this is possible. There is a 60fps nintendo game from 2004 called Smash Bros Melee, and there is a modern platform for playing this game in realtime using direct websockets between the two players. There is a central matchmaking server, and then your computer probably just spins and creates websockets to people with similar geoIPs until it finds two people with low ping who are ready to play. I found there that as long as my ping was <60ms, I can control my character and react almost as if we were playing right next to each other.
They also implemented a net rollback system. So if there is a quick lag spike, let's say 5 frames of connection were lost. Whatever inputs were made during those 5 frames are eventually put together, and the game state gets rolled back 5 frames and the player's inputs used to calculate the new current position to send off to the players. I have plenty of footage using this system if you are interested in this.
The reason I bring it up is that I think we could in theory have something similar for bullet chess.. There were 384,928 unique
bullet players this week on Lichess (I just checked the stats page) and so I imagine this could be a way to provide infrastructure to make a small slice of the world really happy for just at least just a bit. I myself am a developer and I've worked with UDP and other interesting network structures, so I would be happy to try my hand at making something that I myself am passionate about as well as knowing that plenty of other people in the world might find great joy in this.. Curious on your thoughts of what you have seen or if there maybe already exists some general purpose projects about this kind of area that can be used as a base..
> Exactly. That's why I wanted to clarify that my interest in this topic is purely technical.
Excellent - so there's some gaming technology that partially demonstrates this is possible. There is a 60fps nintendo game from 2004 called Smash Bros Melee, and there is a modern platform for playing this game in realtime using direct websockets between the two players. There is a central matchmaking server, and then your computer probably just spins and creates websockets to people with similar geoIPs until it finds two people with low ping who are ready to play. I found there that as long as my ping was <60ms, I can control my character and react almost as if we were playing right next to each other.
They also implemented a net rollback system. So if there is a quick lag spike, let's say 5 frames of connection were lost. Whatever inputs were made during those 5 frames are eventually put together, and the game state gets rolled back 5 frames and the player's inputs used to calculate the new current position to send off to the players. I have plenty of footage using this system if you are interested in this.
The reason I bring it up is that I think we could in theory have something similar for bullet chess.. There were 384,928 unique
bullet players this week on Lichess (I just checked the stats page) and so I imagine this could be a way to provide infrastructure to make a small slice of the world really happy for just at least just a bit. I myself am a developer and I've worked with UDP and other interesting network structures, so I would be happy to try my hand at making something that I myself am passionate about as well as knowing that plenty of other people in the world might find great joy in this.. Curious on your thoughts of what you have seen or if there maybe already exists some general purpose projects about this kind of area that can be used as a base..
I'm not aware of anything specific (I mostly work on networking stack in the OS) but networked action games certainly sound like the most promising direction for research.
Well, lichess.org runs on OVH in Gravelines, France.
This company has now 50% sale for dedicated servers in the Asia-Pacific regions: Singapore, Australia and India. The sale includes dedicated servers for the gaming.
www.ovhcloud.com/
Start talking to Lichess' people with something that makes sense, not the crackpot requirements of 10 microsecond latency or UDP communication like they would have the same budget as the high-frequency traders.
They would probably be open to hosting one explicit websocket server in the APAC region just as a test.
Edit: Corrected location Roubaix->Gravelines.
This company has now 50% sale for dedicated servers in the Asia-Pacific regions: Singapore, Australia and India. The sale includes dedicated servers for the gaming.
www.ovhcloud.com/
Start talking to Lichess' people with something that makes sense, not the crackpot requirements of 10 microsecond latency or UDP communication like they would have the same budget as the high-frequency traders.
They would probably be open to hosting one explicit websocket server in the APAC region just as a test.
Edit: Corrected location Roubaix->Gravelines.
@LagIsBad said in #19:
> you clearly have no idea what you are talking about, i would say people above 250 ms deserve the comp when people under that range should not be getting comp. "real laggers" that are in the range of 140-250 still get CRAZY comp and they dont get as much loss
yes but you said that for people under 250ms it does not make much of a differance
"A solution I am talking about is like not giving comp for people 250 ms and below as it barely makes a difference."
so by your own admition it would be a pointless change as you said "it barely makes a difference"
i was only using your own words
but as i said in #14 lets not fight but rather find a solution that lichess likes
Which means it has to
help all
be secure
and not cost an arm and a leg
making only some get lag comp does not fix the problems
@kalafiorczyk Lichess was designed not in the most scalable way meaning you cant do multiple servers. you can only scale verticaly and not horizontally with the way lichess is written
> you clearly have no idea what you are talking about, i would say people above 250 ms deserve the comp when people under that range should not be getting comp. "real laggers" that are in the range of 140-250 still get CRAZY comp and they dont get as much loss
yes but you said that for people under 250ms it does not make much of a differance
"A solution I am talking about is like not giving comp for people 250 ms and below as it barely makes a difference."
so by your own admition it would be a pointless change as you said "it barely makes a difference"
i was only using your own words
but as i said in #14 lets not fight but rather find a solution that lichess likes
Which means it has to
help all
be secure
and not cost an arm and a leg
making only some get lag comp does not fix the problems
@kalafiorczyk Lichess was designed not in the most scalable way meaning you cant do multiple servers. you can only scale verticaly and not horizontally with the way lichess is written
@for_cryingout_loud said in #27:
> Lichess was designed not in the most scalable way meaning you cant do multiple servers. you can only scale verticaly and not horizontally with the way lichess is written
Then what are the servers socket0.lichess.org to socket5.lichess.org if not the horizontal scaling over 6 servers?
They could put one (or two) in somewhere in the APAC data center. Don't include them in the normal load balancing in Gravelines, but make them available only from the separate "Create a bullet game over Pacific" page.
OVH has special solution available for inter-data-center private networking that works somewhat more efficiently than the public Internet. But my transoceanic & transcontinental tests show that even the public IPv6 between OVH data centers works close enough to the speed of light in glass.
> Lichess was designed not in the most scalable way meaning you cant do multiple servers. you can only scale verticaly and not horizontally with the way lichess is written
Then what are the servers socket0.lichess.org to socket5.lichess.org if not the horizontal scaling over 6 servers?
They could put one (or two) in somewhere in the APAC data center. Don't include them in the normal load balancing in Gravelines, but make them available only from the separate "Create a bullet game over Pacific" page.
OVH has special solution available for inter-data-center private networking that works somewhat more efficiently than the public Internet. But my transoceanic & transcontinental tests show that even the public IPv6 between OVH data centers works close enough to the speed of light in glass.
Wow finally someone agrees with me dm me via discord my friend @LagIsBad
Im played nearly 80k games on this site (%90 ultra)
And yes lag is a big problem. I hated from keyboard players much but i noticed that lag is a bigger problem.
Because you can beat keyboard players with gamestyle or with antipremoves but laggers are able to play slowly (they dont lose time thats why) and they can think more.
(I am not a keyboard player and i wasnt )
Thanks for reading
-@manyamis_manyak
And yes lag is a big problem. I hated from keyboard players much but i noticed that lag is a bigger problem.
Because you can beat keyboard players with gamestyle or with antipremoves but laggers are able to play slowly (they dont lose time thats why) and they can think more.
(I am not a keyboard player and i wasnt )
Thanks for reading
-@manyamis_manyak
This topic has been archived and can no longer be replied to.