Thanks a lot for clearing this up . . . Your feedback brings greater insight to all of us I’m sure . . .
Also . . . I would like to say thanks to you . . . and everyone else for all the work and effort going into making the WUG the exciting experimental platform that it was intended to be - Keep up the good work guys. . .
Getting back to the issues above though . . .
What I’ve notice is that at the time of experiencing packet losses while in Gaming Time, I immediately switched from my game that I was busy playing to windows environment and did the initial tracert which initially displayed packet losses of up to 50% . . . and then would slowly regress and die down to no losses again - Because I had the DNS box ticked just to display the identity (name) of the hops in the trace, the ip addresses was not showing . . . so once I could see which hop number and name (7.dns.puck.ctwug.za.net) was giving issues . . . ,
I stopped the trace and re-started it with DNS box disabled to see what the ip of that hop was so that I could later use this info to log into that rb with ctwug account and continue troubleshooting from there. . .
Which is why only 7 packets can be seen in the screenshot above. . .
Above screenshot displays a round trip of 92 packets sent with only 12 % lost at hop number 7 ==> dns.puck.ctwug.za.net . . .
To my understanding and limited knowledge . . . (please correct me if I’m wrong here )
I derived that the lost packets might have been resend due to the nature and design of the TCPIP Protocol used in data transfer . . . So these packets that was lost in the initial transfer, has now been resend . . .
And due to the connection recovering in the meanwhile, they were successfully resend and accounted for on the receiving end - Hence the losses gets lesser the longer the trace is run . . . Am I correct in saying so ?
So then when I left the tracert running - The packet losses completely disappeared because of this error correction built into TCPIP . . . ( as can be seen from the 113 packets sent in the same tracert that was left to run a bit longer in the screenshot below. . .)
But it still doesn’t explain the cause of the link dropping initially - I would like to suggest maybe having a look at the logs on this nginx server @ 172.26.65.1 to check for issues that might indicate problems that lead to the packet losses at that time - Will be sure to enable time and date stamps on my rb’s winbox next time I post regarding such issues . . .