Pages: 1 2 3 [4] 5 6 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 19 post(s) |
Nova Fox
Gallente Novafox Shipyards
|
Posted - 2008.09.27 15:05:00 -
[91]
we should ask the outer ring allainces muttually have a massive battle and ask the devs to pay attention to that.
Pre Order your Sisters of Eve ship today!!! |
Popsikle
Minmatar Re-Awakened Technologies Inc Electus Matari
|
Posted - 2008.09.27 15:08:00 -
[92]
Originally by: CCP Lingorm
Originally by: Brock Nelson inudex, I think StacklessIO patch was applied only to nodes with heavy demands such as Jita. I understand that mission hubs have large demand but nothing compares to Jita
StacklessIO was applied to all node in the Tranquility Cluster, not just to high load nodes.
The 64bit compile of EVE has been deployed to some high load systems and we are actively monitoring the performance of these systems.
When can we get a 64-bit client version? ;p ____ <t20> i want to be in a manager potition at Hooters <SaraDawn> Garthagk, do you have it up ? <Garthagk> I can get it up anytime. |
Smagd
Encina Technologies
|
Posted - 2008.09.27 15:23:00 -
[93]
Awesome work! This wasn't cheap, and it paid out... I love it when that happens.
Question, since a few fellow pilots mentioned Infiniband:
Does this actually go towards Infiniband or will you have to restart from scratch, well with a much better idea on where all the nuts and bolts are?
I fear something the whole network layer will be obsolete with Infiniband, but then I have no real clue how Infiniband works...
|
DaDutchDude
Minmatar Sebiestor tribe
|
Posted - 2008.09.27 15:39:00 -
[94]
Edited by: DaDutchDude on 27/09/2008 15:43:05
Originally by: Popsikle
When can we get a 64-bit client version? ;p
People think 64 bit code magically makes things faster, but 9 out of 10 cases (or perhaps more like 99 out of 100) it doesn't.
Using 64 bit code has one major advantage, which is being able to address more memory. This is especially useful for server applications, since they are often quite heavy on memory usage. Being limited to 4 GB of addressable memory when you're server many users is bad, so scaling up to 64 bit server code is great when you're server as many users as the EVE servers are.
Using 64 bit code for client applications is hardly ever necessary (at least at this point in time), since hardly any single application uses more then 4 GB of memory. I for one would like the EVE client to fit into that category. ;)
One thing people don't realize is there could actually be a downside to using 64 bit code. Dependent on how strictly declare variables in your code, how your compiler handles these variables and how your OS handles 64 bit code, 64 bit code could actually use up quite a bit more memory while not having any performance advantage (using 64 bits instead of 32 bits for the same variable in memory, doubling its memory footprint), possibly even leading to a degradation in performance on computers that are low on memory.
There is one area where 64 bit CPUs and code can lead to performance enhancements, and this is due to parallel processing of numbers in one ALU (Arithmatic and Logic Unit, the actual calculating bit). If you run a program in 64 bit mode using 64 bit code, you can make the ALU do 1 operation on a 64 bit value in one clock tick. However, it is also possible to do the exact same operation (adding, subtracting, etc) on 2 32 bit values at the same time, or 4 16 bit values. This was all introduced by Intel way back under the name MMX, although the CPU was 32 bit so it could only do 2 16 bit values at the same time.
Using this performance enhancements is very hard to accomplish though, and this is why MMX or similar technologies haven't made CPU's twice at fast in 99 out of 100 programs. Your compiler needs to be able to optimize the code to use special instruction sets, and this only has an advantage when you do a lot of the same sort of processing without having to reload different instructions. With stuff like file compression or movie encoding, this technology actually works quite well, but in most programs, there are too many pieces of conditional code (if statements, while statements,for loops, etc), too many dissimilar operations (subtract and add at the same time doesn't work), too many sequence dependencies (first to operation A and then B on one value instead of being able to do them at the same time) and too many different sized values (8 bit booleans, 16 bit short integers and 32 bit floats, etc) for the compiler to optimize for this. And that's even provided the compiler can actually use the MMX type extensions of all CPU's out there.
Personally I think a 64 bit client would for these reasons be useless, and I'd rather have the devs spend time on stuff that actually gets some results while perhaps being less marketable as saying "We have a fully 64 bit client" (which sounds fancy, but actually means nothing in most cases).
PS: Did I explain that right? And yes, I saw the ;P but I thought I'd explain it anyway for people who really think it would be great.
|
Vyktor Abyss
IONSTAR Curatores Veritatis Alliance
|
Posted - 2008.09.27 15:56:00 -
[95]
Great work, backed up by nice stats.
Great too having regular blogs again to read.
One thing fighting the lag monster though - Will you ever really be able to remove all the bottlenecks and "Fix" lag?
A chain is only as strong as the weakest link. And yes, Anne Robinson is a MILF.
|
Blazde
4S Corporation Morsus Mihi
|
Posted - 2008.09.27 16:00:00 -
[96]
By way of an update, as I suspected the stability teething problems aren't solved. We've got a 200 vs 300 battle in MSHD-4 atm and about 500 people staring at the Entering Game screen. 500 would usually be 'playable' but hugely laggy. Whatever improvements in lag we've had have been exchanged for serious stability issues. _
|
|
CCP Explorer
|
Posted - 2008.09.27 16:19:00 -
[97]
Originally by: Popsikle When can we get a 64-bit client version?
Currently this is the server only. On the server there is only piece of 3rd party middle-ware for which we had to acquire a 64 bit version. On the client there are many more middle-ware components. The old network technology blocked 64 bit development so with StacklessIO there is one less hurdle for the client.
Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games |
|
Levitikon
Destructive Influence Band of Brothers
|
Posted - 2008.09.27 16:41:00 -
[98]
Edited by: Levitikon on 27/09/2008 16:42:04
Originally by: CCP Explorer
Originally by: Popsikle When can we get a 64-bit client version?
Currently this is the server only. On the server there is only piece of 3rd party middle-ware for which we had to acquire a 64 bit version. On the client there are many more middle-ware components. The old network technology blocked 64 bit development so with StacklessIO there is one less hurdle for the client.
If you have time to answer silly questions on the forums, could you please be so kind and reassign a bit faster node (hint; Jita; hint) to MSHD solarsystem? We already had three node crashes in last 30 minutes, fourth won't make much difference.
|
|
CCP Explorer
|
Posted - 2008.09.27 17:44:00 -
[99]
Edited by: CCP Explorer on 27/09/2008 17:48:01
Originally by: Levitikon If you have time to answer silly questions on the forums, could you please be so kind and reassign a bit faster node (hint; Jita; hint) to MSHD solarsystem? We already had three node crashes in last 30 minutes, fourth won't make much difference.
The system administrators have been monitoring this fight closely. MSHD-4 has now been remapped to one of the dedicated machines (native 64 bit code and Jita-style hardware).
Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games |
|
Pliauga
Gallente Federal Defence Union
|
Posted - 2008.09.27 18:20:00 -
[100]
Oh this is GOOOOOD More devblogs like this please My specific request would be for Client and server side 64bit system development progress, with as many details as possible.
And uh... well... LONG LIVE StaclessIO
---------- DRONE love rulez!! 'mkay?! LONG range/"OUT OF SYSTEM" artillery |
|
Faffywaffy
|
Posted - 2008.09.27 19:08:00 -
[101]
Quote: From a player's perspective this would manifest itself in lag and strange client behaviour as requests were delayed and completed by the server much out-of-order.
Whaa? If your design even allows client requests to be processed out of order, you are doing something very very wrong. There is an infinite number of ways you can screwed up if your requests are being processed out of order.
Seriously guys, I'm not pretending to know everything (or much) about your system, but processing requests out of order in an environment where the order is so important is big nono. I would venture a guess that there are many instances where this caused bad things to happen.
|
Bartholomeus Crane
Gallente The Crane Family
|
Posted - 2008.09.27 20:15:00 -
[102]
Originally by: porkbelly
Originally by: Bartholomeus Crane The results certainly look promising, but I would like to know what StacklessIO actually does...
Ah, yes. As the dev primarily responsible I should probably write a technical blog about it. Meanwhile I¦ll offer that StacklessIO is a framework that allows us to make things such as asynchronous IO and work that is spawned off to worker threads appear as regular, blocking operations for tasklets in Stackless Python. We then use this to perform asynchronous Winsock operations using IO completion ports. The semantics are not new, but the scheduling framework and the lightweight winsock layer we use are.
Thank you, this will do ... still would love to see a technical blog about it ofcourse, but I'm glad you're getting such positive results. -- Quis custodiet ipsos custodes? |
Popsikle
Minmatar Re-Awakened Technologies Inc Electus Matari
|
Posted - 2008.09.27 20:31:00 -
[103]
Originally by: DaDutchDude Edited by: DaDutchDude on 27/09/2008 15:43:05
Originally by: Popsikle
When can we get a 64-bit client version? ;p
People think 64 bit code magically makes things faster, but 9 out of 10 cases (or perhaps more like 99 out of 100) it doesn't.
...
Personally I think a 64 bit client would for these reasons be useless, and I'd rather have the devs spend time on stuff that actually gets some results while perhaps being less marketable as saying "We have a fully 64 bit client" (which sounds fancy, but actually means nothing in most cases).
PS: Did I explain that right? And yes, I saw the ;P but I thought I'd explain it anyway for people who really think it would be great.
I know the differences and such, and most of the time there is no performance gain (sometimes its even a drop!) in 64-bit non server apps BUT the only reason I would want a 64-bit client is so I can set the cache option to SUPER HIGH and use 4GB for cache during fleet battles ;) ____ <t20> i want to be in a manager potition at Hooters <SaraDawn> Garthagk, do you have it up ? <Garthagk> I can get it up anytime. |
Chainsaw Plankton
IDLE GUNS IDLE EMPIRE
|
Posted - 2008.09.27 21:14:00 -
[104]
woo! again
However I have some disappointment
I did a bunch of jumps (irjunen to ihakana, on shortest) and did the 1,000,000km emergency warp on just about every gate I jumped through. every solar system load I found myself in warp, or even almost out of warp by the time I loaded the system and my ship.
|
Bartholomeus Crane
Gallente The Crane Family
|
Posted - 2008.09.27 21:54:00 -
[105]
Originally by: Faffywaffy
Quote: From a player's perspective this would manifest itself in lag and strange client behaviour as requests were delayed and completed by the server much out-of-order.
Whaa? If your design even allows client requests to be processed out of order, you are doing something very very wrong. There is an infinite number of ways you can screwed up if your requests are being processed out of order.
Seriously guys, I'm not pretending to know everything (or much) about your system, but processing requests out of order in an environment where the order is so important is big nono. I would venture a guess that there are many instances where this caused bad things to happen.
Nice barking, wrong tree. Clearly, handling IO sequentially is not an option. IO requests were probably handled (semi-)concurrently in random order using standard IO completion port scheduling. They are used in order by the Python part by blocking threads. Problems occur when there are many IO requests at the same time. Then schedulers can get overloaded, and this is probably what happened. Anyway, there's a better scheduler now, and probably more concurrency, and IO request are handled more efficiently, so these things shouldn't happen anymore.
And there was much rejoicing ... -- Quis custodiet ipsos custodes? |
MotherMoon
Huang Yinglong
|
Posted - 2008.09.27 22:16:00 -
[106]
Edited by: MotherMoon on 27/09/2008 22:20:57
Originally by: CCP Explorer
Originally by: Brock Nelson inudex, I think StacklessIO patch was applied only to nodes with heavy demands such as Jita. I understand that mission hubs have large demand but nothing compares to Jita
StacklessIO was applied everywhere on the cluster. It is also coming to a client near you next Tuesday when EVE Online: Empyrean Age 1.1.1 will be released.
wait so it's not just a layer on your side but also on our side?
so right now it's only on the jita side but the players in jita aren't using it?
like... wait... ow
Quote: Finally there is a pool of dedicated dual-CPU machines that only run a single node per machine. Jita and four other solar systems are assigned to that pool. That pool is now running all native 64 bit code and the blades have been upgraded to 16 GB of memory.
just for tech junkies like myself could you let us know if thise upgrade to 16 GB of memory was before or after jita ran out of memory?
if it was upgraded after then this is very good news, and I think you should test it out to see how many players it takes to cap out jita again!
|
Faffywaffy
|
Posted - 2008.09.27 22:30:00 -
[107]
Edited by: Faffywaffy on 27/09/2008 22:33:28
Originally by: Bartholomeus Crane
Nice barking, wrong tree. Clearly, handling IO sequentially is not an option. IO requests were probably handled (semi-)concurrently in random order using standard IO completion port scheduling. They are used in order by the Python part by blocking threads. Problems occur when there are many IO requests at the same time. Then schedulers can get overloaded, and this is probably what happened.
And there was much rejoicing ...
I am not talking about I/O, I'm talking about the processing of the requests themselves (after they've been read by the I/O handling layer).
Obviously the I/O should be asynchronous for performance reasons (which, by the way, is not the same thing as non-sequential, as you seem to be implying). Every request should have a serial number attached to it, which the client increases for every request. The server should then handle these requests in-order. Of course, the serial number is redundant if the connection is over TCP, not UDP (I've no idea which CCP uses).
Allowing requests to be processed out-of-order can cause bad, bad things. Here's a relatively benign example: when tackling a target that is about to warp off, it is necessary to first warp scramble and only then web him (if you web first, the target's max speed is reduced and he warps off immediately, as he is already at 3/4 of the reduced max-speed). If requests are processed out of order, and the two requests are sent close to each other (and they almost always are), the server might end up processing the web request first. I'm sure I can come up with much more dramatic examples, where you lose all your money if market orders are processed out-of-order.
Originally by: Bartholomeus Crane
Anyway, there's a better scheduler now, and probably more concurrency, and IO request are handled more efficiently, so these things shouldn't happen anymore.
There is no such thing as "shouldn't" in this case. From the blurb in the dev blog posting, I understand their design allows requests to be processed out of order. Hoping that you process requests efficiently enough for out-of-order handling to never occur is just irresponsible.
Considering the amount of "WTF? This should not be happening!" moments I've experienced while playing EvE, I think a great chunk of them can be attributed to this issue.
|
|
CCP Explorer
|
Posted - 2008.09.27 22:43:00 -
[108]
Originally by: Bartholomeus Crane Nice barking, wrong tree. Clearly, handling IO sequentially is not an option. IO requests were probably handled (semi-)concurrently in random order using standard IO completion port scheduling. They are used in order by the Python part by blocking threads. Problems occur when there are many IO requests at the same time. Then schedulers can get overloaded, and this is probably what happened. Anyway, there's a better scheduler now, and probably more concurrency, and IO request are handled more efficiently, so these things shouldn't happen anymore.
Exactly, the game logic was still handled in the correct order but client network request were sometimes handled very out-of-order by the server.
Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games |
|
|
CCP Explorer
|
Posted - 2008.09.27 22:49:00 -
[109]
Originally by: MotherMoon
Originally by: CCP Explorer StacklessIO was applied everywhere on the cluster. It is also coming to a client near you next Tuesday when EVE Online: Empyrean Age 1.1.1 will be released.
wait so it's not just a layer on your side but also on our side? so right now it's only on the jita side but the players in jita aren't using it? like... wait... ow
The server is now using the new network technology internally but the protocol is backward compatible so it can communicate with the clients that are still using the old technology until Tuesday.
Quote: just for tech junkies like myself could you let us know if thise upgrade to 16 GB of memory was before or after jita ran out of memory? if it was upgraded after then this is very good news, and I think you should test it out to see how many players it takes to cap out jita again!
It was upgraded after.
Erlendur S. Thorsteinsson Software Director EVE Online, CCP Games |
|
MotherMoon
Huang Yinglong
|
Posted - 2008.09.27 23:26:00 -
[110]
Originally by: CCP Explorer It was upgraded after.
oh my :)
|
|
Levitikon
Destructive Influence Band of Brothers
|
Posted - 2008.09.27 23:43:00 -
[111]
Edited by: Levitikon on 27/09/2008 23:43:21 Can't say anything more than - Thanks.
|
PC5
Pink Bunnies C0VEN
|
Posted - 2008.09.28 00:03:00 -
[112]
Edited by: PC5 on 28/09/2008 00:03:46 Finaly a GOOD devblog! Thanks! Please more stuff like this. So now goons spaming local for lag wont help them much ;)))
Are drones having any significant factor in fleet fights after that change? I think they still are making a lot of lag, am i right? Especialy in fleet fights. After that change it would be nice if you look at aspects connected to fleet fights - like POS lag, drones lag, module cycles lag. Maybe there you can improve much? Any solutions/ideas for those aspects?
|
Garok Nor
Blueprint Haus
|
Posted - 2008.09.28 00:23:00 -
[113]
Lemme see if I understand this right... Eve was slow so you CREATED a completely new and original network protocol to deal with the problem???????
That's it... next time somebody tells me I am wasting time with videogames, I'm gonna tell them that I'm actually involved in high end testing of new internet technologies that are propelling us towards a brighter technological future (and I also understand I am providing study material for Economists).
TBQH I'm impressed, and quite excited to be even a tiny part of of an MMO which is pioneering new methods of digital communication. What other MMO's are changing paradigms like CCP is?
Yay CCP keep up the good work. ------------------------------------------------- Items posted by me are in no way a reflection of the policies and/or opinions of my corporation or alliance. {though they maybe really ought to be} |
Faffywaffy
|
Posted - 2008.09.28 00:47:00 -
[114]
Originally by: Garok Nor Lemme see if I understand this right... Eve was slow so you CREATED a completely new and original network protocol to deal with the problem???????
That's it... next time somebody tells me I am wasting time with videogames, I'm gonna tell them that I'm actually involved in high end testing of new internet technologies that are propelling us towards a brighter technological future (and I also understand I am providing study material for Economists).
TBQH I'm impressed, and quite excited to be even a tiny part of of an MMO which is pioneering new methods of digital communication. What other MMO's are changing paradigms like CCP is?
Yay CCP keep up the good work.
I'm sure they did some good work there, but they did nothing of the kind you're describing. They simply rewrote the network I/O code using a more efficient (but harder to implement) design. The protocol is the same.
|
Garok Nor
Blueprint Haus
|
Posted - 2008.09.28 01:19:00 -
[115]
Originally by: Faffywaffy
Originally by: Garok Nor Lemme see if I understand this right... Eve was slow so you CREATED a completely new and original network protocol to deal with the problem???????
That's it... next time somebody tells me I am wasting time with videogames, I'm gonna tell them that I'm actually involved in high end testing of new internet technologies that are propelling us towards a brighter technological future (and I also understand I am providing study material for Economists).
TBQH I'm impressed, and quite excited to be even a tiny part of of an MMO which is pioneering new methods of digital communication. What other MMO's are changing paradigms like CCP is?
Yay CCP keep up the good work.
I'm sure they did some good work there, but they did nothing of the kind you're describing. They simply rewrote the network I/O code using a more efficient (but harder to implement) design. The protocol is the same.
Ya I kinda gathered that as I read through the thread and CCP further explained... but my first impression aside, this is still an amzing feat (especially if it works).
Does this mean that SoonÖ could be this tuesday for many of us? ------------------------------------------------- Items posted by me are in no way a reflection of the policies and/or opinions of my corporation or alliance. {though they maybe really ought to be} |
Tarron Sarek
Gallente Biotronics Inc. Alternative Realities
|
Posted - 2008.09.28 01:49:00 -
[116]
Great stuff.
___________________________________
Balance is power, guard hide it well
"Ceterum censeo Polycarbonem esse delendam" |
Herschel Yamamoto
Bloodmoney Incorporated
|
Posted - 2008.09.28 03:08:00 -
[117]
1400 in Jita(with more to come this weekend, from the sounds of that memory upgrade), essentially lag-free fleet battles, and this is before Infiniband comes online. What's next, cats and dogs living together in harmony?
Seriously, you guys rock. Keep it up. ------------------ Fix the forums! |
Chainsaw Plankton
IDLE GUNS IDLE EMPIRE
|
Posted - 2008.09.28 04:39:00 -
[118]
Quote: Finally there is a pool of dedicated dual-CPU machines that only run a single node per machine. Jita and four other solar systems are assigned to that pool. That pool is now running all native 64 bit code and the blades have been upgraded to 16 GB of memory.
heh what are the 4 other systems
amarr, motsu, rens, orsulate (or whatever that smelly frenchie system is called)?
|
Aidin Amado
Gulliver Corp Prismatic Refraction
|
Posted - 2008.09.28 07:00:00 -
[119]
Edited by: Aidin Amado on 28/09/2008 07:02:01 Tbh I'm fairly impressed with the fact that Eve actually works at all. I mean, we're 30-40k users logged in on a single shard, and even though you're zoning out the players, the single shard system forces you to keep a tag on everyone, and sometimes everyone congregate in a certain place - like Jita. WoW of course staggers away from this problem by sharding. I doubt there is ever more than a couple of thousand players online in each shard in WoW at any given time, and since they are zoned out into the different lands, you get a fairly smooth experience - most of the time.
In my younger days I sniffed at an MMO, but staggered away in horror when I saw what was involved. I think most people compare MMO's to single player games, and probably even think that physics and game logic and such are handled by the clients. But of course, the clients are nothing more than a window that shows a scene. Almost all of the game handling: io, ai, network, physics, collissions, and so on are handled by the server. This is why we warp right through planets. If the server handled that kind of collissions, we'd all have lag all the time.
And when you get 30-40k users, heck even 1-2k users, you have to find a solution of epic complexity. I mean, how do you handle a simple thing like dropping a can in space considering that whoever is near it must first of all see it, and then be able to approach it and act on it, and this at the same time that it was dropped?
Thus I'm quite impressed with anyone that actually manages to make a working one - even though it glitches at time. So good work, guys and girls.
But fix the lag! :P ------ Recruitment Director, Gulliver Corporation |
Feng Schui
Minmatar Ghost Festival
|
Posted - 2008.09.28 07:37:00 -
[120]
Originally by: Aidin Amado Edited by: Aidin Amado on 28/09/2008 07:02:01 Tbh I'm fairly impressed with the fact that Eve actually works at all. I mean, we're 30-40k users logged in on a single shard, and even though you're zoning out the players, the single shard system forces you to keep a tag on everyone, and sometimes everyone congregate in a certain place - like Jita. WoW of course staggers away from this problem by sharding. I doubt there is ever more than a couple of thousand players online in each shard in WoW at any given time, and since they are zoned out into the different lands, you get a fairly smooth experience - most of the time.
In my younger days I sniffed at an MMO, but staggered away in horror when I saw what was involved. I think most people compare MMO's to single player games, and probably even think that physics and game logic and such are handled by the clients. But of course, the clients are nothing more than a window that shows a scene. Almost all of the game handling: io, ai, network, physics, collissions, and so on are handled by the server. This is why we warp right through planets. If the server handled that kind of collissions, we'd all have lag all the time.
And when you get 30-40k users, heck even 1-2k users, you have to find a solution of epic complexity. I mean, how do you handle a simple thing like dropping a can in space considering that whoever is near it must first of all see it, and then be able to approach it and act on it, and this at the same time that it was dropped?
Thus I'm quite impressed with anyone that actually manages to make a working one - even though it glitches at time. So good work, guys and girls.
But fix the lag! :P
this
Project:Gank
Pilgrim Guide
|
|
|
|
|
Pages: 1 2 3 [4] 5 6 :: one page |
First page | Previous page | Next page | Last page |