ID
Password
FlashGuide
FlashGuide
HA Infomation

General Discussion

  Index

  • Lag Update #4

    02. 22. 2012 00:17


TeamNF_MK2
Hey guys,

This lag situation is driving us nuts. I just want to get that out of the way first.

Ever since your first reports began to come in, we have tried contacting our IDC provider for assistance in fixing this.  Since the reports have been so sporadic (different times of day, different locations), it has been difficult to pinpoint the exact cause. We have also been in contact with our firewall company after receiving data suggesting that an issue may be at that point.

Both companies are now (finally) acknowledging a problem and are complying to fix this. The first step will be to fix our server machine and port with both the IDC and firewall provider.
Our team has notified me that a complete schedule for the fix will be known by tomorrow morning. You will be updated if the schedule will interrupt game play in any way (not that the lag hasn't already done this).

Once this issue has been fully resolved we will consider possible compensation methods.

For the moment, we just want to let you know that we are taking your reports seriously and are making progress on this.

On behalf of the team, I am deeply sorry for any unstable conditions experienced these past few weeks. We are thankful for those of you bearing with us and helping us through this.

-Randy/Mk2

***UPDATE 1***
The schedule has been set. Our team will carry out the work during tonight's regularly scheduled maintenance.

Details of work:
1. 211.43.149.200 server switch port change.
2. Firewall interface change
3. Firewall reboot.

It may be too early to guarantee that this will fix everything completely, but we are optimistic about it helping to improve the conditions. I guess we'll know for certain after tonight.

If issues continue we will take further measures on Friday (I'll provide another update).

***UPDATE 2***
Latest post patch details:

Our IDC and firewall provider worked together as previously scheduled to fix this issue. Results are showing progress, but there is still room for improvement.

Our team is continuing to monitor the reports received on this and have already sent a report to have the server machine completely swapped.

I will provide an update once this happens.

***UPDATE 3***
The server hardware swap is scheduled to take place as soon as possible. This means, it could happen as early as today or as late as 1 or 2 days. This lag situation is our highest priority and the requests for work to fix the issue are being sent as urgent. It will be up to our IDC to follow through.

Our team is also working on the firewall to test several conditions. If conditions do not improve after these actions we will take more drastic measures.

We are all in the same position as you guys; we understand your frustration and hope to fix this as soon as possible. Navy Field is not just a game, but our livelihood. We are doing our best to fix this and are appreciative of your support and understanding during this difficult time. Updates will be provided as soon as available.

***UPDATE 4***
Alright, we have our final schedule set. There is some good news and bad news.

The good news: server hardware change is a GO. Our IDC has tested the software and everything is set. The upgrade should begin at 10PM PST.

The bad news: our IDC predicts the upgrade may take up to 4 hours. We will work to complete the process in as short a time as possible, but for the time being please expect the servers to be down at least from 10PM PST - 1AM.

Thank you for your understanding,

-Randy

 

  • Re : Lag Update #4

    02. 28. 2012 06:29


Hoplita
Originally Posted by basilone

Lag lives on......just tried to play and got significant lag. Even the page loading on here is bad.


Come-one SDE gives us a details

  • Re : Lag Update #4

    02. 28. 2012 06:50


Sanitarium
Long live the LAG.

Greetings from Cyprus

  • Re : Lag Update #4

    02. 28. 2012 06:52


Paximan
why not just check back 4 weeks on the patch and see what could of caused it and fix it. we are rolling into the next month and still no fix cmon Randy we should be getting updates everyday not everyfew days until this is fixed we the community expect updates every day to what is being done to fix the issues


sorry to rant randy
but if this continues i will be seeking refund for all the premium items i have bought this month

  • Re : Lag Update #4

    02. 28. 2012 06:57


ZaGaTo19
i barely can play and im loosing my premium :/
did someone said i want my money back/compensation?

  • Re : Lag Update #4

    02. 28. 2012 07:24


Hoplita
Just sleep your account, and send a support ticked to get premium refund for at-least the last 4 weeks.

  • Re : Lag Update #4

    02. 28. 2012 07:29


Paximan
i will be sleeping all my accounts tonight if we do not get any updates.

randy we should be getting daily updates not every few days. u should be posting everyday on this thread letting us know what fixes will be done that day. if this keeps up there wont be a kaiser server.


just my 2cents

  • Re : Lag Update #4

    02. 28. 2012 08:29


deadlydel
10 minutes just to get the reply page up this is getting a bit silly luckilly were not in the uk or trading standerds would close you down for not providing a service which some off us are paying for through prem subscription your tacking the money and not providing the service that is paid for RANT finished please fix this sooooooon

  • Re : Lag Update #4

    02. 28. 2012 08:34


Allosawyou
silly question this game dies what happens to the olives that are in my acc purchased in good faith do you give me a full rebait!!!!!!!!!!!! fixe this lag pleaseeeeeeeeeeeeeeeeeeeee

  • Re : Lag Update #4

    02. 28. 2012 08:37


Hoplita
9 --- 100/ 100 =100% 85/ 100 = 85% 174.35.18.121
0/ 100 = 0% |
10 --- 100/ 100 =100% 85/ 100 = 85% 174.35.13.230
0/ 100 = 0% |
11 --- 100/ 100 =100% 85/ 100 = 85% 208.80.251.170

25 % Packet lost from those IPS,

“The fraction of lost packets increases as the traffic intensity increases. Therefore, performance at a node is often measured not only in terms of delay, but also in terms of the probability of packet loss…a lost packet may be retransmitted on an end-to-end basis in order to ensure that all data are eventually transferred from source to destination.” [7] The amount of packet loss that is acceptable depends on the type of data being sent. For example, for Voice over IP traffic, the only effect seen due to the occasional dropped packet is jitter, and therefore “[m]issing one or two packets every now and then will not affect the quality of the conversation. Losses between 5% and 10% of the total packet stream will affect the quality significantly.”[8] On the other hand, when transmitting a text document or web page, a single dropped packet could result in losing part of the file, which is where the aforementioned packet retransmission schemes are used.
When given a situation where the amount of content due to be pushed through a connection is growing at a rate greater than it is possible to push through that connection, also known as a bottleneck, then there is no other solution than to drop packets.[9] The TCP protocol is designed with a slow-start connection strategy so that excessive packet loss will cause the sender to throttle back and stop flooding the bottleneck point with data (using perceived packet loss as feedback to discover congestion). [10] The data packets will be transmitted over a longer duration.
There are many methods used for determining which packets to drop. Most basic networking equipment will use FIFO queuing for packets waiting to go through the bottleneck and they will drop the packet if the queue is full at the time the packet is received. This type of packet dropping is calledtail drop. However, dropping packets when the queue is full is a poor solution for any connection that requires real-time throughput. For these types of connections, quality of service and other methods are applied. In some connections, packets may be intentionally dropped in order to slow down specific services for no other reason than to dissuade users from using those services. For this reason, packet loss is not necessarily an indication of poor connection reliability or a bottleneck.
Packet loss is closely associated with quality of service considerations, and is related to the erlang unit of measure.
As a rule of thumb derived from day-to-day practical experience, in general with TCP/IP protocols a packet loss below 0.1% (1 lost packet in every 1000 packets) can be tolerated; anything higher will have more or less impact (depending on circumstances) and needs to be addressed.

ROUTING PROBLEMS ROUTING PROBLEMS! ROUTING PROBLEMS ROUTING PROBLEMS! ROUTING PROBLEMS ROUTING PROBLEMS! ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!ROUTING PROBLEMS ROUTING PROBLEMS!

Now this can't be overlooked.

  • Re : Lag Update #4

    02. 28. 2012 08:41


zanon
worst lag ever :( .

this guys sounds like a wizard so i quote his stuff here .

evil lag from the netherlands t_t
------
Hoplita

Again same issue:

9 --- 100/ 100 =100% 85/ 100 = 85% 174.35.18.121
0/ 100 = 0% |
10 --- 100/ 100 =100% 85/ 100 = 85% 174.35.13.230
0/ 100 = 0% |
11 --- 100/ 100 =100% 85/ 100 = 85% 208.80.251.170

25 % Packet lost from those IPS,

“The fraction of lost packets increases as the traffic intensity increases. Therefore, performance at a node is often measured not only in terms of delay, but also in terms of the probability of packet loss…a lost packet may be retransmitted on an end-to-end basis in order to ensure that all data are eventually transferred from source to destination.” [7] The amount of packet loss that is acceptable depends on the type of data being sent. For example, for Voice over IP traffic, the only effect seen due to the occasional dropped packet is jitter, and therefore “[m]issing one or two packets every now and then will not affect the quality of the conversation. Losses between 5% and 10% of the total packet stream will affect the quality significantly.”[8] On the other hand, when transmitting a text document or web page, a single dropped packet could result in losing part of the file, which is where the aforementioned packet retransmission schemes are used.

When given a situation where the amount of content due to be pushed through a connection is growing at a rate greater than it is possible to push through that connection, also known as a bottleneck, then there is no other solution than to drop packets.[9] The TCP protocol is designed with a slow-start connection strategy so that excessive packet loss will cause the sender to throttle back and stop flooding the bottleneck point with data (using perceived packet loss as feedback to discover congestion). [10] The data packets will be transmitted over a longer duration.

There are many methods used for determining which packets to drop. Most basic networking equipment will use FIFO queuing for packets waiting to go through the bottleneck and they will drop the packet if the queue is full at the time the packet is received. This type of packet dropping is calledtail drop. However, dropping packets when the queue is full is a poor solution for any connection that requires real-time throughput. For these types of connections, quality of service and other methods are applied. In some connections, packets may be intentionally dropped in order to slow down specific services for no other reason than to dissuade users from using those services. For this reason, packet loss is not necessarily an indication of poor connection reliability or a bottleneck.

Packet loss is closely associated with quality of service considerations, and is related to the erlang unit of measure.

As a rule of thumb derived from day-to-day practical experience, in general with TCP/IP protocols a packet loss below 0.1% (1 lost packet in every 1000 packets) can be tolerated; anything higher will have more or less impact (depending on circumstances) and needs to be addressed.


nyerkovic

Please let's focus our efforts in the stickied thread about lag issues. It is best for us all if all concerns are recorded in just 1 place.

Here is the link. Please post there how is the issue for you.

http://fm.en.kupaisky.com/Community/Forum/View.aspx?num=7375&category=C01&searchType=0&searchValue=&pageCount=0&sort=5&page1=1&page=12

- Locked.


-----
AN UPDATE on his post :

ANGER RAGE!! ANGER RAGE ! ANGER RAGE! ANGER ANGER RAGE!!ANGER RAGE!! ANGER RAGE ! ANGER RAGE! ANGER ANGER RAGE!!ANGER RAGE!! ANGER RAGE ! ANGER RAGE! ANGER ANGER RAGE!!ANGER RAGE!! ANGER RAGE ! ANGER RAGE! ANGER ANGER RAGE!!ANGER RAGE!! ANGER RAGE ! ANGER RAGE! ANGER ANGER RAGE!!ANGER RAGE!! ANGER RAGE ! ANGER RAGE! ANGER ANGER RAGE!!ANGER RAGE!! ANGER RAGE ! ANGER RAGE! ANGER ANGER RAGE!!ANGER RAGE!! ANGER RAGE ! ANGER RAGE! ANGER ANGER RAGE!!ANGER RAGE!! ANGER RAGE ! ANGER RAGE! ANGER ANGER RAGE!!ANGER RAGE!! ANGER RAGE ! ANGER RAGE! ANGER ANGER RAGE!!ANGER RAGE!! ANGER RAGE ! ANGER RAGE! ANGER ANGER RAGE!!ANGER RAGE!! ANGER RAGE ! ANGER RAGE! ANGER ANGER RAGE!!ANGER RAGE!! ANGER RAGE ! ANGER RAGE! ANGER ANGER RAGE!!ANGER RAGE!! ANGER RAGE ! ANGER RAGE! ANGER ANGER RAGE!!