Limitations...

[The7DeadlyVenomz]

I remeber back when the server for ARM had difficulty serving 70 players.

Has that changed, and if so, how many can the Game serve properly now, without an inordinate amount of lag and such?

Venomz - of the House of TheSevenDeadly

[Savak]

I'm not really the best person to answer this question, but, to the best of my meagre knowledge the current ginka configuration & link setup has never been significantly lagged -solely- by having large numbers of people logged in.  Way way back in the day (on the 'thrash' machine I believe), we were limited to 30-something (I seem to remember 31 being the magick number for a while) at which point the game would refuse further logins and one had to sit there spamming attempts to log in all night.  But thrash was a relatively minimal machine and, despite it being FAR before my time on staff, I think we had to share a number of machine resources.

In the New Era, the things that have lagged us have primarily been code issues and, at one point, the discussion boards (especially after a crash, when everyone would go to load the GDB simultaneously).  Saikun may have a more thorough set of numbers, and would certainly have a more accurate understanding of our current capabilities.  But at a -guess- we could take well over 100 without detectable slowing.

-Savak

[The7DeadlyVenomz]

Cool, I am just remembering when we had the HRPT...I only remember seeing something like 110-120...I know it was somewhere in that range, and the lag was off the chain. But I was thinking that you folks had changed the machine since then. Not sure if I read that, or just thought it up...

Venomz - the curious little monkey

There is a setting in the code that allows you to maximize connections. Good for smaller machines that cant handle so many connected users, preventing the game from possibly crashing or whatever.

Yeah, it was at like... 80 maybe for the HRPT, then it was increased to 100+ when people starting reporting not being able to get in.

[Angela Christine]

I think the problem during the HRPT wasn't just the number of people, but what they were doing.  If you get 50 people all going into mass combat together (plus a bunch of NPCs too) then you've got a buttload of combat commands and repeted Look and Assess commands as everyone trys to keep a handle on what is going on.  The lag wasn't continuious, sometimes you could go 20 minutes lag-free, and then things would suddenly slow to a crawl, I assume this was when the big fights were going on.  I don't know for sure because I was stuck with a rinthi teenager at the time, and they wouldn't take me with them to the war.   :cry:

AC

[gfair]

Hey... I was reading this thread a second time when I recalled a site that was "slashdotted" a while back, and they got lots of requests for how they handled the server load.  They have an innovative system, perhaps that system, incorporated into Arm, can increase maximum server capacity and still keep at least the service playable?

Here's a direct link to the article:

http://www.aceshardware.com/read.jsp?id=50000347

[krelin]

I've done some sockets code (though not for Arm), so I figured I'd jump in...  back in the day, on older OS's especially, you often couldn't achieve more than 30ish (32), 60ish(64), or 120ish(128) players because you couldn't open more files concurrently than 32, 64, 128...  and a lot of code-bases use an extra couple of file-descriptors for important things like backups, datafiles, stderr, stdout, and so on....

Newer OSes on newer hardware likely up this limit to 512 or 1024.  (note, this limitation applies only to TCP connections, none of this usually applies to properly designed UDP stacks).

So, unless Arm is somehow hardcoded to max out somewhere in particular (and I haven't had trouble logging in, in AGES (years, literally)), then it's probably a long way from peaking out on connections.  As for CPU/network bandwidth, that's a more interesting problem...  how much CPU-time does the addition of one user cost the mud, per cycle?  No idea.  How much network bandwidth does one user consume per second?  No idea, but probably not much...  gotta be well below the 100bytes/second area...  likely WAY lower still...

Just my two 'sid.

Oh, and usually high-availability architectures like what gfair is talking about are extremely expensive and sophisticated, or better suited to "connectionless," transactions, like surfing a website.

[gfair]

Oh, and usually high-availability architectures like what gfair is talking about are extremely expensive and sophisticated, or better suited to "connectionless," transactions, like surfing a website.

Actually, the article has nothing to do with expensive systems, but it seems you didn't read it.  It is a good read if you're in or were once in the field, I recommend it.