Author Topic: Friggin Server Burps are getting tiresome  (Read 634 times)

Offline Pfunk

  • Parolee
  • Silver Member
  • ****
  • Posts: 1308
Friggin Server Burps are getting tiresome
« Reply #15 on: January 08, 2003, 05:20:43 PM »
Quote
Originally posted by Greese
Yet no one has posted ping plotter results....

Just blame HTC.  It's easier I guess.



Considering it effects the WHOLE server not just individuals, I would guess to say that individual ping plots will not make a difference.

Offline Vulcan

  • Plutonium Member
  • *******
  • Posts: 9913
Friggin Server Burps are getting tiresome
« Reply #16 on: January 08, 2003, 05:32:40 PM »
Yup its definitely somewhere at the server end. For example plane updates and vox still work fine (I believe UDP), whereas damage updates and server messages lag (possibly TCP?).

Either way it needs sorting. The new guys are having hissy fits, some not understanding whats happening believe they are seeing 'invinsibile' aircraft, rubber bullets, or even cheating.

Its more than guys squeaking on the BBS - theres an impression newbies are getting that will no doubt wind its way out to other potential 'customers'.

Offline 715

  • Silver Member
  • ****
  • Posts: 1835
Friggin Server Burps are getting tiresome
« Reply #17 on: January 08, 2003, 11:18:11 PM »
I've seen this happen many times lately and I have always checked the pings.  It has nothing whatsoever to do with internet traffic: it's entirely host related.  For example- it once took me 4 minutes and 47 seconds to reach the tower after exiting.  During all that time I was at the center of the map seeing accurate plane movements and having a flatline low ping time.  These aren't 'warps' where plane positions are jumpy- those are always smooth.  Its lack of update for less 'critical' data- kills, deaths, things blowing up, exits, text, etc.  

I would jump to the conclusion (not supported with much data) that the new antiwarp code (which works very well to reduce microwarps for close targets) has an algorithm that 'delays' less critical packets to make room for plane position packets. Perhaps this code has a minor bug that allows 'less critical' information to continually get postponed by 'critical' plane packets and put off for way too long.  I suspect it will probably be fixed soon in the host code once they have time to figure it out by looking at logs of high usage periods.

There is no doubt, however, that something is happening at the host end and when it does it is a bit like flying into the Twilight Zone.