Mark Wedel wrote: >Alex Schultz wrote: > > >>Perhaps system load could be measured in determining what threshold of >>what packet size should be before it is compressed, with a hard minimum >>size set as well (so, if the system load gets high, only compress the >>REALLY big packets, which should be rarer). This isn't the simplest to >>implement, but perhaps if reading the system load directly doesn't work >>well, perhaps measuring how close the ticks are to actually hitting 120 >>ms/game tick, and if they start taking too long, then scale the >>compression to back to be used on fewer packets. >>Neither of these methods is the easiest ways to do it, but IMHO it would >>be the 'smartest' way to do it. >> >> ><snip> > > However, if we were going to go down the idea of adapting what the server > does >base on available time, there are lots of other things. Don't swap out maps >if >busy. Put off for a few ticks the routine stuff (in do_specials()). But that > >also starts getting more complicated - some players may not care much about >compression but don't mind using it to help reduce server bandwidth, etc. Yet >others on low bandwidth connections really want that compression - this could >lead to things like clients saying how badly they want compression. Not sure >if >that complication is worth it. > > Hmm, this is true. However in my opinion, it shouldn't really be that difficult to make a few things like that adaptive to server conditions.
> The other problem I think with that approach is that the bigger the packet, >the longer it takes to compress. > > True, but the bigger packets are more important/worthwhile to compress, and if threshold is moved up, there are fewer packets that will be compressed, causing somewhat of a reduction in compression time. Perhaps if the server is really lagging behind, the threshold would become high enough that it wouldn't compress at all. > but the biggest issue is this scenario - player changes maps - loading this >new map takes time, so server is now short on time. Yet because player is >changing maps, a lot of map data is changing, so that is the packet you want >to >compress. > Hmm, that is also quite true, however I don't think that problem is unsolvable. For example, if the average time/tick of the most recent 10 ticks is used instead of just the most recent tick, it might not cause that to happen so much, and things that cause a more constant system load would still make fewer things get compressed. Also, because such a packet would be rather large, if it is just the threshold of what to compress changing, it could still very well compress if it's a rather large one. It might also be possible to measure time used by I/O operations and exempt it, however I believe that is overcomplicated. Yes, some of the 'best' ways of doing this plan are a bit overcomplicated, but I do believe that a simple form could still be effective. Alex Schultz _______________________________________________ crossfire mailing list [email protected] http://mailman.metalforge.org/mailman/listinfo/crossfire
