EVE Search - Arbitrary Delay Timers

All Channels

EVE General Discussion

Arbitrary Delay Timers

» Click here to find additional results for this topic using Google

Monitor this thread via RSS [?]

Pages: 1 [2] 3 :: one page
Author	Thread Statistics \| Show CCP posts - 0 post(s)
Ban Doga	Posted - 2009.09.03 22:13:00 - [31] Originally by: Venkul Mul Originally by: Ban Doga Originally by: Washell Olivaw Technical reason, 30 second session timers are there to make sure all your stuff is copied correctly from node A to node B within the server. If you don't mind having your stuff disappear, feel free to ask CCP to disable them for you personally. I hope that's not the case. It's pretty lame to wait a fixed, arbitrary amount of time for a process to do something "correctly". I mean will the process copy stuff incorrectly with less time? And is there no way to tell when it finished correctly and continue then, instead of waiting x seconds and hoping (because that's exactly what it would be) that everything went fine? Please don't tell me it works that way... Every time you boar a ship the server us calculating the effect of you skill upon the ship modules and drones, the correct level of the armor, shield and capacitor after your skills and the modules that affect them are onlined by your skills, an so on. Sometime it misses a beat and you leave the station with half shield or offlined module. Probably if the node has no heavy requests or you are boarding a shuttle the time is overaboundant, but when there are heavy requests or you use a ship with plenty of module slots and you have lots of skills the server need every second. 30 second probably was chosen because it is sufficient to do the needed operations, communicate them to your PC and get confirmation back in most heavy lag situations. Having different times depending on the real time needed could favor some player, for example a guy boarding a freighter (no module slots) than a BS and maybe create problems with people boarding ships in rapid sequence and creating lag or server load. You are trying to pull my leg, right? Do you have any idea how much time it takes to make those calculations on an average computer you can buy in the next best store? Milliseconds! The average CPU you have in a half decent home PC nowaways has a couple gigaflops (aka billion floating point operations per second) Linkage. So even if for some very weird reason it takes a billion operations to calculate your ship's status it won't even take a second. Also there are some logical flaws in all this: Why can I change my fitting? All those calculations need to be made and then communicated to my client and confirmation and this takes 30 seconds... And why can I actually undock? I thought the session timer was to prevent rapid "location changes" because that will interfere with the "copying process" and I will lose my stuff? You probably also think the 2 second delay for the directional scanner was introduced to give it enough time to actually scan the system... Originally by: Robdon Coding things based on times and timers is also extremely bad coding practice. This! /me puts on hockey helmet
Lord Haur Amarr StarHunt	Posted - 2009.09.03 22:43:00 - [32] Originally by: Ban Doga And why can I actually undock? I thought the session timer was to prevent rapid "location changes" because that will interfere with the "copying process" and I will lose my stuff? Compare the time it takes to undock right after you change ships to the time it takes to undock if you don't have an active session change timer.
Irida Mershkov Gallente War is Bliss	Posted - 2009.09.03 23:18:00 - [33] Originally by: Cheesestick Charlie Originally by: Zeba Edited by: Zeba on 03/09/2009 17:25:12 ITT: People trying to compare a common enterprise level database servers performance limits and tasks to a single world game servers performance limits and tasks. The two are nothing alike past the fact that they have to transfer and digest huge amounts of realtime data. When was the last time your oracle server had to compute all the crap nessasary for a large fleet fight with its second by second change of enviroment and still have enough power left over for the mundane things like the market and hangers or god knows what else in this game that needs database time. Also ITT: People discussing the way the server works, because they obviously know EXACTLY how it works, why it fails and EXACTLY how it should be fixed. Without ever looking at the code, or any sort of dev saying that this is, indeed, how it works. Ah! it appears you've worked in a business long enough to deal with the common buggers we call customers.
Markesian	Posted - 2009.09.04 00:09:00 - [34] The 30sec session timers are not original equipment. Way back when, it didnt take 30secs to do anything, it took however long, or short, it took. But something changed in some update or other and suddenly ppl were getting stuck on undock and system jumps left and right. The solutiuon came in the form of delay timers on session changes, and it was supposed to be a temporary thing. As with so many temporary solutuions, this one became permanent. You know, now i think of it, i'm almost positive this happened back around the time of the desync debacle.
Washell Olivaw	Posted - 2009.09.04 00:16:00 - [35] Originally by: Markesian You know, now i think of it, i'm almost positive this happened back around the time of the desync debacle. Been there since I started playing, and that was before the desynch debacle. Unless there were 2 of those. Originally by: Signature Everybody has a photographic memory, some people just don't have film.
Cheesestick Charlie	Posted - 2009.09.04 00:27:00 - [36] Originally by: Irida Mershkov Originally by: Cheesestick Charlie Originally by: Zeba Edited by: Zeba on 03/09/2009 17:25:12 ITT: People trying to compare a common enterprise level database servers performance limits and tasks to a single world game servers performance limits and tasks. The two are nothing alike past the fact that they have to transfer and digest huge amounts of realtime data. When was the last time your oracle server had to compute all the crap nessasary for a large fleet fight with its second by second change of enviroment and still have enough power left over for the mundane things like the market and hangers or god knows what else in this game that needs database time. Also ITT: People discussing the way the server works, because they obviously know EXACTLY how it works, why it fails and EXACTLY how it should be fixed. Without ever looking at the code, or any sort of dev saying that this is, indeed, how it works. Ah! it appears you've worked in a business long enough to deal with the common buggers we call customers. Smartass customers, none the less!
Grez Neo Spartans Laconian Syndicate	Posted - 2009.09.04 00:32:00 - [37] When a session timer is initiated, you've changed node. Changing ships, un/docking, using gates/wormholes. The session timer is just there to make sure all information is passed correctly between nodes - this doesn't just mean database information, it could also include other information that we aren't privy to. ---
Markesian	Posted - 2009.09.04 00:36:00 - [38] Originally by: Washell Olivaw Been there since I started playing, and that was before the desynch debacle. Unless there were 2 of those. Been around since late 2004. Cant honestly set a better timeframe than "around", there were so many problems back then one may have seagued into another in the deep dark recesses of momory i think there were some sticky on it at the time, perhaps it could be dug out. And just to be clear, nothing was ever instant, but it didnt use to be on a strict "30sec or more" timer.
Denidil Gallente Shadowed Command Fatal Ascension	Posted - 2009.09.04 02:29:00 - [39] Originally by: Sky Grunthor You called it an arbitrary time sink. Someone informed you that it was not an arbitrary time sink and actually served a technical purpose. /thread. So what are you talking about now? informed my computer science degree holding posterior region. a 1 second timer gives you an entire order of magnitude buffer on any such copy operation inside the cluster. now on the other hand an excess load argument could be involved here - because when you change ships it needs to apply all your relevant skills which is going to involve a lot of data accesses that are going to cause a lot of cache misses on the CPUs at best, but will most likely require hitting the database server at least once. 30 seconds is probably overkill in preventing that, but it is a concern [especially if you had several people playing musical starships in Jita]
Denidil Gallente Shadowed Command Fatal Ascension	Posted - 2009.09.04 02:39:00 - [40] Originally by: Ban Doga < a load of stuff > theoretical maximum CPU FLOPS that are impossible to achieve on any human time scale in a CPU have nothing to do with this* all those calculations are going to necessarily involve cache misses and database access. the bottleneck isn't the CPU's theoretical maximum FLOPS: the bottleneck is it's maximum USEABLE FLOPS - due to data access waits. Whenever a cache miss occurs you're going to RAM and that CPU pipeline stalls waiting for the memory access. when you go to harddrive modern OSes will suspend that thread until the DMA controller the operation is handed off to raises an interrupt indicating that is completed. Suspending it involves a user mode to kernel mode context switch and memory accesses - and then back to usermode bringing the next ready job to ative. then when that first thread gets placed back on the ready queue, another context switch to kernel mode to move it from the wait queue to the ready queue, and then back to whatever job got interrupted. in real world applications throughput rarely approaches theoretical maximum when a data set of any appreciable size is involved, or networking is involved [as that's even slower than spinning-disk mass storage] *a CPU cannot realize its theoretical maximum throughput on a human timescale because the CPU's L1 cache isn't big enough to store enough ops and data to do so... not on any serious computing task anyway.
Ban Doga	Posted - 2009.09.04 07:23:00 - [41] Originally by: Denidil Originally by: Ban Doga < a load of stuff > <another load of stuff> We're not talking about something that the best hardware might achieve in a couple of seconds in ideal circumstances, so we have to have a 30 second delay to acommodate for real life conditions. So stating that actual performance is always lower than theoretical performance is just smartassing. Completely generic answer that while it is true has no relevance. (When you swim in the ocean and get back out of the water, the drops that cling to your body will lower the sea level - see, it's not that hard)
Nyphur Pillowsoft Total Comfort	Posted - 2009.09.04 07:49:00 - [42] Edited by: Nyphur on 04/09/2009 07:48:55 Originally by: Denidil informed my computer science degree holding posterior region. My computer science degree didn't come with omniscience :(. Damn, I should ask for the last five years of my life back. EVE-Tanking.com - Helping you keep your hull in-tact.
Bellac	Posted - 2009.09.04 08:49:00 - [43] As a long time player I see it like this. (no science babble needed ) In the old days you would dock - change ships quickly - undock - and have a 1 in 5 chance of the game locking (just had a black screen). The only cure was to petition and get an admin to unlock you character and put him safely back in the station (leaving game and restarting did not cure this lock up). All in all - on average - this worked out to waay more than 30 seconds - lol Now we have a far from perfect situation with a very annoying 30 second session change timer. But it works and we don't have stuck characters all over the place. I would love to see a better crafted solution to the timer - but for now I am prepared to live with it.
Denidil Gallente Shadowed Command Fatal Ascension	Posted - 2009.09.04 11:45:00 - [44] Originally by: Nyphur Edited by: Nyphur on 04/09/2009 07:48:55 Originally by: Denidil informed my computer science degree holding posterior region. My computer science degree didn't come with omniscience :(. Damn, I should ask for the last five years of my life back. no, and it didn't need to. it came with this thing called "knowledge" and another thing called "understanding". specifically in this case of commonalities between all modern computing architectures. you'll notice that I did indeed call 30 seconds more than a bit overkill. I was just correcting someone talking out their posterior region because their mouth knows better.
EmpressShiva	Posted - 2009.09.04 11:51:00 - [45] Is there some kind of huge problem with the server communicating when transfer is complete? Doesn't seem like crazy rocket science to me. Using some arbitrary timer will eventually fail due to server lag(though i'd have to admit the leeway with 30 seconds is massive). I can't imagine CCP bothering to do anything like this however as its obvious they gave up fixing the issue years ago.
Robdon	Posted - 2009.09.04 11:53:00 - [46] Yep, and its probably why we get 'random' de-syncs if they are relaying on times, rather than correctly using some kind of acknowlgements.
Rakshasa Taisab Caldari Sane Industries Inc. Ethereal Dawn	Posted - 2009.09.04 12:31:00 - [47] Originally by: EmpressShiva Is there some kind of huge problem with the server communicating when transfer is complete? Doesn't seem like crazy rocket science to me. Using some arbitrary timer will eventually fail due to server lag(though i'd have to admit the leeway with 30 seconds is massive). I can't imagine CCP bothering to do anything like this however as its obvious they gave up fixing the issue years ago. In a perfect world there are no weird heisenbugs, no dropped packets, no load-spikes and fluffy pink bunnies give happy endings.
EmpressShiva	Posted - 2009.09.04 12:38:00 - [48] Originally by: Rakshasa Taisab Originally by: EmpressShiva Is there some kind of huge problem with the server communicating when transfer is complete? Doesn't seem like crazy rocket science to me. Using some arbitrary timer will eventually fail due to server lag(though i'd have to admit the leeway with 30 seconds is massive). I can't imagine CCP bothering to do anything like this however as its obvious they gave up fixing the issue years ago. In a perfect world there are no weird heisenbugs, no dropped packets, no load-spikes and fluffy pink bunnies give happy endings. Unless EVE is done in UDP, I fail to see what dropped packets has to do with the issue, and I don't think there's gonna be too many dropped packets between servers unless said server is about to drop dead, in which case I think they have greater problems. Even in said case, it's not hard to re-transmit. TCP been doing it since day one. I understand things will never be perfect, but they certainly might become superior if attended and not shoved under a rug.
Caer Nai	Posted - 2009.09.04 12:39:00 - [49] For ****s sake people. If CCP felt that they [Session timers] didn't need to be there for some reason, they wouldn't have them there. But apparently they are needed, and therefore I call /thread.
EmpressShiva	Posted - 2009.09.04 12:53:00 - [50] I'm pretty sure the game was built for the playerbase, not so CCP could make fun of us. Leaving issues like these alone because CCP 'wants' to annoy us with them is probably not a great stategy. If this was a true game-play measure I cannot comprehend, so be it. but perhaps it could use some updated mechanics, no?
Robdon	Posted - 2009.09.04 14:24:00 - [51] Originally by: Caer Nai For ****s sake people. If CCP felt that they [Session timers] didn't need to be there for some reason, they wouldn't have them there. But apparently they are needed, and therefore I call /thread. Oh they would, cause its 'easier' to put in time delays, than to actually find and understand what the problem is, and fix it correctly :) I've had to work with plenty of coders, in many places, who just could not see the way to code something well, and they just code in crap that makes it worse for the system, but they had no idea or cared enough, to code it properly.
Nyphur Pillowsoft Total Comfort	Posted - 2009.09.04 16:43:00 - [52] Edited by: Nyphur on 04/09/2009 16:43:31 Originally by: Denidil Originally by: Nyphur Originally by: Denidil informed my computer science degree holding posterior region. My computer science degree didn't come with omniscience :(. Damn, I should ask for the last five years of my life back. no, and it didn't need to. it came with this thing called "knowledge" and another thing called "understanding". specifically in this case of commonalities between all modern computing architectures. you'll notice that I did indeed call 30 seconds more than a bit overkill. I was just correcting someone talking out their posterior region because their mouth knows better. Woah, I really did get ripped off at my university, they didn't furnish me with even a fraction of the arrogance your degree came with. EVE-Tanking.com - Helping you keep your hull in-tact.
Denidil Gallente Shadowed Command Fatal Ascension	Posted - 2009.09.04 21:32:00 - [53] race conditions have a notorious tendency to abscond when you load a program in a debugger to. i agree that it should be done with a Future object and syncing and stuff, but RPCs and shared objects across network connections are not always that simple unfortunately the idea ivory tower world of university dies a swift death when the program is a game. games are complex monstrosities.
Denidil Gallente Shadowed Command Fatal Ascension	Posted - 2009.09.04 21:45:00 - [54] Originally by: Nyphur Woah, I really did get ripped off at my university, they didn't furnish me with even a fraction of the arrogance your degree came with. i was unaware that applying my knowledge and being sarcastic in reply to someone else's idiocy when they asserted that i must be omniscience because I pointed out how eve is subject to the properties of modern computing platforms is arrogance now. oh wait... people confuse "confident and unyielding because someone KNOWS they're correct and has a stack of information as proof" with arrogace. stop confusing "confidence" with "arrogance", while the later always causes the former the former is not always due to the latter.
Robdon	Posted - 2009.09.05 12:57:00 - [55] Found another timer today... There is a 5 minute timer on pressing the 'Recover Lost Probes' button :( Which is a complete pain, if you lose your probes, and forget what system it was... throught it was in my current system, but it wasnt, was the previous system. Had to wait 5 minutes before I could pick them up :(
Gunnanmon Gallente UNITED STAR SYNDICATE	Posted - 2009.09.05 13:17:00 - [56] I like the one between changing ships whilst docked. How dare we change ships too fast, Scotty. Signature locked for discussing moderation. Navigator
Xiobe GoonFleet GoonSwarm	Posted - 2009.09.05 14:22:00 - [57] Originally by: Robdon Oh they would, cause its 'easier' to put in time delays, than to actually find and understand what the problem is, and fix it correctly :) ^^^ This ^^^ The timer is arbitrary and is the dodgy wallpapering that covers the cracks of poor coding. You can throw times and success/failure statistics out as much as you like but there is no good reason for the session timer existing at all. A much better idea would be to have a session-change icon inform the user that a session change is still in progress, and when the session change is confirmed complete the icon disappears. No excess waiting and no missed data. It's done when it's done, no mistakes. If players are getting stuck at the end of the session change because something was missed, and you need to wait (an arbitrary amount of time) to let an unknown process finish, then the whole f*cking system is badly coded (and, as we know, it is). -- lose. their. they're. there. couldn't care less. lego. colour. flavour.
Ban Doga	Posted - 2009.09.05 14:46:00 - [58] How dare you say the 30 seconds delay is unnecessary?! It was the only botch available to fix the problem and since the problem was fixed for 99.99% of the cases it works very well as you can obviously see. Let me try to use an analogy so might better understand: If you don't have a screwdriver but a hammer and no nails but some screws, then using the hammer on the screws is the best solution there is. You can talk about screwdrivers or nails or glue all the way you want - you obviously were never in the situation I described above. Because then you would not talk about such nonsense. Let me repeat that for you: it is the only reasonable solution! /sarcasm
BILLYMAYS HERE	Posted - 2009.09.05 15:25:00 - [59] Originally by: Ban Doga Let me try to use an analogy so might better understand: If you don't have a screwdriver but a hammer and no nails but some screws, then using the hammer on the screws is the best solution there is. You can talk about screwdrivers or nails or glue all the way you want - you obviously were never in the situation I described above. Because then you would not talk about such nonsense. Let me repeat that for you: it is the only reasonable solution! /sarcasm They've been using a hammer on screws for a long time. When are they going to start looking for that screwdriver? I have to agree with the OP. This workaround may have been necessary at a certain time in the history of this game, but it doesn't appear to address the actual problem. There is obviously some kind of inadequacy in regards to code related to database access. A timer is just a lazy workaround, rather than actually improve performance in a way that would fix the actual problem. The ship swapping timer is only a minor inconvenience. What really annoys me are the fleet timers. I accept a fleet invite and I can't undock for 30 secs, I am moved to squad leader and I can't undock for yet another 30 seconds. There's obviously something broken here. Like when my squad is warping to a gate and the squad leader jumps though the error "You can't do that while warping" comes up. I can't do what while warping?
Xiobe GoonFleet GoonSwarm	Posted - 2009.09.06 10:09:00 - [60] bump gonna post this in the csm hall thingy -- lose. their. they're. there. couldn't care less. lego. colour. flavour.

Pages: 1 [2] 3 :: one page
First page \| Previous page \| Next page \| Last page

COPYRIGHT NOTICE
EVE Online, the EVE logo, EVE and all associated logos and designs are the intellectual property of CCP hf. All artwork, screenshots, characters, vehicles, storylines, world facts or other recognizable features of the intellectual property relating to these trademarks are likewise the intellectual property of CCP hf. EVE Online and the EVE logo are the registered trademarks of CCP hf. All rights are reserved worldwide. All other trademarks are the property of their respective owners. CCP hf. has granted permission to EVE-Search.com to use EVE Online and all associated logos and designs for promotional and information purposes on its website but does not endorse, and is not in any way affiliated with, EVE-Search.com. CCP is in no way responsible for the content on or functioning of this website, nor can it be liable for any damage arising from the use of this website.