EVE Search - TiDi

Check My IP Information

All Channels

EVE General Discussion

TiDi

» 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)
Lucas Kell Internet Terrorists SpaceMonkey's Alliance 7019	Posted - 2015.12.29 15:58:10 - [31] - Quote Remiel Pollard wrote: Don't worry, no one that's actually capable of understanding computer science is taking Lucas seriously on anything ever anyway. He's a nobody. Hide his posts, pretend he doesn't exist, and the world will become immensely better for you, I promise. So now you're even following me about to insult me? Jokes on you because that dude has no idea what he's talking about. The Indecisive Noob - EVE fan blog. Wholesale Trading - The new bulk trading mailing list.
Remiel Pollard Shock Treatment Ministries 7229	Posted - 2015.12.29 15:59:06 - [32] - Quote I just showed my brother your work Kagura, and he says you know what you're on about. He even explained a few things to me that I didn't understand in all that myself. When it comes to computers, I take my brother's word for everything because he knows better than I do. Kell could learn a lot... wait, no, actually I take that back. It's unlikely Kell ever learns anything. GÇ£Some capsuleers claim that ECM is 'dishonorable' and 'unfair'. Jam those ones first, and kill them last.GÇ¥ - Jirai 'Fatal' Laitanen, Pithum Nullifier Training Manual c. YC104
Lord Molly Mind Games. Suddenly Spaceships. 333	Posted - 2015.12.29 16:07:48 - [33] - Quote Kagura Nikon wrote: Lord Molly wrote: This video documents some real bad tidi issues If you look closely, you might also notice some glitching, such as smart bombs doing damage in warp....... All of this is caused by server node overload when to many people are in one system activating too many mod. To combat this very frustrating trait of gameplay, CCP made a jolly form that you fill in and effectively tell them there is gonig to be a big fight and etc etc, so that they may reinforce a node and divert resources to said systems node and hopefully make it all ok. Only issue is, that's not really the case is it. Have you ever been to a public event or a large pre-arranged scrap where tidi is down to 10%? where you fire a volley, then go and make dinner and come back to find you are still on the same cycle? Id be interested to hear from CCP about how they intend to improve the cancer that is TiDi. TIDi cancer? spoiled kid. before Tidi when we jumped into a large fight what happened is that you would wait between 30 minutes to 2 hours with a black screen. then 30% of people would disconnect, other 33% would load grid and be unable to use any controls of the ship. Other 13% would be able to load and press fire a single time per hour. The rest would wait another hour and try their luck again... I remember thems dark and horror-some days but i mean jita has no lag, that entire area has no lag and that has possibly the most high traffic gates in use in the EvE universe. Why can they not automatically re-allocate server resources as pilots move around. Use some sort of code whereby each pilot in space is given a value and when the combined pilot values peak over a specific figure the server automatically compensates by taking away resources from other areas. I know that in theory this does happen / CCP claim it happens but surely there is a less complicated way of doing it where it actually works out in the pilots favor. My Youtube Chan Alliance Youtube Chan
Solecist Project The Scope Gallente Federation 29072	Posted - 2015.12.29 16:14:48 - [34] - Quote Lord Molly wrote: Kagura Nikon wrote: Lord Molly wrote: This video documents some real bad tidi issues If you look closely, you might also notice some glitching, such as smart bombs doing damage in warp....... All of this is caused by server node overload when to many people are in one system activating too many mod. To combat this very frustrating trait of gameplay, CCP made a jolly form that you fill in and effectively tell them there is gonig to be a big fight and etc etc, so that they may reinforce a node and divert resources to said systems node and hopefully make it all ok. Only issue is, that's not really the case is it. Have you ever been to a public event or a large pre-arranged scrap where tidi is down to 10%? where you fire a volley, then go and make dinner and come back to find you are still on the same cycle? Id be interested to hear from CCP about how they intend to improve the cancer that is TiDi. TIDi cancer? spoiled kid. before Tidi when we jumped into a large fight what happened is that you would wait between 30 minutes to 2 hours with a black screen. then 30% of people would disconnect, other 33% would load grid and be unable to use any controls of the ship. Other 13% would be able to load and press fire a single time per hour. The rest would wait another hour and try their luck again... I remember thems dark and horror-some days but i mean jita has no lag, that entire area has no lag and that has possibly the most high traffic gates in use in the EvE universe. Why can they not automatically re-allocate server resources as pilots move around. Use some sort of code whereby each pilot in space is given a value and when the combined pilot values peak over a specific figure the server automatically compensates by taking away resources from other areas. I know that in theory this does happen / CCP claim it happens but surely there is a less complicated way of doing it where it actually works out in the pilots favor. The latest TQ devblog hints at them being able to direct resources at will ... soon ... ... thanks to virtual environments that allow to sidestep pythons problematic use of multithreading. Don't forget ... it's still python with C, or C++. Doesn't make things easier. Alex Grison > If there was a bipartisan bill supporting cannabis use for arthritic pain, it would be Joint support for Joint support for joint support
Lucas Kell Internet Terrorists SpaceMonkey's Alliance 7019	Posted - 2015.12.29 16:15:50 - [35] - Quote Kagura Nikon wrote: When you are trying to solve a problem where the concurrency is over completely independent set of data, there is no need to keep the threads on the same address space. Those cases are usually the best candidates to be offload to a completely different machine. Now that your edits are showing up, this explains some of where your confusion is coming from. It's true enough that like BIAB, some parts can be moved to a new process, but the problem is that most of the work done on the solar system service can't be offloaded to a different machine and needs to share address space. Also Rem, while your brother may have read the isolated buzz words and unconnected fragments of fact in Kagura's post, for the most part he's missed the entire problem that CCP have that means that tidi is needed. You're doing him a disservice by posting his support without full understanding of the context. The Indecisive Noob - EVE fan blog. Wholesale Trading - The new bulk trading mailing list.
Lucas Kell Internet Terrorists SpaceMonkey's Alliance 7020	Posted - 2015.12.29 16:27:20 - [36] - Quote Lord Molly wrote: I remember thems dark and horror-some days but i mean jita has no lag, that entire area has no lag and that has possibly the most high traffic gates in use in the EvE universe. Why can they not automatically re-allocate server resources as pilots move around. Use some sort of code whereby each pilot in space is given a value and when the combined pilot values peak over a specific figure the server automatically compensates by taking away resources from other areas. I know that in theory this does happen / CCP claim it happens but surely there is a less complicated way of doing it where it actually works out in the pilots favor. Depending on what you are doing you'll already be distributed over multiple services. Undocking does a lot on BIAB now, market are on a service, so is chat, etc. The problem service that causes the lag is SOL, the solar system service. This only has a finite amount of resource that can be used (up to one maxed out CPU core) at which point it's at it's limit. If they know in advance, they can make sure the target solar system is on one of the machine with really beastly CPUs, but they can't move the node with a fight already occurring as everyone will get booted. Then the best they can do is move other solar systems off of the node and crank up the processor a bit. That can go wrong though, like in the battle of Z9PP. In theory though, the new virtual environments will allow them to move or expand a running node without booting people, but we'll have to see how that works out in practice once it's all rolled out. The Indecisive Noob - EVE fan blog. Wholesale Trading - The new bulk trading mailing list.
Max Fubarticus The Scope Gallente Federation 46	Posted - 2015.12.29 16:31:07 - [37] - Quote Fancy that! I have a Masters Degree as well... Sadly it has nothing to do with computers so I guess I will keep moving along. Epeen fencing should be an Olympic sport. Just saying... Max
Lucas Kell Internet Terrorists SpaceMonkey's Alliance 7020	Posted - 2015.12.29 16:34:42 - [38] - Quote Max Fubarticus wrote: Fancy that! I have a Masters Degree as well... Sadly it has nothing to do with computers so I guess I will keep moving along. Epeen fencing should be an Olympic sport. Just saying... Max Now I'm curious... You should start a threadnaught on your chosen subject. The Indecisive Noob - EVE fan blog. Wholesale Trading - The new bulk trading mailing list.
ISD Supogo ISD Community Communications Liaisons 536	Posted - 2015.12.29 21:37:07 - [39] - Quote Removed some posts. Quote: Forum rules 4. Personal attacks are prohibited. Commonly known as flaming, personal attacks are posts that are designed to personally berate or insult another forum user. Posts of this nature are not conductive to the community spirit that CCP promotes. As such, this kind of behavior will not be tolerated. ISD Supogo Lieutenant Commander Community Communication Liaisons (CCLs) Interstellar Services Department
Pix Severus Mew Age Outpaws 1660	Posted - 2015.12.30 00:37:17 - [40] - Quote Always Shi wrote: The new TQ hardware coming in a couple of months time (plus the recent and ongoing software improvements like BitB) are all helping to make TiDi occur less often. I am so looking forward to this. My lord.

Nat Silverguard Aideron Robotics 230	Posted - 2015.12.30 03:10:48 - [41] - Quote Lykouleon wrote: Can't we just run the server in the cloud? Why don't we use the cloud more? Big Data. MapReduce. Buzzwords. My work here is done. Someone go tell HR I'm taking the week off. i understood this reference! yehey! o7 Just Add Water
ISD Buldath ISD STAR 253	Posted - 2015.12.30 05:53:19 - [42] - Quote Greetings Pilot! I would like to invite you to apply to www.ccpgames.com/jobs if you believe you are capable of creating a multi threaded experience For Tranquility that CCP could use to remove Tidi, since you believe it to be so easy. CCP Could really use your Expertise and assistance on such a grand task! ~ISD Buldath Interstellar Services Department Support, Training and Resources Division Lt. Commander
MidnightWyvern Night Theifs 123	Posted - 2015.12.30 06:00:13 - [43] - Quote ISD Buldath wrote: Greetings Pilot! I would like to invite you to apply to www.ccpgames.com/jobs if you believe you are capable of creating a multi threaded experience For Tranquility that CCP could use to remove Tidi, since you believe it to be so easy. CCP Could really use your Expertise and assistance on such a grand task! Critical Sass Levels _#portDust514 Don't let interactions like this become only a memory. (EVE alt> Sarayu Wyvern. Dust 514 alt> Mobius Wyvern.)
Lucas Kell Internet Terrorists SpaceMonkey's Alliance 7035	Posted - 2015.12.30 08:47:47 - [44] - Quote ISD Buldath wrote: Greetings Pilot! I would like to invite you to apply to www.ccpgames.com/jobs if you believe you are capable of creating a multi threaded experience For Tranquility that CCP could use to remove Tidi, since you believe it to be so easy. CCP Could really use your Expertise and assistance on such a grand task! It's funny, because I don't remember seeing anyone saying it was easy. In fact I quite distinctly remember saying the opposite. Here, I'll quote it so you don't need to find it: Lucas Kell wrote: I didn't say it was easy, but good developers don't give up because a task is difficult. Tidi isn't a real solution. The point is that Tidi is a temporary measure. Either they need to find a proper solution (for example multithreading SOL) or they need to face the fact that they can't do big battles, which is what they seem to be leaning to by nuking every aspect of the game that leads to big battles. Also I hear their pay sucks, so no thanks. The Indecisive Noob - EVE fan blog. Wholesale Trading - The new bulk trading mailing list.
Kagura Nikon Bon Jovian Drifters Did he say Jump 2130	Posted - 2015.12.30 09:13:37 - [45] - Quote Lucas Kell wrote: What I find amazing here is that you have the audacity to insult me as if I'm the one that is confusing the terminology. Perhaps you should go back and re-read the posts. You seem to have no understanding of why "parallelism" and "multi-threading" are not directly interchangeable. I call bullshit on you having a degree if you can't even work that out. Screenshot or it never happened. You are the one that made that mistake. You a re the one having the auddacity os trying to put this absurd statement in my mouth. You are the one that started saying that multi threaded is using more than one core. A Thread is the smaller fragment of a task that is subject to the task scheduler. The fact that it runs in one CPU or in another is irrelevant! A Thread can not even be running. And by definition, if you have a scheduler then you have a thread, that means you cannot have a system that is preemptive multi proccess capable (need to put the preemptive word there to avoid confusion with cooperative tasks of embedded systems) that do not have a thread. IT is pretty simple, you have a shceduler that can preempt code? then you have a thread on each proccess that is running. If you have multi proccess by DEFINITION you have multi thread on a preemptive capable system, and we are not discussing embedded systems here so preemptive scheduling is a given. If you have more than one process running in different computers (and assuming these computers are BOTH operating) then you do have a paralelism scenario! If one of these tasks end up being finsihed before the other have started is a potential result of fate and do not change the fact that you have a parallel architecture, even if in some instances of execution the 2 tasks do not really execute at the very same time (parallelism of a system or of an instance of execution are different things, but the later is almost never relevant to any discussion ) . BIAB runs in a DIFFERENT computer so it does imply in parallelism! That is not even up to discussion. I do not need to prove you my degree, that btw was not taken in an online university as you might think degrees are taken by your "screenshot" comment. I had a board of Professors convinced of my knowledge, but internet warriors might not be able to understand what real recognition and degree means. Btw my edits are mostly because English is not my mother language and when I try to type it fast I make a LOT of gramatical mistakes and end up with sentences that could clearly be improved. It is part of being educated to recognize that you made a mistake and correct it, you should try it. "If brute force does not solve your problem.... then you are surely not using enough!"
Kagura Nikon Bon Jovian Drifters Did he say Jump 2130	Posted - 2015.12.30 09:25:07 - [46] - Quote Lucas Kell wrote: Running a single-threaded process twice or running two single-threaded processes that communicate with each other does not make the processes multi-threaded. That is where you fail at basic Computer science. You have 2 process you have 2 threads because a process can be scheduled, therefore it is a thread (in some operating systems) or it has a thread (in other operating systems). The only way for a process to not be or have a thread is if you have a cooperative system or a single process operating system, but we are not discussing embedded software here. You are confusing multi threaded process with multi-threaded system/architecture. Any multi process system is by definition multithreaded, even if each of the process have only 1 thread. BIAB make the SYSTEM multi threaded (if each of their processes is single or multi thread that is not up to discussion and it is not even relevant unless you can prove me that there is strong data dependency in the continuity of their tasks, enough that inter process comunication becomes relevant. Condidering almost everything made in eve is registered in a database, eve probably already faces inter process data barriers. But if that is not already a bottleneck then BIAB being in another process will surely not be a bottleneck either. Therefore your assumption that the PROCESS need to be multithread for them to achieve high performance is based purely on speculation. Again multi thread SYSTEM and multi thread PROCESS are different things on a conceptual level (although in some scenarios might map 1:1) "If brute force does not solve your problem.... then you are surely not using enough!"
sero Hita Science and Trade Institute Caldari State 69	Posted - 2015.12.30 09:48:23 - [47] - Quote Kagura Nikon wrote: Lucas Kell wrote: Running a single-threaded process twice or running two single-threaded processes that communicate with each other does not make the processes multi-threaded. That is where you fail at basic Computer science. You have 2 process you have 2 threads because a process can be scheduled, therefore it is a thread (in some operating systems) or it has a thread (in other operating systems). The only way for a process to not be or have a thread is if you have a cooperative system or a single process operating system, but we are not discussing embedded software here. You are confusing multi threaded process with multi-threaded system/architecture. Any multi process system is by definition multithreaded, even if each of the process have only 1 thread. BIAB make the SYSTEM multi threaded (if each of their processes is single or multi thread that is not up to discussion and it is not even relevant unless you can prove me that there is strong data dependency in the continuity of their tasks, enough that inter process comunication becomes relevant. Condidering almost everything made in eve is registered in a database, eve probably already faces inter process data barriers. But if that is not already a bottleneck then BIAB being in another process will surely not be a bottleneck either. Therefore your assumption that the PROCESS need to be multithread for them to achieve high performance is based purely on speculation. Again multi thread SYSTEM and multi thread PROCESS are different things on a conceptual level (although in some scenarios might map 1:1) Why do you bother replying to him? You know he does not read what you really write and understand it. He will tell you what "you really mean", in spite of what you write and keep defending his homemade definitions, even if they do not fit to the real technical ones that are correct. Your point stands loud and clear, so if anyone comes to this thread they can decide what they find more convincing and look up the definitions themselves. Would also like to point out, one can hide messages from certain posters. Sure you can still see when they are being quoted, but overall it will reduce your blood pressure levels.
Lucas Kell Internet Terrorists SpaceMonkey's Alliance 7035	Posted - 2015.12.30 10:01:34 - [48] - Quote Kagura Nikon wrote: You are the one that made that mistake. You a re the one having the auddacity os trying to put this absurd statement in my mouth. You are the one that started saying that multi threaded is using more than one core. A Thread is the smaller fragment of a task that is subject to the task scheduler. The fact that it runs in one CPU or in another is irrelevant! Good lord man, I said none of this. All I said was that they need to multithread their solar system process. You can keep going on about splitting it out into multiple processes but since they need to share address space it's irrelevant. It's one single service in one single process that needs to operate on multiple threads. Whether it's on one CPU or multiple CPUs is irrelevant, but it still has to be one process. At the end of the day I'm not going to continue this argument with you forever. You have no idea what you are talking about and you clearly want to pretend you have some knowledge on the subject. You're probably a uni dropout or something, but I have no interest in going around in circles. In the absolute simplest terms, their SOL process needs to operate as one process on multiple threads. It really doesn't get simpler than that. Kagura Nikon wrote: I do not need to prove you my degree, that btw was not taken in an online university as you might think degrees are taken by your "screenshot" comment. Then don't prove it, I don't care. The assumption will still be that you're lying. Nobody with a degree would get this confused and riled up over such a simple statement. Kagura Nikon wrote: That is where you fail at basic Computer science. You have 2 process you have 2 threads because a process can be scheduled, therefore it is a thread (in some operating systems) or it has a thread (in other operating systems). The only way for a process to not be or have a thread is if you have a cooperative system or a single process operating system, but we are not discussing embedded software here. No, it's where you fail, since while you have two threads, they are different processes. Running two copies of a single-threaded program don't mean that you have magically muti-threaded that process. For one process to be multi threaded, multiple threads must exist withing that single process. This is where you are confusing parallelism with mutli-threading. While parallelism can be accomplished using multi-threading it's not the same thing. Kagura Nikon wrote: You are confusing multi threaded process with multi-threaded system/architecture. Any multi process system is by definition multithreaded, even if each of the process have only 1 thread. BIAB make the SYSTEM multi threaded (if each of their processes is single or multi thread that is not up to discussion and it is not even relevant unless you can prove me that there is strong data dependency in the continuity of their tasks, enough that inter process comunication becomes relevant. No, I'm not. The SYSTEM is already running in multiple processes, and BIAB is a new service process within that system. The process responsible for all of the stuff happening in a system that causes tidi is called SOL. That SOL process cannot cleanly be broken down into multiple processes, thus to make it able to operate faster than a single core can handle, it must be able to run mutliple threads within that single process. I don't know if language is the problem here, because this is basic computing, like high-school level stuff. There's no way you don't understand why a process might need multiple threads if you have a masters unless it's a masters in comparing rocks. Kagura Nikon wrote: Condidering almost everything made in eve is registered in a database, eve probably already faces inter process data barriers. But if that is not already a bottleneck then BIAB being in another process will surely not be a bottleneck either. Therefore your assumption that the PROCESS need to be multithread for them to achieve high performance is based purely on speculation. Live data such as that occurring during big battles, module activations, warps, etc, won't be stored in a database as that would be shockingly bad for performance. That will all be stored in the SOL process running that solar system. The Indecisive Noob - EVE fan blog. Wholesale Trading - The new bulk trading mailing list.
Lucas Kell Internet Terrorists SpaceMonkey's Alliance 7035	Posted - 2015.12.30 10:05:44 - [49] - Quote sero Hita wrote: Why do you bother replying to him? You know he does not read what you really write and understand it. I understand entirely what he's saying, he's just wrong. He's suggesting that the solution would be to split SOL into multiple processes, like how they split out BIAB, but he has even stated himself why that can't be done because multiple processes can't share address space (easily) and SOL would need to. The only thing I don't get is why he's freaking out so much at the concept of a single process with multiple threads. Anyone with an ounce of technical knowledge can see he's just being difficult, likely on purpose as a troll. The Indecisive Noob - EVE fan blog. Wholesale Trading - The new bulk trading mailing list.
Leila Meurtrier Why Am I Not Surprised 48	Posted - 2015.12.30 10:18:15 - [50] - Quote TiDi is temporary? What nonsense is next, short-term duct tape? Or single use tea bags?

Kagura Nikon Bon Jovian Drifters Did he say Jump 2131	Posted - 2015.12.30 10:57:13 - [51] - Quote Lucas Kell wrote: sero Hita wrote: Why do you bother replying to him? You know he does not read what you really write and understand it. I understand entirely what he's saying, he's just wrong. He's suggesting that the solution would be to split SOL into multiple processes, like how they split out BIAB, but he has even stated himself why that can't be done because multiple processes can't share address space (easily) and SOL would need to. The only thing I don't get is why he's freaking out so much at the concept of a single process with multiple threads. Anyone with an ounce of technical knowledge can see he's just being difficult, likely on purpose as a troll. No I am NOT suggesting that! Are you unable to read? I Suggested not a SINGLE thing as solution. I stated that BIAB is already an effort on paralellism. I am also refuting your premise that you NEED to make the PROCESS multithreaded to solve the problem, when you do NOT have information enough to know if the problem currently resides on the category that NEEDS that as a solution. Reading is not about inventing things in your head and deciding that it is what the other person is trying to say! Learn the basics of communication please! "If brute force does not solve your problem.... then you are surely not using enough!"
Kagura Nikon Bon Jovian Drifters Did he say Jump 2131	Posted - 2015.12.30 11:04:37 - [52] - Quote Leila Meurtrier wrote: TiDi is temporary? What nonsense is next, short-term duct tape? Or single use tea bags? you know very well that when duct tape is applied, the strings of destiny ensure it will be no other solution for as long as there is anyone that remember who was the first to put duct tape there. "If brute force does not solve your problem.... then you are surely not using enough!"
Lucas Kell Internet Terrorists SpaceMonkey's Alliance 7035	Posted - 2015.12.30 11:14:54 - [53] - Quote Kagura Nikon wrote: No I am NOT suggesting that! Are you unable to read? I Suggested not a SINGLE thing as solution. I stated that BIAB is already an effort on paralellism. I am also refuting your premise that you NEED to make the PROCESS multithreaded to solve the problem, when you do NOT have information enough to know if the problem currently resides on the category that NEEDS that as a solution. I know that BIAB is an effort on paralellism, but as you can probably tell, it's doesn't solve the issue of TIDI still being required, thus another solution is needed. And yes, the SOL process would need to be multithreaded. We know this because CCP has actually stated this. Try attending a fanfest sometime and you might have a better understanding of how the nodes are built up. The problem is that they built the processes in stackless python with no ability to be multithreaded during a time when all the focus on improving CPUs was build around doubling of speeds. When that hit a ceiling and CPUs started focussing on adding cores and parallel processing CCP have been stuck with their single threaded process so that a solar system can only make use of a single core. As most of the work done by SOL can't be split out into multiple processes like BIAB was, the solutions are: 1. Find a CPU with a much much higher clock speed. 2. Leave Tidi in place and admit defeat. 3. Thread the process to spread the load across multiple CPUs/cores. In fact, here is an old quote from CCP themselves: Quote: On the hardware side we have been somewhat hampered by the fact that the EVE server is largely a single threaded application and thus limited performance-wise by the clockrate of the CPU. In the past we-¦ve been lucky in that we have been able to rely on clockrates increasing year over year. Sadly that party is mostly over for now and the emphasis is on horizontal scaling with multiple cores. Bad news for fleet fights and olGÇÖ single threaded EVE. Kagura Nikon wrote: If I had to take a guess, I would say that very likely there is not even NEEED of more than 1 modern CPU/CORE to do what is needed in a single system regarding eve current simulation, but since I do not work on eve code I will not put that at a fact. So you assumed there is a problem based on nothing but your own conjectures, while CCP always stated that the current bottleneck is in the operations that are being passed to an external process on the form of BIAB. That's a bad guess and it underestimate just how much the server needs to do with that many people firing off commands at once. Again though, I assumed nothing. CCP stated that a sizable chunk of tidi was caused by docking/undocking/changing ships and the brain calcs that were done with it. While BIAB reduces the loads when a fleet undocks and jumps between systems, it doesn't change tidi much in a big fight, as those events are much less frequent. Kagura Nikon wrote: Reading is not about inventing things in your head and deciding that it is what the other person is trying to say! Learn the basics of communication please! It's a little difficult since the person who's text I'm reading isn't a native English speak, is raging like a lunatic, has no knowledge of what he's discussing, pretends he's got a masters, is going off topic wildy and stops every three seconds to insult me. If you slowed down a little and stopped trying to pretend you know more than you do, you'd be easier to understand. The Indecisive Noob - EVE fan blog. Wholesale Trading - The new bulk trading mailing list.
FarosWarrior De Muuzevangers 7	Posted - 2015.12.30 11:20:03 - [54] - Quote Leila Meurtrier wrote: TiDi is temporary? What nonsense is next, short-term duct tape? Or single use tea bags? Ducttape is short term? Runs off to fix everything with ducttape applied
Solecist Project The Scope Gallente Federation 29258	Posted - 2015.12.30 11:31:10 - [55] - Quote Looking at you two ... ... with Kagura being completely blind about herself ... ... fighting for "him admitting defeat" ... ... I feel reminded of something. Lucas and Kagura ... ... sitting on a tree ... ... K-I-S-S-I-N-G. Indahmawar Fazmarai wrote: The game has changed little from my point of view ... yet here I am, playing again with 3 accounts...
Ima Wreckyou The Conference Elite CODE. 1990	Posted - 2015.12.30 20:20:09 - [56] - Quote Just want to remind everyone here that if you want to show off your mad tech knowledge you need to include at least 'microservice' and 'container' into your drivel or no one will take you serious. the Code ALWAYS wins Elite PvPer, #74 in 2014
Nafensoriel KarmaFleet Goonswarm Federation 244	Posted - 2015.12.31 01:08:06 - [57] - Quote Tech knowledge isnt what is being discussed right now.. Seriously folks.. ISD just bodyslammed the topic. The only thing more epic than that is if Seagull walked in and did the exact same thing. Somehow I still thing people would come back next week and say multithreading is the fix to all the worlds coding issues. (seriously anyone else notice this trend? Ever since x64 magically multithreading is magic even though we've known its pros/cons for almost five damned decades)
Lucas Kell Internet Terrorists SpaceMonkey's Alliance 7039	Posted - 2015.12.31 08:12:17 - [58] - Quote Nafensoriel wrote: Seriously folks.. ISD just bodyslammed the topic. The only thing more epic than that is if Seagull walked in and did the exact same thing. ... Not really. He swooped in with sarcasm about something that nobody said. Nafensoriel wrote: Somehow I still thing people would come back next week and say multithreading is the fix to all the worlds coding issues. (seriously anyone else notice this trend? Ever since x64 magically multithreading is magic even though we've known its pros/cons for almost five damned decades) I don't think anyone here believe it to be a magical pill to solve all the worlds problems, but when you are overclocking a CPU so much that you have to disable cores to dissipate heat, you're still smashing the overclocked core up to 100% and you're getting lag on top of tidi because of the CPU bottleneck on your single threaded process, multithreading actually is the solution. I doubt it's going to happen though which is why CCP are just breaking up big fights which is a damn shame. The Indecisive Noob - EVE fan blog. Wholesale Trading - The new bulk trading mailing list.
RcTamiya SUPREME MATHEMATICS A Band Apart. 46	Posted - 2015.12.31 08:20:16 - [59] - Quote Nafensoriel wrote: Tech knowledge isnt what is being discussed right now.. Seriously folks.. ISD just bodyslammed the topic. The only thing more epic than that is if Seagull walked in and did the exact same thing. Somehow I still thing people would come back next week and say multithreading is the fix to all the worlds coding issues. (seriously anyone else notice this trend? Ever since x64 magically multithreading is magic even though we've known its pros/cons for almost five damned decades) But Legacy Code :O In my opinion the only real solution is to rewrite the server code, however I don't have any degrees in IT, so i might be wrong :P
Nafensoriel KarmaFleet Goonswarm Federation 245	Posted - 2015.12.31 23:08:11 - [60] - Quote Lucas Kell wrote: Nafensoriel wrote: Seriously folks.. ISD just bodyslammed the topic. The only thing more epic than that is if Seagull walked in and did the exact same thing. ... Not really. He swooped in with sarcasm about something that nobody said. Nafensoriel wrote: Somehow I still thing people would come back next week and say multithreading is the fix to all the worlds coding issues. (seriously anyone else notice this trend? Ever since x64 magically multithreading is magic even though we've known its pros/cons for almost five damned decades) I don't think anyone here believe it to be a magical pill to solve all the worlds problems, but when you are overclocking a CPU so much that you have to disable cores to dissipate heat, you're still smashing the overclocked core up to 100% and you're getting lag on top of tidi because of the CPU bottleneck on your single threaded process, multithreading actually is the solution. I doubt it's going to happen though which is why CCP are just breaking up big fights which is a damn shame. Ok. I'll bite. You've championed the need to massively rewrite EVE Online server code to take greater advantage of multithreading and parallelism. That's... Nice. Now lets break down the problem with this entire argument and what many people have tried to explain to you. You have zero idea how the server side is built. You have assumptions and devblogs where things have been publicly described but at base you know exactly zero. Why do you know zero? Because the Tranquility server is a custom built proprietary piece of hardware run by people who have been using it exclusively and tailoring every tiny scrap of physical and software assets for over a decade. You attempting to claim a magic pill that that team hasnt already thought of is on the order of a man looking at a tank and telling someone it needs a new transmission to go faster without ever having physically touched said tank. To further support your lack of knowledge(and well everyones really) consider that CCP is notoriously data crazy. They collect every bit that isnt nailed down and then dig in the sofa for more. Then they spend weeks looking at it and breaking down every aspect of it in relation to that custom designed proprietary hardware and software that is Tranquility. Also You cant claim to know how their system works by past experience. Nothing exists like tranquility. Its a one off. No one but the crazy nutballs(and we love ya) at CCP has had the raw testicular fortitude to actually build a super computer for a video game. So.. no. Your argument is utterly and pointlessly moot. It shows a lack of technical and professional understanding of what you simply cannot know. Trust me.. i have intimate knowledge with people doing this to companies and experts. I used to work on nuclear devices. Did you know that by simply mentioning that people will tell you exactly the wrong information. Apparently you can blow up the world or cause black holes and radiation automatically has a halflife of millions of years. Never mind chernobyl or fukushima or anything recent that shows the physical scientifically backed opposite. Why is this comparable to CCP? Well unless you actually work in the field.. you wont find truly accurate information on it. Same with Tranquility. Unless you physically work with it everything you say is raw conjecture and every comment you make as to its design is automatically doomed to be wrong by simple lack of information. But all that said.. if you seriously have the technical skill to build a superior tranquility(bear in mind this requires the professional understanding of not rebuilding something for exactly zero or nearly zero gain) then email CCP. Im quite sure Hilmar and Seagul would quite seriously welcome such a breakthrough considering how much of their lives theyve invested in EVE and how vested they are in its future success. They also have a track record for making huge changes when needed to support that game and this community. Considering that most other companies would just stop development and go for EVE 2.0 the simple fact that they have basically rewritten the entire game without disruption of service or loss of data should be more than enough proof of their devotion to the project.



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.