Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.

Due to spam on this forum, all posts now need moderator approval.

 Entire forum ➜ SMAUG ➜ Running the server ➜ game_loop(), select(), and dual core CPUs
game_loop(), select(), and dual core CPUs

It is now over 60 days since the last post. This thread is closed.     Refresh page

Pages: 1  2  3  4 5  

Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #45 on Tue 13 Feb 2007 04:31 AM (UTC)
Message
Quote:
At least nothing discussed here relates in any way whatsoever to Samson's timing problem on his MP kernel at all.
As far as I know, we had changed subjects and were talking about other aspects of the network code. Of course this doesn't have to do anymore with the MP kernel etc.

Quote:
Nothing wakes up this select as it returns immediately.
Yes, I was projecting my own solution and misspoke. However, if you get your input in after that one select, you still need to wait a tick, which is what is a problem for me. (Clearly you don't care about it.)

Quote:
While the second select is sleeping and really while any other code in the process is running, network I/O is in fact still occuring during that time.
Not according to the MUD it's not. Obviously the OS is still accepting packets and managing its own buffers. But the MUD is not filling up or emptying its buffers and so forth until the sockets are serviced.

Quote:
For what purpose do you burn up the CPU, when you could just process all the I/O that has occurred during the last 1/4 second all at once? And frankly that's all that matters to Diku.
To you, perhaps, but not to me. (And by the way, we're not really talking about Diku directly. I have never looked at Merc or Diku source code other than via Smaug's code. I make no claim about those games.) Besides, it's not burning up CPU -- you talk about moving a few kbytes of data, maybe even 50k, like it's a massively expensive operation. You have to do it later anyhow, so what cost is there in doing it now? (Assuming, of course, that you work to prevent tick creep and so forth.)

Quote:
Errmmm from the code I've read stock Merc, ROM, Smaug and AFKMud will all send up to 4K per pulse.
Then go read the code again. :-) Search for the comment: If buffer has more than 4K inside, spit out .5K at a time -Thoric.

If the output buffer contains more than 4096 bytes, the MUD does not send more than 512 bytes on that pulse. Therefore, if you have, say, 6k, it will take 5 pulses for that buffer to get sent.

Quote:
I don't know any humans that can handle 4 screens of text per second, regardless of whether it slows their client down.
It really bothers me to type, say, "commands" or "wizlist" and see the result come to my client choppy and bursty. Maybe you don't care, but I find it very, very unattractive.

Quote:
Not really. I would not define cast "some spell", kick, save as in-game commands because just they have wait states and wear, north, wield, score as out-of-game commands because they don't.
Score is fairly clearly an out-of-game command to me, although just as clearly wear, north, wield are not. Nonetheless it's not hard to add a wait of one, if you want to have delay. But:
Quote:
So given that you'd modify the command interpretor to add a WAIT_STATE to all the commands. Simple, but the changes are adding up.
Hardly the massive rewrite you were warning about, no?

Quote:
If you want to see all the neat side effects of that seemingly innocuous decision of your psuedo code simply change it.
My MUD has been running that change for years now and nothing adverse has happened. Players can't use the increased command throughput to their advantage at any time it actually matters due to the stock usage of wait states.

Quote:
Given that problem reported has nothing whatsoever to do with the network code present in DikuMuds, I can only wonder why it's necessary to suddenly discuss Diku networking code.
Conversations change focus; the original thread started out by examining the timing code, and we moved on from there. Wherefore is our crime? Please forgive us. :-)

Quote:
The real design problem of DikuMuds and some others is the tight coupling of the network code to the game itself. It is certainly NOT the two selects()! A network design which used two selects() as Diku does or select()/usleep() are no way better or worse than a design that uses a single select().
That depends on what you want, doesn't it? You obviously don't care at all about the decreased processing, Nick and I seem to care.

Even if I could rather easily grant your point about input to the MUD (minus the "complete rewrite" part of the side effects), I disagree completely that it's not important to service the output as quickly as possible, especially given the 4k-becomes-0.5k change. Of course, you don't seem to care about choppy output, so this might not bother you.

Thank you though for taking the time to explain your positions at length.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Samson   USA  (683 posts)  Bio
Date Reply #46 on Tue 13 Feb 2007 12:20 PM (UTC)
Message
Quote:
Errmmm from the code I've read stock Merc, ROM, Smaug and AFKMud will all send up to 4K per pulse.


Quote:
Then go read the code again. :-) Search for the comment: If buffer has more than 4K inside, spit out .5K at a time -Thoric.

If the output buffer contains more than 4096 bytes, the MUD does not send more than 512 bytes on that pulse. Therefore, if you have, say, 6k, it will take 5 pulses for that buffer to get sent.


The 0.5K thing is why a lot of folks have changed flus_buffer to spit out larger chunks at once. In AFKMud, this function spits out an entire 4K chunk instead of the original 0.5K. That alone made for a pretty significant difference in the feeling of being "choppy" for most people, and even felt a bit smoother for me connecting over my local LAN.

You do have to be careful with deregulating the select() delay if you make no other considerations. Removing it, or even reducing the sleep period, has what I'd call catastrophic affects on the operation of the game. Not just from a standpoint of spam to the user, but to the game's server as well. I experimented once with removing the delay and could barely get the kill command typed due to the runaway CPU usage. It may well be the result of bad game design, but it's what most Dikus are stuck with for now.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #47 on Tue 13 Feb 2007 12:43 PM (UTC)
Message
Quote:
I experimented once with removing the delay and could barely get the kill command typed due to the runaway CPU usage.

That shouldn't happen; what you probably did was to remove all notion of idle time, and simply kept pounding on the main loop, constantly checking if enough time had gone by to process a tick. That will indeed have very negative effects on the CPU, but it's not what we suggested.

The idea is not to completely remove the delay and busy-loop, but to be waiting on input while "sleeping". So if there is nothing to do, the MUD will do nothing and just wait until the timeout expires.

As I said, my game implements the revised network loop Nick and I have outlined in this thread and the CPU usage is quite normal.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Jon Lambert   USA  (26 posts)  Bio
Date Reply #48 on Thu 15 Feb 2007 06:03 AM (UTC)

Amended on Thu 15 Feb 2007 06:04 AM (UTC) by Jon Lambert

Message
> Not according to the MUD it's not. Obviously the OS is still accepting packets and managing its own
> buffers. But the MUD is not filling up or emptying its buffers and so forth until the sockets are
> serviced.

Now just how much time are you saving when all that a non-blocking socket read does is copy memory from kernel space? None.

> (And by the way, we're not really talking about Diku directly. I have never looked at Merc or Diku
> source code other than via Smaug's code. I make no claim about those games.)

They are all the same. That is at least in reference the claim here that the two selects() was bad design, it is relevant to all Diku derived muds that I know of.

> Besides, it's not burning up CPU -- you talk about moving a few kbytes of data, maybe even 50k, like
> it's a massively expensive operation. You have to do it later anyhow, so what cost is there in doing
> it now? (Assuming, of course, that you work to prevent tick creep and so forth.)

No I haven't at all. In fact I pointed out that you will be executing your loop much more frequently than Diku does. You haven't addressed the scenario I mentioned.

> Then go read the code again. :-) Search for the comment: If buffer has more than 4K inside, spit out
> .5K at a time -Thoric.
> If the output buffer contains more than 4096 bytes, the MUD does not send more than 512 bytes on that
> pulse. Therefore, if you have, say, 6k, it will take 5 pulses for that buffer to get sent.
> It really bothers me to type, say, "commands" or "wizlist" and see the result come to my client choppy
> and bursty. Maybe you don't care, but I find it very, very unattractive.

Okay I found that bit of code. Still all these Dikus will send up to 4K per pulse. In Smaug's case which commands would send more than 4K in output? It looks to me like certain OLC commands that list objects, possibly long help files, command lists, social list, area list, etc. Looks like Derek took the opposite tack from you and essentially nerfed the output rate of commands that produce large output. Those that you've called out of game commands. Since Derek was actually running a game that had 200+ players online at it's peak, I'm certainly not going to gainsay that experience and what he's done. I'd suggest to you that he was doing performance tuning. I don't consider tweaking buffer sizes to be fundamanetal design problems.

> Hardly the massive rewrite you were warning about, no?

I never said any such thing. I said "The change would require a rewrite of everything between the selects, separating out what is strictly network I/O from command and update processing." And that is true.

> Players can't use the increased command throughput to their advantage at any time it actually matters
> due to the stock usage of wait states.

So you've gained nothing from processing I/O faster than the commands are processed, except searching the descriptor list dozens of times more every pulse. Oh wait, no that's not it, you've actually optimized the handling of commands without a wait state. So the player typing "HELP STORY" 20 times a second will have optimal servicing. Brilliant. ;-)

> That depends on what you want, doesn't it? You obviously don't care at all about the decreased
> processing, Nick and I seem to care.

You've actually increased processing per the scenario you ignored my last post. If your argument is now that all things are relative, then it hardly makes any sense to post crap like, "The remaining time is somewhere close to a quarter second, which, while not that much, is still an awful lot of wasted time." and "Having two select statements is a fundamental design flaw."

> Even if I could rather easily grant your point about input to the MUD (minus the "complete rewrite"
> part of the side effects), I disagree completely that it's not important to service the output as
> quickly as possible, especially given the 4k-becomes-0.5k change. Of course, you don't seem to care
> about choppy output, so this might not bother you.

No the code reads that output greater than 4K gets changed to .5K per pulse until it falls below 4K.
One of the interesting things about the Diku loop is that because of the order of execution (input/update/output) all output will be sent every pulse levaing only that that exceeds 4K for the next pass. As noted, the choppy output appears to be something deliberate in Smaug.

Now I searched for the phrase "complete rewrite". Who exactly are you quoting? Is his name StrawMan? ;-)

Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #49 on Thu 15 Feb 2007 06:51 AM (UTC)
Message
Quote:
Now just how much time are you saving when all that a non-blocking socket read does is copy memory from kernel space? None.
Yes, but so what? The point is that the MUD is not processing input, and not emitting output. The point is not how much CPU time is saved, but how long I/O takes from the player's perspective. As long as we don't exceed, in real-time, the time until the next pulse, then we don't care how much extra time we spend.

Quote:
No I haven't at all. In fact I pointed out that you will be executing your loop much more frequently than Diku does. You haven't addressed the scenario I mentioned.
Which one? That I would run the loop more often? Yes I have: it's not a problem, because you're not processing that much I/O to begin with, and since you recheck time till the next tick after each processing loop, you won't get behind schedule.

Quote:
In Smaug's case which commands would send more than 4K in output? It looks to me like certain OLC commands that list objects, possibly long help files, command lists, social list, area list, etc. Looks like Derek took the opposite tack from you and essentially nerfed the output rate of commands that produce large output. Those that you've called out of game commands. Since Derek was actually running a game that had 200+ players online at it's peak, I'm certainly not going to gainsay that experience and what he's done. I'd suggest to you that he was doing performance tuning. I don't consider tweaking buffer sizes to be fundamanetal design problems.
I'd want to see actual performance measurement before believing that it's that much more efficient to chop data into small chunks. If we're talking about network efficiency, the OS is supposed to take care of that. If we're talking about the time it takes to copy data, well, ok, I agree that tweaking buffer sizes isn't a fundamental design problem. (Then again, I didn't say it was.) What I *did* say was a fundamental design problem was to not bother even sending out output when you are otherwise doing nothing at all.

Quote:
I never said any such thing. I said "The change would require a rewrite of everything between the selects, separating out what is strictly network I/O from command and update processing." And that is true.
Yes, I apologize, you did not use those exact words. I got the impression due to your suggesting that it would take a separation of I/O from command/update processing, which to me, if it were to be done completely properly, could indeed entail a fairly substantial rewrite. Unless I misunderstood what you meant, of course.

Quote:
So you've gained nothing from processing I/O faster than the commands are processed, except searching the descriptor list dozens of times more every pulse. Oh wait, no that's not it, you've actually optimized the handling of commands without a wait state. So the player typing "HELP STORY" 20 times a second will have optimal servicing. Brilliant. ;-)
I believe you misunderstood. I meant that players cannot get an advantage over other players in e.g. combat by typing in lots of commands in the hope to get multiple ones in per tick.

As for the output servicing, I think we've established over and over again that you don't give a hoot either way but it really bothers me to get choppy output. Unless you demonstrate to me that I am wrong to care about choppy output, I suggest that we should declare that issue to be pretty much over due to being an apparent matter of opinion.

Quote:
You've actually increased processing per the scenario you ignored my last post.
We are not talking about the same kind of processing, I think. I am saying that you do not seem to care about the decreased output throughput. Or, put another way, you do not seem to care about the potential to increase output throughput.

Quote:
If your argument is now that all things are relative, then it hardly makes any sense to post crap like, "The remaining time is somewhere close to a quarter second, which, while not that much, is still an awful lot of wasted time." and "Having two select statements is a fundamental design flaw."
I am not sure what point you are making here. And I don't refer to your claims as crap. :-)

Besides, I still don't understand why we should not be sending output when we'd be doing nothing whatsoever instead anyhow. Again, if it has to do with network usage, let the OS's implementation of the network protocol worry about that. And yes, I do consider it a design flaw to be sitting around idle when there is stuff you could be doing (at what is basically no cost as far as the rest of the system is concerned) that you are not doing.

Quote:
One of the interesting things about the Diku loop is that because of the order of execution (input/update/output) all output will be sent every pulse levaing only that that exceeds 4K for the next pass. As noted, the choppy output appears to be something deliberate in Smaug.
Well, sure, of course it's deliberate. What I'd like to see are the reasons for the decision, and if possible, some data points to back them up.


Let's forget about input for now. As I said, I can see potential problems in properly handling the input case. Let's focus on output. What I'd like to hear from you is simply why we should sit idle when there is output we could be sending.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #50 on Thu 15 Feb 2007 07:39 AM (UTC)
Message
Quote:

At least nothing discussed here relates in any way whatsoever to Samson's timing problem on his MP kernel at all.


My original suggestion was that maybe the select with no descriptors might have been timing out prematurely, due to possible optimization, which is what the behaviour is under windows. Thus, that was relevant.

However it seems that rebooting the PC fixed the problem. As I didn't have the problem on my PC I couldn't say for sure whether or not my suggestion would work.

I accept what you have said earlier about the sleep in the main loop as being defensible - up to a point - on the grounds you outlined.

I think you will find however that any large online program (eg. a web server, MMORPG) would never build sleeps into the main loop, simply because they are going for optimal performance.

The main justification for the "sleep select" seemed to be that it reduced the number of times select needed to be called, thus potentially reducing the times through the main loop.

However it seems to me the downside of that is, in return for that saving, and by allowing more user input to "batch up", ready for when the sleep is over, that you are forcing processing of user input to be chunked more. That is, when the 250 ms is up, you have a lot of work to do, possibly even more than 250 ms worth.

However, the design which has more "turns through the loop" will process user input as it occurs, thus smoothing out the processing. This would be particularly noticeable if the thing the user wants to do (maybe a spell lookup) involves a lot of CPU.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #51 on Thu 15 Feb 2007 07:50 AM (UTC)
Message
Quote:
However, the design which has more "turns through the loop" will process user input as it occurs, thus smoothing out the processing.
The main argument Jon seems to have given against this, as far as I can tell, is that you have lots of useless traversals of the descriptor list. I'm not sure this is really such a big cost, because a linear scan of even 500 elements is very fast. It is probably noise when compared to the time it takes to, say, actually run the tick update function. But it would take actual performance measurements to know for sure.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #52 on Fri 16 Feb 2007 04:44 AM (UTC)
Message
Effectively the dual-select technique is a variant of doing IO by polling. That is, you sleep for a while (to give the CPU a chance to do something else), and then you poll the IO list to see if there is anything to do.

I accept that this works on lightly to medium loaded MUDs, as obviously everyone is happy with it.

I think you would find that at a certain point (and I can't say what that is, maybe even 1000+ players), that the sleep/poll technique would become noticeably ineffecient.

For more lightly loaded MUDs the existing technique may well be perfectly satisfactory.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #53 on Fri 16 Feb 2007 04:58 AM (UTC)
Message
Quote:
For more lightly loaded MUDs the existing technique may well be perfectly satisfactory.
For input, yes; but the delay in output can be quite noticeable. Maybe it doesn't bother some people (clearly Jon thinks it's fine) but to me it's very unaesthetic to have output come in chunky bits.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top
Posted by Jon Lambert   USA  (26 posts)  Bio
Date Reply #54 on Sat 17 Feb 2007 04:53 AM (UTC)
Message
>> So you've gained nothing from processing I/O faster than the commands are processed, except searching
>> the descriptor list dozens of times more every pulse. Oh wait, no that's not it, you've actually
>> optimized the handling of commands without a wait state. So the player typing "HELP STORY" 20 times a
>> second will have optimal servicing. Brilliant. ;-)

> I believe you misunderstood. I meant that players cannot get an advantage over other players in e.g.
> combat by typing in lots of commands in the hope to get multiple ones in per tick.

But you are still ignoring the scenario of a user issuing "help <some massive help file>" 20 times or more per second. Instead you are actually giving priority servicing to users spamming the game with "out of game" commands. I would suggest that it may be a fundamental mud design flaw NOT regulating the user's rate of issuing commands, leaving yourself open to what amounts to in game DoS and spam attacks.

> As for the output servicing, I think we've established over and over again that you don't give a hoot
> either way but it really bothers me to get choppy output.

No we've instead established that Derek Snider decided to chop the output of commands that produce large output. I've postulated that since he was running a mud with a fairly large amount of players, and quite possibly had either limited bandwidth or machine, he did it for performance reasons. I don't really think he needs to provide any proof that whatever tuning he did for his mud must necessarily apply to anyone else.

Secondly there is no need to personalize my defense of the Diku network architecture. I didn't write it and I don't run one.

> Let's forget about input for now. As I said, I can see potential problems in properly handling the
> input case. Let's focus on output. What I'd like to hear from you is simply why we should sit idle
> when there is output we could be sending.

No because you can't separate output from the input/update/output loop and discuss it in isolation because all of the output that will be generated comes from that input/update sequence. It doesn't get magically produced elsewhere. The only leftover output once that pulse loop ends is 1) that which would write block anyway, and 2) the output generated that exceeds the buffer size of the write routines. In the first case, that's what select was designed to test, there is really nothing to do but wait on those sockets to ripen. In the second case as already mentioned you simply tweak your write buffer. Now you aren't going to gain anything in implementing application write buffer sizes greater than the underlying OS sockets stack, which I'm guessing are still 32K for both input and output on most Unices, as you'll be hitting write block conditions again.

Now if you did an analysis and measurement, you are going to discover that 99% of the output generated from a stock Diku/Merc/Smaug Mud per pulse falls under the 4K buffer size. That's about a screen and 1/4 on your traditional 80x40 dummy console, or 5 screens per second. Let's not ignore that DikuMuds and kin are already delivering sub-second response time to their users.

Lastly in the realm of user response time, IBM did studies on response time on multi-user systems and discovered that response times greater than 2 seconds caused the attention of the user to drift and become less productive. That's not suprising and I would posit that "productive" might translate into distracted or annoyed when it comes to text gaming. But they also discovered that installations that provided sub-second but irregular response times to users received more user complaints about "lag" than when response times were uniform but longer.
Top
Posted by Jon Lambert   USA  (26 posts)  Bio
Date Reply #55 on Sat 17 Feb 2007 04:57 AM (UTC)
Message
> My original suggestion was that maybe the select with no descriptors might have been timing out
> prematurely, due to possible optimization, which is what the behaviour is under windows. Thus, that
> was relevant.

Fair enough as he did not specify which OS he was running. Windows select is not Posix compliant. If some version of Linux/BSD broke select() in that way I'm certain it would have generated thousands of bug reports within hours because it would have broken the large body of applications that depend on using select() in the same way Diku uses it, like say apache, rsync, subversion, mailman, kmail, openssl, etc.

> I think you will find however that any large online program (eg. a web server, MMORPG) would never
> build sleeps into the main loop, simply because they are going for optimal performance.

I'm not sure what you mean by large program. If you are talking about web servers and GRAPHICAL MMORPGs we are talking apples and oranges in terms of network architecture decisions.

Apache's main server process does select() sleep in between the select wait for accepting connections and waiting for child processes to end. However that's not even relevant to mud discusion because Apache's optimal architecture is in forking processes for each user (at least on Linux). That architecture would not work very well for muds at all because we share data among users.

On graphical MMOPRGS there are still different architectural considerations. In UOL for example almost all the world data resides on the client, and communications between the server and clients consists primarily of UDP broadcasting of very small packets, mostly under 1K chunks or so I was told. I understand that movement and collisions are resolved simultaneusly on both the client and server and that data syncronization and verification information is exchanged. These games also have front end load sharing code. Frankly the only thing I have to go on is past discussions I've had with some of the authors on mud-dev, as the source to such games like Ultima Online are not generally available for examination.

> The main justification for the "sleep select" seemed to be that it reduced the number of times select
> needed to be called, thus potentially reducing the times through the main loop.

Correct but consider the effects of not regulating user command rate. Other muds like MOO, Cool and ColdC move the command quota regulation out of the networking loop and into the system parse events, thus you see a single poll or select in the networking code. While I might think ColdC's architecture for example is in almost every way superior to a Diku it still doesn't make Diku's fundamentally broken.
Top
Posted by Jon Lambert   USA  (26 posts)  Bio
Date Reply #56 on Sat 17 Feb 2007 05:01 AM (UTC)

Amended on Sat 17 Feb 2007 05:06 AM (UTC) by Jon Lambert

Message
> I think you would find that at a certain point (and I can't say what that is, maybe even 1000+ players),
> that the sleep/poll technique would become noticeably ineffecient.

Sure but I would suggest that someone planning, designing and writing a text mud server to support 1000+ players is extraordinarily optimistic, possibly even delusional. ;-)
Top
Posted by Nick Gammon   Australia  (23,173 posts)  Bio   Forum Administrator
Date Reply #57 on Sat 17 Feb 2007 06:08 AM (UTC)
Message
I have to agree with that, and this is why, with faster CPUs, the existing design, which has theoretical problems, is probably totally acceptable in the current environment.

You may well find that you expend hundreds of hours "improving" it, with no noticeable performance improvements with existing player base numbers.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Samson   USA  (683 posts)  Bio
Date Reply #58 on Sat 17 Feb 2007 08:16 PM (UTC)
Message
Honestly I think throughout all this the number one improvement that I made was in sending 4K buffer chunks if the data exceeds 4K. For whatever reason, quite possibly even the placebo affect, things feel faster to me and anyone else who happens by.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #59 on Tue 20 Feb 2007 07:01 AM (UTC)
Message
Quote:
But you are still ignoring the scenario of a user issuing "help <some massive help file>" 20 times or more per second. Instead you are actually giving priority servicing to users spamming the game with "out of game" commands. I would suggest that it may be a fundamental mud design flaw NOT regulating the user's rate of issuing commands, leaving yourself open to what amounts to in game DoS and spam attacks.
Trivial fix -- check the rate of output to prevent DoS attacks, and leave the speed-up for everybody else. Not a problem.

Quote:
Honestly I think throughout all this the number one improvement that I made was in sending 4K buffer chunks if the data exceeds 4K. For whatever reason, quite possibly even the placebo affect, things feel faster to me and anyone else who happens by.
It's not a placebo effect, it is in fact a very tangible speed-up. I'm not sure what else to say since I feel this horse has been beaten into undeadness and back a few times now. :)
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

198,758 views.

This is page 4, subject is 5 pages long:  [Previous page]  1  2  3  4 5  [Next page]

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home