Operation "Blue Flag" - 24/7 PvP Campaign - ROUND 9

Levanoga, OP says

 

SERVER STATUS : ONLINE FOR TESTING

And Greg literally announced the start of season 9 on page 2 ;) he just has not had the time to edit the frontpage yet

Oh ok... :P sry!

Since the server keeps rebooting is there any chance you could get the 39 radio freqs set? Channel 1 is 264 and the rest are in the 200s.

Thanks for reporting - They will be changed to match this list when we next get a chance:

https://docs.google.com/spreadsheets/d/1LYS-K2EBGBZ1RjD0UGUdOkAXJBGw3mmRQZ2cSsdbJao/edit?pref=2&pli=1#gid=343063148

It's sad that it didn't work for you yet. Will check if there is anything else to look at as there are no changes in the internet connection of the server or so.

Please try one more thing if possible. Lower your graphics (remove HDR etc) and try to see if that improves it. There were some issues connected with fps.

 

Greg

Each red '?' indicates a lost ping packet. Its all the hops from my machine to your server.

Do not mind the reverse DNS resolution. :D

So packets pretty much get lost the last few hops to your server, at a moment when its well outside of my ISPs responsability. So I cant even annoy them to death. :D

here with latency and pl per hop.

So the latency is fine but sometimes stuff gets just dropped which is fairly weird.

It is very obvious that testing should have continued for one more week as the server crashed 3 times in the last 2 hours.

Unfortunate its not due to a feature that can be edited or removed. It's by the numbers of players trying to connect constantly in the background.

Even if we reduce the limit of players, the result is the same as it will be filled quicker and people will try to connect in the background. Problems occur when server gets full and many left outside.

It happens during campaign start day and pick hours.

Greg

Unfortunate its not due to a feature that can be edited or removed. It's by the numbers of players trying to connect constantly in the background.

 

Even if we reduce the limit of players, the result is the same as it will be filled quicker and people will try to connect in the background. Problems occur when server gets full and many left outside.

It happens during campaign start day and pick hours.

 

Greg

Remeber the same happening in Squad early on till it was fixed by the devs guess a fix would have to come from ED in that case

If my brain works correctly all they did to fix it was implementing a queue system

It seems to me that its only the same people that get kicked over and over and over. A lot of us can't even play when we get in because we get the constant connection timeouts. Not saying there is anything you guys can do, just frustrating.

It seems to me that its only the same people that get kicked over and over and over. A lot of us can't even play when we get in because we get the constant connection timeouts. Not saying there is anything you guys can do, just frustrating.

Yup, seems the routes to that network are not properly announced or the link capacities to certain networks are simply completely utilized, which would fit in the good latency but random PL and less PL during non peak time.

But pretty much guesswork without knowing the structure of the network.

At server restart - Update Radios to 1.2.8.1 - https://github.com/ciribob/DCS-SimpleRadioStandalone/releases/latest

It seems to me that its only the same people that get kicked over and over and over. A lot of us can't even play when we get in because we get the constant connection timeouts. Not saying there is anything you guys can do, just frustrating.

Still checking if we can do anything from our part.

Greg

Before we do anything, make sure to repair your DCS and check you don't have any mods running.

Yesterday we were 2 guys trying to play on the blue flag server, first i get disconnected (timed out) after about 15-30 minutes together with about half the server.

I managed to get back in but after about 20 minutes again everyone on the server got disconnected.

FYI :)

Before we do anything, make sure to repair your DCS and check you don't have any mods running.

Did that already, to make sure the "cant join any slot forevar after connect" is not influenced by anything like that.

But if ICMP ping packets are already getting lost, DCS cant do much anyways. Prett ymuch consistant if PL is over 20% it disconnects and below 20% it works more or less.

So apparently switching on the radar in the 21 kills your game and those of other people near you.

So apparently switching on the radar in the 21 kills your game and those of other people near you.

The best way to ragequit ever :doh:

Keep getting connection timed out after 1 min of being in the server.

So apparently switching on the radar in the 21 kills your game and those of other people near you.

is this confirmed, or just a coincidence? :joystick:

is this confirmed, or just a coincidence? :joystick:

afaik its more or less confirmed, but not a problem connected to buddyspike.

EDP71st and 08th red side!

what about all missiles poll?

Anyone else have issues with the comms menu while in-flight in an Mi-8? Last night I noticed it only works when I'm on the ground...while in flight the comm menu kb or joystick shortcut don't work.

So apparently switching on the radar in the 21 kills your game and those of other people near you.

hmmm, you have an approximated range for that ? we might be able to use it as a nuke afterall :D

What's going on with the server disconnects this round? It's pretty bad, either single players getting disconnected or mass groups. It varies from 10 min apart to an hour or two. Also, most people seem to have a significant decrease in FPS this round as well.

I saw Greg say in the other thread that things were changed that were supposed to have helped with connection issues and general performance. From what I've seen and from the other 20-30 people on TS, they are having the same issue of constantly being disconnected. Again, just passing on the info.

What's going on with the server disconnects this round? It's pretty bad, either single players getting disconnected or mass groups. It varies from 10 min apart to an hour or two. Also, most people seem to have a significant decrease in FPS this round as well.

 

I saw Greg say in the other thread that things were changed that were supposed to have helped with connection issues and general performance. From what I've seen and from the other 20-30 people on TS, they are having the same issue of constantly being disconnected. Again, just passing on the info.

Judging by what is happening and what data I was able to collect until now its not anything which is wrong with the server, but the connection.

https://forums.eagle.ru/showpost.php?p=2922298&postcount=29

If everyone had disconnection problems it would be simple. But I have a few people which had 0 disconnects and even said they had better connection then last round.

So, either the link capacity overall changed, which would not explain why some people do not disconnect at all.

Or, what I expect, link capacity to networks most people get routed via was changed or something is simply borked with the announcement of possible routes which arent beeing utilized.

the PL to the server is between 10 and 27%. With 10% the TCP layer can deal quite efficiently but with 20% pl you get into the conditions where you run into protocoll timeouts.

Also pl depends on expected activity in european timezone, so yeah, pretty sure saturated links on the last few hops.

friend of mine did a trace as well, which brought up the same results. I will run MTR from a different network tomorrow and will see how that works out. But I pretty much expect to see the same stuff happening on the last few hops, which could be quite likely be the same.

So literally unless they know someone to poke about the nodes dropping packets there is nothing they can do pretty much. Anything in 147.102.0.0/16 is suffering from that issue.

P.S.: All done with no knowledge of the network the BS is happening on. Could be different.

Okay I did probably more research then necessary, but I have found out a few things.

Server is hosted in the National Technical University Of Athens network. So I checked their site for info about their link to the Internet.

http://www.noc.ntua.gr/index.php?module=ContentExpress&func=display&ceid=14

Last update is a while back but probably not completely outdated.

"The INTERNET connection is made to 10 Gbps through GRNET - GRNET (GRNET has 2CH622 Mbps INTERNET connection - Pan-European Research Internet GEANT)."

Okay, GRNET is some kind of greek networking/VM hosting enterprise which is connected to GEANT, which is some kind of european research network.

​"​GÉANT interconnects research​​​, education an​​​​d innovati​on communities worldwide, with​ secure, high-capacity networks."

So lets have a quick look at the GEANT network maps.

http://www.geant.org/Resources/Documents/topology_map-16OCT15.PDF

http://www.geant.org/Resources/Documents/1142%20Global%20Connectivity_october-2016.pdf

Indeed, seems to be correct.

And indeed my trace goes through the GEANT network, hits GRNET, arrives at the NTUA network and there gets delivered to the buddyspike Server.

The interesting thing is, traffic gets routed through cogentco routers in the USA, which are a pretty big ISP as it seems and probably thats why they have a link to the GEANT network, then hits a node in the UK which seems to be part of the GEANT network but has a link to the GRNET network, even though that is not on the GEANT map. [judging by the reverse DNS "grnet-gws-grnet-gw.mx2.ath.gr.geant.net"]

So from the moment stuff gets routed to the GEANT network PL happens.

Why that is the case is some reaaaal hardcore speculation. The PL we get from the buddyspike server should be the accumulated PL from all the hops that happen before. Since I do not expect the link to the server to be too weak to take a 64byte ping echo per second.

The first address of the NTUA network suffers the same PL pretty much, screenshot is a bad example didnt run it for long enough to even the randomness out.

The GEANT box of cogentco has some pl so probably the link to that thing is operating close to maximum. Now the glorious pl mapping of NTR comes to the rescue to determine which PL really is the main cause for packets to the rescue. MTR fires each ping echo slightly delayed, so one can kinda tell the connection between dropped packets to different hops.

The link to the GEANT box in the USA and from that to the one in the UK seems to be pretty much fine, there is sporadic PL but in general they do not seem to be connected.

[discarding ping packets doesnt have to mean other "important" traffic gets discarded in the same way.]

The one machine which really drops a metric ton of packets is the GRNET box which operates the link to NTUA. So it seems to be the GEANT link between GRNET and the box in the UK, which probably causes most trouble. The box in the UK and or US might play a role, but the peaks seem to be very short, since they do not get carried through to the next hop consistantly and also I dunno how they discard ICMP traffic or not. But its pretty much consistant that the NTUA hop and the Server itself only do not respond IF the GRNET inbetween drops ICMP, so probably that link is saturated.

What does this all mean ?

Well. Since the link between GRNET and NTUA seems to be sufficient, I would blame GRNET for either A not having enough link capacity to the GEANT or B for routing the entire freaggin traffic through GEANT. I mean I cant imagine they only connect to one network. I checked their own webservers, like traffic which 100% isnt for the NTUA also comes through the GEANT.

[Tested from a few web traceroute machines, 4 out of 5 did go through GEANT.]

What also could be the case is that in the GEANT network, none of the routers do reply to ICMP requests, so there is no link from GB GEANT box to GRNET, as one would expect by the link map of GEANT.

In that case, the high PL to the GRNET box could be caused by saturated links INSIDE the GEANT.

So yee, it doesnt get clearer then some internal GEANT stuff or not enough link capacity between GRNET and GEANT.

Main question from me would be why GRNET would be routing all the traffic through GEANT if that is troubled like that.

But again further then this I really cant go with my limited knowledge and no knowledge about the topography of the networks. :D

Later today I can run the trace from uni, which is connected to the DFN, which is direct member of GEANT. That _should_ take the UK and US geant boxes out of the equation and might give an insight if it is something inside GEANT or just the last link between GEANT and GRNET.

Anyone else have issues with the comms menu while in-flight in an Mi-8? Last night I noticed it only works when I'm on the ground...while in flight the comm menu kb or joystick shortcut don't work.

Make sure your trigger is bound to Radio PTT and not Intercom PTT. Then use the trigger to open up the menu.