Windows Server Installer :: Modular & Scripted

[kuahara]

Update: fixed the "Unknown DB string xxx" problem. I wound up using the server files from agnarr-eq.com

I thought I'd tried the dbstr and spells_us files already (I use the underfoot client), but there were also 2 files that needed to go into the resources folder. I don't remember doing anything that would have changed these from when I actually played on the agnarr emu server, but apparently something was changed along the way. Using all their files with the exception of eqhosts.txt resolved the issue I was having.

Also, someone messaged me and said that MQ2 discussion might not be permitted. My apologies. I thought it was condoned here since most of the servers allow it with varying sets of rules to make multiboxing easier.

I also stuck <localaddress>ip</localaddress> just below <loginserver2></loginserver2>. Will give that a try and report back.

Edit: Was trying the <localaddress> thing because after a while, my response time with the server increases from 30ms to nearly 30,000ms (full 30 second delay). I usually have 21 characters logged in. This happened even with the <localaddress> bit in the eqemu_config.xml file in the place I specified above. The response time sits at about 100ms with 21 toons logged in, but after a while, will suddenly start climing from 100 to 900, then 1500, 5000, 19000, and usually stop climbing somewhere between 27000 and 29000. I am not sure if I am triggering this problem or not. The last time it happened, I had just issued an MQ2 command on the GM character. This could have triggered it or it could have been nothing but a coincidence. Won't know without experimenting further. Just updating here in case someone already has an answer.

Edit2: I issued a /bcaa //gate command to make 20 toons all try to gate at once. Usually this is broken in such a way that it just causes the toon to rezone to the current zone in the current location. The idea was to make them all rezone and see if that fixes the problem with the long response time to/from the server. For some reason, on the bards (bound in gfay by default), /gate actually works and sends them to gfay. All toons that were bound in PoK by the soulbinder were kicked to the server select screen when I did the mass gate. The bards wound up in gfay with 30ms response times from the server.

This is also taking up quite a bit of memory. I am not sure that that would contribute to long response times, but when I had 21 logged in, I noticed my machine was using 26.5GB of memory. I have 32GB in this machine. The server runs in a VM on the same machine. Most of the eqgame.exe instances are using about 732MB of memory. EQ instances only account for 15GB of the memory being used. The rest is other garbage running on the machine (firefox, excel, vmware, etc...) The CPU (an i5 @ 3.4GHz) is not being beaten to death or anything. With a toon zoning here and there, I was seeing 15-24% usage.

[Akkadius]

Unknown DB string is going to show up depending on the types of data you're dealing with on older clients.

if you want to minimize string related issues on the client side I would suggest using ROF2

You can grab a clean version of ROF2 and use its spells_us and dbstr files to import to the server before you try exporting. The database tables are not guaranteed to be up to date.

And yes - this is not really the place for MQ2 support - there is mqemulator.net for that.

Memory footprint from the emulator is not going to be that large

[kuahara]

ok, but what about the <localaddress> bit from the last question? Is that in the right place? Would that have anything to do with the long delay? 30s delay makes this unplayable.


Thanks.

[Akkadius]

Originally Posted by kuahara

ok, but what about the <localaddress> bit from the last question? Is that in the right place? Would that have anything to do with the long delay? 30s delay makes this unplayable.


Thanks.

localaddress just needs to be under the <world> section

As far as your delay - you're going to have to narrow down that issue, it could be anything. We have servers in production with folks with 50+ box crews who zone in seconds. I'd suggest looking at your PC's resources when the slowdown occurs.

[kuahara]

I'm getting closer to an answer on this 30,000ms delay thing. I don't think it has anything to do with MQ, but more testing is required.

Right now, I've had 18 characters logged in and all of their delays are 30-50ms. They have all been logged in for over 2 hours, which is way longer than it was taking for this 30 second response time bug to kick in yesterday. Individually, they can all change zones in 3-5 seconds (assuming the zone was already up). I zoned 18 characters all at the same time and it took 27 seconds for it to complete.

Shortly after the mass /gate, all the toons had response times from anywhere between 400ms and 1200ms. This seems to be correcting itself slowly over time while I have them sitting in place not doing anything. Many of the 500ms response times lowered down to 300ms after a minute or two. My main cleric's 1200ms response time was down to 850 and lowering. I think this will work itself out as I wait.

My current theory is that the huge lags don't really kick in until I bring the bards online and make them start twisting their songs. I have 3 total bards and when they are simultaneously twisting, it generates quite a lot of chatter in the chat windows of 20+ toons all at once. I am wondering if more is going on in the background with bard songs that might be contributing to this giant delay. Going to wait for the response times on all my toons to get back down to 100 or less, then bring them online and make them /twist. I will monitor response times both before and after issuing /twist 1 2 3 (makes them twist spells in the first 3 gem slots).

Sorry for bringing up anything MQ related in the post. I'm not seeking MQ support here at all. If I determine that to be a contributor to the problem, I will take this discussion elsewhere. I am including the information for the sake of drawing a more complete picture.


Edit: I brought the bards online. They all three had 30ms response times while in gfay. I #summoned them to PoK with the rest of the toons and they had 40-50ms response times. I left them idle there for several minutes. My response times on all toons are still gradually lowering during the several minutes. Response times on all toons were between 125ms and 135ms. They didn't seem to be lowering further than that, though perhaps it might have happened if I waited longer. I decided to make all three bards twist the songs in their first 3 gem slots. Most of the chatter is in the GM's chat box. It displays the full name of every song as soon as it is successfully cast. The other toons just have a bunch of "The elemental chorus fades" entries in their chat. If this is what triggers the problem I'm investigating, I imagine it could take 15-20 minutes or so for it to kick in. Will edit the post again if it recurs.

In the meantime, this is what my performance currently looks like. Left is the host machine where the eq clients are running. Right side is the guest machine, where the server lives.

[kuahara]

Well... I'm back to where I started. I have no idea what was causing that problem. The bards have been afk twisting, took the wife out for about an hour, came back, and everyone's response time is at 90-135ms.

Was hoping to have something useful to reply back with. Sorry for all the fruitless chatter.

[Akkadius]

It sounds like you are experiencing packet loss. These symptoms occur when the server starts having to re-transmit packets to many clients at once and the ping/latency response from the client perspective rises.

If you're doing this on the same machine through VM etc. you may want to investigate potential bottlenecks or other things going on. Again we have folks who zone 50+ toons on our higher player-base servers and there are 0 issues unless their connection is experiencing packet loss, these sorts of symptoms occur where eventually they completely desync or things get sluggish.

18 clients - my suggestion as well is to use all the filters you can on your boxes, not MQ2 filter, but the client filters. These client filters are pushed up to the server and the server will not send you the packets for those messages, that can heavily reduce spam/resends in combat scenarios etc. If you were doing lots of combat and then you tried to zone not long after something like this that would cause your problem. Another client side thing that you should make sure you're doing as well is making sure that /log is disabled - this is a huge performance hit to the client and I wouldn't ever have it enabled unless you really need to log something

HTH

Akk