| Pages: 1 2 [3] 4 :: one page |
| Author |
Thread Statistics | Show CCP posts - 1 post(s) |
Rangar
   |
Posted - 2005.12.18 10:46:00 -
[61]
Well,
I donŠt think, that hardware is the problem and upgrading it will be the solution. The problem is this patch, brought into Tranquility too early and not tested enough. Even reported bugs from the testserver have been ignored.
And whoever is responsible for that new production system: Better stay on balancing ships next time. I know, that ship, weapons, pvp are the main focus of the development in EVE, but if you donŠt know, what a good production system would be, ask the producers in the game.
|
sonofollo
|
Posted - 2005.12.18 10:48:00 -
[62]
yes its a requirement to run china server seperate,. But given the 1B population such a thing is a non event all chinesse IPs on that server and all other IPs on the TQ. China server being run by china company under license from CCP as well
CCP please restore the recruitment channel |
Gothikia
|
Posted - 2005.12.18 12:22:00 -
[63]
OMFG!! HOW MUCH ARE YOU GUYS PAYING CHRISTIAN TISMER!
He kept that one off the stackless mailing list, thats for sure, hehe!
|
Jeni Silver
|
Posted - 2005.12.18 18:15:00 -
[64]
No more trial accounts! dammit! NO MORE!
|
sonofollo
|
Posted - 2005.12.18 18:52:00 -
[65]
trial accounts are limited at 15k maxiumum - that said getting more paying customers is the aim so the maximum should stay
CCP please restore the recruitment channel |
Niki Silver
|
Posted - 2005.12.18 19:16:00 -
[66]
I feel that the community has been more then patient with the development of RmR. I also feel that community has been extremely patient with the horrid deployment of RmR. But now its going to far. It is Christmas break FFS. Turn off the Mother ******* trial accounts. If 5000 noobs are going to lag me to **** they had better god damn well be paying just as much as I am to play. We don't want to hear a speach about future plans, and the wonderful things that are coming 'soon' we want to play the ******* game, today, right now. Fix it FFS.
|
The Wizz117
|
Posted - 2005.12.18 19:43:00 -
[67]
why do they run the forums on TQ thats stupid.
thats probitly to why they dont put a search function in wich evry other forum on the world does have.
|
sonofollo
|
Posted - 2005.12.18 19:48:00 -
[68]
the programming abilities at CCP are focused in some areas - other non core areas require a specialists or they have issues ie search functions etc
I keep suggesting a seperate server just for trials but nothing. Not much else when everyone insists on being together in one giant carebear system ie jita - yuali etc those in that system are going to lag
When ppl start complaining about lag here - first question is what system are u in - answer comes back often (jita, rens, ourstalert etc) and u say back to them BINGO solution found get out.
CCP please restore the recruitment channel |
Niki Silver
|
Posted - 2005.12.18 20:36:00 -
[69]
Thanks for stating the obvious Sono. No I am not in a crowded system, the game is running like **** for everyone, everywhere.
CCP please ignore the recruitment channel and make the game playable first.
|
Whorrid
|
Posted - 2005.12.18 21:17:00 -
[70]
I don't give a damn about free new content if it lags us all the f*ck up. All i want is to be able to play the game. Hhanging lagged out and idle for 2+ minutes at a 0.0 gate because the game does not respond isn't my idea of fun. |
Mimio
|
Posted - 2005.12.18 21:50:00 -
[71]
Before damned patch trial accounts were ok. Now every "specialist" decided that trial are Big Evil Thing and this Big Evil Thing must be destroyed. Stupid.
Problem is not in the trial, but I guess in pressure on software engineers to deliver patch before Christmas to give ability for CCP managers for carier advancement. Heh, usual practice.
|
Fallout2man
|
Posted - 2005.12.19 00:36:00 -
[72]
Edited by: Fallout2man on 19/12/2005 00:36:45
 Originally by: sonofollo
yes its a requirement to run china server seperate,. But given the 1B population such a thing is a non event all chinesse IPs on that server and all other IPs on the TQ. China server being run by china company under license from CCP as well
Considering chinese players will not be allowed to play for more than three hours straight and/or more than X (I forgot the number) hours per week, unless eve takes off there WoW style, I doubt the chinese server will see that much activity. For once I actually feel lucky to be in the USA. :p Lieberman's tame compared to the chinese ministry of culture.
|
Steven Dynahir
|
Posted - 2005.12.19 06:43:00 -
[73]
Quote:
What is extra in such situations? Instead of 20 ships in space you have 100, and you also have 50 drones and 30 missiles flying around which need their movement path to be calculated. There are also a few dozen shots every second but the hitting formulas are simple. None of the modules (EW) are modifying more than 2 values of the target ship. So this is what brings the SOL server to its knees? Hard to believe.
I think that the problem lies in the fact that the server does all the calculations, thus requiring processor time. When a server is glogged, it is propably due to memory constrains where addressing space is out and it's time to swap to hard drive.. and then it gets slow.
Now how does the calculation part work? All your movement data is processed in the server, propably with a tickrate of 1/2 or 1 seconds. This information is then send to your client and your client just smoothes out the momevement. Movement changes you do on your client are just relayed to the server, and parameters are just point of sphere and speed. When you activate/deactivate a module, once again your personal calculating queue gets one thing more to do.
Now when you add these queues for some time, you get steady growth of processor time usage and memory allocation. When either runs out, you start experiencing lag and alot. What might be done to ease the processor use is to slowdown the tickrate when CPU/Memory hits 90-95%.. (I'm sure they have thought of that =) .. and then you get more of lag.
(CCP: Do you have dynamic tickrate/updaterate?)
So what I have read from the devblogs, they are propably having issues of memory holding up to the number of people, thus the server is swapping. And when swapping occurs, the process is "on hold" until swaping has been done so lag in fleet fights comes from there. And this will be gone after migration to x64, since the memory limit is no longer a bottleneck (for few years).
---
Home, sweet home. |
sonofollo
|
Posted - 2005.12.19 11:13:00 -
[74]
yes for a few years or unless u reach a 1000-1500 player limit in one system.
the memory is the big thing as well as the amount of data the CPU can move ie 64 bit dual is better than 32 bit currently and i think CCP would keep up with new hardware as it becomes available.
CCP please restore the recruitment channel |
reactive
|
Posted - 2005.12.19 15:15:00 -
[75]
Edited by: reactive on 19/12/2005 15:17:18
The server side of eve is flawed by design. From what I've read in the dev blogs, one system is processed in one thread. Because of this they'll never be able to scale to a point where a thousand people can be in the same system without lag. Processors are moving towards dual/quad cores instead of insane processing processing power on a single core. There is a limit to the Ghz a single piece of silicon can put out and were fastly approaching it. The sooner they can have multiple real threads (not the stackless variety) per system the sooner the lag disapears.
|
Fashion Bug
|
Posted - 2005.12.19 21:02:00 -
[76]
I am looking forward to the new 64 bit server setup they have been talking about. Assuming they have a proper 64 bit OS and programming code setup it will greatly effect the preformance of this game. Let me breakdown the numbers to the none tecky guys.
Each bit a PC has is a 1 or a 0 that it can process per beat (Hz). Each bit added doubles the possible combos of 1s or 0s. so a 32 bit PC has 32 1s and/or 0s. Every beat a 32 bit PC can have 4.2 billion differant combos of 0s or 1s. Now add on another 32 bits to make 64 bits. This is not a simple double of the above 4.2 billion, but a double for every added bit. 18.4 x 10^15 (thats a billion billion) differnet combos of 1s and 0s. WOW! So if they can setup an archtech that can handle all this it will greatly reduce the processing, because they can setup codes under a 64 bit PC that take one beat that would have taken 2, 3 or maybe even 100s of beat under the 32 bit server.
I think thier overhead they are looking for will be there after the 32 to 64 bit conversion. hope it goes smooth, Ive been rooting for it since I first heard about it.
|
Erwin Temasi
|
Posted - 2005.12.19 22:53:00 -
[77]
Edited by: Erwin Temasi on 19/12/2005 23:00:08
Originally by: Fashion Bug
Let me breakdown the numbers to the none tecky guys.
Each bit a PC has is a 1 or a 0 that it can process per beat (Hz). Each bit added doubles the possible combos of 1s or 0s. so a 32 bit PC has 32 1s and/or 0s. Every beat a 32 bit PC can have 4.2 billion differant combos of 0s or 1s. Now add on another 32 bits to make 64 bits. This is not a simple double of the above 4.2 billion, but a double for every added bit. 18.4 x 10^15 (thats a billion billion) differnet combos of 1s and 0s. WOW! So if they can setup an archtech that can handle all this it will greatly reduce the processing, because they can setup codes under a 64 bit PC that take one beat that would have taken 2, 3 or maybe even 100s of beat under the 32 bit server.
sorry, but it is one of the worst explanation of 64bits that I have ever read. No need to confuse the non techy guys, as you call them.
PS: it's not because a CPU is going from 32bits to 64bits that it is able to process two time the amount of data. It just means that it is able to handle bigger numbers (which is useless for the majority of softwares, exept cryptographic/compression algorithms) and handle much more memory. Performance improvements are associated with the jump from 32 bits to 64bits on PCs because they are changing other things at the same time (more registers, use of SSE by default, cleaning of old crappy stuffs...), but this is due to the x86 to x86-64 jump, not just the 32->64bits part of it.
|
Thomus
|
Posted - 2005.12.20 18:32:00 -
[78]
Originally by: HippoKing
Edited by: HippoKing on 17/12/2005 19:57:23
in before the modhax! - HippoKing
In before the edit!!!1 - Imaran 
Edited by: HippoKing on 17/12/2005 18:47:56
firstest! - HippoKing
Firster!!!1 - Imaran
In after the edit  - Ductoris
first!
LMAO
----------------
Tom |
Kirell
|
Posted - 2005.12.20 21:07:00 -
[79]
Lag is starting to get the btter of this game. if it's not fixed my whole corp will be leaving for faster gameplay elsewhere.
|
NiveaForSoreNobs
|
Posted - 2005.12.20 21:45:00 -
[80]
talking of lag.....my main character has been stuck at isanamo gate now for 70 mins....
|
Regat Kozovv
|
Posted - 2005.12.20 22:27:00 -
[81]
Originally by: Erwin Temasi
Edited by: Erwin Temasi on 19/12/2005 23:00:08
Originally by: Fashion Bug
Let me breakdown the numbers to the none tecky guys.
Each bit a PC has is a 1 or a 0 that it can process per beat (Hz). Each bit added doubles the possible combos of 1s or 0s. so a 32 bit PC has 32 1s and/or 0s. Every beat a 32 bit PC can have 4.2 billion differant combos of 0s or 1s. Now add on another 32 bits to make 64 bits. This is not a simple double of the above 4.2 billion, but a double for every added bit. 18.4 x 10^15 (thats a billion billion) differnet combos of 1s and 0s. WOW! So if they can setup an archtech that can handle all this it will greatly reduce the processing, because they can setup codes under a 64 bit PC that take one beat that would have taken 2, 3 or maybe even 100s of beat under the 32 bit server.
sorry, but it is one of the worst explanation of 64bits that I have ever read. No need to confuse the non techy guys, as you call them.
PS: it's not because a CPU is going from 32bits to 64bits that it is able to process two time the amount of data. It just means that it is able to handle bigger numbers (which is useless for the majority of softwares, exept cryptographic/compression algorithms) and handle much more memory. Performance improvements are associated with the jump from 32 bits to 64bits on PCs because they are changing other things at the same time (more registers, use of SSE by default, cleaning of old crappy stuffs...), but this is due to the x86 to x86-64 jump, not just the 32->64bits part of it.
I agree. That just plain made my head hurt.
The primary reason for making the move to 64bits is the 4GB memory limitation in x86 architecture. 32bits refers to addressing space, which tops out at just under 4GB. Even with work arounds, (such as Intel's PAE) processes are limited to 4GB each, or less depending on the software. 64bit addressing gives you thousands of GB to work with.
This makes alot of sence when porkbelly was describing running out of memory in his Dev log. Having 64bit systems would allow them to allocate tens or hundreds (!!!) of GB of RAM for a single instance, say, Jita.
It is clear to me however, that the vast majority of comments on this thread have no idea what they're talking about regarding architecture or software of this scale. The reccomendations and demands and criticism seem to be based off whatever crap someone thought up in their head. Clusters are not PCs, you cannot make analogies to your Athlon 64 or home LAN to the problems CCP is facing. Likewise, I doubt many people in here design SQL Server for datacenter applications.
I would reccomend to anyone who finds the current game unbearable please cancel their account and log off so that others can play. It is perfectly acceptable to cancel a subscription to something you don't feel delivers the amount you're paying for it. But leave the ignorant and immature rants to someone else.
And thanks to anyone reading or posting who does not have some sort of miracle fix. =)
|
Fallout2man
|
Posted - 2005.12.21 02:33:00 -
[82]
Okay, just a little annoyance I wanted to address.
Let's all get familiar with the base 2 naming conventions for data size.
1-bit = a single one and zero
1-byte = eight bits.
1024 bytes = a kilobyte
1024 kilobytes = a megabyte
1024 megabytes = a gigabyte
1024 gigabytes = a terrabyte
1024 terrabytes = a petabyte
1024 petabytes = an exabyte
64-bit CPUs can address 18.446 exabytes. Say it with me now, ecs-ah-byte, not billions of gigabytes, not trillions of megabytes, not thousands of terrabytes, eighteen point four four six ecs-ah-bytes. Thank you, that is all. 
|
Steven Dynahir
|
Posted - 2005.12.21 07:33:00 -
[83]
Edited by: Steven Dynahir on 21/12/2005 07:34:46
Originally by: Fallout2man
Okay, just a little annoyance I wanted to address.
Let's all get familiar with the base 2 naming conventions for data size.
1-bit = a single one and zero
1-byte = eight bits.
1024 bytes = a kilobyte
1024 kilobytes = a megabyte
1024 megabytes = a gigabyte
1024 gigabytes = a terrabyte
1024 terrabytes = a petabyte
1024 petabytes = an exabyte
64-bit CPUs can address 18.446 exabytes. Say it with me now, ecs-ah-byte, not billions of gigabytes, not trillions of megabytes, not thousands of terrabytes, eighteen point four four six ecs-ah-bytes. Thank you, that is all.
Err, no
---
Home, sweet home. |
Abe Stormbreaker
|
Posted - 2005.12.21 20:30:00 -
[84]
Eherrm.. ---> problem solved with a couple of these babies? Blue Gene
|
Semkhet
|
Posted - 2005.12.22 10:19:00 -
[85]
I've been designing industry-oriented manufacturing complex systems for years, often having to squeeze microseconds and compressing data up to the last bit due to real-time constraints.
We know that in EVE, there are mainly two aspects difficult to handle: network-induced lag and server data processing.
Concerning network induced lag, the biggest problem is to avoid its propagation in-game. When players are interacting (fighting for example) and you want to create a real-time experience as close to possible from reality, the highest lagging player becomes the common denominator in defining the interaction speed of all other players. Now you cannot of course simply accept this, because if one player would stall, all the other ones would be artificially forced to stall server-side in order to cope with the worst player-induced delay. That's why a trade-off is implemented between adapting reaction speed to the slowest player and defining a thresold where actions must go on if the delay becomes unmanageable. We get here the typical situation were you warp against your opponents, and lag makes you reappear in a pod without having a clue about what happened. Don't forget that this was your particular experience, and is different from people who wasn't lagging (ex. opponents saw you come in, targetted and blowed you up). You can easely test this in two different cases: A. fighting alone against 10 NPC's, or B. being involved in a battle with 10 players. In A, the server creates and manages the NPC's, and during the battle, the only network flow needed by the server corresponds to your client. In B. the server depends of the network flow of all clients in order to repeatedly re-emit the data needed to update your client in parallel to receiving data from your client about your own actions.
Now, your data packets have to travel through nodes (routers) on the internet. The number of nodes between your location and CCP's server may stand anywhere between a few and 20 or more. Each of these nodes receives and re-emit your packets with a slight delay. These delays sum up and give the total latency of your communication line at a given moment. To make matters worse, automated load-balancing on routers may induce that the physical route changes between packets, giving also a different latency from packet to packet.
Therefore, to make a simply example and taking into account a route with 10 network nodes by player, in case A. the packets will travel back and forth on 10 nodes, when in B it must travel on 100 (90 from the other players and 10 from your own route). There is absolutely nothing CCP may do about this, as these delay are generated outside the game environment. In the future, latency may be lowered when networks will commonly be implemented both with optic fiber and optical repeaters/routers. Therefore it makes no sense in complaining of network-induced lag to CCP.
Now if we study EVE's data model, maybe there some changes could be implemented and significantly lower the SQL database load.
My impression is that data is too centralized. Some data could migrate to clients. I will take the buddy list and the BM's as example.
Buddy list:
Why maintain the buddy list of each player on the server ? You only need to access the server when adding a buddy to your list by obtaining an unique identifier for this given buddy. The list is then managed by the client. Instead of getting real-time notifications of the login & logoff of your whole list, the client-server would only refresh the data when you display your list when docked. Each player could have a max number of buddies (maybe 3 ?) set as "high priority". HP buddies would be notified in real-time like before, with the difference that instead of being the SQL-triggers linked to your own list, the triggers would be stored in the in-game data profile of your buddies and emitted during their logon/logoff. Only removing an HP buddy would require server access.
|
Semkhet
|
Posted - 2005.12.22 10:22:00 -
[86]
Bookmarks:
There is also no need to manage bookmarks centrally. Let the client manage them, and just establish a set of checks, conditions & rules that the server will test to define if the warp is legitime or not.
|
Hurray NPE
|
Posted - 2005.12.22 11:51:00 -
[87]
Originally by: Tusko Hopkins
Tbh, I have a hard time understanding why simulating the world of EVE to lets say 15000 concurrent users is such a hard task. The game mechanics (the low level ones) of eve are extremely simple.
The AI in the game is very simple, too. No big tactics, coordination of NPCs, player behaviour learning systems... the best proof for this is that there is still no pathfinding in the game (your player bumps everything, warp lanes are crossing planets).
There is not much not player-driven activity to simulate. Planets are not orbiting the stars, moons are not orbiting the planets, stargates and stations are not orbiting the moons. The rocks in the belts are just standing there, too. The only part of the game which needs realtime simulation are the pilots, npcs, drones, missiles flying around in space, the rest of the things are not moving at all.
Those which are flying around are not following any complicated patterns and collisions occure very rarely.
One would guess that the most complicated and resource-eating part of the game has to do with the market. With all the regional and local markets, with all the trading skills, best price calculations, etc. But these kind of things would push the SQL the most, not the SOL servers. And from all you have told us before, my conclusion was that its the SOL servers which you have the most problems with.
All of us has seen how much lag a fleet combat causes. What is extra in such situations? Instead of 20 ships in space you have 100, and you also have 50 drones and 30 missiles flying around which need their movement path to be calculated. There are also a few dozen shots every second but the hitting formulas are simple. None of the modules (EW) are modifying more than 2 values of the target ship. So this is what brings the SOL server to its knees? Hard to believe. The AI of Settlers back in 1995 was more complicated and was handling over 3000 units on the map without problems, all this on a 386. Please explain.
You Sir, would make a nice politician. Many words but not even the shadow of a clue.
|
FingerThief
|
Posted - 2005.12.22 11:59:00 -
[88]
Originally by: Semkhet
My impression is that data is too centralized. Some data could migrate to clients. I will take the buddy list and the BM's as example.
If you store data on the client that is used by the client WITHOUT validation of any sort somebody will find a way to h4x it and apart that ... keeping it on the client and it ( for some reason or the other ) turns corrupted and then you have to delete will make the "OMG I LOST MY BOOKMARK FOLDERS 1111" screamers into 10x more screaming "OMG I LOST 2346 BOOKMARKS !!!!"
So yes, data storage on client has a small pro but there are huge cons still standing there.
( and don't you come up with using client resources to request validation of client data from the server or anything )
This opinion was free and isn't ever worth the proverbial .02 Cent.
|
sonofollo
|
Posted - 2005.12.22 12:28:00 -
[89]
well the other alternative is upping the minimum bandwidth required to run from dialup to 128k or 256kb ieADSL.
Might shut out a few thousand players but could make more advanced and higher data transfer possible
Im a happy little camper now - CCP 4tw. |
Semkhet
|
Posted - 2005.12.22 21:21:00 -
[90]
Originally by: FingerThief
Originally by: Semkhet
My impression is that data is too centralized. Some data could migrate to clients. I will take the buddy list and the BM's as example.
If you store data on the client that is used by the client WITHOUT validation of any sort somebody will find a way to h4x it and apart that ... keeping it on the client and it ( for some reason or the other ) turns corrupted and then you have to delete will make the "OMG I LOST MY BOOKMARK FOLDERS 1111" screamers into 10x more screaming "OMG I LOST 2346 BOOKMARKS !!!!"
So yes, data storage on client has a small pro but there are huge cons still standing there.
( and don't you come up with using client resources to request validation of client data from the server or anything )
This opinion was free and isn't ever worth the proverbial .02 Cent.
Sound remark. However, validation is such a basic requirement that I understood it was implicit. Encrypted 32-bits CRC's are very useful to quickly check validity of data. It's only 4 bytes long and may serve to check even a megabyte of data...
|
| |
|
| Pages: 1 2 [3] 4 :: one page |
| First page | Previous page | Next page | Last page |