[jhb_airlines] Re: Perception of Server Lag

  • From: Alastair <algy.mcintyre@xxxxxxxxxxxx>
  • To: jhb_airlines@xxxxxxxxxxxxx
  • Date: Sat, 23 Sep 2006 10:14:20 +0100

Alex

Your explanation has some ring of truth to it, however, in the old MP days, using a single home based server (or more often than not Rory's server), we were able to achieve reasonable formation flights, albeit sometimes a bit jerky.

All this was achieved using 56k dial up modems.

One would have thought that with the advent of almost universal broadband use that things would have improved.

I must confess, however, on the old MP set-up we used to experience sever lag, at times, sometimes up to about 3 or 4 minutes.

I realise, that here we are not really comparing like with like, however, like you say it would be 'interesting' to try a bit of 'racing' and close formation flying.

Would Sunday or Monday evening be suitable for anyone?, or do we make the Wednesday evening session a test session?

Alastair



Alex - Reheat.org wrote:
Gerry,

Excuse me for drifting in and out of topics and coherent sentence (as is the norm) but allow me to go back a little bit, touching on some of the other emails that have been flitting back and forth.

You may or may not remember that I joined FPI as the UK - Military Operations Coordinator. Having just come from a purely Military network that lost its funding (Fly-Mil.org)

We searched and tested for around 2 months on all the networks (VATSIM, IVAO, Globalsim/Intvas,) and also on our own FDE servers. All in all we chose FPI because the software itself allowed for the fastest data transfer between machines, making it the only organisation suitable for formation flying.

We were flying highly modified payware aircraft, some with literally gigs of data/sound/gauges attached to them (if anyone is a fan of the Handley Page Victor there is a mix and match model available far more advanced than anything PMDG could come up with!) and still we could close to 20 feet within each other and stay stable on a wingtip for hundreds of miles (Marham to Acsension anyone!?)

Over the past 2 years the ability to do this has decreased, the only common factor between all machines is that the net load has increased, I.E the data we are passing to and from our machines over TCP/IP protocols.

I hope you follow that my digression had some bearing on the postings...

My main point being that, yes a complicated aircraft and scenery WILL have some effect on the lag we experience it is much more likely to have an effect if we reduce the ingoing and outgoing traffic. Ideally AV software should be turned off, ActiveSky and anything like that should go.

Might I suggest a test?

Get as many online as possible and have a bit of a drag race, Two people in default Cessna's with all add-on scenery turned off, starting on parallel runways and tuned to a single VOR, both put throttles forward at the same time, engage the AP with the same settings and you should be, give or take a bit, head to head, both of you call out over voice when 5nm from VOR, 2NM etc etc etc. Then repeat the test with a heavy payware aircraft. See just what the difference is? It might be a lot, it might be a little.

But as with all things the only way is to try....and besides, a race sounds kinda fun doesn't it? <G>

Alex

Gerry Winskill wrote:
Re reading your posting, another couple of questions spring to mind:

Is it less demanding to combine sceneries, eg the VFR AIO way? If so then the only significant limitation on the way in which sceneries could be merged would be the existance of duplicate texture names.

The size of the main Texture folder is presumably a factor? If so, then it would pay to keep the non-Default gauge files of each aircraft in that aircraft's Panel folder. Or is it only possible to use .xml gauge files in this way. If it is possible then removing aircraft to storage, until required, would bring an automatic load reduction?

I tripped across another way of increasing load, yesterday. Loading an aircraft I haven't used for some time, I ran through the Shift + number routine, to see what popups were present. I did this because I hate the damned things and normally design them out of my modified displaced panels. Shortly afterwards, with one of the unsophisticated aircraft in use, I noticed an unfamiliar programme ikon, on the task bar. A quick check showed it to be associated with the Palm Top, or whatever it's called. Another way of unwittingly increasing load.

Gerry Winskill



Alex - Reheat.org wrote:

Frank,

In another project I've been involved in there has been much study done on the subject of FS an its "Data Pipes" (an SDK term so excuse its use) and there are many things that can affect it.

FS data, in and out of multi player sessions is hooked into the FS Engine in two different ways, first of all there is the ported data, brought in through direct IP/P2P access such as MP sessions or XML gauges etc directly into the sim.

The second is the background process information, such as that brought in via a plugin module such as Active Sky or another DLL process.

WideFS and FSUIPC are so successful as they are a mix of the two. An external module that can take data from .gau/xml or other DLLs and directly port it through to FS.

The way that FS gives priority to the data coming from these is not 100% understood but as a basic rule the it goes:

Aircraft
XML Gau
Navaids/ GPS Data
Scenery
Ported
Background

There are algorithms in existance that allow the Background data to refresh doubly as quick as the Ported thus giving superior performance to ported data but this also, to an extent, relies on porting.

As Stefan explained it is the FS engines processing of these that causes lag, the hardware processing the data is limited to the CPU/RAM and HDD. This is one area of FS that the Video card comes into very little unless the process is telling FS to "draw" data...which it isn't - it is the MP session telling FS to do that, which will get reasonably high priority anyway.

I bet that made no sense at all...perhaps a diagram would have worked better!

Alex



franklyn fisher wrote:

I wonder if the hardware can also be at fault, for instance

I have an AMD 64/3200 machine with 1gb ram.

But my video card is from a previous machine ( an AMD1600/32bit).

I do realise that the video is holding up my machine, so an upgrade to an ATI X1600ProAGP from an ATI 9600ProAGP (half the speed) should in theory, half the queing time, thus the draw to screen must be quicker. Therefore cutting my server lag?

Other hardware factors could also contribute, but speeding up the video from machine thro to the screen must be a benifit.

Frank F
















------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.12.8/455 - Release Date: 22/09/2006

Other related posts: