These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Issues, Workarounds & Localization

 
  • Topic is locked indefinitely.
12Next page
 

EVE Client Freeze?

Author
Meditril
Minmatar Secret Service
Ushra'Khan
#1 - 2013-07-20 09:02:54 UTC  |  Edited by: Meditril
Hey guys,

is anybody else experiencing a regular freeze of the EVE client? I have now lost severl ships due to the client is freezing in mid fight. Interestingly this seems only to happen when I am in mid fight. As far as I observed this tend to happen sometimes, when I am zoomed in on my ship and then new enemies (PVP) appear on the grid.

Anybody else observed something like this? Any solutions for this issue? It is very annoying.

Thx,
Meditril

EDIT: After some longer investigations the CCP ticketing team and me came to the conclusion that it was an memory issue. Once I removed the broken memory bank the issue was solved. Interestingly memtest did not found this memory issue. So it was probably a very rare bit-flip.
Aetourus
DEVGRU-M
#2 - 2013-07-22 05:50:09 UTC
You are not alone! Just do a search on "freeze" and you'll find many people with the same problem.
Meditril
Minmatar Secret Service
Ushra'Khan
#3 - 2013-07-22 13:03:56 UTC
I supposed this. Unfortunatelly still no feedback from CCP.
seth Hendar
I love you miners
#4 - 2013-07-22 14:15:29 UTC  |  Edited by: seth Hendar
confirming that sometimes, for no apparent reason, the game will have micro freeze of 1- 2 sec, and when this happens, it occurs every 10 sec or so, no specific action ingame related.

alsoi check my computer, and nothing seems wrong, CPU usage, RAM (globa and game), GPU, T°

also checked my connections, they are OK, donne a tracert / ping to CCP server, nothing abnormal.

restarting game with cache clearing sometime solve the issue, sometime doesn't.

but when it appears, it is on my 3 account, wich runs under 2 different computer, with 2 different internet access

first comp: i7 2600k 4.2Ghz / 16Gb Ram / GTX670 o/c + 560 ti (physx) / SSD

2nd comp is a MSI GE60-20E (i7 4700MQ / GTX 765M / 8GB RAM)

both system running win 7 ultimate 64 Bits, all drivers updated non beta, all windows update, connection is Ethernet cable

this also happen to occur even with 1 account running, whatever the computer and even if i'm not home (meaning i use again another connection).

this occurs way more often on weekends (does the server have load issues?)
Aetourus
DEVGRU-M
#5 - 2013-07-22 15:03:27 UTC
Hi seth,

The micro-freezes may or may not be related. The most likely cause of that from the symptoms I've read is a "memory leak"--the game requests memory from the computer to do something, but doesn't give it back when it's done. Eventually you run out of available memory, which forces the runtime environment to pause and try to forcefully free up some memory before it can continue. Even though this is still the most likely cause, you have to try really hard these days to write code that bad, because lint tools will normally find these problems long before they reach production.

The second but less likely scenario is a graphics issue, which I suspect is the cause of the permanent freezes. As a background, graphics drivers are universally *really* crappy code. The driver manufacturers write lots of horrible, kludgy, "special case" code on purpose to squeeze as much performance out of the graphics cards as possible--but this causes *lots* of bugs. The hardware manufacturers recognize this, and often incorporate a feature where if the card detects a lockup, it will try to do a reset of the card to get things going again.

That second choice is not likely because the reset is very hit or miss, and according to the reports the game will always eventually get going again.
seth Hendar
I love you miners
#6 - 2013-07-23 07:47:34 UTC  |  Edited by: seth Hendar
Aetourus wrote:
Hi seth,

The micro-freezes may or may not be related. The most likely cause of that from the symptoms I've read is a "memory leak"--the game requests memory from the computer to do something, but doesn't give it back when it's done. Eventually you run out of available memory, which forces the runtime environment to pause and try to forcefully free up some memory before it can continue. Even though this is still the most likely cause, you have to try really hard these days to write code that bad, because lint tools will normally find these problems long before they reach production.

The second but less likely scenario is a graphics issue, which I suspect is the cause of the permanent freezes. As a background, graphics drivers are universally *really* crappy code. The driver manufacturers write lots of horrible, kludgy, "special case" code on purpose to squeeze as much performance out of the graphics cards as possible--but this causes *lots* of bugs. The hardware manufacturers recognize this, and often incorporate a feature where if the card detects a lockup, it will try to do a reset of the card to get things going again.

That second choice is not likely because the reset is very hit or miss, and according to the reports the game will always eventually get going again.

please read my post, no memory leak involved, i check RAM status, both the global amount, and the amount dedicated to each client / process.

plus this occurs mainly during peak hours, especially on weekend........

also, this happen both on a laptop and desktop, with 2 different version of drivers, AND i tested both old and new drivers, with no luck.

this was not occuring at all a few week (2-3) ago, and only eve is causing this, no issue on any other game, wich are for some of them way more heavy on the comp.

this make me feel like it is related to server unable to keep up, same as other online game when server is under heavy load.

this is not new that many event fail to register since a few month during peak hours, with fleet orders receive by only part of the fleet, incredible time to jump / dock etc....

those where the first symptoms, and now we have micro freeze, and this is not only on my side, since when it occurs, corpmate report them too, at the same time.

some are EU, other US / canada, and even one is from ASIA, and yesterday night, we had one of those "freeze" session, and we had it for all of us....
clearly no way this is client side issue
Deathoria
Imperial World Development
#7 - 2013-07-23 16:06:30 UTC
I have been having the same problem for a few weeks, sometimes the client runs no problem, sometimes it freezes after 5-10 minutes and sometimes it freezes instantly after the character selection. I have reinstalled and updated all my drivers and i tried installing eve on a separate harddrive, but none of this seems to affect the problem.
Aetourus
DEVGRU-M
#8 - 2013-07-25 17:22:06 UTC  |  Edited by: Aetourus
seth Hendar wrote:

please read my post, no memory leak involved, i check RAM status, both the global amount, and the amount dedicated to each client / process.


Yep, I read your post. I oversimplified a bit in my previous post for the benefit of any of the more neophyte computer users reading this thread, and you were astute enough to catch the inconsistency. :)

Eve runs in it's own "runtime environment", and the way that most runtime environments work is that they request a chunk of memory from the OS "up front" to be used as their own "personal memory" (called a "heap" in developer speak). For example (I'm making up numbers), an Eve client may request 256MB from the OS when it starts up for its own internal heap. When the game "runs out of memory" and needs to free some up, it's really just running out of that 256MB of memory it grabbed for this purpose. In other words, you could have a thousand gigabytes of memory in your computer and it wouldn't make a difference, since the game only requested 256GB for its own memory.

What this means is that this type of memory leak isn't really reflected in any RAM status that you can see, since that will just show the client allocating whatever RAM the software and static data needs, plus that 256MB heap. This also means that the memory management tool mentioned in another thread absolutely could not work, and if it appears to help anyone it's just a coincidence. You would need a "heap walker" tool specific to whatever runtime environment the Eve client uses.

Things get even more complicated because IIRC Eve on the Mac uses Cider, which is a compatibility layer which allows what's effectively the same software that runs on Windows to run on the Mac. I'm not even going to get into that.

That brings us back to what I said previously: it's still most likely a memory leak, but It's possible that you're right and it's actually a network traffic issue. The reason I think that possibility is less likely is because from other users' accounts of the micro freeze, the time of day doesn't seem to have any bearing. The only thing that seems to matter is how long the client has been running.
seth Hendar
I love you miners
#9 - 2013-07-25 17:45:11 UTC  |  Edited by: seth Hendar
Aetourus wrote:
seth Hendar wrote:

please read my post, no memory leak involved, i check RAM status, both the global amount, and the amount dedicated to each client / process.


Yep, I read your post. I oversimplified a bit in my previous post for the benefit of any of the more neophyte computer users reading this thread, and you were astute enough to catch the inconsistency. :)

Eve runs in it's own "runtime environment", and the way that most runtime environments work is that they request a chunk of memory from the OS "up front" to be used as their own "personal memory" (called a "heap" in developer speak). For example (I'm making up numbers), an Eve client may request 256MB from the OS when it starts up for its own internal heap. When the game "runs out of memory" and needs to free some up, it's really just running out of that 256MB of memory it grabbed for this purpose. In other words, you could have a thousand gigabytes of memory in your computer and it wouldn't make a difference, since the game only requested 256GB for its own memory.

What this means is that this type of memory leak isn't really reflected in any RAM status that you can see, since that will just show the client allocating whatever RAM the software and static data needs, plus that 256MB heap. This also means that the memory management tool mentioned in another thread absolutely could not work, and if it appears to help anyone it's just a coincidence. You would need a "heap walker" tool specific to whatever runtime environment the Eve client uses.

Things get even more complicated because IIRC Eve on the Mac uses Cider, which is a compatibility layer which allows what's effectively the same software that runs on Windows to run on the Mac. I'm not even going to get into that.

That brings us back to what I said previously: it's still most likely a memory leak, but It's possible that you're right and it's actually a network traffic issue. The reason I think that possibility is less likely is because from other users' accounts of the micro freeze, the time of day doesn't seem to have any bearing. The only thing that seems to matter is how long the client has been running.

i'll quote myself, i know it's bad but:

Quote:
some [corpmates] are EU, other US / canada, and even one is from ASIA, and yesterday night, we had one of those "freeze" session, and we had it for all of us....
clearly no way this is client side issue

how can then it be a memory leak? or even a client side issue? clearly not.

also, eve is written in pyhton, and, on a quick note:

Quote:
Memory management in Python involves a private heap containing all Python objects and data structures. The management of this private heap is ensured internally by the Python memory manager. The Python memory manager has different components which deal with various dynamic storage management aspects, like sharing, segmentation, preallocation or caching.

At the lowest level, a raw memory allocator ensures that there is enough room in the private heap for storing all Python-related data by interacting with the memory manager of the operating system. On top of the raw memory allocator, several object-specific allocators operate on the same heap and implement distinct memory management policies adapted to the peculiarities of every object type. For example, integer objects are managed differently within the heap than strings, tuples or dictionaries because integers imply different storage requirements and speed/space tradeoffs. The Python memory manager thus delegates some of the work to the object-specific allocators, but ensures that the latter operate within the bounds of the private heap.

It is important to understand that the management of the Python heap is performed by the interpreter itself and that the user has no control over it, even if she regularly manipulates object pointers to memory blocks inside that heap. The allocation of heap space for Python objects and other internal buffers is performed on demand by the Python memory manager
Aetourus
DEVGRU-M
#10 - 2013-07-25 17:57:41 UTC  |  Edited by: Aetourus
Hi Seth,

That sounds more like lag, which is a very different issue from the lockups which is what this thread is about or the micro-freezes which is what I originally thought you were referring to.

That jargon-filled paragraph on Python basically says what I said--Python is a computer language, but it also provides the runtime environment I was referring to. Specifically, it reinforces that you can't rule out memory leaks simply by looking at how much memory Eve is taking up.
seth Hendar
I love you miners
#11 - 2013-07-26 08:06:02 UTC
Aetourus wrote:
Hi Seth,

That sounds more like lag, which is a very different issue from the lockups which is what this thread is about or the micro-freezes which is what I originally thought you were referring to.

That jargon-filled paragraph on Python basically says what I said--Python is a computer language, but it also provides the runtime environment I was referring to. Specifically, it reinforces that you can't rule out memory leaks simply by looking at how much memory Eve is taking up.

i do now what lag looks like, it delays, rebberband, and in some case, CAN lead to micro freeze like this.

and yes, we are talking about the same thing, the whole gui + environnment is frozen for 1- 2seconde, and when it happen, it is several time in a row (sometime every 10-15 second).

and this happen at the SAME time, to almost all my corpmember when we are all so far apart?

we managed to sync memory leaks? let's patent it fast cause we are on something....
Aetourus
DEVGRU-M
#12 - 2013-07-26 12:43:02 UTC  |  Edited by: Aetourus
NO--what you are describing are MICRO freezes, where the game doesn't actually freeze but just appears to do so for a few seconds. This thread is about ACTUAL freezes, where the game locks up permanently and either the game or the computer needs to be restarted. There are plenty of threads discussing the micro-freeze issue without hijacking this one.

And as I said, the micro freezes are likely a memory leak--you can take my word on that.
seth Hendar
I love you miners
#13 - 2013-07-27 00:14:13 UTC  |  Edited by: seth Hendar
Aetourus wrote:
NO--what you are describing are MICRO freezes, where the game doesn't actually freeze but just appears to do so for a few seconds. This thread is about ACTUAL freezes, where the game locks up permanently and either the game or the computer needs to be restarted. There are plenty of threads discussing the micro-freeze issue without hijacking this one.

And as I said, the micro freezes are likely a memory leak--you can take my word on that.

so i think CCP should patent the mechanic, cause having effect of memory leak in sync all over the world, badass!

also, i missed the fact this was about Freeze and not micro freeze, my bad.

regarding your issue, doeas windows pop a message about recovering drivers?

if yes, check if a bios update is available for your graphic card, i used to have this issue a few month ago, and it happened that the gpu vcore was wrong, and an update was available, fixing the issue.

this tend to happen pretty often with cards using non-ref design, or using factory O/C (known issue on some 560 ti o/c, 670 o/c).

and indeed, before that, check the regular, latest non beta drivers, t°, fan, dust etc...
Aetourus
DEVGRU-M
#14 - 2013-07-28 18:16:50 UTC
I'm not using Windows, and modern computers generally don't use BIOS anymore. If you meant a UEFI or card firmware update, I have the most recent updates. However, since the freeze problem is pervasive and seems to affect many different systems I imagine that's not the issue.
seth Hendar
I love you miners
#15 - 2013-07-29 15:02:09 UTC
Aetourus wrote:
I'm not using Windows, and modern computers generally don't use BIOS anymore. If you meant a UEFI or card firmware update, I have the most recent updates. However, since the freeze problem is pervasive and seems to affect many different systems I imagine that's not the issue.

1- i'm talking about the graphic card BIOS, not the mainboard, it doesn't matter weither the mainboard is BIOS or EFI, the graphic card still have it's own BIOS.
also, while some manufaturr provide windows utility to update said bios, i'll always prefer to do it using a boot device (CD or USB), this allow to update it regardless of the OS you are using

2- the solution i gave could, at least, solve the issue for some ppl, and trust me when i tell you that many many cards are facing such issues (i do work for a graphic card manufacturer, so i know what i'm talking about), it might not be the ultimate solution, but it is always worth trying this one at least
Aetourus
DEVGRU-M
#16 - 2013-07-31 07:25:26 UTC
There's no such thing as graphics card BIOS. BIOS stands for Basic Input Output Subsystem, and was the old way computers dealt with hardware, including graphics cards. Graphics cards may have firmware, but they have *never ever* had their own BIOS. You may work for a graphics card manufacturer, but I've been a software engineer for over 20 years and if I do say so myself I'm considered one of the better ones. But we're getting way off topic here, so no matter what crazy thing you say next I'll pretend it's right if it will help you move on... :P
seth Hendar
I love you miners
#17 - 2013-07-31 08:59:39 UTC
Aetourus wrote:
There's no such thing as graphics card BIOS. BIOS stands for Basic Input Output Subsystem, and was the old way computers dealt with hardware, including graphics cards. Graphics cards may have firmware, but they have *never ever* had their own BIOS. You may work for a graphics card manufacturer, but I've been a software engineer for over 20 years and if I do say so myself I'm considered one of the better ones. But we're getting way off topic here, so no matter what crazy thing you say next I'll pretend it's right if it will help you move on... :P

well you might be a poor engineer for not knowing this, or maybe i am for being a gpu bios dev since tnt2 reached the market (and have been up to recently, for the nvidia 8800 series).....

in fact, GPU BIOS are here since EGA (then VGA) exist, if memory serves it's since 1983 or 1984.....

see, pretty sure a über dev for 20+ years can still learn somthing sometimes :)


and back on topic, i posted this to atually HELP ppl, so bitching at me by showing your ignorance doesn't help, just sayin'
Aetourus
DEVGRU-M
#18 - 2013-08-01 16:11:31 UTC  |  Edited by: Aetourus
No, you're clearly not a GPU BIOS dev. You're clearly someone who thinks he's smart enough to BS his way through a conversation but is not smart enough to recognize when someone has intimate knowledge of the field and would recognize BS for what it is. I know you're not a GPU BIOS dev (or any kind of developer) because:

  • there's no such thing as GPU BIOS
  • if it existed, that field would be far too narrow for anyone except a couple of people to make a living at it
  • you would have said so in your previous post instead of vaguely saying you work for a graphic card manufacturer
  • you would not work for a graphic card manufacturer because they do not produce the reference implementations
  • BIOS is a system by which computers deal with hardware--not a system by which hardware deals with itself
  • you would have immediately understood the simplification I made when talking about memory management
  • you would have understood that a "micro freeze" is obviously not the same thing as an actual freeze
  • it's clear you haven't kept up with changes in computer technology in over a decade
  • you would understand that BIOS is essentially a program and you would know how programs work: programs need a CPU to execute their instructions--not a GPU

Your comment about preferring to flash BIOS from a boot disk shows:

  • you don't know what "real mode" is (was)
  • you don't understand that "real mode" applies to CPUs and not GPUs
  • you don't understand why a boot disk was necessary a decade ago but not any more
  • you don't understand that the "real mode" restriction applies to x86 architectures and not GPU architectures
  • your statements are contradictory--if you were a BIOS developer you would need to ensure that the BIOS you developed could be flashed without resorting to a boot disk

I'll give you some serious advice which (if taken) will help you in your life. Trying to act like you were right all along can often have the opposite effect of what you're trying to achieve (showing people you're knowledgeable). The best way to impress people is to be right as much as possible, but also immediately recognize and acknowledge when you're not.
Ombaka
Caveman Lawyers
#19 - 2013-08-02 22:33:15 UTC
Aetourus wrote:
No, you're clearly not a GPU BIOS dev. You're clearly someone who thinks he's smart enough to BS his way through a conversation but is not smart enough to recognize when someone has intimate knowledge of the field and would recognize BS for what it is. I know you're not a GPU BIOS dev (or any kind of developer) because:

  • there's no such thing as GPU BIOS
  • if it existed, that field would be far too narrow for anyone except a couple of people to make a living at it
  • you would have said so in your previous post instead of vaguely saying you work for a graphic card manufacturer




Foot in mouth often?

http://www.overclock.net/t/149879/howto-nvidia-bios-flashing

http://www.overclock.net/t/1353325/tutorial-atiwinflash-how-to-flash-the-bios-of-your-ati-cards
COUGAR ONE
LOGOS Community
#20 - 2013-08-04 00:26:44 UTC
I too am seeing this weird freeze , it has just recently started since the last patch.

I get the little blue round circle icon that spins and the game freezes for like 2 seconds.


was hoping to get some insight instead of someone saying that its on our end. .

any solutions .


Cougar One
12Next page