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

OmegaTwig
Firebird Squadron
Terra-Incognita
Posted - 2010.10.22 16:38:00 - [31]
 

Originally by: Pep Alo
"64 bits are twice as many as 32 bits"


Quoted again for extra awesomeness... And the graphs did help __A__ __LOT__ (Double _ for extra emphasis...)

Also i think the reason they are not going to 128 is mostly why bother when you can do it with 64 =P

John Zorg
Caldari
The Damned Legion
Posted - 2010.10.22 17:15:00 - [32]
 

From what I understood from a previous Blog was that we needed Downtime in order to do the recycling of these IDs. Will this mean the end of DT? Or could it mean a less frequent DT? Say maybe once a week or so?

Would be pretty kewl. YARRRR!!

Stupid McStupidson
Gallente
Hoek Lyne and Sinker
Posted - 2010.10.22 17:16:00 - [33]
 

CCP Creber Cattus : Best dev name ever.

64bit>32bit : Best devblog graph ever.


Charles37
Posted - 2010.10.22 17:20:00 - [34]
 

Glad to hear that you're getting rid of the itemID recycle scripts; less moving parts means less places for things to fail.

Also, you mentioned a 14h or so expected DT; is there a tentative patch day yet? Or any info on when we get the Incursion trailer?

Loki Nahat
Skyforger
Tactical Narcotics Team
Posted - 2010.10.22 17:40:00 - [35]
 

Edited by: Loki Nahat on 22/10/2010 17:42:19
Originally by: Jarjar
Should be enough for... ever, as far as PC gaming is concered. Unless everyone starts unstacking their minerals. Laughing


Hey, that's sounds like fun, everyone in Jita, on the count of 3...

But seriously, this is mint. Welcome to the world of tomorrow!


Loki
edit:(is there anything Incursion won't do?)

Keiko Kobayashi
Amarr
Celestial Janissaries
Curatores Veritatis Alliance
Posted - 2010.10.22 17:48:00 - [36]
 

Edited by: Keiko Kobayashi on 22/10/2010 18:06:16
Originally by: Makko Gray
That extra bit is used for signing, why not use unsigned ints and have twice as many? Or allow negative identities? As from what I remember you don't get the unsigned option on the sql data type.


If they’d be using the sign on the 32-bit numbers then that would give them some more slack, but it’d still be a type change so then might as well go for 64 bits. And on the total number of 63 bits, 1 bit extra doesn’t really add much value, but would add extra migration risk as most systems work with signed numbers by default, as well as existing code.

Going from signed to unsigned would mean that you wouldn’t just have to extend the range, but also would have to change code that might e.g. be using -1 as a special flag value.

Originally by: Makko Gray
That said I wonder how long it'll take for the title to go the way of it's apocryphal originator - maybe you should have gone straight for 128 bits and implemented GUIDs


I don’t think you realise the massiveness of the increase in number range you get with going from 32 to 64-bit :), going 128-bit really is overkill. No system would be even able to store that many IDs, as this would require tens to hundreds of millions of terabytes of disk space.

Mainstream CPU’s also went from 32 bits to 64 bits because there is no way in the foreseeable future that anyone will have a system which has that much storage space that he needs 128 bits to address it. Actually most 64-bit CPUs can’t even really address 64 bits internally but rather have an addressing range of 48 bits at the most.

The only thing that went from 32-bit to 128-bit is IPv4 to IPv6, but the reason why they made that kind of a jump was so that they would be able to waste large address ranges in return for easy addressing and better network topology. And that argument doesn’t really apply in this case.

Tsabrock
Gallente
Circle of Friends
Posted - 2010.10.22 19:05:00 - [37]
 

Armageddon Day... we've not had one of those for a while now. The last one I took part in was during the "retiring" of the TQ cluster, during one of the first hardware overhauls. I think that was in 2005 I think.

The last one in 2007 I vaguely recall. I was still employed at my old job at the time, and I think SiSi was down when I was able to play.

Eileene
Posted - 2010.10.22 19:06:00 - [38]
 

Edited by: Eileene on 22/10/2010 19:11:37
Originally by: Firartix

Well, like, why use global IDs for just every item ?



Because it simplifies game code.

Originally by: Firartix
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)



And how would you differentiate between them? Will you add some integer field with number stating type of the item? It will only make the code more complicated and you will not save any bits.

Bagehi
Association of Commonwealth Enterprises
Posted - 2010.10.22 20:11:00 - [39]
 

Originally by: John Zorg
From what I understood from a previous Blog was that we needed Downtime in order to do the recycling of these IDs. Will this mean the end of DT? Or could it mean a less frequent DT? Say maybe once a week or so?

Would be pretty kewl. YARRRR!!


I hope that was sarcasm.

Metlec
Posted - 2010.10.22 20:21:00 - [40]
 

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

do we get to now scan an entire system???

or are we still limited to that silly 2 bill km


We can now scan every ship in the universe Wink

Louis deGuerre
Gallente
Malevolence.
Posted - 2010.10.22 20:27:00 - [41]
 

Edited by: Louis deGuerre on 22/10/2010 20:28:32

I laughed 2 minutes straight when i saw the 64 = 2 * 32 graph RazzRazzRazz

Korerin Mayul
Amarr
Posted - 2010.10.22 20:42:00 - [42]
 

'It will take a long time to convert all the existing data, so we expect around 14 hours of downtime when we do the upgrade. This will be time well spent though, since we will be gaining 183 trillion item IDs each second. :p'

this cheered me right up. thanks!

Trebor Daehdoow
Gallente
Sane Industries Inc.
Posted - 2010.10.22 20:44:00 - [43]
 

Originally by: Jarjar
Unless everyone starts unstacking their minerals. Laughing

Quick, banhammer Chribba before he destroys EVE.

Soden Rah
Gallente
EVE University
Ivy League
Posted - 2010.10.22 21:00:00 - [44]
 

Originally by: Keiko Kobayashi


I don’t think you realise the massiveness of the increase in number range you get with going from 32 to 64-bit :), going 128-bit really is overkill. No system would be even able to store that many IDs, as this would require tens to hundreds of millions of terabytes of disk space.



32 bit id's = ((2^031 - 1)*032)/(8*(1*10^(3*3))) = 8.59 GB
64 bit id's = ((2^063 - 1)*064)/(8*(1*10^(3*4))) = 73,786,976 TB
128 bit id's = ((2^127 - 1)*128)/(8*(1*10^(3*4))) = 2,722,258,935,367,510,000,000,000,000 TB

128 bit id's are the sort of thing you want when you want to issue a unique identification number to every star, planet, and kilometer+ sized asteroid in the observable universe. (256 bits comes within few orders of magnitude of storing a unique ID for every single atom in the visible universe)

Delnadres Courthelia
Posted - 2010.10.22 21:23:00 - [45]
 

I'm hoping this also means it's easier for CCP to expand the quantity of solar systems, and possibly even the complexity of existing solar systems (larger asteroid belts, comets, etc).

If there's a behind-the-scenes change, I'm just hoping it will open up in-your-face possibilities. XD

Delnadres Courthelia
Posted - 2010.10.22 21:27:00 - [46]
 

Edited by: Delnadres Courthelia on 22/10/2010 21:28:21
Originally by: Soden Rah

(256 bits comes within few orders of magnitude of storing a unique ID for every single atom in the visible universe)



I believe that's a gross underestimation of the amount of molecules some stars have, let alone atoms in the universe...

Alain Kinsella
Minmatar
Posted - 2010.10.22 21:34:00 - [47]
 

Originally by: Gin Andtonic
Really, just tell everyone there will be a day without EVE and take the full 24 hours. It will head off a lot of whining. If nothing goes wrong, hey, shorter than expected downtime, or just take the rest of the day to kick back and enjoy VIP mode. If things go completely balls-up, and the potential for ball elevation is nearly limitless with a change like this, you'll have the buffer to fix it without the player base screaming at you.

Also, warning. Give us plenty of warning, please.


This please...

What is the 'actual' expected time to do the work? I think it would assure a lot of us that you've put in a decent cushion this time.

Also, that day would be a nice opportunity for turning SiSi into soup/slag. Twisted Evil

Gnulpie
Minmatar
Miner Tech
Posted - 2010.10.22 22:17:00 - [48]
 

Originally by: CCP Creber Cattus
64 bits will be enough for... (It will at least not be my problem when that time comes)


Someone give that man some medal! \o/

I enjoyed that blog, well written and full of humour and fun yet also covering the vital points. Nice!

And of course those changes are good.

CCP Creber Cattus

Posted - 2010.10.22 22:23:00 - [49]
 

Originally by: Firartix

Everything removed, because all my questions got answered while i was posting.
I hate you D: !


glad I could help :)

Originally by: John Zorg

Will this mean the end of DT? Or could it mean a less frequent DT? Say maybe once a week or so?


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

Originally by: Charles37

Also, you mentioned a 14h or so expected DT; is there a tentative patch day yet?


The final date has not been set yet... But I would GUESS after about 10-20 days (but don't quote me on that!).

Originally by: Alain Kinsella

What is the 'actual' expected time to do the work? I think it would assure a lot of us that you've put in a decent cushion this time.


Of the now ESTIMATED 14 hours we expect the data migration to take 8 hours (no, the number is not pulled out of a hat)... but after the data migration is done a lot of "checks" need to be done before we can let you all in!

Originally by: Stupid McStupidson, Louis deGuerre, Korerin Mayul, Gnulpie

CCP Creber Cattus : Best dev name ever.
64bit>32bit : Best devblog graph ever.

I laughed 2 minutes straight when i saw the 64 = 2 * 32 graph

this cheered me right up. thanks!

I enjoyed that blog, well written and full of humour and fun yet also covering the vital points. Nice!


Thanks!!

Matalino
Posted - 2010.10.22 22:55:00 - [50]
 

Edited by: Matalino on 22/10/2010 23:06:19
Originally by: Delnadres Courthelia
Edited by: Delnadres Courthelia on 22/10/2010 21:28:21
Originally by: Soden Rah

(256 bits comes within few orders of magnitude of storing a unique ID for every single atom in the visible universe)



I believe that's a gross underestimation of the amount of molecules some stars have, let alone atoms in the universe...
No, that estimate is not too far off. Your estimate of the mass of a star is much further from the mark.

The mass of the sun is 1.99e+30 kg. The mass of a proton is 1.60e-27 kg. 256 bits gives you 1.16e+77 IDs. That gives you at least enough ids for every atom in 9.3e+19 solar masses. That goes far beyond any star or even our entire galaxy. That is still 72 million times bigger than the local group of galaxies.

By my calculations 256 bits might fall a bit short of giving every atom in the observable universe a unique id. Given an estimated mass for the universe of 9e+21 solar masses, Soden Rah's estimate is accurate within two (a couple) orders of magnitude, just like he said. 263 bits should provide enough ids for every atom in the universe.

Tonto Auri
Vhero' Multipurpose Corp
Posted - 2010.10.23 00:09:00 - [51]
 

Every limited space will be overflown eventually.
So, telling us that you'll not be in need of recycle is "a bit" imprecise.

Originally by: OmegaTwig
Also i think the reason they are not going to 128 is mostly why bother when you can do it with 64 =P


Bigger memory consumption is what holding them from using 128 bit.
They already nearly doubled the memory pool used with this update, pushing it even higher is just unreasonable.
And more processing power need to deal with bigger numbers. Neglegible per single operation, it stacks rather fast, when you dealing with monsters like EVE is.

Soden Rah
Gallente
EVE University
Ivy League
Posted - 2010.10.23 01:16:00 - [52]
 

Originally by: Delnadres Courthelia
Edited by: Delnadres Courthelia on 22/10/2010 21:28:21
Originally by: Soden Rah

(256 bits comes within few orders of magnitude of storing a unique ID for every single atom in the visible universe)



I believe that's a gross underestimation of the amount of molecules some stars have, let alone atoms in the universe...


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)

Noun Verber
Gallente
Posted - 2010.10.23 01:22:00 - [53]
 

Will this affect the uses of 'CCP infinite' values in game (invalid autopilot routes/WH distances)?

Will the new scanner max be changed or be coded to remain the same as it is now? If it gets a code change, will it be rounded off to a whole AU value?

capn zed
Gallente
Democracy of Klingon Brothers
Posted - 2010.10.23 01:24:00 - [54]
 

So for those of you new to these upgrades,

On the night before patch day, plan for an "extended" downtime.
Fill your skill que to run longer than a day (long train skills)
Go outside.
Do the dishes.
Return to real life for a day.

Complaining about how long it's taking will not make it go faster.
Venting your frustrations on the forums is highly encouraged.
Expecting your venting to change anything is futile.

Just some handy tips I've picked up since Apocrypha.
I hope they help you through patch day with minimal insanity.

Solbright
Advanced Security And Asset Protection
Posted - 2010.10.23 02:37:00 - [55]
 

We finally have the real reason for the mass deletion of secure canisters ... can we have them back now please?

Or at the very least reinstate a more reasonable policy of NOT auto deleting them in deep space!


Adunh Slavy
Ammatar Trade Syndicate
Posted - 2010.10.23 02:41:00 - [56]
 

Why not use UUIDs?

Morgenholt Blue
RED.Legion
Posted - 2010.10.23 03:38:00 - [57]
 

Will you be doing this at the same time Incursion is deployed? Take like 24 hours to do both at the same time so we don't have a really long downtime for this and incursion.. I would just rather have 1 day of DT than 2 days of it being down most of the day.

Also Armageddon day on Sisi, yes please Razz


Skill points for the long DT? lol jk Wink

Rakshasa Taisab
Caldari
Sane Industries Inc.
Posted - 2010.10.23 03:39:00 - [58]
 

Originally by: Solbright
We finally have the real reason for the mass deletion of secure canisters ... can we have them back now please?

Or at the very least reinstate a more reasonable policy of NOT auto deleting them in deep space!

It was always more about in-space objects than item id's.

The latter does not really affect much the loading of a system, the former does.

Solbright
Advanced Security And Asset Protection
Posted - 2010.10.23 04:17:00 - [59]
 

Edited by: Solbright on 23/10/2010 04:19:27
Originally by: Rakshasa Taisab
Originally by: Solbright
We finally have the real reason for the mass deletion of secure canisters ... can we have them back now please?

Or at the very least reinstate a more reasonable policy of NOT auto deleting them in deep space!

It was always more about in-space objects than item id's.

The latter does not really affect much the loading of a system, the former does.

The argument of server congestion never made any sense at all. Especially in the way the deletion was executed - Outright mass deletion of every seemingly derelict canister, including all unanchored structures and ships I think. There was never any need for everything to be wiped like that based on congestion arguments.

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.

The only solid explanation that would cause CCP to modify the game so dramatically from one of a sandbox to one of emptiness is the slow but fatal depletion of item IDs.


Solbright
Advanced Security And Asset Protection
Posted - 2010.10.23 04:32:00 - [60]
 

Edited by: Solbright on 23/10/2010 04:35:15
Originally by: Solbright
The only solid explanation that would cause CCP to modify the game so dramatically from one of a sandbox to one of emptiness is the slow but fatal depletion of item IDs.

That also explains why CCP laughed at the idea of only unlocking the cans, instead of deleting them, so that scavengers could go collecting them. Because that wouldn't have actually reduced the item count, well, not in the short term at least.



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