EVE Search - LAg. Simply unberaable.

Check My IP Information

All Channels

Corporation, Alliance and Organization Discussions

LAg. Simply unberaable.

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

Monitor this thread via RSS [?]

Pages: 1 2 3 4 5 6 7 8 [9] 10 :: one page

Author	Thread Statistics \| Show CCP posts - 0 post(s)
dor amwar Occam's Razor Combine	Posted - 2007.04.18 14:48:00 - [241] beside the 'need for speed' initiative, i have never heard ccp admit that there is a problem. for sure if you request a reimbursment due to a 1 fps battle loss your told that nothing was seen in the logs, nothing we can do, not our problem bla bla bla. so i can only assume that this is their short term tactic for reducing blobs.
lles Roving Guns Inc. RAZOR Alliance	Posted - 2007.04.18 14:54:00 - [242] They should ask some marketing employees how to get the job done,cause marketing seems to go well at ccp... Sell a more and more crappy produkt, looks pretty tho..
Kaylana Syi The Nest Interstellar Alcohol Conglomerate	Posted - 2007.04.18 15:15:00 - [243] Lag is pretty crap atm for anything over 15 v 15. I've had one 50 v 50 fight in the past 3 months that was playable and that was vs Rise in RIT where the region is so big it must have multiple nodes running it. I won't be quitting EVE over it tho but its fustrating as an FC. The gang system is the first problem, the way calculations are done on decloak. Why we can't be temporarily assigned gang bonuses like boosters for x amount of minutes is beyond me. Having to calculate gang bonuses after ever bloody jump in is retarded. So yeh my solution is : Join gang with squad commander pilot x is assigned bonus from squad commander for x amount of minutes like a booster. If the gang recieves a wing commander then pilot x is given another bonus injection that will stack like a booster on a booster. Rinse and repeat up the chain of command. Then put a gang leader option to uplink with gang members to extend the bonus timers or recertify bonuses( like if a better bonus giver joins ). But for heavens sake it needs to be fixed. Team Minmatar
Solbright	Posted - 2007.04.19 00:38:00 - [244] Just remember everyone that it's not lag that you are talking about here, momentary client lockups can not be generated by lag. Instead of calling it client side lag, so as to avoid thinking it's related to lag, I've been calling it stutter.
Solbright	Posted - 2007.04.19 01:31:00 - [245] Also, and this one's especially for Mister Zero. Just because a program runs too slow, and in this case also freezes, doesn't mean that the hardware or config of said hardware is at fault. It can simply be badly written software which, obviously, should be cleaned up.
Phoebus Athenian Gallente KIA Corp KIA Alliance	Posted - 2007.04.19 02:53:00 - [246] Originally by: Solbright ... Yeah its most likely client-side lag due to badly written code. Which, agreed, needs to be amended soon. But its still lag and experienced as such even if we call it something else... ---
Solbright	Posted - 2007.04.19 03:55:00 - [247] Originally by: Phoebus Athenian But its still lag and experienced as such even if we call it something else... Hmmm... Stutter and lag are two quite different beasts. Lag has many reasons for occuring - from simple latency to various network problems to server processing interval, and many observable effects - from unresponsive commands to repeating or skipping actions to late or surprise events. Stutter only has one reason - inattention resulting in badly coded program, and only one observable effect - momentary lockups. Lag is also unavoidable where as stutter is entirely avoidable.
ThunderGodThor KIA Corp KIA Alliance	Posted - 2007.04.19 06:01:00 - [248] Originally by: ElCoCo Node can't handle stuff. But sends/receives data anyway at low rate. Client tries to keep up with the action, but with the low rate data comes and goes, it gets stuck on a catch-up loop and while it's at it, everything is frozen. The little video that was posted here isn't the actual terrible problem we're describing. That's normal network lag since you can move the camera etc as usual, but the system hasn't loaded up. Fraps actualy shuts down (!) when our problem occurs. So it's two things to blame simultaneously... node isn't up to the task and client has faulty code. As simple as that. Elcoco when that used to happen we would LAG WARP.. cause the servers used to see it as a disconncet then it would catch back up eventually. When was the last time any one has lag warpped? Cause i havent for over what a year back during the end days of PA lag was so bad up there every gate u would LAG. So my question is did CCP disable it for the most part or completly.
Solbright	Posted - 2007.04.19 09:01:00 - [249] Originally by: ThunderGodThor So my question is did CCP disable it for the most part or completly. It's the same function as logoff auto-warp except it'll be triggered internal to the server. It'll still exist. So what has changed? The answer seems to me that the servers are no longer lagging enough to trigger it. In fact I'd guess the cluster is performing better than ever. You can see where I'm leading with this. Less lag makes for more stutter. When stutter hits you it's individual to your client so the enemy has chance of free meal. It also mean your client is unable to issue a disconnect command so the auto-warp won't activate until you are logging back in.
Solbright	Posted - 2007.04.19 12:02:00 - [250] Stutter is entirely preventable. Completely, right down to no framerate variation at all. It's possible to lock framerate to a fixed figure - typically sync'd to vertical refresh. Then we could get back to arguing about what cluster setups would be best performance for Eve. :)

Viqer Fell Minmatar Trinity Nova KIA Alliance	Posted - 2007.04.19 22:58:00 - [251] Whatever semantics you argue about the fact is the client is still freezing up when it shouldn't. Call it stutter call it lag , dress it up in a bloody dress shave its legs and call it dame edna everage for all i care, it's still crapping on my gameplay when it never used to and i want ccp to recognise the problem and tell me how theyre trying to fix it please Click here to visit our site
Solbright	Posted - 2007.04.19 23:23:00 - [252] Originally by: Viqer Fell ... it's still crapping on my gameplay when it never used to and i want ccp to recognise the problem and tell me how theyre trying to fix it please Exactly. Good to see this. The reason why I'm getting picky is because there is so much anger at the supposed inability of CCP to fix the cluster but the cluster is working just fine. And then people start acussing CCP of lying about lag. That's just counter productive.
Solbright	Posted - 2007.04.20 06:06:00 - [253] The other part of what I'm up to is directing attention on the rather sorry state of stutter and the possibility of fixing it once and for all. This can be done - if the devs are willing.
Viqer Fell Minmatar Trinity Nova KIA Alliance	Posted - 2007.04.20 07:29:00 - [254] Some of my last post may have been influenced by the large quantity of red wine i consumed after finally getting a completion date for my new house. Apologies if it was phrased somewhat enthusiastically ;) Click here to visit our site
Matthew Caldari BloodStar Technologies	Posted - 2007.04.20 08:34:00 - [255] Originally by: Pan Crastus Originally by: Matthew Every node is a special ultra huge node. There simply aren't any more powerful blades available. That made me laugh. First of all, blades aren't the most powerful hardware you can get, second the stuff IBM sold to CCP back then is already outdated by their current Intel based offerings, third even back then their Power(tm) based blades were probably suited better to the workload (yes, I know that CCP loves x86+Microsoft). Sure, blades aren't the most powerful hardware around. But that isn't the only concern. Technically, BlueGene/L could run Eve wonderfully. But load the existing server software onto it and you're not going to be going anywhere fast. Could the software be recoded for it? Sure. Are you willing to wait a year for that to happen? I doubt it. It's also not really an economically viable solution. At the time of the big server upgrade, CCP tested all the top-end blades available, and they picked the ones that ran their code the best (which afaik resulted in AMD nodes with an Intel DB cluster). While the Power based blades might be better for this type of work from a purely theoretical standpoint, that doesn't mean anything if that theoretical advantage is not realised in practical tests. Computer hardware is outdated as soon as it goes out the factory gate anyway. If CCP started chasing every incremental new blade release, you'd end up with the server being a horrible mish-mash of different blades (can you say maintenance nightmare), not to mention the complications of load-balancing across those performance differences (which will likely vary with what type of load it is as much as how much there is of it). I would far rather see the proper, structured upgrade plans CCP actually pursue, rather than an ad-hoc bunging in of whichever blade is at the top of IBM's "new releases" list each month. Originally by: Solbright At any rate, it's clearly not blocking, from observation, because CPU usage doesn't fall to zero for those periods. I didn't mean it's blocking anything, and blocking doesn't necessarily mean that you're sitting there idle waiting. What I'm saying is that the rendering path in the client is being blocked by some other part of the client. For example, the incoming packet hander sees that the server has sent it a huge list of people that have just locked you. This list will need to be processed out of the incoming packet, into a cached list that the client is maintaining. But this cached list also needs to be read by the rendering process, to know who to draw nice flashing yellow boxes around. It is not unreasonable to think that maybe the render process is being blocked from accessing the list while the incoming packet handler is writing to it. It's not the best way to handle it, but that doesn't mean that's not what's happening. You wouldn't see CPU usage drop hugely if this was the case, as nothing else other than that specific operation is being blocked. It's even possible that most of the render loop keeps going, but just times out at the bit that's blocked, drops the frame, and starts again. Originally by: Solbright What it will be doing is bogging down after the new packets have arrived, the client can't process the data quick enough without causing a stutter. Actually, that problem isn't about bloat, it's about what their machonet network handler was optimized for. It was optimised for lots of small packets, because that is the vast majority of traffic eve generates. The downside of these optimizations is that it tends to choke on very large packets. Hopefully this problem will be rectified by the new Slipstream system Oveur mentioned in his blog thread. ------- There is no magic Wand of Fixing, and it is not powered by forum whines.
Solbright	Posted - 2007.04.20 10:44:00 - [256] Matthew: Congrats on doing some testing. Glad to have you on board.
Solbright	Posted - 2007.04.20 13:13:00 - [257] Now that I've got a little traction I'll pop my own bubble. The particular incident that started this thread clearly is more exceptional than common stutter. It's hard to find a good reason why it is so much worse than Eve's norm yet still a rare event or maybe only happens in certain places. One idea that I keep thinking about is the old jpeg in the billboard bug. I haven't been in 0.0 for a while now but have been informed that billboards don't exist in 0.0 so another source has to be involved. A bad texture maybe? If so then when would there be a rare texture usage at gates? Not likely to be the gate itself, there isn't very many types. Maybe a particular planet variant that is also visible from a gate? That just might be a good rare combo ...
Solbright	Posted - 2007.04.21 04:03:00 - [258] Edited by: Solbright on 21/04/2007 04:03:56 That's interesting. Not in 0.0. Made an assumption there. Just went and checked it out, jumping from Jachanu into Sazre, nothing out of the usual even on this "recommended" spec'd machine. It does however leave open the billboard option ...
Solbright	Posted - 2007.04.21 07:50:00 - [259] Looking at some of the bug hunting reports, The beaten-with-the-ugly-stick-lag-monster thread, are making it look more like it's a general bahaviour now, rather than exceptional. Maybe I'm not so alone any more. :P
Solbright	Posted - 2007.04.21 07:58:00 - [260] One thing that gnaws at me though, is that some fleet combat is not this bad according to other reports. Not that I would know, it's always been impossible on my setup.

AproK	Posted - 2007.04.21 18:04:00 - [261] Looking thru that topic you posted right now... Looks like everytime its something with the overview / drones? The problem I had with the 1fps lagshow was with suddenly getting 40 people on my overview.. http://oldforums.eveonline.com/?a=topic&threadID=506320 With that fight we lost around 25 ships while taking down 3 ships. Nuff said?
Solbright	Posted - 2007.04.21 21:31:00 - [262] There's been drones in use without a major hiccup also, according to yet more reports. Gotta be something else. Can you vouch for all your recent combat? Some big ones that didn't freeze up?
DerArt1st	Posted - 2007.04.21 22:09:00 - [263] Eve is going to be unplayable. Sometimes i think this doensn't deserve the title "game", i would prefer the term "diashow". If there is a fleetfight going on i often stuck with 1 fps and this is just not acceptable. Remove Fleetwar or fix it... but in the current state its just broken.
AproK	Posted - 2007.04.22 00:31:00 - [264] Our problem happend when the enemy suddenly uncloaked at the gate after they jumped through. Before that everything went fine with our little 25 pilot fleet.
Solbright	Posted - 2007.04.22 04:58:00 - [265] Originally by: Matthew Hopefully this problem will be rectified by the new Slipstream system Oveur mentioned in his blog thread. Rant mode on Being too hopeful, me thinks, given CCP's history with this issue. Stutter has always killed gameplay and everyone has always complained about it. Although calling it lag may have been a bit confusing for the devs, surely they understood. Not to mention see it for themselves. It's not like stutter was a rare event that only a few setups encountered. It affects everything from clicking on window tabs right up to the bigest events! Rant mode off
Garrett Smith ARK-CORP FREGE Alliance	Posted - 2007.04.22 05:57:00 - [266] Yeah the lag is **ing me off. Walking in stations? Who gives a damn! WTS: Clue for CCP Originally by:** El Yatta they shouldnt have gotten involved in supercaps, because on the whole they are very dull, except for 2-3 people in the alliance who get to go "wheee, i cant be scrambled, pwn pwn".
MightyGuy	Posted - 2007.04.22 06:01:00 - [267] im seriously tired of the lag. please do somthing about it instead of adding lots of new content because your fanbase will die if you dont. you will get new people but they will quit because of all the bugs and game rating will go down the tube.
VD ThatsNotRight	Posted - 2007.04.22 06:19:00 - [268] http://search.bbc.co.uk/cgi-bin/search/results.pl?tab=av&q=eve+online+video&scope=all i have to say.im a fan boy..but here we have a dev talking about 1000 ship fleet battle.and telling a bbc journo its possible.. this may have been posted before, but im too lazy to read the thread..all sounds very familiar
Mister Zero Synergy Alliance	Posted - 2007.04.22 09:29:00 - [269] Originally by: VD ThatsNotRight http://search.bbc.co.uk/cgi-bin/search/results.pl?tab=av&q=eve+online+video&scope=all i have to say.im a fan boy..but here we have a dev talking about 1000 ship fleet battle.and telling a bbc journo its possible.. this may have been posted before, but im too lazy to read the thread..all sounds very familiar Nice find. Here's a direct link to the WMP file: http://news.bbc.co.uk/media/avdb/news/video/81000/nb/81851_16x9_nb.asx He mentions 1000 ship fleet battles twice, like it's common, or for the average player - when most of them lag out on fights of 3-4 ships. What a load of CRAP.
Solbright	Posted - 2007.04.22 21:25:00 - [270] Edited by: Solbright on 22/04/2007 21:46:32 Can't help myself, just have to pick at it ... Originally by: Matthew This list will need to be processed out of the incoming packet, into a cached list that the client is maintaining. But this cached list also needs to be read by the rendering process, to know who to draw nice flashing yellow boxes around. It is not unreasonable to think that maybe the render process is being blocked from accessing the list while the incoming packet handler is writing to it. It's not the best way to handle it, but that doesn't mean that's not what's happening. Good try but doesn't quite add up with observation. This cached list will be alot more. It'll be a world simulation on the client approximating the servers own larger simulation. From this you get complete decoupling which inturn removes any need for the rendering loop to ever block on anything server related. One area where the renderer could have some improvement is with it's own caching. It is very much getting stuck fetching this stuff when it could just forget it until the material is available or use a little more RAM and preload everything from the HDD. But, I'll come back to bloatware again. Generally the design of the client seems fine, just it's too slow. Maybe the packet handler is part of the problem. Dunno, doesn't really matter as it still equates to bloat if the client has to spend forever inserting such small amounts of info into it's simulation.



Pages: 1 2 3 4 5 6 7 8 [9] 10 :: 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.