Houston.. .we have a problem

eqjoe · Post by **eqjoe** » Tue Apr 22, 2003 6:01 pm

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?

dont_know_at_all · Post by **dont_know_at_all** » Tue Apr 22, 2003 7:37 pm

What server are you on?

I know that PvP servers are more closely watched... Maybe they have additional memchecks enabled.

Mckorr · Post by **Mckorr** » Tue Apr 22, 2003 7:47 pm

I haven't experienced any of these problems. How long does it take before the netstat bar starts jumping?

Jaerin · Post by **Jaerin** » Tue Apr 22, 2003 7:52 pm

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

eqjoe · Post by **eqjoe** » Tue Apr 22, 2003 8:01 pm

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?

eqjoe · Post by **eqjoe** » Tue Apr 22, 2003 8:01 pm

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.

Mckorr · Post by **Mckorr** » Wed Apr 23, 2003 8:32 am

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.

eqjoe · Post by **eqjoe** » Thu Apr 24, 2003 9:06 pm

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.....

dont_know_at_all · Post by **dont_know_at_all** » Thu Apr 24, 2003 9:53 pm

Have you tried dbgview to see if there are any extra debug messages coming out?

EqMule · Post by **EqMule** » Fri Apr 25, 2003 5:17 am

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...

eqjoe · Post by **eqjoe** » Fri Apr 25, 2003 11:23 am

Mule, What about the extra zone-client network traffic? This problem started when SoE installed MemCheck3.

eqjoe · Post by **eqjoe** » Fri Apr 25, 2003 1:20 pm

Has anyone modified the makefile for detours so that it builds a release version rather than a debug version?

eqjoe · Post by **eqjoe** » Sun Apr 27, 2003 7:31 pm

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.

Densetsu · Post by **Densetsu** » Mon Apr 28, 2003 1:30 am

so where does that leave us?

dont_know_at_all · Post by **dont_know_at_all** » Thu May 01, 2003 4:32 am

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?