I don't think so... Nexu from World Garage Explains it all...
Reduce lag, technically plausible by dividing the load over more servers. But depend what kind of lag the user is experiencing: network lag or graphics/fps lag. But it's rather weird to suggest they are running it on a single server right now; the servers are or should probably be a cluster. So splitting it up into Shard doesn't fit the idea that this is done to fix the lag. And if network bandwidth was the issue, they could have always just decided to relocate their server park to another datacenter which can provide the necessary bandwidth, but it's unlikely that bandwidth issue is the case.
I don't believe this will be THE solution to fix sync or lag issues. In fact, when i login and select NA server (and remind you, i'm in Europe). I'm actually connecting to a server located in the UK.
< snippet >
TCP 192.168.2.2:51652 22.214.171.124:https ESTABLISHED 6132 [nfsw.exe]
TCP 192.168.2.2:51653 126.96.36.199:5222 ESTABLISHED 6132 [nfsw.exe]
The 188.8.131.52 IP is the one the game uses for game data. The whois database as well traceroute tells me the IP is routed to UK (London):
inetnum: 184.108.40.206 - 220.127.116.11
descr: Base-01 IP Space
9 25 ms 25 ms 25 ms coreb-edge4.lon3.rackspace.net [18.104.22.168]
10 25 ms 25 ms 25 ms core5a-coreb.lon3.rackspace.net [22.214.171.124]
11 25 ms 25 ms 25 ms aggr301a-core5a.lon3.rackspace.net [126.96.36.199]
12 24 ms 25 ms 25 ms 188.8.131.52
Or see Netcraft results here.
Doing a ping test from Amsterdam:
Pingen naar 184.108.40.206 met 32 bytes aan gegevens:
Antwoord van 220.127.116.11: bytes=32 tijd=24 ms TTL=238
Antwoord van 18.104.22.168: bytes=32 tijd=25 ms TTL=238
Which seems to be consistent with pinging BBC:
Pingen naar bbc.co.uk [22.214.171.124] met 32 bytes aan gegevens:
Antwoord van 126.96.36.199: bytes=32 tijd=27 ms TTL=243
Antwoord van 188.8.131.52: bytes=32 tijd=26 ms TTL=243
(Ignore the Dutch, it was done on a machine with Dutch version of Windows installed)
Improve sync during race? Probably not:
As posted above: the game uses TCP connection for the game data. The nature of TCP is designed for reliability that the packets arrives correctly, thus not suitable for low latency network application, such as online video game. It will tries to resend the packet till it arrives.
If you look at most other online video games which involves low-latency, such as FPS games. They all (or nearly all) uses UDP connection. UDP will simply send the packet and let the application on how to handle it.
Another catch of TCP connection is that it's an ordered delivery of a stream. So it has to send all the packets in order. Where as UDP just disgards whatever hasn't received, rather than trying to resend it again.
Wonder why sometimes a legit player that is lagging appear to be brieftly "speedhacking/warping"? That's because the delayed TCP packets finally arrived (on the server and/or on your client) and has to be processed, messing up the time stamp and make some appear to be 'flying'.
What the game needs to fix the sync during races is to switch over to UDP connection for races for the game data: player positions and input. While introducing some sort of prediction mechanism/anti-lag for when a player is lagging. Similar to how most FPS deals with network connection lag anno 2000 A.C (yes, a technique more than a decade old).
PS = I'm using FPS games for reference because i have technical experience with the details of Quake 3 and Unreal engines and network mechanism design and coding wise.
While it might not fix sync, it would definitely reduce the load on the servers and prevent times where the servers break down or where some players can't sign in because the maximum no of players the server could handle is reached.
So... It might still be a good thing to have this after all...