microvax

I just posted fresh MTRs.

Glorious. MJ2 is self targeting like the skeets right ? At least the swedish wiki article and the ginormous weight for a submunition indicates that.

Yeah its a pity that record route mostly gets ignored. :/

If I had the same results as you, I would make the same conclusions, but here look at my traceroutes: At peak time the PL got to something like 25%. In the morning [everything before 12] it usually is between 0 and 5%. I dunno how pl looks during peak time ATM. I am not 100% sure that the simultaneous mass disconnects are network related, I am pretty sure its not only network related. But the Problem I had in the beginning and a few other people as well, like singular disconnects without even beeing able to taxi or choose a slot before timeout were pretty surely connected to the Pl right there. Because independant of buddyspike server client count it was correlated to overall PL to buddyspike server.

Tried both in release and open alpha. But it didnt work equally in both versions. I get what you mean, so it does something that can help but its practically not working as it should. :D Sad thing that. Well Razbam has done a stellar job until now, so I guess we will get it working in the future. :)

I have 10-20% PL to the Buddyspike server, from DFN I have 0%. I agree that the 50-80% pl on one router on the way are probably just discarded ICMP packets, but the 10-20%pl pretty much exactly levels out to be the same as the Cogent node connected to the GEANT network. [talking something like 30k requests here] And as forwarding ICMP packets is just the same as forwarding any other IP packet that pretty much matches what I observed and you told about le non hardware implemented ICMP handling.

Am I retarded or is INS position update not working ATM ? Both using OBL and overflight I get polar delta towards the selected WP, but if I press the VAL button, the delta is not used to update the INS. For example if you fix 7nm away from the WP via overflight, press VAL, it should, if I am not missunderstanding things here, shift the INS 00 position and thus lead to the waypoint beeing in the place we just fixed. But nothing changes with pressing VAL. :(

... there is Radars that do over the horizon detection of tanks, there is radar MWS, its not impossible, infact its very possible to detect missile sized targets. So ye, the possibility to build a AWACS Radar which does that kind of jazz is possible, I doubt though it would be considered usefull IRL, since you simply can fit the planes with MWS which doesnt have the slow update rate of an AWACS radar. So yee, if DCS had an option to turn off missile visibility globally that would be cool.

Yee would agree flight attitude. Fluglage in german. )))

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].

It is not _the_ Connection, in the Internet there is not _one_ connection. There is alternative routes. And its often not a question of can not fix as much as there is no need to fix. A fix is usually piece of cake for big networks. Put in another interface or populate another one with additional capacity hooked up to target net, done. Question I cant answer is if on the rounds before ISPs didnt route all over the place or the link simply worked better. As said before, tracing grnet-gws-grnet-gw.mx2.ath.gr.geant.net, which is literally 3 hops totaling 3ms away from the Server, routes through way less hops only totalling to 31ms. Its not that there is no alternative route. They are just not beeing used. And yes that is how the internet does practically work. Sometimes if you have destination C, which is in D, which is reachable via B, and you are coming from A, setting destination D might take you A, B, D, but if you set C as the target it might bounce around the whole alphabet until the packet finds a box which actually knows it can reach C. It shouldn't but often is that way that routes are not optimal, point here is you usually do not notice if you load website xyz, because TCP really is designed to take more then 20%pl ! ;D. tl;dr Its in a good location, IP is designed the way it is, changing server locations because some routes are broken ATM might be a viable option for a enterprise but not for a hobbyist community. Everyone just getting VPN connections to appropriate endpoints would be easier and more sensible then anything else.

My I7 6850K is in love with you ! Gimme all ze threads ! :D

Well its based in Europe, and latency wise they have a stellar connect. Less then 5ms to Cogent. For me its 45ms to Cogent, 89ms to the last hop of cogent and 92 to the server itself. Buddyspike is not to blame at all. They have a good connection and a server which can handle it. Its Murrican pewpew yieeha cowboy ISP inbetween who is messing up all the things. :lol::lol:

Explanation anything buddyspike can do stuff about is fine. Its pretty much in the middle between player ISP and their ISP. So, yee, Not sure who is even to blame if anyone.

Is the RDO one implemented or lemme ask like this, any of the switches on the VTB except the toggle reference waypoint ? Also is the radar memory switch on the radar panel or doppler filter setting planned to be implemented or is DCS radar model simply not accurate enough to implement it in a sensible way.

Ye I know they were initally the same thats why i wrote they are practically the same. :D They got the LST first thought through the ad hoc chinpod. AFAIK, since the bucaneer lazed initially with the tiald iirc.

Tornado GR1 and IDS are practically the same. The GR1 got a laser spot tracker later on, something the IDS never did afaik. GR1 and IDS are limited to unguided weapons apart from ASM and SEAD missiles. British one also has JP233 cluster dispensers which are dedicated anti runway devices, german counterpart is the MW1 which holds much more submunitions, also can be used with anti vehicle and just mine submunition to block off battlefield space. Both got terrain maping radar and terrain following radar which allows any configuration to be run at 200ft radar alt hands off. Tornado is fully FBW which also allows it to fly attack profiles fully automatic. They field modified the TIALD into the GR1 during the gulf war iirc, so it also could laze for itself. GR4 got an build in FLIR in the chin but that isnt used anymore really since later gen targeting pods got integrated. the GR4 didnt initially get modern MFDs for the WSO and also the one for the pilot is just some basic things overlaying the original map projector afaik. Later models got classsic MFDs though. obviously over time the INS got upgrades such as laser ring gyros which reduce drift to a bare minimum and GPS. ECR is the SEAD variant. Having a built in emiter locator system its especially designed against mobile SAM and other RADAR g2a threats. Triangulates the position to keep it simple, which allows it to do real SEAD and just fire the HARM at that area so if a RADAR goes live it will be destroyed or simply never turns on. The GR1 uses the ALARM missile which has comparable lackluster performance to the HARM if you believe the usual reports. Also the GR1 never had an ELS afaik so it could not fire the missiles at a inflight spoted SAM site if the radar did go off. The GR4s later got brimstone, stormshadow and a whole range of GBUs integrated. The IDS got Taurus and GBUs integrated. Thats pretty much what I do know. Given the 3d model is at that detail stage yet its probably an Tornado IDS, since it doesnt have the built in FLIR of an GR4 neither the laser spot tracker of an GR1. And honestly, if we get an early tornado an IDS would be glorious because of the MW1.

routes change. peers change. link capacity changes. That is why. :) "The Internet" is not that everything connected to everything thing you are usually made to believe. Its definitely the cogent part, if your traffic is going through that network. Tried to use the VPN service of my uni, but unfortunately they are oply providing VPN access to their internal net. :DD And yeah I already gave up as well, there is no point to fight a flawed connection.

Thx DanielNLl, yeah your provider doesnt route via cogent, so you do not have the problem thats the final proof pretty much I guess.

Could you provide the full trace ? And for telling where something should be located geographically, whois is your friend, there is DNS records which kinda tell you, but they dont all do that. Its likely that your ISP routes the traffic along the route mine uses for contacting the GRNET box directly. Because now its pretty much obvious its cogent which is probably inducing the PL. Last round most ISPs probably didnt route through COGENT. Case closed IP random routing life. ;D

the GRNET.gr box seems to simply hate icmp echo it forwards fine. the PL is introduced before that box. See muh previous post.

Its not GRNET as Whisper expected. Its also not GEANT. Done from uni network, where it directly goes to GEANT via the german DFN. GEANT is obviously fine, since it takes the exact same last hops and has no PL at all. the GRNET box drops ICMP echo like crazy but forwards them 0 problem so it indeed seems to be cogent. Interesting part was, that If I did tracerouted the GRNET box directly it didnt respond to ICMP echo at all, but the whole Cogent thing was circumvented. So it seems there is different links to GRNET but either they aren announced properly or they are indeed that sparse that simply everything gets routed to Cogent. I guess I can simply connect my router to my uni Network via VPN and route all the traffic for given address space through that. But thats obviously not a solution for everyone. But its literally in the middle between GRNET and everyone else so its pretty much nobodys fault. only thing which is to blame is the way le internet works. RIP.

An ECR would be awesome because its one of the few planes with an ELS. A GR4 would indeed be cool with the brimstones stormshadows and a TGP, but TBH a GR1 would be very cool already and tbh even cooler due to the glorious map projectors. :D And if you have a WSO which fixes the nav for you with Map/radar map overlay, then you really do not need LGBs from 200ft. xD

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.

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.