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

Hello Cisco (guess I'll have to rename myself Juniper just for trolling purposes ;) ).

Actually the MTR shown clearly show packet loss starting from 1 hop and continuing on all hops after that.

Also, when doing the same during the morning (I'm in the same hours than Greece), I didn't see any packet loss, and I use the incriminated link. This is quite indicative of congestion during peak trafic hours.

Checking the GEANT RIPE entry (https://apps.db.ripe.net/search/query.html?searchtext=AS20965), they seem to have quite a few peering links and are also using Level3 as a second upstream provider, so people using these peering or Level3 links would not be affected if the issue is indeed a Cogent - GEANT congestion. That would explain why some people are not affected, and others are.

I'd say many things point toward a congested link in this case :)

I talked to my boss, shoved him this thread and he was totally up for giving buddyspike a server for free for some advertising space on the websites, forums threads and in the server name. I see your name is Buddyspike but im not sure if you are the big boss to talk to?

 

The locations offered are Oslo, Norway (very good latency for being in northern Europe and the best hardware) or Amsterdam, Netherlands (Best latency but not as good hardware as in Oslo, also, if hardware fails it will be slower to repair because we noone down there 24/7)

 

The person in charge of buddy spike can talk to me in TS, my name is Cisco or just send me a PM on the forums. I have never hosted a DCS server before so i would like to talk about hardware and OS requirements.

Hello Cisco. Thanks a ton for the offer. Buddyspike user in this forum is a player in the server but not member of the Buddyspike Team.

We will contact you shortly. Thanks again!

*Buddyspike members are Xcom, Greg, Crash, Ciribob

Whenever I have such kind of problems with customers and their Uplinks I am happy if I have a phone number and service contract that leads you to the right guys that actually have themselves phone numbers and contacts inside the carrier world that they can contact.

As a "normal" customer you have very limited changes to be taken seriously if you you cannot

specify the symptom and best the root cause too (...my packets get dropped at blabla ...etc.. ).

Something your 1st POC can reproduce and verify and may also see that the problem is beyond his network. From their own it really pays if they do this for you, aka have to due to contracts, or if you are then left alone with a unknown big carrier to talk to and say "Hi, ehhh, we loose some of our Pilots every 15min Sir" ....and yes...we are not your customer 1st place "

Usually, if that thing is run at a Uni there are Admins that you can talk to and see if they know of others suffering from the same root cause. If that is the case you have chances to get it solved at home.

If they dont lend you an ear it will be hard to hop up in the ladder and find someone to talk to like "Dave, god damn exchange that ol' Juniper , its causing trouble AGAIN !"

The Above poster Cisco would be someone I`d call if he'd manage our networks on the ISP/DC side. As an administrator for the machine the larger network is not your game if it goes beyond a certain point imho.

One thing...whatever the root cause was, none of those things was fixed in a few days, maybe 1-2 weeks, some took months until the right people reacted tbh.

The fastest way to solve this problem is to SHIP AROUND it..aka host the service somewhere else as you have no direct means to solve it yourself and are very dependant on others good will.

just my 2 cents how to approach it in a timely fast manner

...and then they find out you need a server with dedicated root access, Windows only, doesn't support Virtual machine and requires the minimum spec as per the same client...

Offer withdraws... :)

Sorry to see you having this problem Buddyspike. GWS.

...and then they find out you need a server with dedicated root access, Windows only, doesn't support Virtual machine and requires the minimum spec as per the same client...

 

Offer withdraws... :)

 

Sorry to see you having this problem Buddyspike. GWS.

+100 :(

ED, proper dedicated server is paramount to unified DCSv2 success, tbh.

Is there no other server providing this scenario currently? If not, okay, then it'd be cool to have this but only after or before Round 10 (not during Round 9).

Might not have made myself clear, 1 round at a time.

Finish round 9 and then hopefully we get the Vietnam war scenario :)

There are servers playing MIG21 vs F5 but it is just not the Blue Flag scenario :)

To ciribob (and all of BS team): Do not throw in the towel on this project, i think eveyrone is just frustrated because of the DC issue. But i think i speak for the majority when i say that this is a great project for DCS :D

Or, even better, make it delayed, like 3 or 5 minutes later a message "5 minutes ago, this-and-this happened", so at least fighter pilots know after 5 minutes which pilot they shot down :)

Even better would be kill messages for player only, like in Open Conflict server, 'good kill' and 'you have been killed by player x in y with missile z'.

Great scenario, perfect mission, simple radio use is awesome... but it kept timing me out :(

This chips are the ones who does all the routing and switching, and its all done in hardware, for example, older routers do not support IPv6 because its not supported by the chip.

Wait, the chips were made to NOT be able to understand letters and ":" (IPv6) ? Only numbers and dots? (IPv4) o_O (Are these chips from 1960s or when? :D xD)

The ping you send to the router is slow because it has to send your ping to a piece of shit CPU over the backplane, ...

wait, are you insulting our players' CPUs or whom? (i7 2600k @ 4.5 GHz is quite powerful you know, more than 83 GFLOPs, which it already reaches @ 3.4 GHz)

Or you mean "the boxes that run the ICMP deamon on the routers from 1990s" ?

Didn't they already know that someday IPv4 adresses will run out and new protocol will be integrated?

The locations offered are Oslo, Norway (very good latency for being in northern Europe and the best hardware) or Amsterdam, Netherlands (Best latency but not as good hardware as in Oslo, also, if hardware fails it will be slower to repair because we noone down there 24/7)

Omg you and your boss are awesome!!! Oslo ftw! :D You work for "an ISP" that starts with "C..." and ends with "...isco" btw? :)

Btw. for whoever is interested,

Hey there, i work for an ISP that delivers Dedicated server, Network infrastructure and Colocation. Let me explain to you why your traceroute appears to be dropping packets.

 

In networking the boxes that does the routing are divided into 2 main parts, the linecards and the supervisor. These are physical cards that slot into a big box called a chassis, examples of boxes that does this is Cisco 7600 series "7k's" (7609, 7613, 7604) and Cisco Catalyst "switch" 6500 series (6509, 6513, 6504) where the last number of the series means the chassis size. The chassis of this appliances take max 2, minimum 1 supervisor cards. The supervisor is the brains of the router, it saves the config to flash disks, and runs the services that cannot be accelerated in hardware, like telnet and ssh access. The supervisor also does the job of pushing the routing table out to the linecards, and im pretty sure it runs the daemons for all routing protocols like BGP and OSPF (there are more, protocols but the ones i mentioned are standardized and most common). The supervisor also contains a super low performance RISC or MIPS cpu that does all this, and its very VERY slow.

 

The second part, linecards are the ones who do the heavy lifting, they are the ones that takes traffic on on the 10 gig ports and sends it out on the correct ports so that the traffic gets there. The way the linecards does this so quick is because it uses a very special chip called an ASIC, which stands for Application specific integrated circuit. This chips are the ones who does all the routing and switching, and its all done in hardware, for example, older routers do not support IPv6 because its not supported by the chip. So, why does all of this matter? Well, in your traceroute you send an ICMP packet, a traceroute is just a ping where the hop counter is set very low and the gradually increased. Therefor you are sending a ping where the hop count reaches 0 and the current hop will send the ICMP ping packet back. The thing to note here is that ICMP IS NOT ACCELERATED IN HARDWARE. The ping you send to the router is slow because it has to send your ping to a piece of shit CPU over the backplane, sometimes it just drops it because the CPU has enogh things to do. The reason you have bad latency to the hop is not because the links are congested or because the routing is bad, it just because the boxes that run the ICMP deamon on the routers are from the 1990's. When running MTR you have to make sure that all the hops AFTER where you suspect a loss also increase in latency and loss.

Ah kay, I did knew the general task dividing between linecards and supervisor and also that at theese link speeds its obviously done in hardware, but I honestly would have expected ICMP to be freaggin hardware accelerated ! :D

I mean I run a wild combination of FDDI, ATM, various forms of Ethernet, Fibrechannel, DSSI, memory channel [glorious 1998 memory link where 512mb of RAM are reflected into the RAM of all connected machines, 4 micro seconds latency, yes not miliseconds, 1gbit/s] with mainly old DEC/Compaq Hardware I save from beeing scraped. But that one really surprised me ! :D

That perfectly explains the high packetlos from the GRNET machien in the middle. Since the uni specified something like 2*622mbit/s which sounds some like uneven ATM stuff which really suggests a pretty aged router.

Well came to the conclusion that I have to check behind the PL, if its less then its just router discarding icmp stuff, but I expected it for the wrong reasons. :D Overnight pl for me has stabilised around 2,5% for 30 000 ICMP echos. That should mean stuff should be playable for me.

And indeed, If I ping the first GEANT box, it routes me via 2 link3 boxes in Frankfurt [glorious DE-CIX].

Even better would be kill messages for player only, like in Open Conflict server, 'good kill' and 'you have been killed by player x in y with missile z'.

Exactly!!!

Yes BS, awesome work!!!

I don't think kill messages for air kills would be better, remove them all!

Remove everything from the chat window that gives any form of intel, I can't be the only one that feels that way.

I don't think kill messages for air kills would be better, remove them all!

Remove everything from the chat window that gives any form of intel, I can't be the only one that feels that way.

No you aren't :thumbup:

There is no reason for having intel and specifically kill confirmation messages. Contrary, there are reasons for not having them.

Ah kay, I did knew the general task dividing between linecards and supervisor and also that at theese link speeds its obviously done in hardware, but I honestly would have expected ICMP to be freaggin hardware accelerated ! :D

I mean I run a wild combination of FDDI, ATM, various forms of Ethernet, Fibrechannel, DSSI, memory channel [glorious 1998 memory link where 512mb of RAM are reflected into the RAM of all connected machines, 4 micro seconds latency, yes not miliseconds, 1gbit/s] with mainly old DEC/Compaq Hardware I save from beeing scraped. But that one really surprised me ! :D

That perfectly explains the high packetlos from the GRNET machien in the middle. Since the uni specified something like 2*622mbit/s which sounds some like uneven ATM stuff which really suggests a pretty aged router.

 

Well came to the conclusion that I have to check behind the PL, if its less then its just router discarding icmp stuff, but I expected it for the wrong reasons. :D Overnight pl for me has stabilised around 2,5% for 30 000 ICMP echos. That should mean stuff should be playable for me.

 

And indeed, If I ping the first GEANT box, it routes me via 2 link3 boxes in Frankfurt [glorious DE-CIX].

To add on a subject, since it's the same CPU that handles ICMP messages and real important routing tasks, we very often artificially limit the amount of ICMP packets that will reach the CPU to avoid loading it with not important stuff. This is done via filters, usually. So packet loss on a hop may not indicate anything at all, apart from the fact that this node is getting pinged by too many people and its operators have limited ping bandwidth. But when you keep having packet loss on a route after a certain point, the explanation is more on a saturated link. The probablility of hitting ICMP limits of every hop after the 1st showing PL, and no limit of any hop before, is pretty low.

Shure I had some connection issues on BLUE FLAG, but if it runs it looks like this...

I don't think kill messages for air kills would be better, remove them all!

Remove everything from the chat window that gives any form of intel, I can't be the only one that feels that way.

No you aren't. I also want them removed.

No you aren't. I also want them removed.

I agree they give to much intel. First thing I do when I see zu23 has been killed by XXXX is look to see what farp is being hit.

The intel of gadget and trigger messages is more my type.

Shure I had some connection issues on BLUE FLAG, but if it runs it looks like this...

 

"Some connection issues" is like "a few chinese people in shanghai" right now. Cant connect, cant stay connected.

Sent from my SM-N910P using Tapatalk

As far as kill messages being removed, has something changed where this is possible or have you guys missed the previous discussions where it was stated theyre essential to scripts running properly?

Sent from my SM-N910P using Tapatalk

Yes you may have missed that they fixed the need to display the messages, and the messages were removed at one point in round 9, but came back for some reason.

"Some connection issues" is like "a few chinese people in shanghai" right now. Cant connect, cant stay connected.

 

Sent from my SM-N910P using Tapatalk

Unfortunatly I got some time outs....not more not less. :(

Not happy about it, but what shall I do? :huh:

I know the guys are aware of it! :D

As stated previous page use free VPN like Tunnel Bear.

Yes you may have missed that they fixed the need to display the messages, and the messages were removed at one point in round 9, but came back for some reason.

Outstanding news!

Sent from my SM-N910P using Tapatalk

By the way....

is there any chance to use LotATC within BLUE Flag? :pilotfly:

Regards

Running events since 2013 on the same server, plus 9 rounds of blue flag , including case blue, without connection issues and normal pings (please don't mess disconnects with lag issues) .

Having disconnects for many pilots for five days.

Conclusion : change the server machine and location :doh:

 

Greg

Not to be a dick... but having played rounds and rounds ago... ping hate was all the rage.

Well server location may not be at the heart of the current issues, relocating the server should still be on the table.