open All Channels
seplocked EVE Information Portal
blankseplocked New Dev Blog: The Long Lag
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: 1 2 3 4 [5] 6 7

Author Topic

Vincent Athena
Posted - 2010.08.18 21:50:00 - [121]
 

In my experience, a good programmer can do improvements over the built in optimizer. You want to do both the programming tricks and use the optimizer. After all, do you really think an optimizer would know that

if ( sqrt(a) > b )

can be replaced with

if ( a > b^2 )

?

paritybit
Stimulus
Rote Kapelle
Posted - 2010.08.18 22:58:00 - [122]
 

Edited by: paritybit on 18/08/2010 23:03:57
Originally by: Vincent Athena

if ( sqrt(a) > b )

can be replaced with

if ( a > b^2 )



Can it?

a = 4
b = -4

I sincerely hope my fellow engineers are smart enough not to try that optimization. But I know that the compiler won't try it.

Liang Nuren
Posted - 2010.08.18 23:42:00 - [123]
 

Originally by: Vincent Athena
In my experience, a good programmer can do improvements over the built in optimizer. You want to do both the programming tricks and use the optimizer. After all, do you really think an optimizer would know that

if ( sqrt(a) > b )

can be replaced with

if ( a > b^2 )

?


Here's some fun for you: http://ridiculousfish.com/blog/archives/2010/07/23/will-it-optimize/

-Liang

Vincent Athena
Posted - 2010.08.18 23:42:00 - [124]
 

Actually I thought of that case right after I posted. Its why the optimizer cannot make that change. But a human, who knows a and b will always be positive, can.

For example, if b is a defined positive constant and a = x^2 + y^2 + z^2, we know they are both positive, but an optimizer would not.

Tinneus Nor
Posted - 2010.08.19 00:30:00 - [125]
 

Originally by: Liang Nuren


Here's some fun for you: http://ridiculousfish.com/blog/archives/2010/07/23/will-it-optimize/

-Liang


Wow, that schooled me :)

Mirjam Starborn
Amarr
Posted - 2010.08.19 00:31:00 - [126]
 

Vincent,

do you ever find yourself looking for bugs in your code which you thought was ok?

Johnny Neutral
Posted - 2010.08.19 00:41:00 - [127]
 

Originally by: Mirjam Starborn
Vincent,

do you ever find yourself looking for bugs in your code which you thought was ok?


This. And can you find them?

Pre-optimizing your code, unless you know with certainty that it will be a bottleneck, is usually a bad idea. This is especially true when you do it in a way that obfuscates what your code is actually supposed to be doing.

I would rather have my guns delay a few milliseconds in starting rather than start immediately and do negative damage simply because the algorithm was pre-optimized.

Mirjam Starborn
Amarr
Posted - 2010.08.19 01:15:00 - [128]
 

Originally by: Vincent Athena
For example, if b is a defined positive constant and a = x^2 + y^2 + z^2, we know they are both positive, but an optimizer would not.


You first case was a non-linear comparison, however this example is a bounded linear comparison. Since the comparison is linear a direct test can be made with a and b with no lose of information (in higher speed optimization levels a complier may detect and optimize cases like these as well) which leave the question open on to why the non-linear comparison was made in the first place.

The sense moral is: in general do not bother with code optimization as it just mess things up - it is simply not worth the cost (in time, money, etc). In addition, within the next years the very same code will run at least double as fast anyway (i.e. Moore's law).

Sluggzz
Caldari
School of Applied Knowledge
Posted - 2010.08.19 01:59:00 - [129]
 

Suggestion for the jump lag problem:
* Explore improved client-server handshaking during jumps. Give it a 5 or 10 second timeout. If the client hasn't confirmed that the player's ship has "successfully jumped" then have the server kick it back to the originating system/gate.

Ideas about server side dynamic-granularity:
* Explore grid-level granularity -- i.e. allow the server to dynamically assign one gate per core, some number of planets/moons/belts per core, one station per core, etc. as load demands. Warp would potentially (necessarily?) become like a gate jump.
* So as the number of users starts to increase in a given grid, the server can start moving the unoccupied grids onto other cores.
* Alternately (using historical data for balancing a static allocation) the instanced grids, planets, belts, etc. that don't often see the high ship volume can be put on separate cores, while the high-volume gates get one core each.

While on the surface this might imply the need for a scary number of cores at first glance, dynamic granularity theoretically permits the consolidation of hundreds of systems worth of empty grids of onto single a core.

ghosttr
Amarr
ARK-CORP
Intrepid Crossing
Posted - 2010.08.19 02:08:00 - [130]
 

Is there anyway to tell if people (at least on tq) are using weapon grouping?

I seem to recall that weapon grouping had a fairly large effect on lag, but with the autorepeat bug ppl went back to manual cycling. Its not the cause of the lag (i hopeRolling Eyes), but people dropping it for cycling activations would certainly make things worse

Ban Doga
Posted - 2010.08.19 05:52:00 - [131]
 

Originally by: Vincent Athena
Another example: Lets say you have a block of code that executes only when a unlikely event happens, like 2 ships bumping, and several conditions have to be true before that code executes. You could use

If (condition1 .and. condition2 .and. condition3) then
[code]
endif

But its better to do

If (condition1) then
If (condition2 .and. condition3) then
[code]
endif
endif

because more than likely condition 1 will be false and the other conditions will not even have to be evaluated. I had one program which this single change made run 10 times faster.


Google "short-circuit evaluation".
It improved your performance because you used Fortran (assuming from your .and.)
Virtually all modern languages don't require you to distort your code that way to increase execution speed.

For the rest of the list:
You really think no one at CCP has the mathematical/theoretical background to know that a division is slower than a multiplication and that a/b is that same as a*1/b?

Schmacos tryne
Posted - 2010.08.19 06:32:00 - [132]
 

High level sux!

register magic rules!

compilers = idiot way of thinking you gotz zum good code. Check the output and you'll see!

Bomberlocks
Minmatar
CTRL-Q
Posted - 2010.08.19 07:29:00 - [133]
 

Edited by: Bomberlocks on 19/08/2010 07:33:32
Originally by: CCP Warlock
.....

Originally by: Lord Zim

Having said the obvious, I have a few questions.

1) Does SiSi have multiple nodes? I've been able to jump into systems with 500+ easily, and load grid within a minute, and I've jumped into systems with 50 (not fighting) and not loading. I've also been kept in the old system for 20-30 minutes while jumping out, while watching everyone else at the gate (hostiles and friendly) warp around and shoot eachother just fine, only to load almost instantly once I'm "out of" the old system. So my theory is that the problem may be hard to reproduce on SiSi because you're jumping from one system to the next within the same physical node, and thus not triggering the specific issue that was introduced (or worsened, I really don't care about the distinction) in Dominion. I assume this has been thought of, but I just want to throw this in there just in case it hasn't, because I remember seeing it mentioned somewhere that sisi and tq aren't quite as equal as might be desired for testing complex issues like we're looking at now.



Yes it does. SiSi isn't always completely identical to TQ, at the moment it has slightly slower hardware for example. Generally though that's an advantage, especially for work on load related issues.

The large variation in situations where this problem can occur, and also when it doesn't, is decidedly strange. There has been a lot of debate about this, and there are various theories, but no good answers at the moment at least. The within the same physical server or between servers issue has also been explored, and as far as we are aware it's not a factor. It has also been a consideration in mass test design.

....
I was very glad to see you responding to this question as it answered another something that has been puzzling me, namely the age old question of the source of the lag. From your reply above, it seems that the lag is not necessarily an artefact of player load on the server (although this exacerbates it) as, if I understand it correctly, the problem occurs even on systems that are not sharing nodes with another busier system.

From Lord Zim's post above and my own experiences, it seems the problem, from a code perspective, lies at the level of the player object's session change handling, to state what is probably obvious to you.

I'm pretty sure you've all thought of things like this before, but could Python's Garbage Collector be poking its nose into the works at the wrong time. I presume this isn't the case as it sounds more like a stalled blocking I/O operation where an operation is waiting on data from somewhere it's not receiving. And talking about I/O, would it be remiss of me to ask whether the problem has been isolated away from the database, where everything in eve comes together?

Edit: My final shot in the dark: Given that the Eve client seems to be somewhat fickle with respect to network operations, i.e. the desync operation, could it possibly be related to the client's network code, where the server process is waiting for for information that the client thought it sent but never arrived?

Lord Zim
Goonswarm Federation
Posted - 2010.08.19 07:53:00 - [134]
 

Edited by: Lord Zim on 19/08/2010 08:05:35
Originally by: CCP Warlock
We have quite a few activities going on in parallel, some of them have a longer time frame than others of course.

Of course, I was saying this more for others, I was expecting that the need to completely restructure everything to scale in a completely different way than currently (if we're to see more reliable 1000+ (or 10000+? Very Happy) fights without relying on ever-increasing processor core speeds.

Originally by: CCP Warlock
Yes it does. SiSi isn't always completely identical to TQ, at the moment it has slightly slower hardware for example. Generally though that's an advantage, especially for work on load related issues.

I agree, and if this was a timing issue (and not a direct load issue), then I would assume it should be even easier to trigger, but that's the joy of these kinds of situations, you never really know when it'll actually hit. It sucks.

Originally by: CCP Warlock
The large variation in situations where this problem can occur, and also when it doesn't, is decidedly strange. There has been a lot of debate about this, and there are various theories, but no good answers at the moment at least. The within the same physical server or between servers issue has also been explored, and as far as we are aware it's not a factor. It has also been a consideration in mass test design.

Ok. I was hoping against hope that it would just be that simple, but I was (as I said) expecting that it had been thought of and tested.

I have to say, though, that it's been a very frustrating last 8 months, especially as it seemed to be such an abrupt change from pre- to post-dominion with the session change problem. It really was like night and day, so it was extremely frustrating when there was literally no information forthcoming from you guys on what seemed like an easily reproducible situation (to us anyways Laughing).

Devblogs like this is shedding light onto what the problem looks like on your end, and it gives me at least a slimmer of hope that it's actually being thought of as a serious problem (and being worked on). Thanks for that.

Quick ninjaedit: I have to say I agree with bomberlocks, to me it seemed like it was some sort of lock somewhere that seems to sometimes unlock itself, but with the resource graphs provided in another devblog, I'm no longer so sure. Not that the CPU usage explains how one side can easily literally give the fleet jumping in "surprise sex" while the fleet jumping in can't do squat, since I would've expected that both sides would be equally helpless/toothless if it really was a case of CPU starvation.

But silly question time again (I just thought of it after reading the automatron devblog), is it possible for the automatrons to be used to compare the apocrypha code to the dominion/tyrannis code? I'm really curious as to the differences between the two versions in these specific scenarios (not just during normal operations where there's not much fighting going on).

Wolfcheck
The Ice Cartel
Posted - 2010.08.19 08:11:00 - [135]
 

Originally by: Nareg Maxence
Originally by: Vincent Athena
I have been writing programs for decades, and over that time have learned several tricks to getting code to run faster. Many of these are specific to the task the program is doing, but some are more general. They tend to be methods that modify one or a couple of lines of code. I wonder how much effort CCP puts into this sort of tuning of the code in its quest for speed.


A decent compiler should be able to optimize those code examples to the point where there is no difference in execution speed.


I've been writing code for decades as well... and that's exactly the point ;)
When you've grown up with the speed vs memory optimization, and trained by writing assembler codes into C snippets to make some operations go faster... you're cursed.
You'll always think that...

return (C > 2);

is better than...

if (C > 2) return true;
else return false;


;)

CCP Warlock

Posted - 2010.08.19 14:20:00 - [136]
 

Originally by: Bomberlocks
Edited by: Bomberlocks on 19/08/2010 07:33:32
Originally by: CCP Warlock
.....
The large variation in situations where this problem can occur, and also when it doesn't, is decidedly strange. There has been a lot of debate about this, and there are various theories, but no good answers at the moment at least. The within the same physical server or between servers issue has also been explored, and as far as we are aware it's not a factor. It has also been a consideration in mass test design.

....
I was very glad to see you responding to this question as it answered another something that has been puzzling me, namely the age old question of the source of the lag. From your reply above, it seems that the lag is not necessarily an artefact of player load on the server (although this exacerbates it) as, if I understand it correctly, the problem occurs even on systems that are not sharing nodes with another busier system.


Personally I have only experienced this jumping into fleet fights, and there has been a general assumption that when it does happen in an empty system it's because there is a fleet flight somewhere else on that server.

But there have been a few too many players on the forums saying they've seen this jumping into lightly loaded systems for my spider sense to be entirely happy with that explanation these days. One thing we all learn when troubleshooting these kinds of problems is to keep a very open mind about the possibilities.
Originally by: Bomberlocks

From Lord Zim's post above and my own experiences, it seems the problem, from a code perspective, lies at the level of the player object's session change handling, to state what is probably obvious to you.

I'm pretty sure you've all thought of things like this before, but could Python's Garbage Collector be poking its nose into the works at the wrong time. I presume this isn't the case as it sounds more like a stalled blocking I/O operation where an operation is waiting on data from somewhere it's not receiving. And talking about I/O, would it be remiss of me to ask whether the problem has been isolated away from the database, where everything in eve comes together?

Edit: My final shot in the dark: Given that the Eve client seems to be somewhat fickle with respect to network operations, i.e. the desync operation, could it possibly be related to the client's network code, where the server process is waiting for for information that the client thought it sent but never arrived?




CCP Porkbelly took a very close look at the Garbage collection as a result of this, that was one of the initial suspicions. He also sorted out the DB problems connection problems that were introduced with Dominion, which we thought for a brief period were the sole source of this. Part of the general nastiness with this problem is that essentially this is a symptom, with a lot of potential causes, and we certainly haven't ruled out that it is more than one thing. In my personal experience the worst bugs are often a couple of issues working together, and that can be really nasty to track down.

The distributed messaging, tasklet management and locking systems in EVE are where a lot of our suspicions are currently focused, but this is fairly deep "cluster os" level stuff, where you really have to think very hard indeed about what's going in with the various interactions.

Trebor Whettam
Posted - 2010.08.19 15:16:00 - [137]
 

Edited by: Trebor Whettam on 19/08/2010 15:17:31
Originally by: Liang Nuren
Originally by: Vincent Athena
In my experience, a good programmer can do improvements over the built in optimizer. You want to do both the programming tricks and use the optimizer. After all, do you really think an optimizer would know that

if ( sqrt(a) > b )

can be replaced with

if ( a > b^2 )

?


Here's some fun for you: http://ridiculousfish.com/blog/archives/2010/07/23/will-it-optimize/

-Liang


I'm super impressed that GCC can optimize out superficially non-tail recursion. Since I write 95% of my code in either Haskell or ML-family languages, I have a natural affinity for that sort of thing.

IMO, the only time you should do early optimization is if it's an algorithmic optimization (which is often more of a redesign). Otherwise the goal should be simplicity and correctness until much later when you can demonstrate that there is a bottleneck. And save the bit-tweaking for the innerest inner loops.

Vincent Athena
Posted - 2010.08.19 17:52:00 - [138]
 

Do I look for or introduce bugs into my code? Of course, any time you touch code you run the risk of adding a bug. But I also make bugs when I clean up clumsy code to make it more readable and understandable. At least when making changes for speed those changes are done to code that runs alot, so the bugs are found right away.

Is is worth it? I sure think so. One of my codes had to be batch run about a million times, and if I had not dripped blood over it speeding it up over the past years the task would not have gotten done on time. "Never enough time to do it right, always enough time to do it over". I find its better to find the time to do it right, and make it fast, because you will be doing it over and over and over.

Do other programmers know about and do coding for speed? Given the performance of most of the applications I have, I would say no, they do not. They seem to have the attitude that they do not need to code for speed, because next year's computer will make it fast. I prefer the Air force attitude: Speed is Life.

How about CCP? I don't know! They have not said.

Bomberlocks
Minmatar
CTRL-Q
Posted - 2010.08.19 17:54:00 - [139]
 

Originally by: CCP Warlock
....
Personally I have only experienced this jumping into fleet fights, and there has been a general assumption that when it does happen in an empty system it's because there is a fleet flight somewhere else on that server.

But there have been a few too many players on the forums saying they've seen this jumping into lightly loaded systems for my spider sense to be entirely happy with that explanation these days. One thing we all learn when troubleshooting these kinds of problems is to keep a very open mind about the possibilities.


I think you'll possibly have more luck on this front when the automated headless client can roam systems on both TQ and Sisi and possibly have the ability to raise a flag when it happens to them, depending on the level of customisation possible. The flag could possibly trigger a server side logging routine to to isolate the system, time, node, other nearby lagged systems etc.
Originally by: CCP Warlock

CCP Porkbelly took a very close look at the Garbage collection as a result of this, that was one of the initial suspicions. He also sorted out the DB problems connection problems that were introduced with Dominion, which we thought for a brief period were the sole source of this. Part of the general nastiness with this problem is that essentially this is a symptom, with a lot of potential causes, and we certainly haven't ruled out that it is more than one thing. In my personal experience the worst bugs are often a couple of issues working together, and that can be really nasty to track down.

The distributed messaging, tasklet management and locking systems in EVE are where a lot of our suspicions are currently focused, but this is fairly deep "cluster os" level stuff, where you really have to think very hard indeed about what's going in with the various interactions.

I certainly don't envy you in having to dig around at that level, but I agree that a small bug at that level (locks, race conditions due to network, I/O or memory latency), combined with small but significant increases in resource usage elsewhere, could be a very likely cause.

Thanks again for taking the time to answer my questions, it's been enormously interesting, and I personally am satisfied that CCP as a whole is working extremely hard on this problem and that you will find the source eventually.

Good luck and keep us posted!

CCP Warlock

Posted - 2010.08.19 19:15:00 - [140]
 

Originally by: Vincent Athena
<snip>

Do other programmers know about and do coding for speed? Given the performance of most of the applications I have, I would say no, they do not. They seem to have the attitude that they do not need to code for speed, because next year's computer will make it fast. I prefer the Air force attitude: Speed is Life.

How about CCP? I don't know! They have not said.


Personally I love the optimization stuff - Programming Pearls by Bentley is one of my favourite books. One of the many fun things about working for CCP is having so many other Dev's to talk with, and also throw the sort of things that have been discussed here around. Those old Fortran examples brought back some fond memories.

Generally we optimize at all levels. We also pay a lot of attention to making sure that the empirical evidence supports the perceived benefit - otherwise it's easy to spend a lot of time optimizing the 0.001% code path. Algorithmic performance is also very important in these kinds of applications. My favourite quote at the Para conference was one of the meteorologists discussing the problems caused by needing "peta-scale memory" if your peta-scale computing setup was trying to store entries from each node (*sigh*). What was also quite interesting from his talk, was that if his figures were correct, most of the improvements in meteorological modeling performance over the last decade were due to improved hardware. Which certainly makes me hope, since we're about at the limit of simple processor CPU speed up's, that code and algorithmic optimization is about to enjoy a bit of a resurgence.

Liang Nuren
Posted - 2010.08.19 20:12:00 - [141]
 

Edited by: Liang Nuren on 19/08/2010 20:13:00
Originally by: Vincent Athena

Do other programmers know about and do coding for speed? Given the performance of most of the applications I have, I would say no, they do not. They seem to have the attitude that they do not need to code for speed, because next year's computer will make it fast. I prefer the Air force attitude: Speed is Life.



You're incredibly naive if you think that we don't also look at these things. The difference is that we're inclined to write code that is reasonable and then look and see where the bottlenecks are. Spending 3 weeks optimizing CPU usage on a 99% IO bound program is a bit of a waste in most cases - and there's absolutely nothing wrong with saying that you'd rather spend $5k on another machine to throw in your cloud than pay a team of 5 developers for 6 weeks to optimize your code.

And before you tell me I don't know how to scale and program for speed... I do. It's actually my bailiwick. I just don't do it uselessly because its far too easy to write code that's simply unmaintainable. ;-)

-Liang

Ed: I like the way Warlock said it really. Optimizing the 0.001% path is silly... and I too hope we'll see the resurgence of focus on algorithm. ;-)

Lord Zim
Goonswarm Federation
Posted - 2010.08.19 22:02:00 - [142]
 

Originally by: CCP Warlock
Personally I have only experienced this jumping into fleet fights, and there has been a general assumption that when it does happen in an empty system it's because there is a fleet flight somewhere else on that server.

But there have been a few too many players on the forums saying they've seen this jumping into lightly loaded systems for my spider sense to be entirely happy with that explanation these days. One thing we all learn when troubleshooting these kinds of problems is to keep a very open mind about the possibilities.

Just to reinforce this, I just logged two chars in more or less at the same time. This char into N-TFXK, and my other char into another system. The other char loaded just fine, whereas this char just hung on the entry. I could see that this char was "in" (i.e. it was visible in channels), but it just wouldn't go that final step. I closed the client and relogged in, and it loaded station within literally 15 seconds tops.

I definitely doubt that the CPU usage across the entire node was reduced that drastically in the 3 minutes this transpired, so you guys definitely have a non-fun problem to find. I don't really envy you.

Hamish Nuwen
Gallente
Escuadron Federal de Asalto
Posted - 2010.08.19 22:57:00 - [143]
 

Originally by: Venkul Mul
Define combat for you "suggestions". Have you considered some scenario like: [...]

The user explicity activates/deactivates the combat mode. The idea is to only use it in large scale fleet battles, to try to reduce the lag issues.

Newo Snave
Posted - 2010.08.20 00:20:00 - [144]
 

Originally by: Hamish Nuwen
Originally by: Venkul Mul
Define combat for you "suggestions". Have you considered some scenario like: [...]

The user explicity activates/deactivates the combat mode. The idea is to only use it in large scale fleet battles, to try to reduce the lag issues.


Combat = red blinky on grid

marcel72
Posted - 2010.08.20 07:26:00 - [145]
 

Originally by: Newo Snave
Combat = red blinky on grid


Nah, that's too prone to DOS attacks... just keep flying small, fast ships in an enemy's systems to prevent him from doing anything with the market or contracts.

Haral Heisto
Posted - 2010.08.20 11:26:00 - [146]
 

Originally by: CCP Warlock

Personally I have only experienced this jumping into fleet fights, and there has been a general assumption that when it does happen in an empty system it's because there is a fleet flight somewhere else on that server.

But there have been a few too many players on the forums saying they've seen this jumping into lightly loaded systems for my spider sense to be entirely happy with that explanation these days. One thing we all learn when troubleshooting these kinds of problems is to keep a very open mind about the possibilities.


I've seen this a couple of times, and it seems to hang around a good few hours when you get a troublesome system. Is there a way to get one of you on the batphone when we do see a lagged out empty system? Raising a petition with the GMs mostly just gets session cleared and a move which is helpful for the immediate problem of getting stuck on jump-in, but masks the true problem in the system.

Last time I saw it was a month or so back, our 6 man roaming gang passed through a system with one blue ratting. We all had jump-in lag for a couple of minutes, but carried on and assumed it was just a temporary thing as it passed when we moved on. A few hours later, we passed back through and had the same lag problem, with two of us getting completely stuck for nearly half an hour.

A quick convo to the ratter showed he had been in the system the whole time, but was only seeing a few seconds of module activation lag.

There had been no fleet battles in the region during this whole time.

CCP GingerDude

Posted - 2010.08.20 13:40:00 - [147]
 

Originally by: Haral Heisto

I've seen this a couple of times, and it seems to hang around a good few hours when you get a troublesome system. Is there a way to get one of you on the batphone when we do see a lagged out empty system? Raising a petition with the GMs mostly just gets session cleared and a move which is helpful for the immediate problem of getting stuck on jump-in, but masks the true problem in the system.

Last time I saw it was a month or so back, our 6 man roaming gang passed through a system with one blue ratting. We all had jump-in lag for a couple of minutes, but carried on and assumed it was just a temporary thing as it passed when we moved on. A few hours later, we passed back through and had the same lag problem, with two of us getting completely stuck for nearly half an hour.

A quick convo to the ratter showed he had been in the system the whole time, but was only seeing a few seconds of module activation lag.

There had been no fleet battles in the region during this whole time.


If the lone ratter was experiencing module lag, then that strongly indicates that the node was heavily loaded running stuff other than that particular system.

Can you dig up specifics, i.e. which system it was and the date?

Haral Heisto
Posted - 2010.08.20 14:04:00 - [148]
 

Originally by: CCP GingerDude
Originally by: Haral Heisto

I've seen this a couple of times, and it seems to hang around a good few hours when you get a troublesome system. Is there a way to get one of you on the batphone when we do see a lagged out empty system? Raising a petition with the GMs mostly just gets session cleared and a move which is helpful for the immediate problem of getting stuck on jump-in, but masks the true problem in the system.

Last time I saw it was a month or so back, our 6 man roaming gang passed through a system with one blue ratting. We all had jump-in lag for a couple of minutes, but carried on and assumed it was just a temporary thing as it passed when we moved on. A few hours later, we passed back through and had the same lag problem, with two of us getting completely stuck for nearly half an hour.

A quick convo to the ratter showed he had been in the system the whole time, but was only seeing a few seconds of module activation lag.

There had been no fleet battles in the region during this whole time.


If the lone ratter was experiencing module lag, then that strongly indicates that the node was heavily loaded running stuff other than that particular system.

Can you dig up specifics, i.e. which system it was and the date?


I can do you one better. I had to be GM moved, which was petition 2024657. There's full system, time and date info in there. This was raised on the return trip, so the lag was for at least 2 hours preceding the petition.

Yeay Fritg
Caldari
Confrerie de Kaedri
Cluster Of Rebirth
Posted - 2010.08.20 14:51:00 - [149]
 

New Lag Detected !

Now Eve Gate is Lagging too !

Yeay

horace bagpole
Posted - 2010.08.20 17:13:00 - [150]
 

Originally by: CCP Warlock
My favourite quote at the Para conference was one of the meteorologists discussing the problems caused by needing "peta-scale memory" if your peta-scale computing setup was trying to store entries from each node (*sigh*). What was also quite interesting from his talk, was that if his figures were correct, most of the improvements in meteorological modeling performance over the last decade were due to improved hardware. Which certainly makes me hope, since we're about at the limit of simple processor CPU speed up's, that code and algorithmic optimization is about to enjoy a bit of a resurgence.


Is eve ever likely to benefit from GPU computing? It seems that it provides immense performance boosts for particular problems (n-body physics calculations for example), and I was wondering if the physics simulation that runs eve lends itself to running on a GPU?


Pages: 1 2 3 4 [5] 6 7

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