LDoN slow

[Cryonic]

I run SEQ on a Quad PPro 200 with no issues that I can tell. SEQ isn't multi-threaded, so the other 3 CPUs spend the vast majority of their time completely idle. I also export the display over my network to a Windows machine running Exceed to actually display SEQ. I keep the map refresh rate down around 2fps since I don't need it to update very fast in the large outdoor zones that I hunt in.

Maybe by this weekend I'll get into an adventure with a couple of friends and record the session just to capture the data.

[fester]

Originally posted by Tor K'tal
But nowhere in the system req update/upgrades have they said we will no longer support dial-up connections (meaning they have increased network trafficed to the point a modem running at 42K wouldn't be getting enough or all the data the client needed to function properly).

I have a friend that 2 boxes from a 28.8 modem (getting 26k connects) at home. He lives in a very secluded location (blame his wife.) He rarely has trouble. Ever since they improved the protocol, the data rate has been excellent. Often in near idle zones, it looks like you are going LD, because the server will not be sending you anything for 2-5 seconds.

Originally posted by Tor K'tal
Celeron has a better on die cache than the P2, which I think had L2 off die, yet, still on the riser card for the SLOT1 interface ...

http://www.mobiledyne.com/pub/x86perf.html

Celeron 333 A (the CPU I had was slot1) is a 32k L1, 128K L2 100mhz, 100mhz ram system.

PII 266 is a 32K L1, 512K L2 133mhz, 66mhz ram system.

PII 500 is a 32K L1, 512K L2 250mhz, 100mhz ram system.

PPro 200 is a 16K L1, 256K or 512K L2 200mhz, 66mhz ram system.

From my experience, Linux (and all other unixie like systems) performs significantly better if you have a larger cache. Blame it on the size of the quantum between context switches?

I personally believe the PII 266 and PPro 200 should outperform the Celeron 333A (the one with onboard 128K cache.)

Originally posted by Tor K'tal
[B]You mention loosing of sync in SEQ... could you go into more detail about what that means, maybe that is truelly what I'm seeing and just don't know it.[B]

This is several years ago, but went something like this:
ShowEQ would eventually get to be 20 or 30 seconds in the past. I would go walk somewhere and stop, then about 30 seconds later ShowEQ is catching up to where I stopped. I never examined it very close, but It appeared to get in a state where the pcap thread could not get enough cpu (or context switches) to go to the OS for the waiting packets before the OS started dropping packets. I forget precisely how it would fail, but it would eventually completely fail. I believe this was actually before Luclin, so before the 64bit encryption. It would take sometimes 10-20 minutes to brute the key.

Originally posted by Tor K'tal
[B]At the top of the spawn list it is listed as 10fpm and below the map itself it is listed as 5fps. [B]

I should have mentioned this before, but I ran at 1 (one) frame per second setting.

I don't know how long you have been running in this setup, but I suspect the new encryption (XOR) is so much leaner on the CPU that the Celeron may have been nearly sufficient.

I believe the LDON maps may have more mobs packed tighter? I believe you should have the same trouble in a zone like Hate or Droga/Nurga.

[S_B_R]

I have successfully ran 4 instances of SEQ 4.3.x on a Cyrix P266+ (200Mhz clock) with 384 megs or ram. I don't think it's an issue with the hard where.

As it stands now my Current SEQ machine is a 400MHz Celeron with 384megs and I have no probelms running 2 instances of SEQ, under KDE, along with XMMS, Mozilla, and Gaim. Plus it's my network Firewall and Fileserver.

Only downside is it takes about 27 minutes to compile SEQ other than that it's just fine

[Tor K'tal]

It's been a while since I added anything to this thread that might be considered constructive or helpful, but after last night I might have some new information.

I spent some time in SolC and ChardokB and noticed the exact same problem as I did with LDoN zones. What I found odd was even though I had to fight my way to the entrances of SolC and CharB; Chardock, SolA and B never slowed down once or became laggy in any way. At the time my group was the only one in the any of the 5 zones.

I am curious to know if these zones happen to send more information to the client and slightly different information thus causing SEQ to think longer between important bits of information. This seems very odd and down right stupid from a technicaly stand point, but if SOE had thought, we can do X to make SEQ less effective in these new zones with out giving up too much performance why not. But that is the side of me that believes in consperacies as well. Is there a way for me to check/compair the amount of traffic that is really being sent to the clien in SolB and SolC just so I can look some time?

~ TK

[S_B_R]

Well, I have to say since you seem to be the only person experiencing this, I don't think it's anything SOE is doing to the data stream that is causing this.

I know that's not really helpful, just trying to save some time. It might be worthwhile for you to completely wipe your current SEQ install and start 100% from scratch.

[Samefudge]

Well, I have and continue to run SEQ on a P1 150 MMX and other than the 3 hour compile times (compile it while at work usually ), I do not have the slow-down issues at all in LDoN zones, so far. I run anywhere from 10 FPS to 4 FPS. Spawn list population is slow sometimes, but at this point that's about the only issue.

[Tor K'tal]

Just for kicks I tried a couple more things and I learned something.

It only slows down and bogs out on one of the two sessions I can run.

If I monitor 10.0.0.2 it slows to a craw and maxes out my CPU usage %. While that is going on if I change workspace the CPU is still maxed out but my other session monitoring 10.0.0.3 seems to be keeping up much better. If I kill the session monitoring 10.0.0.2 the one monitoring 10.0.0.3 catches up and keeps up just fine.

So I'm currently trying to find reasons why it is only bogged down when monitoring Machine A vs Machine B. I highly doubt that the IP Address itself if the cause, but I might have to swap the IPs just to satify my curiosity.

I do have some Windows shares on Machine A that my linux box running SEQ connects to... would those connections themselves possably be causing SEQ to have to sift through too many packets? If that really is the case why isn't slowed down in a larger number of zones than the slect ones I have found?

Thanks for listening and making suggestions.

~ TK