Page 1 of 1
Houston.. .we have a problem
Posted: Tue Apr 22, 2003 6:01 pm
by eqjoe
Guys, I have compiled the latest CVS using the makefile and a fresh build on a newly installed XP system with .NET installed. Both builds when installed on a Win98SE system have the same symptoms. The netstat bar in the upper left of your screen is jumping around wildly, and a network sniffer reveals extra zone-client data. Doing an /unload at any time stops the lag and the extra traffic. The only variation that I have not tried would be in install all on the XP system and use that as my gaming system. (XP dogs perfectly good hardware and Win98SE has twice the frame rates on the same hardware)
What do you think?
Posted: Tue Apr 22, 2003 7:37 pm
by dont_know_at_all
What server are you on?
I know that PvP servers are more closely watched... Maybe they have additional memchecks enabled.
Posted: Tue Apr 22, 2003 7:47 pm
by Mckorr
I haven't experienced any of these problems. How long does it take before the netstat bar starts jumping?
Posted: Tue Apr 22, 2003 7:52 pm
by Jaerin
The original fixes that were put in place to fix the lag issues fixed the problems for me, but I've noticed the last could days that it might be coming back again.
Jaerin
Posted: Tue Apr 22, 2003 8:01 pm
by eqjoe
Mckorr wrote:I haven't experienced any of these problems. How long does it take before the netstat bar starts jumping?
Right away.
My EQlib.dll build on .NET is 486k. The build using the make file on win98SE and VC6 is 360k.
How does the compair to your builds?
Posted: Tue Apr 22, 2003 8:01 pm
by eqjoe
dont_know_at_all wrote:What server are you on?
I know that PvP servers are more closely watched... Maybe they have additional memchecks enabled.
I am on a blue server.
Posted: Wed Apr 23, 2003 8:32 am
by Mckorr
EQLib.dll on VC.Net, 464k. Yes, I have a few things stripped out, but I have larger pieces of code added in. Most of my changes are experimental stuff aimed at fixing some of the broken functions.
Will have to do more tests, the longest I've had EQ/MQ running for in weeks is maybe 10 minutes. But no problems at all during that time. Moving from VC6 to VC7 even fixed that /charinfo crash to desktop I've been having.
Posted: Thu Apr 24, 2003 9:06 pm
by eqjoe
Well crap... the patch on the 23rd didnt change anything. MQ is still unuseable because of this problem.
4 systems of various quality... all exactly the same thing.. I am disconnected within a min or two, running a macro or not. No packet loss, just lots of extra traffic and boom.
I am looking at what these 4 systems have in common. They are all running Win98SE, they are all behind a NAT gateway.
I am gonna try moving one of them out of behind the NAT gateway first.. then I am gonna install XP on one of my gaming systems.....
Posted: Thu Apr 24, 2003 9:53 pm
by dont_know_at_all
Have you tried dbgview to see if there are any extra debug messages coming out?
Posted: Fri Apr 25, 2003 5:17 am
by EqMule
ok Im gonna put my reputation on line here, but I think its a structure size problem... as an example I tried changing sizes on calls dealing with charinfo and spawninfo... for example:
Code: Select all
SPAWNINFO TempSpawn;
FLOAT Distance;
ZeroMemory(&TempSpawn,sizeof(TempSpawn))
by changing the size I got rid of lag...
Code: Select all
SPAWNINFO TempSpawn;
FLOAT Distance;
ZeroMemory(&TempSpawn,364))
but its just a stupid to hardcode a size, best way is to make sure the struct size is ok from the start, dont know if im making sence here... but Im throwing a bone...
Posted: Fri Apr 25, 2003 11:23 am
by eqjoe
Mule, What about the extra zone-client network traffic? This problem started when SoE installed MemCheck3.
Posted: Fri Apr 25, 2003 1:20 pm
by eqjoe
Has anyone modified the makefile for detours so that it builds a release version rather than a debug version?
Posted: Sun Apr 27, 2003 7:31 pm
by eqjoe
After spending some time debugging this darn code... I have figured out that the reason MQ compiled debug (rather than release and optimized for speed) is more stable is simply because is runs slower.
I have found that the MOST stable build is a single threaded debug build.
The client is responding to a server memory check and taking longer to respond. It appears that the client is sending the same packets over and over... spaming the server with something other than normal zone-client data. Even though I cant decode the net-data, the direction of 90% of the extra data is is client->zone.
Posted: Mon Apr 28, 2003 1:30 am
by Densetsu
so where does that leave us?
Posted: Thu May 01, 2003 4:32 am
by dont_know_at_all
I think it's memcheck3 that's the problem. It's the only thing that's getting hit often enough to cause that flickering. Can someone double check that the code is correct?