Pages: [1] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Hesperius
|
Posted - 2011.03.28 22:27:00 -
[1]
Problem: Something I have noticed is that if I log in during Euro TZ, I am at a general disadvantage and do poorly compared to when I log in during US peak time. I did a little research into it, asking various people what their pings were to the server and it turns out that in the best case scenario for most people in the states, NZ & Australia, we are 1-2 seconds behind Europe.
As an example of what can and does happen: You jump through a gate and hit warp at the beginning of the first server cycle, then you hit cloak which is denied because the server has not cycled and sent you a response that you have uncloaked yet. So at the end of the cycle the server send you the ok to cloak, which can take over 1 second to get to you. Within that second someone in the UK can have you warp scrambled. When your command goes back to the server to cloak, it is denied and sent back with a notice that you are warp scrambled.
It is impossible for those two roles to be reversed and have the same outcome because of the latency. This holds true for everything from cloaking to chasing someone down to get a point on them, to warping out in structure and dieing mid warp. It did seem that in the Tyranis patch that CCP did make a slight tweak to this system by adding in 1 second safety timer after decloaking so you can't be locked, it did balance it out a bit, but the issue is still there. If it extends any further, anything with less than a 3 second align time would be virtually impossible to tackle.
This might just be a reason that CCP wants Eve to be more geared toward large fleet fights. This delay is buried under other lag and goes unnoticed in large fleet fights. Also nobody should be ashamed that 2000 players on a single battlefield complain about lag, it looks amazing with current tech that you CONNECTED 2000 players on a single battlefield. When 6 players complain that they notice lag, its embarrassing.
Solution: To improve performance to players in their peak time, I suggest that the server 'floats' across the globe. How it would work is when a system is empty and someone jumps into that system, the session change would make the request to the operator, and the operator would direct the system and player onto the server which is in the peek time.
So over 24 hours most PVP systems would move like this: Moscow -> UK/Reykjavik -> Atlanta -> Shanghai/Toyoko/Brisbane
So that a player can not 'hold' a system open on their time zone I would also include a client side flag that would be raised when the player has been AFK for 5 minutes. If there are players in that system that wants to be moved, once all players have been flagged as AFK the server will move and all players will enter a session change.
|
Vardec Crom
Executive Intervention Controlled Chaos
|
Posted - 2011.03.29 00:16:00 -
[2]
I was under the impression everything went to London no matter where you live. Seems like it would really expensive to set up 4 or 5 server clusters across the globe so everyone has equal latency. Unless I'm misunderstanding your solution.
|
Flex Nebura
Caldari
|
Posted - 2011.03.29 06:56:00 -
[3]
I havent personally experienced any problems, but the way you describe it certainly looks interesting. And I can see how distance to the server could have an effect.
Im assuming, as you say that you are a at a disadvantage during EU peak time, that you are in the US or even further away. But how would a floating server solve that particular problem?
You would still be at a disadvantage to EU players if you played vs them in their peak hours.
It would ofcourse let everyone else have their own advantage at their peak times. And I guess that would be fair. Another way to do it would be to nerf the EU connections and give them a worse server response time... But dont think anyone would ever try to make connections worse intentionally.
|
Hayaishi
Gallente Aperture Harmonics
|
Posted - 2011.03.29 06:59:00 -
[4]
Edited by: Hayaishi on 29/03/2011 06:59:36 If you're getting a 1000-2000 ms ping, then you have one hell of a bad connection.
Pinging 87.237.38.200 with 32 bytes of data: Reply from 87.237.38.200: bytes=32 time=422ms TTL=107 Reply from 87.237.38.200: bytes=32 time=423ms TTL=107 Reply from 87.237.38.200: bytes=32 time=423ms TTL=107 Reply from 87.237.38.200: bytes=32 time=423ms TTL=107
^ my ping from Perth WA.
edit: 87.237.38.200 = TQ
|
WillageGirl
|
Posted - 2011.03.29 07:19:00 -
[5]
My RTT stays under 500ms even if I tunnel my connection through a server in Japan... thats Finland -> Japan -> GB
So if your RTT goes over 2000ms your ISP is to blame and no distributed servermodels are gonna fix that.
Fighting for Our right to Cloak since 2004 |
Jaari Val'Dara
Caldari Atomic Zeppelins BricK sQuAD.
|
Posted - 2011.03.29 09:08:00 -
[6]
Solution: Press warp and then press cloak. Even if you've got lag, you will cloak instantly, because the requests for decloak and cloak are sent in the same cycle. At least I think thats how it works.
|
Ophelia Ursus
|
Posted - 2011.03.29 09:27:00 -
[7]
Better Solution: Move to a civilised country. Don't know why you're expecting much of anything out there in the colonies, should consider yourself lucky to be able to participate at all. Damnable colonials and their ridiculous jumped-up senses of entitlement.
30 ms average ping to TQ.
(Seriously - asking a company to quadruple their server-related operating costs just to reduce the pings of a fraction of their customer base? yeah, probably not gonna happen) Signature removed. |
Reeno Coleman
|
Posted - 2011.03.29 11:28:00 -
[8]
I'm sorry, that idea is ridiculous.
Hamsters are used to London climate, they die, when the sun shines.
|
GizzyBoy
|
Posted - 2011.03.29 12:06:00 -
[9]
Pinging 87.237.38.200 with 32 bytes of data:
Reply from 87.237.38.200: bytes=32 time=394ms TTL=115 Reply from 87.237.38.200: bytes=32 time=391ms TTL=115 Reply from 87.237.38.200: bytes=32 time=393ms TTL=115 Reply from 87.237.38.200: bytes=32 time=392ms TTL=115
Ping statistics for 87.237.38.200: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 391ms, Maximum = 394ms, Average = 392ms
From nz whilst i download a couple of gigs of stuff.. at 1mbs on dsl
|
Francis en Welle
|
Posted - 2011.03.29 12:32:00 -
[10]
Before you post something like that again, check out the latest tech devblog and google the prices for the things they said they bought.
|
|
|
|
|
Pages: [1] :: one page |
First page | Previous page | Next page | Last page |