open All Channels
seplocked EVE Information Portal
blankseplocked New Dev Blog: 64 bits should be enough for everybody
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: 1 2 [3] 4

Author Topic

Gerard Deneth
Caldari
Pavlov Labs GmBH
Independent Faction
Posted - 2010.10.23 04:44:00 - [61]
 

Originally by: Solbright

Player observable performance wise, stuttering, was purely a client side issue so was always a false claim. This particular problem is solved by fixing the client. Which CCP have gone some way to achieving.



I dunno about you, but there wasn't much "false claim" whenever i warped into a belt with my lil' Osprey back in the day. True my machine wasn't a monster, but it was laggy as heck when I got into a belt.

Frug
Omega Wing
Snatch Victory
Posted - 2010.10.23 04:54:00 - [62]
 

Hilarious graphs.

Love it.

Solbright
Advanced Security And Asset Protection
Posted - 2010.10.23 05:28:00 - [63]
 

Edited by: Solbright on 23/10/2010 05:34:40
Originally by: Gerard Deneth
Originally by: Solbright

Player observable performance wise, stuttering, was purely a client side issue so was always a false claim. This particular problem is solved by fixing the client. Which CCP have gone some way to achieving.



I dunno about you, but there wasn't much "false claim" whenever i warped into a belt with my lil' Osprey back in the day. True my machine wasn't a monster, but it was laggy as heck when I got into a belt.

Ya, that was all client side stuttering though. Which makes it a false claim as to why CCP did the mass deletion.

And I don't think CCP themselves ever claimed display stutter as a reason for the deletion by the way. It was just some whiners who thought it was a good idea to wipe out everything just because the client performed poorly with a little bit of clutter on the screen.


Cresalle
Posted - 2010.10.23 06:06:00 - [64]
 

Edited by: Cresalle on 23/10/2010 06:13:26
Originally by: Firartix
Well, like, why use global IDs for just every item ?
I don't personally get the purpose of having extractors along missiles and fighters in the database... Sounds like a waste of IDs, inecrase in database size stuff, and moar to me (not like i actually know DBs so i guess it's wrong XD)


The alternative would be to store a type-id and an item-id. That would be 128 bits of identification rather than 64 and would negatively impact server performance because two values would have to be fetched and handled instead of one. Alternatively they could segregate items into storage groups, but that would require creating a different database for each item category. Since many items cross category types over the course of their lifetime (ammo gets loaded to a weapon, an implant gets plugged in, a control tower gets unanchored, etc, etc) this would mean creating a lot more items, since the change would involve invalidating the item and then creating a new one of the type that it's changing to. Additionally the overhead of storing and handling multiple databases instead of one would result in an overall performance loss that could be quite significant depending on how many dbs you split it into. With a single database you can do things like quickly iterate through items and update them all with much less code to traverse and a greatly simplified "Where do I go in memory to find this value?" type lookups.

tl:dr - Having all kinds of items use a unique id in a single master database really is (part of) the fastest solution.

Douchie McNitpick
Free-Space-Ranger
Posted - 2010.10.23 08:18:00 - [65]
 

Edited by: Douchie McNitpick on 23/10/2010 08:20:21
Originally by: Solbright

Ya, that was all client side stuttering though.



You are wrong.
The can clutter affected gridload times to the point where it could even time out if there were too many around. It was a server side issue first and foremost, especially considering that there would sometimes be hundreds of objects in close proximity, all to be taken into account whenever someone used his directional scanner.

Solbright
Advanced Security And Asset Protection
Posted - 2010.10.23 08:34:00 - [66]
 

Grid load times, for cans back then at least, were mostly the client burdened with the effort of inserting the update packet into it's internal simulator. Which is quite different to the server sending it out since the server already has the content loaded in it's simulator.

That was the embarrassing part - That the client would stall so badly on such a seemingly trivial operation.


Matthew
Caldari
BloodStar Technologies
Posted - 2010.10.23 10:49:00 - [67]
 

Originally by: Solbright
Ya, that was all client side stuttering though. Which makes it a false claim as to why CCP did the mass deletion.


Read and be educated

In particular about the server-side SOL-node caches and the problems that arise when the number of containers in space exceeds the number that can be held in the SOL-node cache at any one time. (Hint: having to retrieve all the container info from the database every time someone jumps into the system because it doesn't all fit in the cache is NOT good for server performance).

Marchocias
Posted - 2010.10.23 11:17:00 - [68]
 

Originally by: Sgt Blade
128 would have been better....Laughing


Not really.

Since they're using 64bit machines and MS SQL Server, 64 bits is twice as fast as 128 bits.

Every 128 bit ID would require 2 64bit columns to store in the main table and every table that references it, and compound (over more than 1 column) primary and foreign keys and indexes to perform lookups quickly. With 64bit hardware, such operations require extra operations on the processor.

Moving from 32bit to 64bit doesn't have this slowdown, as the 32bit code takes the same number of operations (roughly) as 64bit code would on 64bit hardware.


Caveat: IF they were also using some theoretical 128bit hardware, and a version of SQL Server that supported it, THEN it would be better. Maybe.

Solbright
Advanced Security And Asset Protection
Posted - 2010.10.23 11:25:00 - [69]
 

Originally by: Matthew
... having to retrieve all the container info from the database every time someone jumps into the system because it doesn't all fit in the cache is NOT good for server performance).

That may be a slightly reasonable reason for vacuuming the belts and gates (And I didn't have a problem with that part of the cleanup btw) but that's as far as that argument goes. The in-space data for a container is hardly substantial, memory is cheap, container contents isn't part of that data, or at least they shouldn't be.

Again, scavengers could have done that job, if server congestion was the real problem then scavenging would have been a great solution.

All in all, the mass deletion was a way overkill feature nerf that hopefully will at least be partly restored now.


Vuk Lau
4S Corporation
Morsus Mihi
Posted - 2010.10.23 11:48:00 - [70]
 

Edited by: Vuk Lau on 23/10/2010 11:49:23
What arithmetic algorithm you guys used for calcing those graphs?

Mashie Saldana
Minmatar
Veto Corp
Posted - 2010.10.23 13:35:00 - [71]
 

Originally by: Solbright
And I don't think CCP themselves ever claimed display stutter as a reason for the deletion by the way. It was just some whiners who thought it was a good idea to wipe out everything just because the client performed poorly with a little bit of clutter on the screen.



Tbh I don't care why they are deleted but I do prefer it now when it isn't a few hundred anchored cans in every belt turning them into yellow clouds.

Solbright
Advanced Security And Asset Protection
Posted - 2010.10.23 13:56:00 - [72]
 

Originally by: Mashie Saldana
Tbh I don't care why they are deleted but I do prefer it now when it isn't a few hundred anchored cans in every belt turning them into yellow clouds.

That's not the issue of concern here. What matters is all the other cans that were deleted along with the belt cans.


elitatwo
Caldari
Posted - 2010.10.23 18:49:00 - [73]
 

Originally by: Vuk Lau
Edited by: Vuk Lau on 23/10/2010 11:49:23
What arithmetic algorithm you guys used for calcing those graphs?

Very Happy my guess would be that the is a kind of humor, that not everybody understands.
I like it and it make the ones who know about relational db's laugh a bit.
For those who cant follow us here (dont wanna be the smartass but..) 64bit is of course not exactly twice as much as 32bits because:
in signed 32bit values you have ((2^32)-1)bits and "twice" as much would be ((2^33)-1).
Now (2^64)-1 bits are "twice" on the exponent because of the exponential laws (2^(32*2)) equals 2^64 Wink.
[/smartassness].
I love the work you put into EVE and we can never thank you enough for the that!
And when do we get the 64bit client for stackless jumps?

Thrasymachus TheSophist
Posted - 2010.10.23 21:28:00 - [74]
 

Edited by: Thrasymachus TheSophist on 23/10/2010 21:30:14
I applaud CCP's decision to tell us now, "Oh, BTW, your stuff may be ****ed when we make the change" instead of relying on damage control later.

I'm alert to the issue, I won't be surprised, and I anticipate prompt corrections to errors.

Win-Win-Win.


EDIT: Why does F double O, K, get censored? Silly sir, silly.

Tonto Auri
Vhero' Multipurpose Corp
Posted - 2010.10.24 07:18:00 - [75]
 

Originally by: Adunh Slavy
Why not use UUIDs?


UUID = 128 bit. That's why.

Lost Hamster
Hamster Holding Corp
Posted - 2010.10.24 19:00:00 - [76]
 

Is this downtime separated from the winter expansion?

I hope you don't plan to do both at the same time, personally I think that would be a big risk.

Shaalira D'arc
Posted - 2010.10.24 21:33:00 - [77]
 

Originally by: kano donn
wait..... the d-scan. how does this affect the max range on that?

Andrew Holland
Life. Universe. Everything.
Clockwork Pineapple
Posted - 2010.10.25 11:41:00 - [78]
 

Great! I've been waiting for this ever since I heard the first mention of you guys "recycling" item IDs (an unusual concept to say the least). Any chance this will shorten daily downtimes on average?

Lost Hamster
Hamster Holding Corp
Posted - 2010.10.25 17:28:00 - [79]
 

Originally by: Andrew Holland
Great! I've been waiting for this ever since I heard the first mention of you guys "recycling" item IDs (an unusual concept to say the least). Any chance this will shorten daily downtimes on average?


Originally by: CCP Creber Cattus

Cleaning up item ids is not the reason for downtime. We do most of our id cleanup while the game is running.



It has no affect on the DT lenght.

Thy Collector
Posted - 2010.10.25 19:05:00 - [80]
 

Originally by: Aurora Robotnik
If it isn't broke, don't fix it.

Oh wait, hi CCP.


????

If it isn't broke. Then you're probably doing it wrong.

Lan Staz
Posted - 2010.10.25 20:33:00 - [81]
 

Originally by: Soden Rah
wiki lower estimate for number of atoms in universe (number quoted in other sources but you can look wiki up) is 10^80 as 256 bits goes into the high 10^70's it comes within a few orders of mag. Of course to actually store a unique number 256+ bits long for every atom in the universe would require more atoms than actually exist... which explains why you can only see 10% of the universe, the remaining 90% is the accounting. (discworld joke)

I think you have forgotten to take into account the number of atoms required for storing the count of the number of atoms in the universe, given that CCP's servers (which have to store the number) are part of that universe.

Could someone knowledgeable in quantum information storage density calculation methods please clarify?

Soden Rah
Gallente
EVE University
Ivy League
Posted - 2010.10.25 21:41:00 - [82]
 

Edited by: Soden Rah on 25/10/2010 21:48:34
Edited by: Soden Rah on 25/10/2010 21:44:06
Originally by: Lan Staz
Originally by: Soden Rah
wiki lower estimate for number of atoms in universe (number quoted in other sources but you can look wiki up) is 10^80 as 256 bits goes into the high 10^70's it comes within a few orders of mag. Of course to actually store a unique number 256+ bits long for every atom in the universe would require more atoms than actually exist... which explains why you can only see 10% of the universe, the remaining 90% is the accounting. (discworld joke)

I think you have forgotten to take into account the number of atoms required for storing the count of the number of atoms in the universe, given that CCP's servers (which have to store the number) are part of that universe.

Could someone knowledgeable in quantum information storage density calculation methods please clarify?


well I thought I had it covered with "discworld joke" but...

To classically store a unique id for every atom in the universe with a storage system which can store 1 bit per atom would require (slightly more than) 256 bits(atoms) to store the id for every atom. thus you would need over 256 times as many atoms to store the id's for all the atoms.

Useing quantumn information storage where quibits (quantumn-bits) can both be 0 and 1 at the same time you could store every required id on (slightly more than) 256 quibits.

In otherwords, a classical computer needed to store unique id's for every atom in the universe would weigh 256+ times the mass of the universe... a quantumn computer could do the same job and fit not only inside the universe in question but could fit in the palm of your hand. (or inside the nucleus of one of the cells in your hand)

However the classical computer could be dramatically improved by moving away from binary data storage.
It would still probably need to be at least astronomically large if not actually occupying a significant portion of the mass of the universe.

EDIT: or as an alternative one could just compress all the matter in the universe into nutronium (the stuff of nutron stars) thuss effectively reducing the number of atoms (a nutron star can effectively be thought of as one single atomic nucleus) to a more manageable number.

Quantumn computing (or the end of mankind, or of at least the internet, which is much the same thing) is likely to come along well before CCP needs to resort to stellar sized computers to store the item Id's for all the items in eve. Of course it's entirely possible that the end of mankind will be caused by some well meaning dev forgetting to build in an off-switch for a bunch of nanites tasked with building a new data server, and they slowly convert the entire planet into one giant supercomputer. Those unfortunate enough to not be able to afford a spaceship off the planet will have to choose between death or uploading themselves into the eve server and living the rest of their lives as charachters in eve...

Incarna will probably still be to be released SoonTM...

Manfred Rickenbocker
Pan Galactic Gargle Blasters
Important Internet Spaceship League
Posted - 2010.10.26 00:27:00 - [83]
 

The Item IDs are expanding to meet the needs of the Expanding Item IDs.

Mashie Saldana
Minmatar
Veto Corp
Posted - 2010.10.26 13:34:00 - [84]
 

Originally by: Solbright
Originally by: Mashie Saldana
Tbh I don't care why they are deleted but I do prefer it now when it isn't a few hundred anchored cans in every belt turning them into yellow clouds.

That's not the issue of concern here. What matters is all the other cans that were deleted along with the belt cans.



Just visit your cans once a month and they will remain there as long as you are subscribed.

Cuchulain Spartan
Posted - 2010.10.26 21:23:00 - [85]
 

Originally by: Cuchulain Spartan
Maybe next time gives us a heads up.

E.g Dear Players,

We are about to release a substantial upgrage to our UI. We have done extensive internal QA tests but believe that some bugs may pass to Tranquility. In the first 72 hours of the release we will have all hands on deck working overtime to deal with any bug reports that are filed and we will be constantly present in the forums. We apologise in advance for an difficulties you encounter but rest assured that the long term results will be a much much better gaming experience for us both.

Regards,
CCP



Originally by: CCP Zymurgist
On the deployment day we will be monitoring feedback, error logs, bug reports and general server health very carefully and be ready to react quickly to any issue. So deployment day is an “all hands on deck” day until we’re sure we’re sailing the smooth seas of awesome.


Glad to see you guys/gals listen. Please reemphasize this closer to the time of release and it should go a long way towards smoothing over any bumps in the deployment.

Solbright
Advanced Security And Asset Protection
Posted - 2010.10.27 12:48:00 - [86]
 

Originally by: Mashie Saldana
Just visit your cans once a month and they will remain there as long as you are subscribed.

The rather silly monthly requirement isn't even the problem. The real problem is they just vanish. There's no give in the system at all. It's truly pathetic.


AC Tesla
Posted - 2010.10.28 08:29:00 - [87]
 

Originally by: Solbright
Originally by: Mashie Saldana
Just visit your cans once a month and they will remain there as long as you are subscribed.

The rather silly monthly requirement isn't even the problem. The real problem is they just vanish. There's no give in the system at all. It's truly pathetic.




Seriously, visiting an ammo container once a month is too rigid. Hell it's more likely someone probed it out before then and blew it up.

Solbright
Advanced Security And Asset Protection
Posted - 2010.10.28 11:34:00 - [88]
 

Originally by: AC Tesla
Seriously, visiting an ammo container once a month is too rigid.

Thank you. Good to get some support.

Secure cans can't be probed btw. But that's the sort of thing that should be introduced. Say, instead of deleting them, they are just unlocked. And when they are not locked they become probe-able just like ships are now.

I'd also make it a six month timeout too. One month is an annoyingly short period if you are spending time in a number of different places.


Kaba Zaoshi
Posted - 2010.10.28 15:34:00 - [89]
 

2^31-1 = 2,147,483,647
I'm sorry but why do you use signed integer? I don't think you use negative values, so why not to use unsigned integer?
2^32-1 = 4,294,967,295
2^64-1 = 18,446,744,073,709,551,615
It's twice more values, and no number gets left unused.

Soden Rah
Gallente
EVE University
Ivy League
Posted - 2010.10.28 18:27:00 - [90]
 

Originally by: Kaba Zaoshi
2^31-1 = 2,147,483,647
I'm sorry but why do you use signed integer? I don't think you use negative values, so why not to use unsigned integer?
2^32-1 = 4,294,967,295
2^64-1 = 18,446,744,073,709,551,615
It's twice more values, and no number gets left unused.


Because as moving to unsigned values on 32 bit doesn't get the job done, and you will have died of old age before it becomes an issue on 64 bit. As it would require extra codeing and compatability issues to make the database use unsigned values its just quicker and easyer to use signed ones. wich means less chance of things going wrong, less dev time writeing code for the backend database and more tme spent making shiny new spaceships to fly in.


Pages: 1 2 [3] 4

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only