| Pages: [1] :: one page |
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Maverus Penthark
GoonFleet
GoonSwarm
   |
Posted - 2007.10.07 14:26:00 -
[1]
As an FPGA Engineer, I was wondering if this has ever been considered to reduce lag in EvE? It should be possible (though likely expensive) to design an expansion card with one or two fairly high end FPGAs on it and offload certain computations to the FPGA to reduce processor load. Something that has to happen on a regular basis, like calculating position of all the objects on the grid or something (I don't know how the math for that works right now, but I'm just shooting off ideas).
Basically FPGAs (or ASICs) are very good at specific tasks, and can process a lot of data, particularly if it's repetitive data that always requires the same amount of computation. For instance, on a project I've worked on with my company we can push more than 12.8 Gbps of data through an FPGA each way (so 25.6 Gbps), while doing some processing on it.
Something to consider anyway, and if anyone has some comments, feel free to post them here.
|
Maverus Penthark
GoonFleet
GoonSwarm
|
Posted - 2007.10.07 14:38:00 -
[2]
Now that I think about this, maybe this should be in the Game Development forum. If someone could move it there, that would be awesome :).
|
Solbright altaltaltalt
|
Posted - 2007.10.07 20:12:00 -
[3]
The coding required to take advantage of parallel processing is not done. This coding is what is holding up the nodes right now. Once it's sorted CCP will just throw more processors at it and we'll all be happy.
In this particular case the reason to throw hardware designs at the job would be as a cost saving - both in terms of hardware purchased and electricity used. But it won't happen until they have a way to share the load of a single node.
|
Amida Ta
|
Posted - 2007.10.07 21:39:00 -
[4]
Just by switching to native programing vs. Python code Eve could probably be made 10-100 times faster.
However development time also plays a major role. Same thing (in fact to a much higher degree) is true for specialized chips.
|
Maverus Penthark
GoonFleet
GoonSwarm
|
Posted - 2007.10.07 22:58:00 -
[5]
 Originally by: Amida Ta
Just by switching to native programing vs. Python code Eve could probably be made 10-100 times faster.
However development time also plays a major role. Same thing (in fact to a much higher degree) is true for specialized chips.
True. I was thinking something along the lines of choosing some frequently called function that always has to happen and offloading it to an FPGA/ASIC, perhaps even only on a few nodes. On those super-reinforced nodes, it allows the CPU to just send the data to the FPGA whenever that function is called, rather than do the function in software.
It may be a silly idea, and you're right that recoding in C rather than using an interpreted language might be a better use of resources ;).
|
Andargor theWise
Collateral Damage Unlimited
Interstellar Alcohol Conglomerate
|
Posted - 2007.10.08 04:14:00 -
[6]
Originally by: Amida Ta
Just by switching to native programing vs. Python code Eve could probably be made 10-100 times faster.
However development time also plays a major role. Same thing (in fact to a much higher degree) is true for specialized chips.
Server-side is a mix of .NET and C++, AFAIK. Only the client is Python, and the UI lag is being addressed in Rev 3 by offloading to the GPU.
To the OP: although I think a hardware solution is a bit unwieldy, the idea of offloading server-side computing to the clients a la SETI is interesting. Distributed processing ftw. 
-
Stop the Feature Glut: Take the API to the Next Level
|
Maverus Penthark
GoonFleet
GoonSwarm
|
Posted - 2007.10.08 06:19:00 -
[7]
Edited by: Maverus Penthark on 08/10/2007 06:19:31
Originally by: Andargor theWise
To the OP: although I think a hardware solution is a bit unwieldy, the idea of offloading server-side computing to the clients a la SETI is interesting. Distributed processing ftw.
I'm not sure if it's as far fetched as you might think. I read somewhere they are looking into super-computing techniques for the EvE cluster to try and increase parallelism, and several super-computers (Cray's latest generation machines, for instance) include Xilinx Virtex FPGAs on the processor cards for increased parallelism/handling certain tasks better suited to hardware.
As cool as it would be to hardness all the computing power of everyone's clients, I can't see offloading to the clients as a viable option, both due to uncontrolled network latencies and due to security issues (one hacked client messing up the server for everyone potentially).
|
Solbright altaltaltalt
|
Posted - 2007.10.08 06:54:00 -
[8]
Get with it! Offloading server functions to the client is just stupid.
|
Amida Ta
|
Posted - 2007.10.08 16:57:00 -
[9]
Edited by: Amida Ta on 08/10/2007 17:01:55
Originally by: Andargor theWise
Server-side is a mix of .NET and C++, AFAIK. Only the client is Python, and the UI lag is being addressed in Rev 3 by offloading to the GPU.
I dont't believe that. It seems that even the network layer is based on Python. And that means that there is very likely also Python on the server.
And it would be just plain silly if the rest would be .Net and just the network layer Python.
They may have some C/C++ on the server, but I fear that it is even less than there is in the client.
P.S. There is obviously some ASP, perhaps ASP.Net in the Webserver, but not in the Gameserver.
|
Andargor theWise
Collateral Damage Unlimited
Interstellar Alcohol Conglomerate
|
Posted - 2007.10.08 21:48:00 -
[10]
Edited by: Andargor theWise on 08/10/2007 21:49:15
Edited by: Andargor theWise on 08/10/2007 21:48:25
Originally by: Maverus Penthark
As cool as it would be to hardness all the computing power of everyone's clients, I can't see offloading to the clients as a viable option, both due to uncontrolled network latencies and due to security issues (one hacked client messing up the server for everyone potentially).
Hey, never said it would be easy.  But, for argument's sake...
SETI had integrity checking in their code. The client-side didn't actually know what it was calculating, and any modifications were discarded.
As for latency, it's a trade-off: server-side latency vs network latency. As I understand it, server-side is the bottleneck, with activation delays of 10s to 5 minutes (been there, done that, FAT ftl).
Say you send a computing job to 3 or 4 clients, and take the first one to get back to you (fastest, least busy CPU + best network combination) that passes integrity checking.
Since you know the client responsiveness because you have their current connection status, you are even able to predict with some certainty when an answer will come back.
You could have dedicated hardware just for managing distributed job dispatching. And of course, you dispatch to clients not currently involved in a fleet fight...
Ah well, I like to dream...
-
Stop the Feature Glut: Take the API to the Next Level
|
Shinhan
Phoenix Knights
Dark Nebula Galactic Empire
|
Posted - 2007.10.09 06:22:00 -
[11]
Originally by: Andargor theWise
Ah well, I like to dream...
Exactly :)
Because clients can never calculate it faster than dedicated servers, even when those servers are overloaded with fleet fights.
SETI was not time critical. Fleet battles are time critical.
--
Selling apples, 1 signature each.
ѼѼѼѼѼѼѼ |
Solbright altaltaltalt
|
Posted - 2007.10.09 06:33:00 -
[12]
Originally by: Andargor theWise
SETI had integrity checking in their code. The client-side didn't actually know what it was calculating, and any modifications were discarded.
The primary way of protecting against deliberate false results is by comparison between many clients reporting back with the same work results. Individual work units are computed on a "many hours" basis with the compares done over many weeks before the culling takes place.
Eve's server game cycle is once per second! ... keep dreaming.
|
Andargor theWise
Collateral Damage Unlimited
Interstellar Alcohol Conglomerate
|
Posted - 2007.10.09 19:04:00 -
[13]
Ah, man.... Having hacked my way through a lot of stuff and having modded games, I have met many nay-sayers and proved them wrong. Supposedly "impossible" stuff. 
I would love to do that for Eve... Too bad I can't start hacking the client and messing with the servers...
-
Stop the Feature Glut: Take the API to the Next Level
|
ElfeGER
Black Eclipse Corp
Band of Brothers
|
Posted - 2007.10.09 19:42:00 -
[14]
I think it is hard to accelerate the code with those devices as eve isn't pure number crunching like video de/encoding
it's more complex processing or have you seen a php/asp webserver accelerating chip?
the solution for eve should be to use multiple cores first but this needs breaking up the one cpu core=one node and multiple systems static mapped stuff
a good os should handle balancing much better than the static mapping
an other cheap way of trying to improve the performance would be to use a cell (ps3 then cell blades)
or even this processor
|
Ghula Schwartz
|
Posted - 2007.10.10 06:50:00 -
[15]
Game logic on the scale we're facing in EVE is generally more dependant of data transfer rates than pure number crunching. This makes it, at best, marginally interesting to talk about distributing computational work to custom hardware or over ultra high latency connections to clients. This also makes arguments like "C is much faster than Python" a moot point as most of the time is spent waiting for data transfers.
The main problem in all cluster computing is to split the data into chunks that are independent enough to be crunched separately and complex enough to motivate spending time on network transfer of data between nodes. To complicate things further, MMORPG's have the additional requirement of real time response that limits the time that can be spent on a data set before resychronization with other data sets.
The programming staff at CCP have a lot of difficult problems to solve, and they must do it on a centralized live production system where reliability is a primary issue.
It's nice to know there are still people who have the guts to take on impossible tasks. :-)
|
Andargor theWise
Collateral Damage Unlimited
Interstellar Alcohol Conglomerate
|
Posted - 2007.10.10 13:09:00 -
[16]
Originally by: Ghula Schwartz
The programming staff at CCP have a lot of difficult problems to solve, and they must do it on a centralized live production system where reliability is a primary issue.
It's nice to know there are still people who have the guts to take on impossible tasks. :-)
I'd call it a dream job. 
-
Stop the Feature Glut: Take the API to the Next Level
|
Solbright altaltaltalt
|
Posted - 2007.10.10 14:12:00 -
[17]
:)
|
Maverus Penthark
GoonFleet
GoonSwarm
|
Posted - 2007.10.11 18:00:00 -
[18]
Edited by: Maverus Penthark on 11/10/2007 18:04:37
Originally by: El***ER
I think it is hard to accelerate the code with those devices as eve isn't pure number crunching like video de/encoding
it's more complex processing or have you seen a php/asp webserver accelerating chip?
the solution for eve should be to use multiple cores first but this needs breaking up the one cpu core=one node and multiple systems static mapped stuff
a good os should handle balancing much better than the static mapping
an other cheap way of trying to improve the performance would be to use a cell (ps3 then cell blades)
or even this processor
I agree the this would make a lot of sense, as far as working toward more parallelism, in whatever ways are possible.
As far as a PHP/ASP webserver accelerator, I agree that it doesn't make much sense. But if you take some aspects of EvE that require the same calculation to be done over and over constantly, I still think there is some potential for dedicated hardware.
For example, if we look at position of ships on the grid: The server has to constantly determine the position, velocity and acceleration vectors of every ship on the grid. I'm not sure how this is calculated right now, but let us assume that every ship's position, velocity and acceleration vectors are computed based on the origin at the center of the grid. This has a lot of advantages, since you perform exactly the same computation for every ship with every update to the clients. Each client knows how far each ship is from the grid center, and can do some simple vector addition to compute distance, relative velocities, etc...
Given that the math involved for this would be the same for every ship, all the time, I could see it as a candidate for running on dedicated hardware. The hardware, whether it be an ASIC or an FPGA, would just run through some memory segment and compute the relevant new positions and vectors for each ship, and write them to some other memory area. When it comes time to update the clients, the CPU just sends out all the data contained in that area of memory set aside for it, without having to do any computation on it. Similarly, when new data comes in from a client (I activate my MWD, or turn my ship, or whatever) it would just be written by the CPU into the input memory area, and the dedicated hardware would handle it from there. As a bonus, the hardware could run the same math in a massively parallel fashion, and handle a very large number of ships/objects on the grid simultaneously.
Now, this is all speculation, since I don't know if this is how EVE handles ship positions on a grid, or if that is a particularly intensive operation, but it's just one idea for the usefulness of a dedicated processor. And this kind of thing isn't what you get in a PHP/SQL server ;).
|
Solbright altaltaltalt
|
Posted - 2007.10.12 00:49:00 -
[19]
Originally by: Maverus Penthark
Now, this is all speculation, since I don't know if this is how EVE handles ship positions on a grid, or if that is a particularly intensive operation,
What we do know is that the current method does not support parallel processing.
I suspect the Python based threads rely on a cooperative multitasking system providing atomic data handling. Without addressing this relationship then adding more concurrency will wreak havoc.
As for speeding up CPU intensive calculations and the likes, CCP can keep on with the existing practice of shifting those bits into C. It's an easy transition with good results.
Another possibility for issues is that the bulk of combat processing runs in one huge thread ... Now I'm speculating ... :)
|
| |
|
| Pages: [1] :: one page |
| First page | Previous page | Next page | Last page |